# 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. ## SFFI — Stabilize a native compression boundary before wider adoption A fictional desktop backup tool calls a small Rust compression library from Node.js. The binding leaks buffers on exceptions and treats ABI mismatches as corrupted input. Build against generated byte arrays and a local native library; no production archive format or user files are supplied. **Field:** Systems programming. **Suggested stack:** Rust, C ABI, Node-API, Sanitizers. **Engineer value:** Practice language-boundary contracts, native resource safety and version negotiation. **Company value:** Review a binding that fails safely and can be rolled back before native code enters additional application paths. **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 - FFI ownership - Binary compatibility - Error handling ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SFFI-101 — Write the buffer ownership table before exposing the binding **Task · Medium priority · Foundational** noCV practice brief v5 · SFFI-101 · Stabilize a native compression boundary before wider adoption 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% · 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. JavaScript and Rust both believe the other side frees an output buffer when conversion throws. Acceptance criteria - Document owner for every input, output, error, and callback value - Each transfer has one release operation and allowed thread - Borrowed memory cannot outlive its originating call Implementation constraints - Do not infer ownership from constness or language garbage collection. Verification - Trace success and error paths through the ownership table. - Inject failure after native allocation and verify exactly one release. Deliverables - FFI ownership contract and allocation counter test Rollout and recovery: Keep the pure-language fallback until every path has an owner. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-102 — Validate lengths before converting JavaScript buffers **Bug · Medium priority · Foundational** noCV practice brief v5 · SFFI-102 · Stabilize a native compression boundary before wider adoption 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% · 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 signed length crosses the C boundary and becomes a very large unsigned value. Acceptance criteria - Binding rejects lengths outside the actual buffer and native type range - Zero-length input follows a documented contract - Conversion failure calls no compression function Implementation constraints - Perform validation on the boundary side that has both pointer and buffer length. Verification - Compress empty, small, and maximum-fixture buffers. - Pass negative-equivalent, oversized, and detached buffers and verify rejection. Deliverables - Length checks and boundary corpus Rollout and recovery: Reject unsupported buffers before enabling the native path. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-103 — Map native errors without losing machine-readable causes **Story · Medium priority · Intermediate** noCV practice brief v5 · SFFI-103 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SFFI-101, SFFI-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · API design 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. Every nonzero native status becomes 'compression failed', hiding whether the caller supplied bad input or the allocator exhausted its cap. Acceptance criteria - Stable public codes distinguish input, capacity, version, cancellation, and internal faults - Native diagnostic text is bounded and treated as untrusted - Unknown statuses map to one safe internal category Implementation constraints - Do not include raw input bytes or native addresses in errors. Verification - Trigger and map each declared native status. - Return an unknown status with oversized text and verify bounded safe mapping. Deliverables - Versioned error map and contract tests Rollout and recovery: Callers must stop branching on old free-form messages before migration. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-104 — Release native output after JavaScript cancellation **Chore · Medium priority · Intermediate** noCV practice brief v5 · SFFI-104 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-101, SFFI-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · Real-time systems 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. The caller abandons a promise while native work finishes later; its output buffer has no remaining JavaScript consumer and is leaked. Acceptance criteria - Operation state records whether a result still has a consumer - Late output is released on the native allocation thread or declared safe path - Cancellation and completion races release once Implementation constraints - Cancellation is cooperative; do not unload code while a native call is running. Verification - Cancel before start and after successful delivery. - Race cancellation with native completion across repeated deterministic schedules. Deliverables - Cancellation cleanup protocol and race tests Rollout and recovery: Keep native concurrency at one until release counts reconcile. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-105 — Move blocking compression off the JavaScript event loop **Task · High priority · Advanced** noCV practice brief v5 · SFFI-105 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-102, SFFI-104. 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 50 MB synthetic buffer blocks timers and health checks because the binding invokes native compression synchronously. Acceptance criteria - Large work runs in a bounded worker pool - Completion returns on the expected runtime thread - Queue saturation rejects before copying the full input Implementation constraints - Measure copy cost separately from compression time and cap fixture size. Verification - Compress concurrent small and large buffers while measuring timer delay. - Saturate the pool and confirm bounded memory with a typed overload result. Deliverables - Asynchronous binding and event-loop latency report Rollout and recovery: Route buffers above a measured threshold first and retain synchronous fallback for small fixtures. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-106 — Negotiate ABI capability before the first compression call **Bug · High priority · Advanced** noCV practice brief v5 · SFFI-106 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-103. Difficulty: Advanced. Estimated focused work: 240 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. A newer binding calls an option function missing from the loaded native library and the process terminates during symbol resolution. Acceptance criteria - Initialization reads ABI version and explicit capability bits - Unsupported required capabilities fail before accepting work - Optional capabilities have documented fallback behavior Implementation constraints - Do not infer ABI compatibility from package version or filename alone. Verification - Load current and compatible older fixture libraries. - Load a library missing a required symbol and fail closed before dispatch. Deliverables - ABI handshake and compatibility matrix Rollout and recovery: Probe in startup readiness while the pure-language provider remains selectable. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-107 — Contain a native panic without pretending the process is safe **Story · High priority · Expert** noCV practice brief v5 · SFFI-107 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SFFI-103, SFFI-106. Difficulty: Expert. Estimated focused work: 360 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. Malformed options trigger a Rust panic that crosses the C ABI and aborts the Node process. Acceptance criteria - FFI entry points catch supported unwind cases before the ABI boundary - Panic maps to an internal fault with operation identity - Abort-configured builds are identified and isolated out of process Implementation constraints - Do not claim catch_unwind protects memory after arbitrary native corruption. Verification - Trigger a controlled recoverable panic and map its result. - Select an aborting fixture provider and require process-isolation policy instead of in-process execution. Deliverables - Panic-boundary policy and controlled failure fixtures Rollout and recovery: Keep risky codecs behind an external process provider until their failure mode is qualified. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-108 — Compare native output against the compatibility oracle **Chore · High priority · Advanced** noCV practice brief v5 · SFFI-108 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SFFI-105, SFFI-106. Difficulty: Advanced. Estimated focused work: 240 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. The native path is faster but emits archives the existing decompressor accepts differently around empty blocks. Acceptance criteria - Golden corpus defines byte compatibility or declared semantic compatibility - Both providers round-trip every supported case - Differences are classified before rollout Implementation constraints - Use generated non-sensitive bytes and pin provider versions in the report. Verification - Compare providers across corpus sizes and option combinations. - Inject a one-byte divergence and show the gate blocks promotion. Deliverables - Differential harness and compatibility report Rollout and recovery: Canary only corpus classes with reconciled outputs. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-109 — Unload a retired native revision only after callbacks drain **Task · High priority · Expert** noCV practice brief v5 · SFFI-109 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SFFI-104, SFFI-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 60% · Platform 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. Hot replacement unloads the old library while an asynchronous completion callback still points into its code. Acceptance criteria - Each operation pins one library revision through callback completion - Retirement blocks new calls and observes active reference count - Deadline reports unresolved references without forced unload Implementation constraints - Prefer process restart for platforms that cannot guarantee safe dynamic unloading. Verification - Run old and new revisions concurrently, then retire the old after drain. - Hold one completion callback and verify unload does not occur at the deadline. Deliverables - Revision lifetime protocol and delayed-callback test Rollout and recovery: Use process replacement as the default until in-process retirement is proven for the target platform. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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. #### SFFI-110 — Package the native binding with a reversible compatibility gate **Bug · Medium priority · Intermediate** noCV practice brief v5 · SFFI-110 · Stabilize a native compression boundary before wider adoption Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SFFI-107, SFFI-108, SFFI-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Systems programming 70% · DevOps 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 package publish selects the native binary by platform name but ignores CPU features and libc compatibility. Acceptance criteria - Artifact metadata binds OS, architecture, ABI, runtime, and required CPU features - Installer rejects an incompatible binary before load - Pure-language fallback selection is explicit and observable Implementation constraints - Do not download or execute binaries outside the generated local fixture set. Verification - Select each compatible fixture artifact and report its identity. - Present wrong architecture, ABI, and feature metadata and verify safe fallback. Deliverables - Artifact selector, compatibility cases, and rollback note Rollout and recovery: Publish metadata and fallback behavior before enabling native-by-default selection. Project prerequisites: FFI ownership Binary compatibility Error handling Engineer value: Practice language-boundary contracts, native resource safety and version negotiation. Company value: Review a binding that fails safely and can be rolled back before native code enters additional application paths. 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.