f0d695ec97
Save the current implementation and README, status, and known-issue documentation at the user-requested stop. No completed release or deployment is claimed. Co-Authored-By: Claude <noreply@anthropic.com> Co-Authored-By: GPT-6 Codex <noreply@openai.com>
3.7 KiB
Authoring preparation
An optional WarmWorkerPreparation provider receives only coordinator-verified immutable bundle bytes, their SHA-256, the original .ts entry point and toolchain identity. It receives no actor, record data, capability token or invocation. The SPI is not a qualification or readiness guarantee.
Explicit test/context-test, publish, bind and enabling an existing binding may prepare code before dispatch or mutation. Draft saving, compilation, ordinary execution and record hooks never prepare code. Preparation refuses ambient transactions and recursive worker/preparation callbacks. The service rechecks the original session/instance/provider, current actor permissions, native project/target access, signature and exact build/artifact/publication association after external preparation and again at the dispatch/write boundary. Preparation failure leaves existing publication activation and bindings intact. Partial remote warming may safely remain, since it grants no authority.
PersistentWorkerProvider(Configuration) retains source compatibility and prepares one copy. The additive (Configuration, int preparationCopies) constructor accepts only 1 through the configured execution connection count. The SPI checks the operator toolchain and delegates to the existing bounded cold admission/deadline path; the operator profile is pinned by the existing authenticated handshake. Warm execute has no new fallback or cold work. Non-cache providers continue using the existing lifecycle without implementing this SPI.
No new table, registry, queue or runtime is introduced. Native startup/reconnect reconciliation is now implemented separately in WARM-LIFECYCLE.md; deployed cache capacity/eviction and supervisor qualification remain gates; publication does not promise perpetual residency or a functioning compiler. A miss still refuses rather than silently compiling inside a record write.
Verified on 2026-10-31: focused 48 tests passed with normal loopback access (11 new authoring cases, 12 TLS transport cases, 25 existing lifecycle/hook/context cases), followed by the full 173-test main suite with zero failures/errors/skips, Checkstyle and configured coverage gates. Main JAR SHA-256: B1F62E12FA4BFC5884AEF0E20DCD9217EEAEBA86F8D992BEF619CFF490039778. No install or deployment occurred.
The evidence preserves five separate runs: initial import-order Checkstyle failure; restricted-loopback focused run (48 tests, 2 failures and 7 errors); unchanged single TLS case under normal loopback access (1 pass); normal-loopback focused suite (48 pass); full main verify (173 pass). The environment control did not change TLS settings or assertions. Logs and their exact hashes distinguish these scopes; a passing retry is not represented as a product TLS fix.
Preparation rechecks existing native credential/client-channel write ceilings before transfer and afterward. Enabling a binding also pins its capabilities JSON. A callback that installs an unexpected ambient transaction is refused and the original absent ambient reference is restored without committing, rolling back or closing that collaborator-owned transaction. If preparation itself throws, that primary failure is preserved.
The source/JAR and filtered-log evidence is sealed separately in docs/evidence/authoring-preparation-20261031-1050. Full raw logs remain local at the hashed paths; they are not copied into the proof because framework diagnostics can include synthetic session identifiers. Prior 161-test/JFR bundles remain unchanged. Native service/mutual-TLS tests do not qualify runtime isolation, Kubernetes readiness or a durable database deployment; separate fixed trusted Wasm trials are not production qualification.