# noCV engineering task library Content version 5 Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs. Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence. ## SRUNTIME — Evolve a bounded bytecode runtime without executing host code 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. **Field:** Systems programming. **Suggested stack:** Rust, Bytecode fixtures, Property tests, Fuzzing. **Engineer value:** Practice runtime invariants, validation, resource accounting and compatibility. **Company value:** Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. **Delivery agreement:** Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note. ### Setup prerequisites - Stacks - Instruction decoding - Control flow ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SRUNTIME-101 — Decode instructions without reading past the bytecode buffer **Task · Medium priority · Foundational** noCV practice brief v5 · SRUNTIME-101 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Compiler and language tooling 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A truncated PUSH instruction reads its operand from bytes beyond the supplied program. Acceptance criteria - Decoder checks opcode and operand length before advancing - Unknown opcodes return a stable offset and code - Failure exposes no partially decoded instruction Implementation constraints - Keep bytecode length bounded before parsing. Verification - Decode a program containing every documented instruction. - Truncate at every byte and confirm deterministic errors without panic. Deliverables - Checked decoder and truncation matrix Rollout and recovery: Reject programs not validated by the new decoder. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### SRUNTIME-102 — Validate stack depth across both sides of a branch **Bug · Medium priority · Foundational** noCV practice brief v5 · SRUNTIME-102 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SRUNTIME-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Compiler and language tooling 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. One branch pushes a value and the other does not, so the merge point underflows only for certain inputs. Acceptance criteria - Validator computes required and resulting depth per instruction - Control-flow merges require compatible stack shape - Maximum stack depth is bounded before execution Implementation constraints - Validation must terminate on loops through a visited-state worklist. Verification - Validate a diamond control flow with matching stack shapes. - Change one branch to omit a push and reject the merge. Deliverables - Stack-shape validator and branch fixtures Rollout and recovery: Keep runtime stack checks even after static validation. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### SRUNTIME-103 — Reject jumps that land inside instruction operands **Story · Medium priority · Intermediate** noCV practice brief v5 · SRUNTIME-103 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SRUNTIME-101, SRUNTIME-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Security 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A crafted jump targets the second byte of a literal and reinterprets it as an opcode. Acceptance criteria - Decoder records every legal instruction boundary - Jump targets must reference a boundary in the same program - Backward jumps remain permitted within the execution budget Implementation constraints - Do not normalize invalid offsets to the nearest instruction. Verification - Execute forward and backward jumps to valid boundaries. - Target each byte inside a multi-byte operand and reject validation. Deliverables - Boundary-indexed control-flow validation Rollout and recovery: Invalidate cached programs when the instruction format version changes. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Control resources and concurrency Implement bounded behavior under realistic interleavings. #### SRUNTIME-104 — Report integer overflow instead of changing arithmetic by build mode **Chore · Medium priority · Intermediate** noCV practice brief v5 · SRUNTIME-104 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Quality engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Debug builds trap on addition overflow while optimized builds wrap, producing different rule outcomes. Acceptance criteria - Arithmetic semantics are identical across build profiles - Overflow returns a typed runtime fault with instruction offset - Division defines zero and minimum-value edge cases Implementation constraints - Use checked operations; do not expose floating-point values in this bytecode revision. Verification - Evaluate boundary-safe addition, subtraction, multiplication, and division. - Exercise every overflow boundary and division by zero in both profiles. Deliverables - Arithmetic contract and profile-parity tests Rollout and recovery: Version any intentional arithmetic semantic change. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### SRUNTIME-105 — Stop infinite programs with a deterministic instruction budget **Task · High priority · Advanced** noCV practice brief v5 · SRUNTIME-105 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-103, SRUNTIME-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Security 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A backward jump with an always-true condition consumes a worker indefinitely. Acceptance criteria - Caller supplies a positive maximum instruction count - Every executed instruction consumes budget - Exhaustion returns current offset and no successful result Implementation constraints - Wall-clock timeout can be defense in depth but is not the deterministic oracle. Verification - Run a terminating loop at exactly the declared budget. - Run an infinite loop and verify failure at the same step in repeated executions. Deliverables - Instruction metering and loop-bound tests Rollout and recovery: Begin with a conservative budget and expose exhaustion separately from invalid bytecode. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### SRUNTIME-106 — Bound heap-like values without adding a garbage collector **Bug · High priority · Advanced** noCV practice brief v5 · SRUNTIME-106 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-102, SRUNTIME-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Performance engineering 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A proposed LIST instruction allocates on every loop iteration and the prototype retains all intermediate values. Acceptance criteria - Compare arena reset, reference counting, and no-list alternatives for the bounded language - Chosen design defines maximum live bytes and value count - Budget failure releases all runtime-owned allocations Implementation constraints - Do not introduce tracing collection without a workload and cycle requirement that needs it. Verification - Evaluate a bounded list program and reconcile peak live bytes. - Allocate until the value budget and confirm clean failure without leaks. Deliverables - Memory strategy decision and bounded-value prototype Rollout and recovery: Keep LIST disabled until the memory contract is accepted. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### SRUNTIME-107 — Cache validated programs without confusing bytecode revisions **Story · High priority · Expert** noCV practice brief v5 · SRUNTIME-107 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SRUNTIME-103, SRUNTIME-105. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Compiler and language tooling 40%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. A cached validation result for version one is reused after an opcode gains a wider operand in version two. Acceptance criteria - Cache identity binds exact bytes, bytecode version, validator version, and limits - Validation failure is not cached across a newer validator - Hash collision handling cannot return another program Implementation constraints - Cache entries contain immutable validated metadata and bounded program bytes only. Verification - Reuse one validated program under identical authority. - Change each identity dimension and require a miss; inject a key collision and compare bytes. Deliverables - Versioned validation cache and collision tests Rollout and recovery: Enable read-through caching after hit/miss telemetry reconciles with validation calls. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. ### Prove recovery and handoff Measure, diagnose and safely replace the component. #### SRUNTIME-108 — Make runtime faults useful without leaking input values **Chore · High priority · Advanced** noCV practice brief v5 · SRUNTIME-108 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SRUNTIME-104, SRUNTIME-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Privacy engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Fault logs dump the full operand stack, which may later contain customer-derived values, while omitting the bytecode revision needed for diagnosis. Acceptance criteria - Fault records contain code, instruction offset, runtime version, and bounded trace identity - Operand values and full program bytes are excluded - Repeated identical faults aggregate under bounded dimensions Implementation constraints - Use synthetic values in the exercise and keep generic analytics content-free. Verification - Produce each fault class and reconcile its diagnostic fields. - Push a sentinel value and confirm it appears in no log or metric. Deliverables - Redacted runtime fault schema and tests Rollout and recovery: Replace verbose stack dumps before adding any non-synthetic inputs. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### SRUNTIME-109 — Load a new runtime revision without changing in-flight programs **Task · High priority · Expert** noCV practice brief v5 · SRUNTIME-109 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SRUNTIME-107, SRUNTIME-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Platform engineering 30%. 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: Singleton (remove). Singleton — Remove: Replace the mutable process-wide opcode registry with immutable runtime revision snapshots bound explicitly to each execution. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Reloading the opcode table mutates a global registry while workers execute programs validated under the old table. 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 - 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. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence. #### SRUNTIME-110 — Fuzz the runtime under fixed memory and step limits **Bug · Medium priority · Intermediate** noCV practice brief v5 · SRUNTIME-110 · Evolve a bounded bytecode runtime without executing host code Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SRUNTIME-105, SRUNTIME-106, SRUNTIME-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Quality engineering 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Random bytecode tests occasionally hang or consume the test host, so the suite is disabled in continuous integration. Acceptance criteria - Harness caps input bytes, instructions, value memory, and wall-clock defense - Every failure records a minimized reproducible seed - Crash, panic, timeout, and semantic disagreement are distinct outcomes Implementation constraints - Run only the capability-free local runtime; never execute generated host code. Verification - Replay the checked-in seed corpus with deterministic results. - Seed malformed loops and oversized allocations and confirm bounded termination. Deliverables - Bounded fuzz harness and minimized regression corpus Rollout and recovery: Start with a short deterministic CI corpus and schedule longer local runs separately. Project prerequisites: Stacks Instruction decoding Control flow Engineer value: Practice runtime invariants, validation, resource accounting and compatibility. Company value: Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities. AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior. Planning status does not create Outcome Evidence or Ownership Evidence.