# 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. ## CUPDATE — A recoverable edge software-update simulator Fictional information kiosks receive small generated image blobs through a local update adapter. Simulate slots and boot outcomes in software; do not flash hardware or execute image contents. **Field:** Embedded and edge. **Suggested stack:** TypeScript, Slot emulator, Filesystem adapter, Vitest. **Engineer value:** Practice update state machines and recoverable activation. **Company value:** Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. **Delivery agreement:** Use local emulator evidence only; signing fixtures never authorize production devices. ### Setup prerequisites - Generate inert byte images with manifests and development-only signing fixtures. - Implement simulated boot success failure and power-cut points. ### Validate update candidates Define version and image integrity. #### CUPDATE-101 — Parse edge-update manifests with explicit supported versions **Task · Medium priority · Foundational** noCV practice brief v5 · CUPDATE-101 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate update candidates. 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% · 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. Unknown manifest fields are treated as executable update instructions. Replace loose parsing with a bounded schema. Acceptance criteria - Known schema parses - Unsupported version rejects - Oversized fields reject before allocation Implementation constraints - Manifests are data and never scripts. Verification - Parse valid inert image manifest - Reject unsupported version Deliverables - Manifest parser and cases Rollout and recovery: Reject new updates when schema identity is uncertain. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. #### CUPDATE-102 — Verify edge-update image size and digest before staging **Bug · High priority · Foundational** noCV practice brief v5 · CUPDATE-102 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate update candidates. Depends on: CUPDATE-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Embedded and edge 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 truncated synthetic image is marked downloaded. Gate staging on complete integrity verification. Acceptance criteria - Size and digest both match - Mismatch blocks staging - Current active slot stays untouched Implementation constraints - Stream verification under an explicit memory bound. Verification - Verify generated image - Truncate or flip a byte Deliverables - Image verifier and corruption cases Rollout and recovery: Keep failed images quarantined from slot activation. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. #### CUPDATE-103 — Validate edge-update manifests using local trust fixtures **Task · High priority · Intermediate** noCV practice brief v5 · CUPDATE-103 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Validate update candidates. Depends on: CUPDATE-101, CUPDATE-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Embedded and edge 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 simulator accepts any manifest signature. Add a trust adapter using ephemeral development keys. Acceptance criteria - Trusted fixture signature passes - Unknown signer fails - Tampered manifest fails Implementation constraints - No private keys enter source control or production configuration. Verification - Verify local signed fixture - Change signed manifest field Deliverables - Trust adapter and negative cases Rollout and recovery: Disable update acceptance if trusted verification is unavailable. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. ### Stage and activate Keep a recoverable known-good slot. #### CUPDATE-104 — Write edge-update images only into the inactive simulated slot **Task · High priority · Advanced** noCV practice brief v5 · CUPDATE-104 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-102, CUPDATE-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 50% · Storage systems 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. Update copying overwrites the currently selected image before validation finishes. Restrict staging to the inactive slot. Acceptance criteria - Active slot remains byte-identical - Inactive slot gets candidate bytes - Failed write leaves active selection unchanged Implementation constraints - Slot paths must stay inside the fixture root. Verification - Stage valid image - Fail copy midway Deliverables - Slot writer and isolation cases Rollout and recovery: Abandon inactive candidate and retain active slot. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. #### CUPDATE-105 — Record edge-update activation intent before changing the boot selector **Bug · High priority · Expert** noCV practice brief v5 · CUPDATE-105 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-104. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Embedded and edge 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 power cut during selector change leaves no recoverable activation decision. Journal intent and candidate identity. Acceptance criteria - Intent is durable before selector change - Recovery identifies pending activation - Repeated recovery is deterministic Implementation constraints - Do not execute image bytes; use boot-result stubs. Verification - Cut before selector update - Cut after selector update Deliverables - Activation journal and cut-point matrix Rollout and recovery: Restore prior validated selector when activation state is ambiguous. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. #### CUPDATE-106 — Mark an edge-update candidate healthy only after simulated boot confirmation **Task · High priority · Intermediate** noCV practice brief v5 · CUPDATE-106 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-105. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 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. Merely selecting a slot labels the update successful. Require an explicit boot acknowledgement from the emulator. Acceptance criteria - Selection yields pending health - Confirmation marks success - Missing confirmation reaches bounded failure state Implementation constraints - Health means only the declared simulator check. Verification - Confirm successful boot - Omit confirmation past deadline Deliverables - Health transition and timer cases Rollout and recovery: Keep prior slot available until health acknowledgement commits. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. #### CUPDATE-107 — Roll back failed edge-update boots without retry loops **Story · High priority · Advanced** noCV practice brief v5 · CUPDATE-107 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Stage and activate. Depends on: CUPDATE-105, CUPDATE-106. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Embedded and edge 60% · Site reliability 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 failing candidate is selected repeatedly on each restart. Persist failed-candidate disposition and restore the known-good slot. Acceptance criteria - Failed candidate does not auto-reactivate - Prior slot is selected - No valid fallback produces explicit recovery-required state Implementation constraints - Do not label fallback existence without validating its metadata. Verification - Fail candidate boot - Invalidate both slot manifests Deliverables - Rollback coordinator and failure cases Rollout and recovery: Stop automatic activation when no validated fallback exists. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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 local rollout outcomes Bound retries and explain simulator status. #### CUPDATE-108 — Reject unintended edge-update downgrades under an explicit version policy **Task · High priority · Advanced** noCV practice brief v5 · CUPDATE-108 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle local rollout outcomes. Depends on: CUPDATE-103, CUPDATE-107. Difficulty: Advanced. Estimated focused work: 165 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Embedded and edge 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. Replaying an older signed image silently reverts a device. Add a declared minimum-version policy with a separate recovery mode. Acceptance criteria - Normal mode rejects lower versions - Equal-version replay is idempotent - Recovery override is explicit and audited locally Implementation constraints - Version order must be defined, not string-compared casually. Verification - Accept newer fixture - Replay older signed fixture Deliverables - Version policy and override cases Rollout and recovery: Disable updates if version comparison is ambiguous. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. #### CUPDATE-109 — Limit concurrent downloads in the simulated kiosk update cohort **Chore · Medium priority · Intermediate** noCV practice brief v5 · CUPDATE-109 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle local rollout outcomes. Depends on: CUPDATE-104, CUPDATE-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Embedded and edge 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. A local cohort starts every download at once and overwhelms the provider stub. Bound concurrency and retain per-device outcome. Acceptance criteria - Active transfers stay within limit - Failures release slots - One device retry cannot starve all others Implementation constraints - Cohort fixtures contain synthetic device IDs only. Verification - Update small cohort - Fail one transfer repeatedly Deliverables - Download scheduler and fairness cases Rollout and recovery: Reduce concurrency to one while queue behavior is repaired. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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. #### CUPDATE-110 — Report edge-update stages without overstating fleet success **Story · Medium priority · Intermediate** noCV practice brief v5 · CUPDATE-110 · A recoverable edge software-update simulator Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle local rollout outcomes. Depends on: CUPDATE-107, CUPDATE-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Frontend 50% · Embedded and edge 30% · Site reliability 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. Dashboard counts downloaded images as updated kiosks. Project download, staged, boot-pending, healthy and rolled-back separately. Acceptance criteria - Healthy requires committed boot confirmation - Rollback remains visible - Unknown outcomes are not counted successful Implementation constraints - Reports describe simulator outcomes, not real-device certification. Verification - Complete one simulated update - Interrupt another before boot confirmation Deliverables - Update status report and consistency checks Rollout and recovery: Hide aggregate success if per-device authority is unresolved. Project prerequisites: Generate inert byte images with manifests and development-only signing fixtures. Implement simulated boot success failure and power-cut points. Engineer value: Practice update state machines and recoverable activation. Company value: Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions. 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.