# 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. ## BAPIAUTH — Delegated partner API access A fictional operations platform lets customers connect automation clients. Broad API keys and inconsistent tenant checks make delegated access difficult to review. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, PostgreSQL. **Engineer value:** Practice delegated authorization, resource scoping, and secure public API ergonomics. **Company value:** Provide usable partner access that remains least-privilege and revocable. **Delivery agreement:** Deliver local credential and access contracts; connect no real partner account. ### Setup prerequisites - Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. ### Define delegated authority Separate actor, organization, client, and permission scope. #### BAPIAUTH-101 — Define partner scopes from concrete API operations **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIAUTH-101 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define delegated authority. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 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 single automation scope permits every operation in the organization. Acceptance criteria - Map scopes to specific operation classes. - Separate read, write, and administrative authority. - Document unsupported scope combinations. Implementation constraints - Do not derive permissions from client-provided role names. Verification - Authorize a read-only synthetic client. - Deny a write under the read-only scope. Deliverables - Partner scope matrix. Rollout and recovery: Review least-privilege defaults before issuing credentials. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-102 — Bind delegated credentials to organization and client identity **Task · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-102 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define delegated authority. Depends on: BAPIAUTH-101. Difficulty: Advanced. Estimated focused work: 180 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 valid credential can be paired with another organization ID in the URL. Acceptance criteria - Store organization and client authority server-side. - Require exact binding on each service call. - Reject caller attempts to substitute actor identity. Implementation constraints - Opaque credentials are never interpreted as authorization claims without lookup or verification. Verification - Call an owned resource. - Reuse the credential against another organization and deny safely. Deliverables - Credential authority model. Rollout and recovery: Fail closed on missing client or membership authority. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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 access Validate resource authority and token lifecycle. #### BAPIAUTH-103 — Return non-enumerating errors for unauthorized partner resources **Task · High priority · Intermediate** noCV practice brief v5 · BAPIAUTH-103 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 40% · Privacy 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. Partners can distinguish nonexistent records from records belonging to another organization. Acceptance criteria - Define stable safe denial semantics. - Keep error bodies free of foreign identifiers. - Preserve internal diagnostic categories separately. Implementation constraints - Use Problem Details-style public errors. Verification - Read an authorized record. - Compare missing and foreign-record public responses. Deliverables - Partner error contract. Rollout and recovery: Use the same safe projection across all resource endpoints. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-104 — Enforce authorization in nested and batch partner operations **Bug · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-104 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-102, BAPIAUTH-103. Difficulty: Advanced. Estimated focused work: 180 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. The parent resource is authorized, but nested record IDs bypass tenant checks. Acceptance criteria - Reauthorize every nested resource at the service boundary. - Define atomic or per-item denial behavior. - Prevent unauthorized items from influencing result totals. Implementation constraints - Client-supplied parent-child relationships are untrusted. Verification - Process a valid nested update. - Insert a foreign child ID and verify the declared denial behavior. Deliverables - Nested authorization regression. Rollout and recovery: Gate batch rollout on cross-tenant and relationship checks. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-105 — Rotate partner credentials without indefinite dual-key access **Task · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-105 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-102, BAPIAUTH-104. Difficulty: Advanced. Estimated focused work: 210 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 rotation overlap, but old keys remain valid forever. Acceptance criteria - Issue a distinct new credential generation. - Set an explicit overlap expiry for the old generation. - Show generation status without exposing credential values. Implementation constraints - Reveal a generated test credential only through the intended creation response. Verification - Use both generations during overlap. - Reject the old generation after expiry. Deliverables - Credential rotation workflow. Rollout and recovery: Keep overlap bounded and auditable; never restore retired credentials silently. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-106 — Revoke partner access across cached authorization decisions **Bug · High priority · Advanced** noCV practice brief v5 · BAPIAUTH-106 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Enforce access. Depends on: BAPIAUTH-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · 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. Revoked clients retain access until a long cache TTL expires. Acceptance criteria - Bind caches to current authorization revision. - Recheck or invalidate revoked authority within the declared bound. - Deny new operations after revocation. Implementation constraints - Cached membership is not permanent authority. Verification - Serve a current authorized cache entry. - Revoke the client and verify cached access stops within policy. Deliverables - Revocation-aware authorization cache. Rollout and recovery: Prioritize denial when revision freshness is unavailable. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. ### Support client operations Handle rotation, auditing, and migration. #### BAPIAUTH-107 — Rate-limit by delegated client without losing tenant-wide protection **Task · Medium priority · Intermediate** noCV practice brief v5 · BAPIAUTH-107 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-104, BAPIAUTH-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Site reliability 30% · Security 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. Creating many client keys bypasses a per-key request limit. Acceptance criteria - Apply both client and organization budgets. - Return documented retry guidance. - Keep denied requests from consuming unrelated client authority. Implementation constraints - Use deterministic local counters and no customer profiling. Verification - Exercise separate clients within the organization ceiling. - Create multiple clients and verify the shared cap holds. Deliverables - Delegated rate-limit contract. Rollout and recovery: Start with published conservative limits and inspect false rejection cases. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-108 — Expose an audit trail of privileged partner-client changes **Story · High priority · Intermediate** noCV practice brief v5 · BAPIAUTH-108 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-105, BAPIAUTH-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 60% · Privacy engineering 20% · 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. Organization owners cannot see who expanded a client scope. Acceptance criteria - Append actor, client, changed scope, and UTC time. - Exclude tokens and request payloads. - Scope audit reads to current authorized organization members. Implementation constraints - Do not overwrite previous audit facts. Verification - Inspect a credential rotation and scope change. - Deny a cross-organization audit read. Deliverables - Partner access audit projection. Rollout and recovery: Enable audit recording before scope mutation endpoints. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-109 — Design migration from broad keys to scoped delegated clients **Task · High priority · Expert** noCV practice brief v5 · BAPIAUTH-109 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-107, BAPIAUTH-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · System design 30% · 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. Existing integrations depend on broad keys and cannot all migrate at once. Acceptance criteria - Inventory actual required operations through safe synthetic usage records. - Define staged scope reduction and client cutover. - Compare compatibility burden with the risk of retained broad authority. Implementation constraints - No real partner usage is inferred from absence of traffic. Verification - Migrate two synthetic clients with different needs. - Keep an unknown integration unresolved instead of silently revoking or broadening it. Deliverables - Delegated-access migration plan. Rollout and recovery: Use explicit reviewed deadlines and retain a bounded recovery process. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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. #### BAPIAUTH-110 — Write a partner credential handling example for rotation and denial **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIAUTH-110 · Delegated partner API access Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support client operations. Depends on: BAPIAUTH-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 40% · Security 40% · 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. Documentation encourages hardcoding keys and retrying every unauthorized response. Acceptance criteria - Read credentials from the intended runtime boundary. - Handle expiry and revocation without infinite retries. - Show safe rotation using local test credentials. Implementation constraints - Examples must not log authorization headers. Verification - Run the example through a valid rotation. - Revoke access and verify a terminal actionable error. Deliverables - Executable partner access guide. Rollout and recovery: Version examples with the credential contract and remove obsolete broad-key guidance. Project prerequisites: Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only. Engineer value: Practice delegated authorization, resource scoping, and secure public API ergonomics. Company value: Provide usable partner access that remains least-privilege and revocable. 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.