# 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. ## ALEASE — Coordinate scheduled maintenance with fenced leases A fictional document service runs periodic retention planning on multiple application instances. Paused instances resume after lease expiry and can overlap newer schedulers. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL. **Engineer value:** Practice lease assumptions, fencing and stale-owner rejection. **Company value:** Review safe coordination that remains explainable under pauses and recovery. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create a synthetic maintenance queue and two independent scheduler clients. - Use fake time where possible and no destructive real retention actions. ### Define scheduler authority Model lease identity, expiry and protected actions. #### ALEASE-101 — Specify scheduler lease state with a separate authority epoch **Task · Medium priority · Foundational** noCV practice brief v5 · ALEASE-101 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define scheduler authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 100%. 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 scheduler table stores only owner name and expiry, so an old owner can appear identical to a later process with the same name. Acceptance criteria - Include lease identity, holder instance, expiry and monotonic epoch. - Define active and expired semantics at the exact boundary. - Keep display names outside authority checks. Implementation constraints - Use opaque process-instance identities. Verification - Represent two successive owners with distinct epochs. - Reuse a display name and verify it cannot impersonate the previous instance. Deliverables - Lease schema and authority contract Rollout and recovery: Review the schema before scheduler writes; leave coordination disabled until epoch checks exist. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-102 — Use one authoritative clock boundary for lease decisions **Task · Medium priority · Intermediate** noCV practice brief v5 · ALEASE-102 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define scheduler authority. Depends on: ALEASE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 100%. 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 instances disagree about lease expiry because their local clocks differ by several seconds. Acceptance criteria - Define the clock used for acquisition and expiry checks. - Keep client clock readings out of authority decisions. - Document pause and network-delay assumptions. Implementation constraints - Prefer database time within the transaction for this local PostgreSQL exercise. Verification - Skew client clocks and obtain the same database lease decision. - Reach exact expiry and verify the documented eligibility boundary. Deliverables - Clock-bound lease queries and skew test Rollout and recovery: Canary lease reads under controlled skew; stop acquisition if authoritative time is unavailable. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-103 — Classify maintenance actions that require fencing before side effects **Task · Medium priority · Foundational** noCV practice brief v5 · ALEASE-103 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define scheduler authority. Depends on: ALEASE-101, ALEASE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System design 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 design adds a lease but assumes every downstream operation automatically knows whether its caller is still leader. Acceptance criteria - List each protected mutation and its fencing check location. - Separate read-only planning from state-changing execution. - Mark unfenceable external effects as unresolved. Implementation constraints - Use synthetic retention plans; delete no real objects. Verification - Trace a plan-state update to its epoch guard. - Identify an external adapter without epoch support and block its destructive action. Deliverables - Fencing coverage matrix Rollout and recovery: Require coverage before enabling actions; keep unresolved provider operations read-only. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. ### Guard competing owners Acquire, renew and execute with fencing. #### ALEASE-104 — Acquire a scheduler lease atomically under competing instances **Story · High priority · Advanced** noCV practice brief v5 · ALEASE-104 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-102, ALEASE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed 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. Two instances see an expired lease and both believe they became the active scheduler. Acceptance criteria - Acquire through one guarded database transaction. - Increment the epoch only for the winning acquisition. - Return current safe ownership metadata to the loser. Implementation constraints - Use two independent database connections and a barrier. Verification - Race two acquisitions and assert one winning epoch. - Hold a valid lease and verify another instance cannot replace it early. Deliverables - Atomic acquisition command and race test Rollout and recovery: Canary with two local clients; stop scheduling if ownership results conflict. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-105 — Renew a scheduler lease only for the current holder and epoch **Bug · Medium priority · Intermediate** noCV practice brief v5 · ALEASE-105 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed 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. A delayed renewal from an earlier process extends the newest owner's lease row while reporting success to the stale process. Acceptance criteria - Match holder instance and epoch in the renewal update. - Bound extension duration from the authoritative clock. - Return lost authority when no matching active lease exists. Implementation constraints - Never renew solely by a shared scheduler name. Verification - Renew the current owner successfully. - Acquire a newer epoch, then submit the old renewal and reject it. Deliverables - Guarded renewal and stale-message test Rollout and recovery: Enable guarded renewal before automated scheduling; make authority loss stop further work claims. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-106 — Fence maintenance writes after a paused scheduler resumes **Task · High priority · Expert** noCV practice brief v5 · ALEASE-106 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-103, ALEASE-104, ALEASE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed 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. A scheduler pauses past expiry, then resumes a previously prepared plan after another instance has taken over. Acceptance criteria - Every protected write checks current authority epoch. - A stale owner cannot complete or activate a plan. - Record rejected stale activity without overwriting current progress. Implementation constraints - Carry epoch through the command and recheck at commit. Verification - Pause owner A, let B acquire, then finish B's plan. - Resume A and verify its write is rejected even if it began earlier. Deliverables - Commit-time fencing and pause reproduction Rollout and recovery: Canary synthetic plan activation; disable unfenced writes until every path passes the stale-owner probe. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-107 — Make scheduled maintenance occurrences idempotent across leadership changes **Story · Medium priority · Advanced** noCV practice brief v5 · ALEASE-107 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard competing owners. Depends on: ALEASE-104, ALEASE-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed 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. A new leader repeats the current maintenance period and creates a second plan for the same logical occurrence. Acceptance criteria - Derive occurrence identity from schedule and intended UTC instant. - Enforce one durable logical run per occurrence. - Allow a new owner to resume existing nonterminal work safely. Implementation constraints - Do not derive identity from acquisition time or process name. Verification - Change leader midway through an occurrence and retain one run. - Retry a terminal occurrence and return its recorded result. Deliverables - Occurrence identity contract and leader-change test Rollout and recovery: Enable idempotent creation before multi-instance operation; reconcile existing duplicates through read-only reports. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. ### Exercise time and connection failures Reconcile ownership and recover interrupted runs. #### ALEASE-108 — Expose lease health without implying the holder is making progress **Story · Medium priority · Foundational** noCV practice brief v5 · ALEASE-108 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise time and connection failures. Depends on: ALEASE-105, ALEASE-106, ALEASE-107. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Site reliability 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 scheduler renews its lease while stuck on one task, so the status page incorrectly reports healthy processing. Acceptance criteria - Report lease authority and work-progress timestamps separately. - Distinguish no leader, active leader and stalled work. - Keep unknown progress explicit after observation gaps. Implementation constraints - Use safe instance tokens rather than host secrets. Verification - Show an active progressing scheduler. - Freeze progress while renewing the lease and show stalled work. Deliverables - Scheduler status projection Rollout and recovery: Add status before alert thresholds; disable noisy alerts while retaining raw safe state. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-109 — Recover coordination after a database connection partition **Task · Medium priority · Expert** noCV practice brief v5 · ALEASE-109 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise time and connection failures. Depends on: ALEASE-102, ALEASE-106, ALEASE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Networking 20% · 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. An instance loses database connectivity but can still contact the fake work provider, raising the risk of acting on expired authority. Acceptance criteria - Stop new protected actions when authority cannot be verified. - Reconcile lease and run state after reconnection. - Resume only under a current valid epoch. Implementation constraints - Use controlled local adapter disconnection, not real network disruption. Verification - Disconnect one owner, acquire with another, and continue valid work. - Reconnect the old owner and reject its cached authority before any action. Deliverables - Partition drill and authority recovery trace Rollout and recovery: Run before multi-instance scheduling; fail closed on unresolved ownership. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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. #### ALEASE-110 — Document lease guarantees and the provider conditions they depend on **Chore · Medium priority · Intermediate** noCV practice brief v5 · ALEASE-110 · Coordinate scheduled maintenance with fenced leases Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise time and connection failures. Depends on: ALEASE-103, ALEASE-107, ALEASE-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System design 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 release note says exactly one scheduler runs, even though stale processes may execute until downstream fences reject their writes. Acceptance criteria - Describe mutual authority separately from process execution. - List clock, transaction and provider fencing assumptions. - Link each guarantee to a race or partition probe. Implementation constraints - Avoid claiming leases alone guarantee exactly-once effects. Verification - Trace a protected-write guarantee to its fencing test. - Identify an unfenced provider and state the unsupported guarantee. Deliverables - Coordination operating contract Rollout and recovery: Review before enabling external actions; revise the contract when provider semantics change. Project prerequisites: Create a synthetic maintenance queue and two independent scheduler clients. Use fake time where possible and no destructive real retention actions. Engineer value: Practice lease assumptions, fencing and stale-owner rejection. Company value: Review safe coordination that remains explainable under pauses and recovery. 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.