# 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.

## SIPC — Supervise local worker processes without losing their output

A fictional document converter launches local sandbox substitutes as child processes. Its prototype parses newline-delimited output, leaks descriptors, and retries requests after ambiguous worker exits. Create a Rust supervisor and deterministic worker fixtures; no document content or production sandbox is supplied.

**Field:** Systems programming. **Suggested stack:** Rust, Child processes, Unix sockets or named pipes, Vitest or cargo test.

**Engineer value:** Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

**Company value:** Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

**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

- File descriptors

- Framing

- Process signals

### Establish the machine contract

Make representation, ownership and failure boundaries explicit.

#### SIPC-101 — Frame worker messages without treating newlines as boundaries

**Task · Medium priority · Foundational**

noCV practice brief v5 · SIPC-101 · Supervise local worker processes without losing their output

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% · 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.

A diagnostic string contains a newline and splits one response into two apparent messages.

Acceptance criteria

- Frame declares version, type, request identity, and bounded payload length

- Reader handles partial headers and payloads

- Unknown versions fail without consuming the next frame

Implementation constraints

- Cap frame size before allocating its payload buffer.

Verification

- Read several frames split across every header boundary.

- Advertise an oversized or truncated payload and verify bounded rejection.

Deliverables

- Versioned frame codec and fragmentation tests

Rollout and recovery: Keep the line protocol available only for old local fixtures during migration.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-102 — Close inherited descriptors before executing the worker

**Bug · Medium priority · Foundational**

noCV practice brief v5 · SIPC-102 · Supervise local worker processes without losing their output

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 child inherits the supervisor listener and keeps it open after the parent exits, preventing clean restart.

Acceptance criteria

- Child receives only declared stdin, stdout, stderr, and control handles

- Supervisor closes duplicate ends after spawn

- Restart can bind the same local endpoint

Implementation constraints

- Do not depend on a global close-all scan that races other threads opening handles.

Verification

- Spawn, complete, and restart a worker while checking descriptor counts.

- Add an undeclared inheritable handle and confirm the fixture detects it.

Deliverables

- Spawn handle policy and leak regression

Rollout and recovery: Audit handle inheritance before enabling multiple workers.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-103 — Correlate out-of-order worker replies to the right caller

**Story · Medium priority · Intermediate**

noCV practice brief v5 · SIPC-103 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Establish the machine contract. Depends on: SIPC-101.

Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Systems programming 70% · Distributed 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.

Two conversions finish in reverse order and the supervisor resolves the first waiter with the second result.

Acceptance criteria

- Every accepted request has a unique operation identity

- Replies resolve only the matching pending request

- Duplicate and unknown replies are recorded without completing another caller

Implementation constraints

- Keep the pending map bounded by admission capacity and deadlines.

Verification

- Complete three requests in reverse order and verify each result.

- Send a duplicate and an unknown identity and confirm pending callers remain unchanged.

Deliverables

- Correlation table and ordering tests

Rollout and recovery: Enable concurrent requests only after correlation checks pass.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-104 — Separate protocol output from worker diagnostics

**Chore · Medium priority · Intermediate**

noCV practice brief v5 · SIPC-104 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Control resources and concurrency. Depends on: SIPC-101, SIPC-102.

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 library warning written to stdout is parsed as a reply and closes the worker connection.

Acceptance criteria

- Protocol frames use one declared channel

- Diagnostics use stderr with bounded capture

- Malformed protocol bytes fail the request without hiding diagnostics

Implementation constraints

- Sanitize diagnostics and cap retained bytes per worker.

Verification

- Return a valid response while writing warnings to stderr.

- Write nonprotocol bytes on the protocol channel and verify isolated failure.

Deliverables

- Channel contract and mixed-output fixtures

Rollout and recovery: Treat unexpected stdout as a worker defect during local migration.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-105 — Apply backpressure when a worker stops reading

**Task · High priority · Advanced**

noCV practice brief v5 · SIPC-105 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Control resources and concurrency. Depends on: SIPC-103, SIPC-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.

Pattern topics: Bulkhead (apply).

Bulkhead — Apply: Isolate each child process buffer and preserve global capacity so one stopped reader cannot consume every supervisor resource.

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.

A stalled child leaves the supervisor buffering every request body until memory is exhausted.

Acceptance criteria

- Per-worker and global pending byte limits are enforced

- Admission reports overload before consuming the body

- Healthy workers can continue within their own capacity

Implementation constraints

- Do not solve the stall with an unbounded retry queue.

Verification

- Drive balanced workers to their declared capacity.

- Pause one reader and prove buffers remain bounded while another worker progresses.

Deliverables

- IPC admission controller and stalled-reader test

Rollout and recovery: Start with small limits and expose overload to callers.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-106 — Classify worker exit before deciding whether to retry

**Bug · High priority · Advanced**

noCV practice brief v5 · SIPC-106 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Control resources and concurrency. Depends on: SIPC-103.

Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Systems programming 60% · Distributed 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.

The worker exits after writing its output but before the acknowledgement frame; automatic retry may produce a second external artifact.

Acceptance criteria

- Outcome distinguishes not-started, running, acknowledged, failed, and unknown

- Unknown completion requires status lookup or explicit review

- Retry reuses the stable operation identity

Implementation constraints

- Do not infer failure solely from pipe closure or process exit code.

Verification

- Exercise exits before start and after acknowledged completion.

- Exit after effect but before acknowledgement and preserve UNKNOWN without blind retry.

Deliverables

- Exit classification state machine and ambiguity fixtures

Rollout and recovery: Disable automatic retry for unknown outcomes until the worker supports reconciliation.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-107 — Terminate a process tree without signaling unrelated work

**Story · High priority · Expert**

noCV practice brief v5 · SIPC-107 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Control resources and concurrency. Depends on: SIPC-102, SIPC-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.

A timed-out worker launches a helper. Killing only the parent leaks the helper; reusing a process-group identifier risks signaling a newer process.

Acceptance criteria

- Each operation owns a fresh supervised process group or platform job object

- Termination verifies the group identity before signaling

- Cleanup observes all declared descendants or reports unresolved members

Implementation constraints

- Tests use inert local helpers and never enumerate or signal arbitrary host processes.

Verification

- Terminate a fixture parent and its two waiting children.

- Reuse a synthetic numeric identifier and prove identity validation blocks the stale cleanup.

Deliverables

- Process-tree lifecycle adapter and safe termination tests

Rollout and recovery: Keep worker concurrency at one until descendant cleanup is reliable.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-108 — Restart crashed workers without retry storms

**Chore · High priority · Advanced**

noCV practice brief v5 · SIPC-108 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Prove recovery and handoff. Depends on: SIPC-105, SIPC-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.

Pattern topics: Circuit Breaker (apply).

Circuit Breaker — Apply: Open a bounded unavailable state after repeated worker crashes so replacement attempts stop until the declared recovery probe.

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.

A corrupt fixture crashes every replacement worker, and immediate restart loops consume the supervisor CPU.

Acceptance criteria

- Restart budget uses bounded attempts and backoff

- Stable runtime resets the failure window

- Exhaustion opens a visible unavailable state

Implementation constraints

- Use injected time and deterministic jitter; do not sleep in tests.

Verification

- Crash twice, recover, and verify the budget clears after stability.

- Crash every replacement and confirm restart attempts stop at the bound.

Deliverables

- Restart policy and crash-loop test

Rollout and recovery: Fail new requests fast while a worker class is unavailable.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-109 — Reconcile pending operations after supervisor restart

**Task · High priority · Expert**

noCV practice brief v5 · SIPC-109 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Prove recovery and handoff. Depends on: SIPC-103, SIPC-106, SIPC-108.

Difficulty: Expert. Estimated focused work: 360 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.

The supervisor restarts with requests marked running but no in-memory correlation table and no proof whether workers completed them.

Acceptance criteria

- Persist stable operation identity and last acknowledged state before dispatch

- Recovery queries a deterministic worker ledger when supported

- Unresolved operations remain visible and are never silently marked failed

Implementation constraints

- The local ledger contains synthetic identities and bounded metadata, not document bodies.

Verification

- Restart after acknowledgement and restore the completed result.

- Restart during an unqueryable effect and retain UNKNOWN for review.

Deliverables

- Pending-operation journal and restart drill

Rollout and recovery: Require reconciliation support before enabling autonomous retry.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.

#### SIPC-110 — Document the IPC boundary for a future isolated provider

**Bug · Medium priority · Intermediate**

noCV practice brief v5 · SIPC-110 · Supervise local worker processes without losing their output

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Prove recovery and handoff. Depends on: SIPC-107, SIPC-108, SIPC-109.

Difficulty: Intermediate. Estimated focused work: 150 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 local child-process harness is about to be mistaken for a production candidate-code sandbox.

Acceptance criteria

- Document framing, resource limits, process identity, shutdown, and unresolved outcomes

- State which isolation guarantees the local supervisor does not provide

- Define the provider contract a hardened external executor must satisfy

Implementation constraints

- Do not claim namespace, secret, network, or host isolation from ordinary child processes.

Verification

- Reproduce the local crash and restart drill from the guide.

- Attempt to select the local adapter under a production configuration and require fail-closed behavior.

Deliverables

- IPC contract and explicit production boundary note

Rollout and recovery: Keep the local supervisor restricted to synthetic development fixtures.

Project prerequisites: File descriptors Framing Process signals

Engineer value: Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.

Company value: Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.

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.
