# 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. ## AAUDIT — Make privileged support actions inspectable A fictional support console can reveal protected account settings and run repairs. The team needs bounded elevation, clear reasons and durable records of what happened. **Field:** Security. **Suggested stack:** TypeScript, PostgreSQL, REST. **Engineer value:** Practice privileged workflows, denial paths and audit integrity. **Company value:** Review accountable support operations without unnecessary access to customer data. **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 synthetic support actors and organizations. - Implement a local authorization boundary and append-only audit store. ### Constrain elevated access Define permission, purpose and expiry. #### AAUDIT-101 — List support actions with required permission and disclosure level **Task · Medium priority · Foundational** noCV practice brief v5 · AAUDIT-101 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain elevated access. Depends on: No preceding ticket. 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. Support agents share an admin role because nobody has separated read diagnostics from account-changing actions. Acceptance criteria - Classify each action by permission and exposed fields. - Default unknown actions to denied. - Keep read-only diagnostics separate from mutation authority. Implementation constraints - Use six concrete fictional support actions. Verification - Map an allowed diagnostic read to its minimal permission. - Attempt an unlisted action and deny it before data access. Deliverables - Support permission matrix Rollout and recovery: Review the matrix before enabling new actions; retain unknown operations as disabled. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-102 — Require a bounded purpose record before support elevation **Story · Medium priority · Intermediate** noCV practice brief v5 · AAUDIT-102 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain elevated access. Depends on: AAUDIT-101. Difficulty: Intermediate. Estimated focused work: 150 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. An agent opens account settings using permanent elevated access with no connection to a support case. Acceptance criteria - Record target organization, permitted actions, reason and expiry. - Require an authorized actor to request elevation. - Reject empty purpose or an excessive lifetime. Implementation constraints - Use synthetic case references without copying case conversations. Verification - Create a scoped time-limited elevation. - Request a different organization's action outside the grant and deny it. Deliverables - Elevation request contract Rollout and recovery: Canary grants for synthetic actors; revoke active test grants if policy checks fail. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-103 — Remove sensitive account fields from ordinary support search **Bug · High priority · Foundational** noCV practice brief v5 · AAUDIT-103 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Constrain elevated access. Depends on: AAUDIT-101, AAUDIT-102. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 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. Searching by account ID returns confidential settings before the agent opens an elevated support session. Acceptance criteria - Ordinary search returns an explicit minimal projection. - Protected details require the exact active grant. - Denied search responses do not reveal account existence across scope. Implementation constraints - Define response schemas at the service boundary. Verification - Find an account using permitted safe fields. - Search outside scope and inspect response and logs for protected fields. Deliverables - Minimal support search projection Rollout and recovery: Deploy projection before elevation rollout; disable broad debug search endpoints. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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 privileged mutations Bind changes to reviewed scope and durable records. #### AAUDIT-104 — Reauthorize elevation immediately before a support repair commits **Bug · High priority · Advanced** noCV practice brief v5 · AAUDIT-104 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-102, AAUDIT-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. An agent starts a repair, loses access, then the pending request commits using the authorization decision from several minutes earlier. Acceptance criteria - Reload actor and grant authority in the mutation transaction. - Check target scope, permitted operation and expiry. - Revoked or expired grants leave domain state unchanged. Implementation constraints - Use controlled barriers to model revocation between read and commit. Verification - Commit a repair under an active matching grant. - Revoke at the barrier and verify rollback with no repair effect. Deliverables - Commit-boundary authorization guard Rollout and recovery: Canary the guard on synthetic repairs; disable repair writes if authorization freshness fails. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-105 — Commit privileged repair state and its audit fact together **Task · Medium priority · Advanced** noCV practice brief v5 · AAUDIT-105 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Security 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 repair succeeds while the audit insert fails, leaving an unrecorded privileged change. Acceptance criteria - Persist repair and audit fact in one transaction. - Audit captures actor, grant, action and safe target identity. - Audit failure rolls back the repair. Implementation constraints - Keep payload contents and secrets out of the audit record. Verification - Commit a synthetic repair and inspect one matching audit fact. - Force audit persistence failure and verify unchanged domain state. Deliverables - Atomic repair audit and failure test Rollout and recovery: Deploy transactional writes before exposing repairs; stop mutation if audit storage is unavailable. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-106 — Make support repair commands replay-safe without repeating side effects **Story · Medium priority · Expert** noCV practice brief v5 · AAUDIT-106 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-105. Difficulty: Expert. Estimated focused work: 300 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 console retries a repair after a timeout, generating a second account reset and confusing the support trail. Acceptance criteria - Bind idempotency to actor, grant, target and operation input. - Return the original result for identical retries. - Reject changed parameters under the same key. Implementation constraints - Audit the logical operation once and retain safe retry observations separately. Verification - Lose a post-commit response and retry to one repair. - Reuse the command key for another target and deny it. Deliverables - Idempotent support repair command Rollout and recovery: Canary with disposable accounts; pause conflicting command keys for investigation. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-107 — Expire support grants without relying on a cleanup job **Task · Medium priority · Intermediate** noCV practice brief v5 · AAUDIT-107 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Guard privileged mutations. Depends on: AAUDIT-104, AAUDIT-106. Difficulty: Intermediate. Estimated focused work: 150 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 delayed cleanup worker leaves expired support sessions usable throughout an outage. Acceptance criteria - Every privileged authorization checks the stored expiry. - Cleanup only archives derived state and cannot extend authority. - Use one documented exact-expiry boundary. Implementation constraints - Use an injected UTC clock at the service boundary. Verification - Authorize a matching action immediately before expiry. - Advance to expiry while cleanup is paused and deny the action. Deliverables - Expiry enforcement and paused-cleanup test Rollout and recovery: Enable boundary checks before cleanup changes; revoke grants if clock assumptions are violated. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. ### Review and recover Inspect events and respond to missing audit coverage. #### AAUDIT-108 — Provide a scoped audit timeline with stable cursor pagination **Story · Medium priority · Intermediate** noCV practice brief v5 · AAUDIT-108 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review and recover. Depends on: AAUDIT-105, AAUDIT-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 40% · API design 30% · 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. Security reviewers need to inspect a repair sequence, but an unbounded audit endpoint times out and exposes unrelated organizations. Acceptance criteria - Filter by authorized organization and bounded time window. - Order by committed sequence with a stable cursor. - Return safe action metadata without repair payloads. Implementation constraints - Reject cursors bound to another scope. Verification - Page a synthetic incident timeline while new events arrive. - Tamper with scope in a cursor and return a nondisclosing denial. Deliverables - Audit timeline endpoint and scope tests Rollout and recovery: Expose read-only timelines to a review role; revoke the route if projection checks fail. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-109 — Detect missing privileged audit coverage using domain references **Chore · Medium priority · Expert** noCV practice brief v5 · AAUDIT-109 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review and recover. Depends on: AAUDIT-105, AAUDIT-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Quality 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 legacy repair path may still bypass the transactional audit method; reviewers need a precise way to find uncovered changes. Acceptance criteria - Compare privileged operation references with audit identities. - Report missing and contradictory links separately. - Do not invent audit facts for historical gaps. Implementation constraints - Use bounded synthetic data and a read-only reconciliation command. Verification - Reconcile a complete operation history with no gaps. - Remove one audit reference in a fixture and report explicit incomplete coverage. Deliverables - Audit coverage reconciler Rollout and recovery: Run read-only before enabling legacy repair paths; disable uncovered writes until corrected. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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. #### AAUDIT-110 — Rehearse termination of an active support elevation incident **Task · Medium priority · Foundational** noCV practice brief v5 · AAUDIT-110 · Make privileged support actions inspectable Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Review and recover. Depends on: AAUDIT-107, AAUDIT-108, AAUDIT-109. Difficulty: Foundational. Estimated focused work: 120 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 support account is suspected of misuse while one elevated request is still running. Acceptance criteria - Runbook revokes grants and checks in-flight commit protection. - Preserve immutable audit facts and record coverage limits. - Verify ordinary support access remains scoped after containment. Implementation constraints - Use only synthetic actors and repairs. Verification - Contain an active grant and verify later actions are denied. - Pause a repair before commit, revoke authority, and confirm no mutation completes. Deliverables - Support containment runbook and drill trace Rollout and recovery: Rehearse locally before release; keep repairs disabled if containment cannot be verified. Project prerequisites: Create synthetic support actors and organizations. Implement a local authorization boundary and append-only audit store. Engineer value: Practice privileged workflows, denial paths and audit integrity. Company value: Review accountable support operations without unnecessary access to customer data. 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.