# 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. ## CKV — A crash-consistent local key-value store Fictional desktop cache Pebble needs a small embedded key-value engine. Build against generated keys and bytes using an ordinary filesystem adapter; no production database replacement is implied. **Field:** Storage systems. **Suggested stack:** TypeScript, Filesystem adapter, Vitest. **Engineer value:** Practice storage formats, durability boundaries and corruption handling. **Company value:** Inspect whether an engineer can state and test persistence guarantees. **Delivery agreement:** Each ticket adds one narrow engine behavior; publish measured local limits, not database performance claims. ### Setup prerequisites - Create a disposable local fixture directory. - Implement fault injection for partial writes, sync failure and process restart. ### Specify records Define bounded encoding and reads. #### CKV-101 — Encode local key-value records with explicit length limits **Task · Medium priority · Foundational** noCV practice brief v5 · CKV-101 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify records. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 70% · Database 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. Delimiter-based records fail when values contain newlines. Add a length-prefixed binary record format. Acceptance criteria - Arbitrary bytes round-trip - Key and value limits are enforced - Version is encoded explicitly Implementation constraints - Specify byte order in the format note. Verification - Round-trip binary fixture - Reject oversized declared length Deliverables - Encoder decoder and format document Rollout and recovery: Keep old files read-only until conversion is explicit. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-102 — Distinguish missing local keys from empty values **Bug · Medium priority · Foundational** noCV practice brief v5 · CKV-102 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify records. Depends on: CKV-101. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 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. Empty buffers are interpreted as Not found. Return explicit presence separate from byte length. Acceptance criteria - Empty stored value is found - Absent key is missing - Deletion yields missing Implementation constraints - Avoid truthiness checks on encoded values. Verification - Read empty value - Read deleted key Deliverables - Read result contract and cases Rollout and recovery: Revert callers to explicit result checking. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-103 — Build a local key-value index from validated log records **Task · Medium priority · Intermediate** noCV practice brief v5 · CKV-103 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Specify records. Depends on: CKV-101, CKV-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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. Startup trusts offsets without reading record boundaries. Rebuild the index only from validated records. Acceptance criteria - Latest valid record wins - Offsets stay within file bounds - Invalid record reports its position Implementation constraints - Do not allocate from untrusted length fields before bounds checks. Verification - Rebuild repeated keys - Use record extending past EOF Deliverables - Startup index and malformed-file cases Rollout and recovery: Refuse writes to logs that cannot be validated. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. ### Recover durable writes Handle torn records and atomic updates. #### CKV-104 — Declare local write acknowledgement after the durability barrier **Bug · High priority · Advanced** noCV practice brief v5 · CKV-104 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 70% · Database 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. Put returns success before the log flush completes. Define durable acknowledgement using the filesystem adapter. Acceptance criteria - Success follows required sync - Sync failure reports uncertain outcome - Failed acknowledgement is not silently retried as new write Implementation constraints - Document the adapter's actual durability assumptions. Verification - Put with successful sync - Inject sync failure after write Deliverables - Acknowledgement contract and fault cases Rollout and recovery: Switch to read-only if durability barriers fail repeatedly. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-105 — Recover a torn key-value record at the end of the log **Task · High priority · Advanced** noCV practice brief v5 · CKV-105 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-103, CKV-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 80% · Database engineering 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 crash leaves a partial final record and startup refuses every key. Recover the valid prefix conservatively. Acceptance criteria - Valid prefix remains readable - Incomplete tail is identified - Middle corruption fails closed Implementation constraints - Tail truncation requires an explicit recovery mode. Verification - Recover partial final record - Corrupt middle record Deliverables - Tail recovery and corruption cases Rollout and recovery: Preserve original log before applying tail repair. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-106 — Represent key deletion as an ordered tombstone **Story · Medium priority · Intermediate** noCV practice brief v5 · CKV-106 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-104, CKV-105. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 60% · Database 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. Rebuilding the index resurrects deleted keys because deletion only changed memory. Append durable tombstones. Acceptance criteria - Deleted keys stay missing after restart - Later puts can recreate key - Tombstones obey acknowledgement rules Implementation constraints - Keep record ordering authoritative. Verification - Delete and restart - Fail tombstone sync Deliverables - Tombstone format and restart cases Rollout and recovery: Disable deletion if durable ordering is uncertain. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-107 — Reject key-value batches that cannot commit atomically **Task · High priority · Expert** noCV practice brief v5 · CKV-107 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover durable writes. Depends on: CKV-104, CKV-106. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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 multi-key update survives restart with only half its changes. Add one bounded batch commit marker protocol. Acceptance criteria - Complete batch applies all records - Uncommitted batch applies none - Batch size is capped Implementation constraints - Do not claim filesystem transaction support that the adapter lacks. Verification - Restart after committed batch - Crash before commit marker Deliverables - Batch protocol and fault schedule Rollout and recovery: Disable batch writes while preserving single-key operations. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. ### Reclaim old storage Compact safely and inspect damage. #### CKV-108 — Compact the local log without changing visible key values **Task · High priority · Advanced** noCV practice brief v5 · CKV-108 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reclaim old storage. Depends on: CKV-106, CKV-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Database engineering 30% · Performance engineering 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. Repeated updates grow the log. Write a compacted generation from one consistent logical view. Acceptance criteria - Latest live values survive - Deleted keys stay absent - Compaction output validates before activation Implementation constraints - Bound memory by documented fixture limits or streaming plan. Verification - Compare reads before and after - Inject corrupted output record Deliverables - Compaction writer and equivalence cases Rollout and recovery: Discard unactivated compacted generation on failure. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-109 — Activate a compacted key-value generation recoverably **Bug · High priority · Expert** noCV practice brief v5 · CKV-109 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reclaim old storage. Depends on: CKV-108. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 70% · Database 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. Crashing during compacted-file replacement leaves no selected log. Add a recoverable generation manifest. Acceptance criteria - One valid generation is selected - Interrupted switch retains fallback - Repeated recovery makes same choice Implementation constraints - Keep previous generation until activation is durable. Verification - Crash at switch boundaries - Remove incomplete new generation Deliverables - Generation activation and crash tests Rollout and recovery: Restore the last validated manifest and retain both files. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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. #### CKV-110 — Inspect local key-value corruption without modifying files **Chore · Medium priority · Intermediate** noCV practice brief v5 · CKV-110 · A crash-consistent local key-value store Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reclaim old storage. Depends on: CKV-105, CKV-109. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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. Support has no way to identify damaged record offsets safely. Add a read-only inspection command. Acceptance criteria - Reports format and valid prefix - Never rewrites bytes - Output omits values by default Implementation constraints - Restrict command to an explicitly supplied fixture path. Verification - Inspect healthy log - Inspect malformed length and checksum Deliverables - Inspector and immutable-input checks Rollout and recovery: Remove repair suggestions if they imply automatic destructive changes. Project prerequisites: Create a disposable local fixture directory. Implement fault injection for partial writes, sync failure and process restart. Engineer value: Practice storage formats, durability boundaries and corruption handling. Company value: Inspect whether an engineer can state and test persistence guarantees. 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.