# 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. ## ATOKEN — Repair API token scope and revocation boundaries A fictional B2B export API uses long-lived tokens. Tokens copied between organizations can access too much, and revocation takes effect unpredictably. **Field:** Security. **Suggested stack:** TypeScript, PostgreSQL, REST. **Engineer value:** Practice authorization boundaries, credential lifecycle and safe diagnostics. **Company value:** Review denial paths and operational control over service access. **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 local synthetic API and two isolated organizations. - Use generated disposable credentials only. ### Define token authority Separate identity, scope and safe display. #### ATOKEN-101 — Define token scopes as an explicit allowlist of export operations **Task · High priority · Foundational** noCV practice brief v5 · ATOKEN-101 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define token authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · API design 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 token marked read-only can still trigger an export job because the handler treats every authenticated token equally. Acceptance criteria - List exact read and create operations per scope. - Unknown scopes are rejected at issuance. - Protected handlers deny missing required scope. Implementation constraints - Do not infer permission from token naming conventions. Verification - Use a read scope for a permitted status request. - Attempt export creation with that token and verify no job is created. Deliverables - Scope matrix and authorization checks Rollout and recovery: Deploy handler checks before issuing scoped tokens; disable legacy unrestricted issuance. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-102 — Store only token verification material and a safe display prefix **Task · Medium priority · Intermediate** noCV practice brief v5 · ATOKEN-102 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define token authority. Depends on: ATOKEN-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. The token-management page retrieves complete credentials from the database every time an administrator opens it. Acceptance criteria - Show the full token only at initial issuance. - Persist one-way verification material and a nonsecret identifier. - List views never return reusable token material. Implementation constraints - Use a mature cryptographic primitive and document verification behavior. Verification - Issue and authenticate a disposable token. - Read the list and stored record; verify the raw token is absent. Deliverables - Token storage contract and disclosure tests Rollout and recovery: Migrate new tokens first; retire legacy raw-token records through explicit rotation. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-103 — Bind API token queries to the issuing organization **Bug · Urgent priority · Advanced** noCV practice brief v5 · ATOKEN-103 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define token authority. Depends on: ATOKEN-101, ATOKEN-102. Difficulty: Advanced. Estimated focused work: 210 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 export identifier from another organization succeeds because the service checks token validity but omits tenant scope. Acceptance criteria - Repository reads include the token organization. - Cross-organization IDs receive nondisclosing denial. - Authorization occurs before artifact-link creation. Implementation constraints - Test repository boundaries as well as routes. Verification - Read an export in the issuing organization. - Request a second organization's export and verify no signed-link provider call. Deliverables - Tenant-bound repository guard Rollout and recovery: Deploy the scope guard before further token distribution; inspect denied access metadata. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. ### Control token lifetime Rotate and revoke without widening authority. #### ATOKEN-104 — Enforce token expiration at the request authorization boundary **Bug · Medium priority · Foundational** noCV practice brief v5 · ATOKEN-104 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-102, ATOKEN-103. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. A token expires in storage but remains usable because the cached authentication result has no expiry check. Acceptance criteria - Check current expiry with an injected clock. - Cache lifetime cannot exceed token expiry. - Expired tokens fail before protected service execution. Implementation constraints - Use UTC instants and avoid logging presented credentials. Verification - Authenticate just before expiry. - Advance to the exact expiry instant and deny cached and uncached requests. Deliverables - Expiry enforcement and clock-boundary cases Rollout and recovery: Canary with disposable short-lived tokens; flush incompatible authentication caches. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-105 — Rotate a token with a bounded overlap window **Story · Medium priority · Advanced** noCV practice brief v5 · ATOKEN-105 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · API design 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. Customers need to replace credentials without downtime, but unrestricted overlap leaves old tokens valid indefinitely. Acceptance criteria - Create a replacement with no broader scopes. - Persist an explicit predecessor retirement deadline. - Expose both token identities and overlap state safely. Implementation constraints - Require authorized rotation and bind it to an expected token revision. Verification - Rotate and authenticate both during the declared overlap. - Advance beyond the overlap and deny the predecessor while accepting the replacement. Deliverables - Rotation command and overlap tests Rollout and recovery: Test with a synthetic client; revoke the new token if adoption fails within the window. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-106 — Make revocation override cached authentication results **Task · High priority · Expert** noCV practice brief v5 · ATOKEN-106 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-104, ATOKEN-105. 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 administrator revokes a leaked token, but one process continues accepting its cached authority. Acceptance criteria - Define a maximum revocation propagation contract. - Invalidate or version cached authority using durable token state. - Fail closed when required revocation freshness cannot be established. Implementation constraints - Use two local consumer instances and controlled connectivity failures. Verification - Revoke a token and verify both consumers deny within the declared bound. - Disconnect revocation freshness and verify the documented denial behavior. Deliverables - Revocation protocol and propagation probe Rollout and recovery: Canary two synthetic consumers; reduce cache lifetime or disable caching on propagation failure. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-107 — Prevent a retry from issuing multiple replacement credentials **Bug · Medium priority · Advanced** noCV practice brief v5 · ATOKEN-107 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control token lifetime. Depends on: ATOKEN-105, ATOKEN-106. Difficulty: Advanced. Estimated focused work: 210 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. The rotation response is lost and a retry creates another active successor that the customer never receives. Acceptance criteria - Bind rotation idempotency to actor, predecessor and requested scope. - One successful command creates one successor. - Changed rotation parameters under the same key conflict. Implementation constraints - Store only a bounded issuance response under the declared secret-handling policy. Verification - Retry a completed rotation and count one successor. - Reuse its key with broader scopes and verify rejection. Deliverables - Idempotent rotation transaction Rollout and recovery: Enable rotation retries with a short documented response lifetime; revoke orphan test tokens during recovery. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. ### Observe denied access Verify isolation and respond to exposure. #### ATOKEN-108 — Record denied API access without turning audit logs into a token store **Task · Medium priority · Intermediate** noCV practice brief v5 · ATOKEN-108 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe denied access. Depends on: ATOKEN-103, ATOKEN-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Privacy engineering 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. Security needs failed-access context, but the existing logger captures the Authorization header and request body. Acceptance criteria - Record safe token identity, route, reason and UTC time. - Exclude authorization headers and body content. - Bound repeated denial events to prevent log exhaustion. Implementation constraints - Use synthetic token strings in redaction tests. Verification - Trace a scope denial by safe token identity. - Send repeated malformed tokens and verify redaction and bounded logging. Deliverables - Safe denial audit and rate-bound checks Rollout and recovery: Deploy audit filtering first; quarantine old diagnostic logs for authorized review. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-109 — Rehearse credential exposure containment for one organization **Task · Medium priority · Expert** noCV practice brief v5 · ATOKEN-109 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe denied access. Depends on: ATOKEN-106, ATOKEN-107, ATOKEN-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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 fictional customer reports that a token was pasted into a public issue; operations needs a tested containment sequence. Acceptance criteria - Identify and revoke the affected token without listing secrets. - Confirm denial across every local consumer. - Preserve safe audit facts and issue a scoped replacement through the normal flow. Implementation constraints - Use a disposable token and a fabricated incident only. Verification - Run the complete containment drill and verify old-token denial. - Simulate an unreachable consumer and keep containment status incomplete. Deliverables - Exposure response runbook and executable drill Rollout and recovery: Practice in a synthetic organization; stop replacement distribution until revocation status is known. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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. #### ATOKEN-110 — Show token last-use status without claiming it proves nonuse **Story · Medium priority · Foundational** noCV practice brief v5 · ATOKEN-110 · Repair API token scope and revocation boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Observe denied access. Depends on: ATOKEN-108, ATOKEN-109. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. Administrators interpret an empty last-used field as proof that a token was never used, despite audit ingestion gaps. Acceptance criteria - Distinguish observed use, no recorded use and unknown coverage. - State the observation window and freshness. - Avoid exposing request payloads in token summaries. Implementation constraints - Treat last-use metadata as operational evidence with stated limits. Verification - Record a successful request and show its observation time. - Remove audit coverage and show unknown instead of never used. Deliverables - Token activity projection Rollout and recovery: Publish the explicit coverage labels; revert UI wiring if scope checks fail. Project prerequisites: Create a local synthetic API and two isolated organizations. Use generated disposable credentials only. Engineer value: Practice authorization boundaries, credential lifecycle and safe diagnostics. Company value: Review denial paths and operational control over service access. 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.