# 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. ## SMEM — Repair a packet arena before it becomes shared infrastructure A fictional telemetry collector copies decoded packet fields into a small native arena. The prototype misaligns wide values and reuses memory while readers still hold views. Create a local Rust crate or C library with generated byte fixtures; no device traffic or production allocator replacement is supplied. **Field:** Systems programming. **Suggested stack:** Rust or C, Property tests, AddressSanitizer or Miri. **Engineer value:** Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. **Company value:** Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. **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 - Pointers and slices - Integer overflow - Memory alignment ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SMEM-101 — Specify aligned arena offsets without relying on host luck **Task · Medium priority · Foundational** noCV practice brief v5 · SMEM-101 · Repair a packet arena before it becomes shared infrastructure 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 80% · Embedded and edge 20%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Eight-byte fields happen to work on one machine because the backing buffer begins aligned; a sliced buffer starts at an odd address. Acceptance criteria - Round every allocation to its declared power-of-two alignment - Reject zero and unsupported alignments - Report requested size and remaining capacity without exposing addresses Implementation constraints - Use checked integer arithmetic before changing the cursor. Verification - Allocate mixed one-, four-, and eight-byte records and verify every offset. - Start near the numeric limit and confirm overflow leaves the cursor unchanged. Deliverables - Arena layout contract and boundary tests Rollout and recovery: Keep the current copy path until the layout suite passes on two target architectures. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-102 — Return exhaustion without handing out a partial slice **Bug · Medium priority · Foundational** noCV practice brief v5 · SMEM-102 · Repair a packet arena before it becomes shared infrastructure 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% · Performance 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. A capacity miss advances the arena cursor before returning an error, so the following small allocation also fails. Acceptance criteria - An exhausted allocation returns a typed capacity error - Cursor and prior bytes remain unchanged after failure - A later fitting allocation can still succeed Implementation constraints - Do not grow the backing region or panic on caller-controlled sizes. Verification - Fill the arena exactly and inspect the final valid allocation. - Request one byte too many, then allocate a smaller record and verify state. Deliverables - Atomic allocation update and exhaustion regression Rollout and recovery: Treat exhaustion as backpressure in the local collector; never retry without changing capacity or workload. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-103 — Invalidate borrowed packet views when the arena resets **Story · Medium priority · Intermediate** noCV practice brief v5 · SMEM-103 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SMEM-101, SMEM-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 decoder stores a view into the arena across reset and later reads bytes belonging to a different packet. Acceptance criteria - Views carry the generation in which they were created - Reset advances generation before storage is reused - Stale view access fails deterministically in the safe API Implementation constraints - Keep unsafe reads inside one reviewed boundary; do not claim runtime checks prove arbitrary raw pointers safe. Verification - Read several current-generation views before reset. - Reset, reuse the same offset, and reject the older view. Deliverables - Generation-bound view API and stale-view reproduction Rollout and recovery: Migrate the decoder through the checked view API before enabling reset reuse. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-104 — Free large spill blocks without double-releasing arena pages **Chore · Medium priority · Intermediate** noCV practice brief v5 · SMEM-104 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-102. 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. Oversized records spill to separate blocks. Error cleanup releases a spill block, then arena teardown releases the same block again. Acceptance criteria - Each spill block has one recorded owner - Cleanup is safe when invoked repeatedly - Arena teardown releases only blocks still attached Implementation constraints - Model ownership explicitly; a boolean freed flag cannot authorize access after release. Verification - Allocate and release several spill blocks in different orders. - Inject a decode error after spill allocation and run teardown twice under a memory checker. Deliverables - Spill ownership model and double-free regression Rollout and recovery: Disable spill allocation if the checker reports any invalid release. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-105 — Coalesce adjacent free spans without corrupting the index **Task · High priority · Advanced** noCV practice brief v5 · SMEM-105 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-101, SMEM-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 75% · Quality engineering 25%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The free-span list merges with the previous range but forgets the next range, leaving overlapping entries that can be allocated twice. Acceptance criteria - Free spans remain ordered, nonoverlapping, and maximal - Freeing in any order yields the same canonical span set - Double-free and out-of-range spans are rejected Implementation constraints - Update the span index under one mutation boundary and preserve the arena on validation failure. Verification - Free three adjacent blocks in all six orders and compare the final index. - Attempt an overlapping release and prove no index entry changes. Deliverables - Canonical coalescing algorithm and permutation tests Rollout and recovery: Run shadow invariant checks in the local benchmark before using reclaimed spans. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-106 — Bound fragmentation before adding a more complex allocator **Bug · High priority · Advanced** noCV practice brief v5 · SMEM-106 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-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. The team proposes size classes after one trace shows poor reuse, but the trace mixes long-lived metadata with short-lived packet records. Acceptance criteria - Measure internal and external fragmentation separately - Replay at least three declared lifetime distributions - Compare reset-only, free-list, and size-class approaches with correctness held constant Implementation constraints - Do not select an allocator from mean throughput alone; retain raw workload seeds and peak memory. Verification - Reproduce each workload and its fragmentation measurements. - Change the seed and show the report identifies noncomparable runs. Deliverables - Allocator comparison with workload manifest Rollout and recovery: Adopt additional complexity only if the declared workload crosses an agreed bound. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-107 — Contain unsafe decoding behind a length-checked cursor **Story · High priority · Expert** noCV practice brief v5 · SMEM-107 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SMEM-103. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Security 35%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. Several parsers perform pointer arithmetic independently; one reads a declared payload length before confirming those bytes remain. Acceptance criteria - One cursor owns offset advancement and remaining-length checks - Primitive reads define endianness and alignment behavior - A failed read returns no partially initialized value Implementation constraints - Fuzz only the local parser process and cap input length, nesting, and execution time. Verification - Decode a complete packet containing every primitive type. - Truncate at every byte boundary and run the corpus under sanitizer or Miri. Deliverables - Checked decode cursor, fuzz corpus, and unsafe-boundary note Rollout and recovery: Route one packet family at a time through the cursor and retain the prior decoder for comparison. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-108 — Expose arena pressure without logging packet contents **Chore · High priority · Advanced** noCV practice brief v5 · SMEM-108 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SMEM-102, SMEM-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Site reliability 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. Operators can see allocation failures only in verbose decoder logs that include synthetic payload bytes and unbounded record labels. Acceptance criteria - Publish bounded counters for allocations, spills, resets, and exhaustion - Record capacity and high-water mark without payload content - Reject unbounded caller-provided metric dimensions Implementation constraints - Metrics are diagnostic observations for this component, not proof of production capacity. Verification - Drive allocations and reconcile counters with the deterministic workload. - Supply a unique record label per request and confirm it cannot become a dimension. Deliverables - Bounded arena telemetry and reconciliation test Rollout and recovery: Enable metrics before changing allocation policy; remove verbose payload logging. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-109 — Recover a persisted arena snapshot only when its layout matches **Task · High priority · Expert** noCV practice brief v5 · SMEM-109 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SMEM-105, SMEM-107. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 65% · Storage systems 35%. 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 warm-start experiment maps a snapshot written by an older layout and interprets its free-list metadata as current records. Acceptance criteria - Snapshot header binds format version, byte order, size, and checksum - Recovery validates every offset before exposing records - Unknown versions fail closed without modifying the snapshot Implementation constraints - Use generated snapshots only; memory mapping does not make untrusted offsets safe. Verification - Write and restore a current snapshot with identical logical records. - Corrupt each header field and one nested offset, then confirm rejection. Deliverables - Versioned snapshot reader and corruption matrix Rollout and recovery: Keep cold reconstruction as the default until compatible recovery is repeatable. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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. #### SMEM-110 — Hand off the arena with explicit reasons not to use it **Bug · Medium priority · Intermediate** noCV practice brief v5 · SMEM-110 · Repair a packet arena before it becomes shared infrastructure Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SMEM-106, SMEM-108, SMEM-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Developer 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 second team wants the arena for long-lived session objects even though reset semantics and spill behavior were designed for packet batches. Acceptance criteria - Document supported lifetimes, alignment, capacity, thread-safety, and reset rules - List measured bounds and unresolved risks with reproduction commands - Include rejection examples for workloads better served by standard allocation Implementation constraints - Do not present local benchmark results as universal performance claims. Verification - Have a reviewer reproduce one supported workload from a clean checkout. - Apply the documented long-lived workload and confirm the guide recommends against adoption. Deliverables - Usage contract, decision record, and reproducible handoff Rollout and recovery: Require a separate review before any new workload adopts the component. Project prerequisites: Pointers and slices Integer overflow Memory alignment Engineer value: Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics. Company value: Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code. 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.