# 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. ## RDELETE — Delete a workspace member profile across owned stores A fictional collaboration product lets a member request removal of their personal profile. Search, notifications and cached displays retain copies after the primary row disappears. The exercise uses a documented product deletion policy and synthetic identities. **Field:** Privacy engineering. **Suggested stack:** TypeScript, PostgreSQL, Queue adapter, Search adapter. **Engineer value:** Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. **Company value:** Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. **Delivery agreement:** Ten tickets across request, cleanup and reconciliation phases. No live accounts are deleted; the brief does not certify legal erasure or removal from undeclared third parties. ### Setup prerequisites - Create local profile, search-index and notification fixtures with controlled provider failures. - Define synthetic members, organizations and a current-session authorization fixture. ### Accept a scoped removal request Define identity, authority and the product deletion contract. #### RDELETE-101 — Separate profile removal from leaving one organization **Task · Medium priority · Foundational** noCV practice brief v5 · RDELETE-101 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept a scoped removal request. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · System design 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. A member belongs to two organizations. The current button says delete account but removes only the active membership. Acceptance criteria - Define distinct commands for leaving one organization and removing the global personal profile. - List owned stores affected by each command and any retained records under the fictional policy. - Show the command scope and expected access change before submission. Implementation constraints - Do not infer global identity from an organization-local display name or email field. Verification - Trace a two-organization member through both commands and compare affected records. - Verify a membership-only request leaves the other organization and global profile unchanged. Deliverables - Deletion scope contract and multi-organization fixtures Rollout and recovery: Introduce distinct command names before enabling cleanup adapters. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-102 — Verify the current member before accepting profile removal **Story · Medium priority · Intermediate** noCV practice brief v5 · RDELETE-102 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept a scoped removal request. Depends on: RDELETE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Privacy 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. A request body supplies a profile ID and the API trusts it even when it differs from the authenticated member. Acceptance criteria - Resolve the subject from the current authorized session and declared command scope. - Reject substituted profile IDs and stale sessions before creating a request. - Return a safe request reference without exposing another profile’s existence. Implementation constraints - Reuse an explicit authentication provider fixture; this ticket does not invent a new identity-assurance claim. Verification - Submit as the matching synthetic member and verify the request subject. - Substitute a second member’s ID and revoke the session; both cases must create no request. Deliverables - Authorized request endpoint and subject-substitution tests Rollout and recovery: Gate request creation before enabling background work; rollback disables new requests while preserving accepted ones. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-103 — Make repeated removal requests return the same active operation **Bug · High priority · Intermediate** noCV practice brief v5 · RDELETE-103 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Accept a scoped removal request. Depends on: RDELETE-102. Difficulty: Intermediate. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Privacy engineering 40% · 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 double-click starts two cleanup chains that race and send contradictory completion messages. Acceptance criteria - Use a subject-scoped active-operation uniqueness rule and a stable request identity. - Return the existing operation for a duplicate accepted request. - Preserve previous terminal history when a genuinely new eligible request is allowed by the policy. Implementation constraints - Create the request and dispatch intent transactionally; a retry must not depend on process memory. Verification - Submit concurrent duplicates and verify one operation plus one dispatch intent. - Lose the first response and retry, confirming the same safe operation reference. Deliverables - Idempotent request creation and concurrency regressions Rollout and recovery: Apply the uniqueness constraint before deploying the accepting endpoint. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. ### Remove declared copies Coordinate idempotent cleanup and prevent data from returning. #### RDELETE-104 — Stop new profile-derived writes after removal begins **Bug · High priority · Advanced** noCV practice brief v5 · RDELETE-104 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove declared copies. Depends on: RDELETE-101, RDELETE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 50% · Distributed systems 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. The notification worker recreates a cached profile card while cleanup is deleting it. Acceptance criteria - Record a lifecycle boundary that profile-derived writers check before producing new copies. - Define how already queued work is cancelled or rejected for the removal generation. - Preserve required nonpersonal operational records without copying the removed profile into them. Implementation constraints - Use a generation or tombstone contract with explicit retention; do not keep the entire deleted profile inside a tombstone. Verification - Queue a notification before removal and release it afterward; no new profile copy may appear. - Race an edit with removal and verify one declared outcome with no profile resurrection. Deliverables - Write barrier and profile-resurrection race tests Rollout and recovery: Deploy the writer check before activating cleanup; stop new operations if a writer cannot honor it. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-105 — Remove profile documents from search using the removal generation **Story · Medium priority · Advanced** noCV practice brief v5 · RDELETE-105 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove declared copies. Depends on: RDELETE-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Data engineering 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. A delayed indexing event arrives after a search document was deleted and makes the profile searchable again. Acceptance criteria - Bind indexing and removal to a comparable subject generation or explicit suppression rule. - Make repeated search deletion safe and keep stale indexing events from restoring the profile. - Keep cleanup tenant/subject-scoped so similarly named profiles remain searchable. Implementation constraints - Treat the search adapter as eventually consistent and define the observation needed before declaring that location complete. Verification - Delete a profile, replay its older indexing event and verify it stays absent after the adapter’s declared convergence condition. - Search for a same-name profile in another organization and verify it remains unaffected. Deliverables - Search cleanup adapter and stale-event regressions Rollout and recovery: Canary on synthetic subjects; retain unresolved search state if the adapter cannot establish the expected convergence. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-106 — Track notification and cache cleanup separately from the primary profile row **Bug · High priority · Advanced** noCV practice brief v5 · RDELETE-106 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Remove declared copies. Depends on: RDELETE-104, RDELETE-105. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Distributed systems 30% · 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. The operation reports success after deleting the database row even though a notification snapshot and cache entry still show the member’s details. Acceptance criteria - Track required locations with independent pending, confirmed and failed states. - Differentiate already absent from unavailable or unauthorized provider responses. - Advance overall completion only when the declared required locations satisfy the policy. Implementation constraints - The location registry is versioned for each operation so a later implementation change cannot silently rewrite its promised scope. Verification - Fail cache cleanup after database removal and verify a partial state with a retryable location. - Return an authorization error from notifications and confirm it cannot be counted as confirmed absence. Deliverables - Location progress model and partial-cleanup fixtures Rollout and recovery: Enable adapters one at a time in the local exercise; unsupported locations remain explicitly unresolved. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. ### Reconcile exceptions and completion Make partial progress and recovery inspectable. #### RDELETE-107 — Keep the removal status page useful after the profile is gone **Story · Medium priority · Intermediate** noCV practice brief v5 · RDELETE-107 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-102, RDELETE-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Security 40% · Frontend 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. Deleting the profile also removes the data needed to render progress, leaving the requester with a broken page before cleanup is finished. Acceptance criteria - Provide a narrowly scoped status mechanism independent of the removed profile display fields. - Expose progress categories and unresolved exceptions without returning deleted content or internal storage identifiers. - Define status access expiry and deny access to unrelated operations. Implementation constraints - Use the exercise authentication contract or an explicitly scoped expiring receipt; do not place a reusable access secret in generic analytics. Verification - Read progress before and after primary-profile removal. - Attempt another subject’s operation and an expired receipt/session; verify denial without detail leakage. Deliverables - Minimal status response and post-removal access tests Rollout and recovery: Publish the status contract before enabling destructive cleanup; retain safe operation metadata for its declared lifetime. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-108 — Reapply profile suppression before a restored backup becomes readable **Task · Medium priority · Expert** noCV practice brief v5 · RDELETE-108 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-104, RDELETE-106. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 40% · Site reliability 30% · Storage 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. A restore rehearsal brings back a profile that was removed after the backup was taken. Acceptance criteria - Define a minimal removal ledger and a restore gate that reconciles post-backup removals before serving reads. - State the retention and access boundaries of the ledger without storing full profile snapshots. - Keep the restored environment unavailable if reconciliation is incomplete or the ledger cannot be trusted. Implementation constraints - Use local database snapshots and synthetic subjects; a backup exception must be visible in the policy rather than called immediate erasure. Verification - Restore a snapshot containing a later-removed profile and verify suppression before any simulated read endpoint is enabled. - Make the ledger unavailable and verify the restore gate fails closed. Deliverables - Restore reconciliation protocol and backup resurrection rehearsal Rollout and recovery: Add the gate to the local restore runbook before accepting the deletion workflow as complete for its declared stores. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-109 — Retry a removal operation after losing a provider acknowledgement **Chore · Medium priority · Advanced** noCV practice brief v5 · RDELETE-109 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-103, RDELETE-105, RDELETE-106. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. A provider removes a copy but the cleanup process crashes before recording the result. Retrying currently converts the missing object into a fatal error. Acceptance criteria - Reconcile uncertain acknowledgement states using the provider’s declared lookup/removal contract. - Make repeated cleanup converge without recreating data or duplicating completion notifications. - Retain a distinct unresolved state when the provider cannot confirm the outcome. Implementation constraints - Use deterministic crash points around dispatch, provider completion and local persistence. Verification - Crash after external removal and before local update, then retry and verify truthful convergence. - Inject repeated provider timeout and verify bounded retries plus visible unresolved status. Deliverables - Acknowledgement-loss regression and retry procedure Rollout and recovery: Retry only through the recorded operation identity; unresolved high-impact states require authorized review in the exercise. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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. #### RDELETE-110 — Produce a removal report that names remaining exceptions **Task · Medium priority · Expert** noCV practice brief v5 · RDELETE-110 · Delete a workspace member profile across owned stores Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reconcile exceptions and completion. Depends on: RDELETE-107, RDELETE-108, RDELETE-109. Difficulty: Expert. Estimated focused work: 270 minutes; setup and prerequisite tickets are additional. Estimated field mix: Privacy engineering 80% · 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. The proposed confirmation says all your data is deleted even when a declared backup copy or unavailable provider remains. Acceptance criteria - Generate a bounded report of completed locations, retained policy exceptions and unresolved outcomes. - Bind the report to the operation and policy versions and distinguish requested time from observed completion time. - Avoid claiming global erasure or legal compliance beyond the declared local scope. Implementation constraints - The report is workflow status, not noCV Outcome Evidence or Ownership Evidence; practice completion grants neither. Verification - Generate reports for complete, partial and backup-exception fixtures and compare their language with actual store state. - Attempt report access as another subject and verify no operation details leak. Deliverables - Truthful completion report and scope/authorization tests Rollout and recovery: Use the report only after reconciliation; corrections append a new status record rather than rewriting earlier confirmations. Project prerequisites: Create local profile, search-index and notification fixtures with controlled provider failures. Define synthetic members, organizations and a current-session authorization fixture. Engineer value: Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states. Company value: Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy. 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.