# 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. ## SKERNEL — Build an operating-system boundary that fails predictably A fictional local agent watches generated inbox files and schedules bounded processing. Direct system calls are scattered across the code, mishandle interrupted operations, and make tests platform-dependent. Build a Rust OS adapter with temporary fixture directories; no kernel module, elevated privilege, or production host modification is required. **Field:** Systems programming. **Suggested stack:** Rust, Filesystem APIs, Polling adapter, Temporary directories. **Engineer value:** Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. **Company value:** Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. **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 - System calls - File descriptors - Monotonic clocks ### Establish the machine contract Make representation, ownership and failure boundaries explicit. #### SKERNEL-101 — Read a file completely across short system calls **Task · Medium priority · Foundational** noCV practice brief v5 · SKERNEL-101 · Build an operating-system boundary that fails predictably 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% · Storage 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 adapter assumes one read fills the requested buffer and silently truncates a generated manifest after an injected short read. Acceptance criteria - Loop until EOF, declared length, or typed error - Return bytes already read only when the contract permits partial results - Zero-progress reads cannot spin forever Implementation constraints - Use a controllable local read adapter; never require privileged system-call interception. Verification - Read the same manifest through one-byte and irregular chunk schedules. - Return zero progress before EOF and confirm bounded failure. Deliverables - Complete-read primitive and short-read tests Rollout and recovery: Route manifest reads through the helper before larger files. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-102 — Write a durable replacement without exposing a half file **Bug · Medium priority · Foundational** noCV practice brief v5 · SKERNEL-102 · Build an operating-system boundary that fails predictably 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 60% · Storage systems 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 crash between truncation and write leaves the agent configuration empty. Acceptance criteria - Write to a unique file in the destination directory - Flush file content before atomic replacement where the platform supports it - Document directory durability and unsupported-platform behavior Implementation constraints - Preserve permissions intentionally and reject symlink destination surprises. Verification - Replace an existing fixture and observe either old or complete new content. - Interrupt before rename and confirm the destination remains unchanged. Deliverables - Atomic-replace adapter and interruption cases Rollout and recovery: Retain backups only under an explicit bounded retention policy. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-103 — Retry interrupted calls without hiding cancellation **Story · Medium priority · Intermediate** noCV practice brief v5 · SKERNEL-103 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish the machine contract. Depends on: SKERNEL-101. 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. Every interrupted call is retried automatically, so a cancelled operation keeps waiting after shutdown begins. Acceptance criteria - Retry only declared interrupt errors - Check cancellation and deadline between attempts - Preserve noninterrupt error identity Implementation constraints - Retry policy belongs beside the operation contract, not in a catch-all error loop. Verification - Inject two interrupts followed by success before deadline. - Cancel between interrupts and verify no further system call is attempted. Deliverables - Interrupt-aware retry helper and cancellation tests Rollout and recovery: Adopt per operation after its retry safety is reviewed. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-104 — Keep wall-clock changes out of elapsed-time deadlines **Chore · Medium priority · Intermediate** noCV practice brief v5 · SKERNEL-104 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: No preceding ticket. 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. An NTP correction moves wall time backwards and extends a file-processing deadline by several minutes. Acceptance criteria - Elapsed deadlines use an injected monotonic clock - User-facing timestamps remain UTC wall time - Conversion between the two clock domains is prohibited Implementation constraints - Tests advance fake clocks; they do not alter the host clock. Verification - Expire a deadline through monotonic advancement. - Move wall time forward and backward and prove elapsed behavior is unchanged. Deliverables - Clock boundary and time-jump tests Rollout and recovery: Migrate deadline call sites before changing displayed timestamps. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-105 — Normalize watcher bursts into a bounded rescan request **Task · High priority · Advanced** noCV practice brief v5 · SKERNEL-105 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SKERNEL-102, SKERNEL-104. Difficulty: Advanced. Estimated focused work: 240 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. One editor save produces create, rename, and modify events; the agent processes the same file three times and misses changes after queue overflow. Acceptance criteria - Events trigger idempotent directory reconciliation rather than direct truth - Burst coalescing has a maximum delay - Overflow schedules a full bounded rescan and remains visible Implementation constraints - Do not promise identical watcher events across operating systems. Verification - Replay create-via-rename and direct-write event sequences with one final reconciliation. - Overflow the event buffer and confirm a rescan restores the fixture state. Deliverables - Watcher reconciliation loop and platform event fixtures Rollout and recovery: Keep periodic scans as a fallback during watcher rollout. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-106 — Bound open descriptors while scanning a deep inbox **Bug · High priority · Advanced** noCV practice brief v5 · SKERNEL-106 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SKERNEL-101, SKERNEL-105. Difficulty: Advanced. Estimated focused work: 240 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. Recursive scanning opens every subdirectory before closing any, exhausting the process descriptor limit. Acceptance criteria - Traversal has an explicit descriptor and work-queue bound - Directory handles close on success, skip, and error - Unreadable entries are reported without aborting unrelated roots Implementation constraints - Use a generated tree and configured low limit; do not change host-wide limits. Verification - Scan a deep and wide tree while measuring peak open handles. - Inject an unreadable directory and repeated short reads, then check cleanup. Deliverables - Bounded scanner and descriptor accounting test Rollout and recovery: Start with one configured root and expose incomplete scans. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-107 — Prevent path traversal through a watched-root handle **Story · High priority · Expert** noCV practice brief v5 · SKERNEL-107 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control resources and concurrency. Depends on: SKERNEL-102, SKERNEL-106. 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. A path is validated under the inbox, then a directory is replaced with a symlink before open, escaping the allowed root. Acceptance criteria - Operations resolve relative to an already opened trusted root - Traversal rejects symlinks or verifies each component under declared policy - Validation and use cannot be separated by an attacker-controlled rename Implementation constraints - Use temporary synthetic directories and no elevated privileges. Verification - Open and replace normal nested fixture files through the root handle. - Race a directory-to-symlink swap and confirm no outside file is read or changed. Deliverables - Root-relative filesystem adapter and race regression Rollout and recovery: Fail closed on platforms where the required safe primitive is unavailable. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-108 — Expose platform capability instead of silently changing semantics **Chore · High priority · Advanced** noCV practice brief v5 · SKERNEL-108 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SKERNEL-102, SKERNEL-105. 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. The Windows fixture cannot provide the same directory-flush guarantee as the Unix adapter, but both report durable replacement. Acceptance criteria - Adapter reports exact supported capabilities - Callers can require a capability and fail before mutation - Fallback semantics have distinct result codes and documentation Implementation constraints - Do not erase platform differences behind a boolean success value. Verification - Run the shared contract against two declared capability fixtures. - Require directory durability from an unsupported fixture and confirm no replacement starts. Deliverables - OS capability model and cross-adapter contract suite Rollout and recovery: Gate each deployment profile on its required capability set. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-109 — Recover an orphaned temporary replacement after restart **Task · High priority · Expert** noCV practice brief v5 · SKERNEL-109 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SKERNEL-102, SKERNEL-107, SKERNEL-108. Difficulty: Expert. Estimated focused work: 360 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. A crash leaves temporary files beside the destination; startup cannot tell whether they are incomplete writes or a replacement ready to finish. Acceptance criteria - Temporary name binds operation identity and expected content hash - Recovery verifies destination and temporary content before action - Ambiguous or foreign files remain untouched and visible Implementation constraints - Cleanup is scoped to the opened trusted root and never follows links. Verification - Recover before-rename and after-rename crash fixtures idempotently. - Place a foreign matching-looking file and confirm the agent records but does not delete it. Deliverables - Replacement journal and startup reconciliation drill Rollout and recovery: Run recovery in report-only mode before enabling scoped cleanup. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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. #### SKERNEL-110 — Package the OS adapter without requesting unnecessary privilege **Bug · Medium priority · Intermediate** noCV practice brief v5 · SKERNEL-110 · Build an operating-system boundary that fails predictably Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove recovery and handoff. Depends on: SKERNEL-107, SKERNEL-108, SKERNEL-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. An installer manifest requests administrator access even though the agent operates only inside a user-selected directory. Acceptance criteria - Document required paths, handles, notifications, and permissions - Default installation runs as an unprivileged user - Unavailable optional watcher capability falls back visibly to polling Implementation constraints - Do not install services, modify the registry, or request real privilege in the exercise. Verification - Run the packaged local fixture under a restricted temporary account profile. - Remove watcher capability and verify bounded polling without elevated fallback. Deliverables - Privilege inventory, packaging manifest, and fallback test Rollout and recovery: Keep installation local and reversible until platform review is complete. Project prerequisites: System calls File descriptors Monotonic clocks Engineer value: Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries. Company value: Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent. 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.