# 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. ## CFRAME — An emulated device-link framing library Fictional environmental-display devices send synthetic noncritical readings to a local gateway. Implement a byte-stream emulator; no physical device, radio, credentials or safety-critical control is involved. **Field:** Embedded and edge. **Suggested stack:** TypeScript, Byte-stream emulator, Vitest. **Engineer value:** Practice incremental parsing, fixed resource limits and protocol recovery. **Company value:** Inspect whether a device adapter survives malformed input without corrupting accepted readings. **Delivery agreement:** All execution uses software fixtures; hardware timing and production readiness are unqualified. ### Setup prerequisites - Specify a small frame format with length sequence payload and checksum. - Generate local byte streams with fragmentation corruption and reconnects. ### Define frame boundaries Validate bytes before interpreting payloads. #### CFRAME-101 — Decode emulated device frame integers with explicit byte order **Task · Medium priority · Foundational** noCV practice brief v5 · CFRAME-101 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define frame boundaries. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Networking 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 synthetic device length reads as 512 instead of 2 because endpoints disagree on byte order. Specify and implement the format. Acceptance criteria - Length and sequence use documented order - Valid boundary values round-trip - Truncated integer fields fail explicitly Implementation constraints - Use byte fixtures rather than host-native integer casts. Verification - Decode known two-byte values - Provide truncated header Deliverables - Integer codec and format examples Rollout and recovery: Reject frames from unknown format versions. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-102 — Reject emulated device frames above the receiver limit **Bug · High priority · Foundational** noCV practice brief v5 · CFRAME-102 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define frame boundaries. Depends on: CFRAME-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Security 30% · Networking 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. An untrusted length prefix causes a large allocation. Validate declared size before reserving payload storage. Acceptance criteria - Supported sizes pass - Oversized lengths fail before allocation - Zero-length policy is explicit Implementation constraints - Keep receiver limits independent from sender claims. Verification - Decode small fixture - Declare maximum integer length Deliverables - Frame admission guard and allocation checks Rollout and recovery: Stop reception if bounded allocation cannot be guaranteed. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-103 — Verify emulated device frame checksums before dispatch **Task · High priority · Intermediate** noCV practice brief v5 · CFRAME-103 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define frame boundaries. Depends on: CFRAME-101, CFRAME-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Networking 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. Corrupted readings reach the dashboard because checksum failures are warnings only. Gate payload dispatch on verification. Acceptance criteria - Valid frame dispatches once - Bad checksum dispatches nothing - Failure records a bounded category Implementation constraints - Checksum detects corruption and does not authenticate senders. Verification - Accept valid frame - Flip payload byte without updating checksum Deliverables - Checksum gate and corruption cases Rollout and recovery: Disable payload dispatch if verification is unavailable. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. ### Handle partial transport Recover fragmented and damaged streams. #### CFRAME-104 — Assemble fragmented emulated frames across arbitrary read boundaries **Bug · High priority · Advanced** noCV practice brief v5 · CFRAME-104 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-102, CFRAME-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Networking 50%. 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 single frame split across reads is discarded as malformed. Maintain incremental parser state. Acceptance criteria - Every legal split yields same frame - Multiple frames in one read decode - Incomplete suffix remains bounded Implementation constraints - Transport read boundaries are not message boundaries. Verification - Test every split of small frame - Feed partial header then disconnect Deliverables - Streaming decoder and split cases Rollout and recovery: Buffer only up to the declared frame limit. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-105 — Resynchronize emulated device framing after a corrupt header **Story · Medium priority · Advanced** noCV practice brief v5 · CFRAME-105 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Networking 50%. 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 damaged length prevents decoding all later frames. Recover at a documented sync marker without trusting random payload bytes. Acceptance criteria - Valid later frame can recover - Recovery scans within a cap - Rejected bytes never dispatch as readings Implementation constraints - Define marker escaping or ambiguity handling explicitly. Verification - Corrupt header before valid frame - Embed marker-like bytes in payload Deliverables - Resynchronization algorithm and ambiguity cases Rollout and recovery: Close the link when a safe boundary cannot be found. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-106 — Discard incomplete emulated frames after an idle deadline **Task · Medium priority · Intermediate** noCV practice brief v5 · CFRAME-106 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-104, CFRAME-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Networking 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 sender transmits a header and stops, pinning a receive buffer indefinitely. Add an injected idle timer. Acceptance criteria - Active progress refreshes deadline - Expired partial frame releases buffer - New valid frame can start afterward Implementation constraints - Use monotonic elapsed time rather than calendar time. Verification - Complete frame before deadline - Pause midway beyond deadline Deliverables - Partial-frame timeout and clock cases Rollout and recovery: Reset connection on timeout if local recovery is uncertain. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-107 — Handle emulated device sequence wrap without accepting stale frames **Bug · High priority · Expert** noCV practice brief v5 · CFRAME-107 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle partial transport. Depends on: CFRAME-103, CFRAME-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Networking 30% · Distributed systems 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. Sequence 0 after 65535 is rejected as old, while delayed frames sometimes overwrite current readings. Define a bounded modular-order window. Acceptance criteria - Legitimate wrap is accepted - Duplicates do not dispatch twice - Outside-window frames are rejected or require reset Implementation constraints - State the maximum reorder window and session boundary. Verification - Feed wrap boundary sequence - Replay delayed pre-wrap frame Deliverables - Sequence policy and boundary cases Rollout and recovery: Require a new session when sequence ordering is ambiguous. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. ### Bound receiver behavior Limit work and explain rejected data. #### CFRAME-108 — Apply backpressure when emulated device consumers fall behind **Task · High priority · Advanced** noCV practice brief v5 · CFRAME-108 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound receiver behavior. Depends on: CFRAME-104, CFRAME-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 40% · Performance engineering 40% · Networking 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. Parsing outruns downstream processing and queues grow indefinitely. Bound accepted-frame buffering. Acceptance criteria - Queue capacity is explicit - Overflow follows documented reject or pause policy - Parser state remains valid Implementation constraints - Do not claim lossless delivery under an explicit drop policy. Verification - Consume at normal speed - Stall consumer past capacity Deliverables - Bounded queue and overload cases Rollout and recovery: Pause emulator input if the consumer cannot keep up. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-109 — Reset emulated receiver state on a new link session **Bug · Medium priority · Intermediate** noCV practice brief v5 · CFRAME-109 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound receiver behavior. Depends on: CFRAME-106, CFRAME-107. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Networking 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. Bytes from a previous connection combine with a new header after reconnect. Clear session-owned parsing state. Acceptance criteria - New session discards partial buffer - Sequence window resets by contract - Completed prior frames remain recorded Implementation constraints - Connection identity must not come from payload text alone. Verification - Reconnect after complete frame - Reconnect mid-header Deliverables - Session reset and reconnect cases Rollout and recovery: Recreate the receiver per connection until state isolation is repaired. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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. #### CFRAME-110 — Expose emulated frame rejection counters without raw payloads **Chore · Low priority · Intermediate** noCV practice brief v5 · CFRAME-110 · An emulated device-link framing library Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bound receiver behavior. Depends on: CFRAME-108, CFRAME-109. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 40% · Site reliability 30% · 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. Debug logs contain complete sensor payloads even when only corruption rates are needed. Emit bounded categories. Acceptance criteria - Counts separate size checksum timeout and sequence failures - Payload bytes are omitted - Counter reset scope is documented Implementation constraints - Measurements describe the synthetic emulator only. Verification - Feed valid and corrupt fixtures - Inject secret-like payload and inspect logs Deliverables - Receiver metrics contract and samples Rollout and recovery: Disable detailed logging if payload content escapes. Project prerequisites: Specify a small frame format with length sequence payload and checksum. Generate local byte streams with fragmentation corruption and reconnects. Engineer value: Practice incremental parsing, fixed resource limits and protocol recovery. Company value: Inspect whether a device adapter survives malformed input without corrupting accepted readings. 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.