# 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. ## VAULT — Rotate an integration credential without losing work A fictional supplier integration signs incoming webhooks and uses an outbound API credential. Operators currently replace environment values by hand. Build with a deterministic secret-store adapter and fabricated keys only; no live provider account or production credential is part of the exercise. **Field:** Security. **Suggested stack:** TypeScript, NestJS, PostgreSQL, Secret-provider interface. **Engineer value:** Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. **Company value:** Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. **Delivery agreement:** Ten issues across inventory, rotation, and recovery phases; deliver a deterministic provider, synthetic contract checks, and a credential incident drill. ### Setup prerequisites - Cryptographic hash APIs - HTTP webhook handling - Access control ### Make credential use explicit Establish provider boundaries and prevent secret exposure. #### VAULT-101 — Inventory credential consumers without exporting their values **Task · Medium priority · Foundational** noCV practice brief v5 · VAULT-101 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make credential use explicit. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Operations knows the supplier key is used by the API but discovers a nightly worker still reads an old environment variable. Rotation planning has no reliable consumer list. Acceptance criteria - List logical credential names, consuming processes, purposes, and required permissions. - Distinguish inbound signing verification from outbound API authentication. - Exclude credential values and private material from the inventory artifact. Implementation constraints - Prepare a synthetic API/worker consumer configuration; inspect its names only and do not enumerate the user's environment or local secrets. Verification - Account for API and worker consumers in the synthetic configuration prepared for this project. - Insert a dummy secret value and confirm the inventory output never contains it. Deliverables - Credential consumer map and rotation dependency list Rollout and recovery: Review the map before changing lookup paths; version it with each new consumer. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-102 — Move secret lookup behind a version-aware provider **Task · High priority · Intermediate** noCV practice brief v5 · VAULT-102 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make credential use explicit. Depends on: VAULT-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Backend 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: Ports and Adapters (apply). Ports and Adapters — Apply: Separate version-aware secret lookup from provider details so the deterministic adapter and an unavailable provider obey the same fail-closed contract. 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. API and worker read process environment independently and cannot report which credential version they are using. The test suite also embeds key values in request snapshots. Acceptance criteria - Define lookup by logical credential name and permitted version reference. - Return a non-secret version identity separately from sensitive material. - Use a deterministic fixture adapter and fail closed when no provider is configured. Implementation constraints - Keep secret material out of serialized DTOs and snapshot assertions. Verification - Resolve a known synthetic version for an authorized consumer. - Reject an unknown version, unauthorized consumer, and absent provider without fallback secrets. Deliverables - Secret provider contract and deterministic adapter Rollout and recovery: Migrate one synthetic consumer at a time; keep configuration rollback limited to the fixture provider. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-103 — Redact credentials from failed supplier requests **Bug · High priority · Foundational** noCV practice brief v5 · VAULT-103 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make credential use explicit. Depends on: VAULT-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · Backend 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. The HTTP client's error serializer includes Authorization headers and query parameters. A supplier timeout writes the outbound credential into a generic error log. Acceptance criteria - Log an allowlisted error projection with operation, status class, timeout, and correlation ID. - Exclude headers, raw URLs, request bodies, and provider response bodies. - Expose credential version identity only when it is a non-secret reference. Implementation constraints - Do not rely on replacing one known key value; future values and nested errors must remain safe. Verification - Diagnose a synthetic timeout through permitted metadata. - Inject secret-like values into nested headers, URLs, and response bodies and assert absence. Deliverables - Safe supplier error serializer and redaction fixtures Rollout and recovery: Replace error serialization before rotation drills; disable verbose client logging in the fixture configuration. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. ### Rotate with controlled overlap Handle version changes, webhook verification, and in-flight work. #### VAULT-104 — Model credential activation and retirement as explicit transitions **Story · High priority · Intermediate** noCV practice brief v5 · VAULT-104 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-102, VAULT-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Backend 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. An operator changes a credential row from RETIRED to ACTIVE to recover an outage. The service resumes using a version that was deliberately revoked after a drill. Acceptance criteria - Define staged, active, retiring, retired, and revoked states with named commands. - Prevent revoked and retired versions from becoming active again. - Audit actor, reason, version references, and transition time without secret material. Implementation constraints - A replacement requires a new credential version; state changes cannot rewrite historical identity. Verification - Walk a staged fixture version through activation and retirement. - Attempt forbidden reactivation and stale revision updates; assert unchanged history. Deliverables - Credential lifecycle operations and transition matrix Rollout and recovery: Route fixture operator changes through the commands before removing direct state writes. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-105 — Verify signed webhooks against raw bytes before parsing **Bug · High priority · Advanced** noCV practice brief v5 · VAULT-105 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-102. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Integrations 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 receiver parses JSON and reserializes it before checking the supplier signature. Harmless whitespace changes break valid signatures, while trusted routing fields are read before authenticity is established. Acceptance criteria - Verify the exact bounded raw body using the fixture protocol's HMAC signature format. - Use constant-time comparison for equal-length signature bytes and reject malformed encodings. - Parse trusted fields only after successful verification and enforce the protocol's timestamp tolerance. Implementation constraints - The fixture protocol signs timestamp plus raw body with HMAC-SHA-256; define the byte separator explicitly. Verification - Accept a correctly signed body including deliberate whitespace. - Reject one-byte changes, invalid signature length, and timestamps outside the declared tolerance. Deliverables - Raw-body webhook verification and protocol fixtures Rollout and recovery: Run signature checks on a fixture receiver first; fail closed when verification material is unavailable. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-106 — Accept old and new webhook signatures only during a bounded overlap **Task · High priority · Advanced** noCV practice brief v5 · VAULT-106 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-104, VAULT-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Integrations 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 supplier rotates signing keys gradually across senders. Switching instantly drops valid traffic; retaining every old key forever defeats retirement. Acceptance criteria - Accept only the configured active and retiring versions during their explicit validity windows. - Reject retired or revoked versions regardless of timestamp tolerance. - Record the non-secret verifying version identity for accepted webhook receipts. Implementation constraints - Bound the candidate key set; an untrusted key ID cannot trigger arbitrary provider lookups. Verification - Accept both fixture versions inside overlap and only the new version after retirement. - Try a revoked version and an unknown attacker-controlled key ID; assert rejection without broad lookup. Deliverables - Signing overlap policy and boundary-time tests Rollout and recovery: Stage the new version, begin bounded overlap, then retire the old version after fixture sender convergence. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-107 — Keep duplicate signed callbacks from creating duplicate supplier events **Bug · High priority · Intermediate** noCV practice brief v5 · VAULT-107 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rotate with controlled overlap. Depends on: VAULT-105, VAULT-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · Integrations 30% · 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. The supplier retries a valid signed callback through both old and new signing keys during overlap. Signature checks pass twice and both requests create a purchase-order update. Acceptance criteria - Deduplicate by authenticated supplier event identity and tenant, independent of signing version. - Bind the identity to a canonical payload fingerprint and conflict on changed content. - Commit the receipt and business dispatch intent atomically. Implementation constraints - A valid signature proves message authenticity under the fixture protocol, not permission for duplicate side effects. Verification - Deliver the same event under both allowed keys and assert one business dispatch. - Race duplicate callbacks and reuse the event ID with changed content; inspect stable state and conflict. Deliverables - Authenticated receipt deduplication and overlap replay cases Rollout and recovery: Enable receipt uniqueness before starting overlap; retain receipts through any receiver rollback. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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 and audit Revoke compromised versions, bound caching, and rehearse provider failure. #### VAULT-108 — Rotate outbound credentials without retrying an ambiguous write twice **Task · High priority · Expert** noCV practice brief v5 · VAULT-108 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and audit. Depends on: VAULT-104, VAULT-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 30% · 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. An outbound supplier update times out during credential rotation. The worker retries with the new key and a fresh request ID, creating the same supplier instruction twice. Acceptance criteria - Keep one operation identity across credential version changes and retries. - Distinguish authentication rejection from an unknown remote commit outcome. - Use the fixture supplier's idempotency/status contract before resending an ambiguous write. Implementation constraints - Do not assume changing credentials resets business idempotency or proves a timed-out request failed. Verification - Rotate after a confirmed authentication failure and complete one logical operation. - Simulate remote commit followed by timeout; reconcile through status lookup and assert no duplicate instruction. Deliverables - Outbound rotation retry protocol and ambiguous-outcome reproduction Rollout and recovery: Verify against the deterministic supplier adapter before switching fixture consumers; pause ambiguous writes if status lookup fails. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-109 — Make emergency revocation reach cached consumers **Bug · High priority · Expert** noCV practice brief v5 · VAULT-109 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and audit. Depends on: VAULT-104, VAULT-106, VAULT-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. An operator revokes a synthetic compromised key, but a worker's indefinite cache continues signing requests with it. Another worker refreshes and succeeds, hiding the inconsistent state. Acceptance criteria - Bound cache lifetime and propagate credential authority revisions to all consumers. - Prevent use after the declared revocation deadline, including during provider outage. - Audit revocation convergence using version references and consumer acknowledgements only. Implementation constraints - Cached availability cannot override explicit revocation; define the exercise's maximum revocation delay. Verification - Revoke a cached fixture key across two consumers and measure convergence. - Drop one invalidation notification and disable lookup; verify use stops at the deadline. Deliverables - Revocation propagation design and failure-interleaving tests Rollout and recovery: Enforce bounded caching before testing emergency revoke; pause outbound work when authority cannot be refreshed safely. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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. #### VAULT-110 — Rehearse a secret-provider outage and document recovery limits **Chore · Medium priority · Advanced** noCV practice brief v5 · VAULT-110 · Rotate an integration credential without losing work Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and audit. Depends on: VAULT-103, VAULT-108, VAULT-109. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. The provider is unavailable during a planned rotation. On call needs to know which reads can continue, which writes must wait, and how to recover without pasting keys into environment files. Acceptance criteria - Exercise provider outage before activation, during overlap, and after old-version revocation. - Document allowed cached behavior and fail-closed conditions for each stage. - Restore processing through the provider while preserving operation IDs and audit history. Implementation constraints - Use fabricated credentials and deterministic failures; no manual secret-value fallback is allowed. Verification - Recover a staged fixture rotation after provider availability returns. - Keep the revoked version unusable throughout outage and recovery, and inspect logs for secret absence. Deliverables - Credential incident drill report and stage-specific recovery runbook Rollout and recovery: Version the runbook with provider and policy versions; repeat the drill when cache or overlap behavior changes. Project prerequisites: Cryptographic hash APIs HTTP webhook handling Access control Engineer value: Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets. Company value: Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety. 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.