# 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. ## ACCESS — Tighten a partner portal's access boundaries A fictional manufacturing company shares purchase-order documents with partner organizations. Buyers, partner administrators, and read-only agents use the same API. Recent support reports suggest list filters and background downloads disagree about who may see an order. **Field:** Security. **Suggested stack:** TypeScript, NestJS, PostgreSQL, Redis. **Engineer value:** Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. **Company value:** Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. **Delivery agreement:** Ten defensive engineering issues over mapping, enforcement, and assurance phases; use synthetic accounts and documents in an owned test environment. ### Setup prerequisites - HTTP APIs - Session authentication - Tenant-scoped data access ### Map permissions Identify resources and define authorized actions. #### ACCESS-101 — Write the partner permission matrix from existing routes **Task · High priority · Foundational** noCV practice brief v5 · ACCESS-101 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Map permissions. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 80% · System 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. The portal has three roles, but engineers infer permissions from page names. A read-only agent can discover an Edit route that was added for partner administrators. Acceptance criteria - Inventory order, document, invitation, and export actions at route and service boundaries. - Define allowed actions for buyer, partner administrator, and read-only agent. - Mark unspecified combinations as denied and identify ownership or tenant conditions. Implementation constraints - A hidden button is not an authorization rule; include non-UI callers. Verification - Map each fixture route to exactly one documented action. - Show explicit denials for agent edits and cross-partner document reads. Deliverables - Permission matrix and route-to-action inventory Rollout and recovery: Review the matrix before enforcing new checks; record intentional compatibility changes for test clients. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. ### Enforce at every boundary Apply tenant and permission rules across synchronous and asynchronous access. #### ACCESS-102 — Remove partner scope from client-controlled list filters **Bug · High priority · Intermediate** noCV practice brief v5 · ACCESS-102 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-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. Changing partnerId in the purchase-order query reveals another partner's orders. The controller authenticates the session but trusts the query filter to choose the tenant. Acceptance criteria - Derive authorized partner scope from the server-side actor context. - Apply that scope within the order repository query. - Return scoped counts and pagination cursors that cannot widen access. Implementation constraints - Test the repository directly as well as the route; controller-only filtering is insufficient. Verification - List two pages of the authorized partner's orders with correct counts. - Replace partnerId and replay a foreign cursor; assert no foreign records or totals. Deliverables - Tenant-scoped list boundary and denial regressions Rollout and recovery: Switch the synthetic partner list first; disable the route if scoped count comparisons fail. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-103 — Make bulk order updates all-or-nothing across authorization checks **Bug · High priority · Advanced** noCV practice brief v5 · ACCESS-103 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-101, ACCESS-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database engineering 30% · 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. A batch update contains nine permitted order IDs and one foreign ID. The service updates the first nine before discovering the forbidden order and returning 403. Acceptance criteria - Authorize the complete bounded target set before committing changes. - A missing, duplicate, or foreign order prevents the entire batch update. - Record no success audit when the transaction is rejected. Implementation constraints - Do not reveal which foreign order exists through different error shapes. Verification - Update a fully authorized synthetic batch atomically. - Mix permitted and forbidden IDs and inject a final-write failure; verify unchanged records. Deliverables - Atomic bulk command and mixed-scope reproduction Rollout and recovery: Enable a bounded batch size on the synthetic client; revert batch routing without relaxing individual authorization. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-104 — Stop a document lookup from revealing foreign filenames **Bug · High priority · Foundational** noCV practice brief v5 · ACCESS-104 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · API design 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 foreign document request returns Forbidden: invoice-acme-september.pdf. Download is blocked, but the error itself leaks the other partner's filename. Acceptance criteria - Use the same public not-found response for missing and out-of-scope documents. - Do not include filename, owner, storage key, or existence hints in denied responses. - Keep an internal denial reason behind authorized audit access. Implementation constraints - Apply the projection to metadata and download-link routes, not just the file response. Verification - Retrieve an authorized filename normally. - Compare missing and foreign-document response bodies and inspect sanitized logs. Deliverables - Document denial projection and metadata-leak regression Rollout and recovery: Replace external error text immediately in the fixture routes; keep internal reason codes for diagnosis. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-105 — Consume partner invitations once under concurrent acceptance **Task · High priority · Advanced** noCV practice brief v5 · ACCESS-105 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database engineering 30% · 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. Two acceptance requests use the same invitation token at nearly the same time. The portal creates duplicate memberships and occasionally accepts a token after its role was revoked. Acceptance criteria - Bind an invitation to partner, intended recipient, role, expiry, and current invitation state. - Consume it and create membership in one transaction. - Concurrent acceptance yields one membership with a documented replay or conflict response. Implementation constraints - Persist token hashes only; synthetic invitation secrets must not enter logs. Verification - Accept a valid invitation once and inspect its membership. - Race acceptance and try expired, revoked, and wrong-recipient tokens; assert denial or one winner. Deliverables - Invitation consumption command and concurrency cases Rollout and recovery: Issue the new token format for future synthetic invitations; retain a documented expiry window for legacy links. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-106 — Narrow integration keys to the permissions they were issued **Story · High priority · Intermediate** noCV practice brief v5 · ACCESS-106 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce at every boundary. Depends on: ACCESS-101, ACCESS-102. 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. A partner creates a read-only reporting key while an administrator is logged in. Requests using that key inherit the administrator's full session permissions. Acceptance criteria - Evaluate key scopes separately from browser-session roles. - Restrict effective permissions to both key scope and current partner authority. - Support key revocation without disabling unrelated partner sessions. Implementation constraints - A key cannot grant a permission its issuer was not authorized to delegate. Verification - Read permitted reports through a scoped synthetic key. - Attempt order edits, cross-partner reads, and use after revocation; assert denial. Deliverables - Integration-key authorization policy and scope tests Rollout and recovery: Create scoped test keys alongside existing clients; remove broad key support after explicit client migration. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. ### Prove revocation and explain denials Handle changes in authority and provide useful audit records. #### ACCESS-107 — Recheck export authority when a background job completes **Bug · High priority · Expert** noCV practice brief v5 · ACCESS-107 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-103, ACCESS-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Distributed systems 20% · Storage systems 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 administrator starts a large partner export and loses membership while it runs. The worker later emails a long-lived storage URL using authorization captured only at request time. Acceptance criteria - Record immutable request scope without treating it as permanent authorization. - Reauthorize delivery and each download against current membership and export scope. - Revoked users cannot receive or use new access grants; completed artifacts remain tenant-restricted. Implementation constraints - Use an authenticated download boundary or similarly revocable design; do not send real email in this exercise. Verification - Complete and download a permitted synthetic export. - Revoke access between request, completion, and download; verify denial at each relevant boundary. Deliverables - Export authorization lifecycle and revocation timing tests Rollout and recovery: Route synthetic exports through the new download boundary; expire legacy links before removing their compatibility path. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-108 — Invalidate cached permissions after a role downgrade **Bug · High priority · Advanced** noCV practice brief v5 · ACCESS-108 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-102, ACCESS-106. Difficulty: Advanced. Estimated focused work: 210 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. A partner administrator is downgraded to read-only but retains edit access on one API instance for an hour because permission caches are local and keyed only by user ID. Acceptance criteria - Scope cached decisions by actor, partner, and authority revision. - Enforce a documented maximum revocation delay with an authoritative fallback. - Fail closed for privileged writes when current authority cannot be established. Implementation constraints - User ID alone is insufficient when the same user belongs to multiple partners. Verification - Downgrade a role across two synthetic API instances and measure the revocation delay. - Simulate cache invalidation loss and authority-store failure; assert privileged writes cannot persist indefinitely. Deliverables - Permission cache policy and revocation-latency reproduction Rollout and recovery: Shorten cache lifetime before enabling revisioned entries; bypass the cache if revision propagation fails. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-109 — Record useful access-denial audits without copying documents **Chore · Medium priority · Foundational** noCV practice brief v5 · ACCESS-109 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-104, ACCESS-106. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Privacy 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. Security receives Denied entries with no action name, while application debug logs include complete document metadata. Neither source is suitable for reviewing a partner complaint. Acceptance criteria - Record actor reference, scoped action, tenant reference, reason code, and correlation ID. - Exclude document text, credential values, request bodies, and raw download URLs. - Protect audit queries with a dedicated read permission and bounded date range. Implementation constraints - Security audit records are append-only; generic analytics must not receive sensitive audit detail. Verification - Follow an authorized denial investigation through its correlation ID. - Attempt audit access as a partner agent and scan secret-like fixture values for absence. Deliverables - Minimized audit schema and investigation example Rollout and recovery: Mirror fixture denials into the new sink and inspect redaction before enabling operator queries. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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. #### ACCESS-110 — Serialize membership removal with privileged order approval **Task · High priority · Expert** noCV practice brief v5 · ACCESS-110 · Tighten a partner portal's access boundaries Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prove revocation and explain denials. Depends on: ACCESS-103, ACCESS-108, ACCESS-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Database engineering 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 buyer is removed from a partner while their order-approval request is between authorization and commit. The current implementation commits the approval after removal without a defined policy. Acceptance criteria - Declare the transactional ordering rule for removal and approval. - Reconcile authority revision within the privileged write transaction so one ordering is enforced. - Keep successful approvals and rejected stale authority attempts separately auditable. Implementation constraints - A second controller check does not close the race; prove the service/database boundary controls it. Verification - Commit approval before removal under the declared ordering and inspect attribution. - Commit removal first while approval is paused and assert no unauthorized order mutation. Deliverables - Authority/write serialization design and deterministic interleaving tests Rollout and recovery: Apply the rule to order approvals before broader privileged writes; retain audit records through application rollback. Project prerequisites: HTTP APIs Session authentication Tenant-scoped data access Engineer value: Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery. Company value: Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records. 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.