Load a new runtime revision without changing in-flight programs
Reloading the opcode table mutates a global registry while workers execute programs validated under the old table.
- Focused work estimate
- 6h + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Versioned runtime · Concurrency · Immutability
Estimated field mix
- Systems programming70%
- Platform engineering30%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- SingletonRemove
Replace the mutable process-wide opcode registry with immutable runtime revision snapshots bound explicitly to each execution.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional rules engine executes a tiny arithmetic bytecode over synthetic integers. Its interpreter trusts jump offsets and can run forever. Build a local Rust runtime; it has no filesystem, network, dynamic loading, host calls, or candidate-source execution.
Setup prerequisites
- Stacks
- Instruction decoding
- Control flow
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- SRUNTIME-101 · Decode instructions without reading past the bytecode buffer
- SRUNTIME-102 · Validate stack depth across both sides of a branch
- SRUNTIME-103 · Reject jumps that land inside instruction operands
- SRUNTIME-104 · Report integer overflow instead of changing arithmetic by build mode
- SRUNTIME-105 · Stop infinite programs with a deterministic instruction budget
- SRUNTIME-107 · Cache validated programs without confusing bytecode revisions
- SRUNTIME-108 · Make runtime faults useful without leaking input values
Acceptance criteria
- Each execution binds one immutable runtime revision
- New programs select only fully initialized revisions
- Retirement waits for in-flight references without blocking unrelated execution
Implementation constraints
- Avoid a mutable Singleton registry; publish immutable snapshots through explicit ownership.
Verification to include
- Run old and new program revisions concurrently and verify their semantics.
- Attempt a partial revision load and confirm no execution can select it.
Deliverables
- Revision registry, concurrent load test, and retirement protocol
Rollout and recovery
Publish one synthetic revision behind an explicit selector and retain rollback to the prior snapshot.
Value of the work
For the engineer: Practice runtime invariants, validation, resource accounting and compatibility.
For the team: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.