# 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. ## DDEV — Make local development reproducible without hiding dependencies A fictional support portal requires a database, cache, object store, and mail catcher. Setup lives in personal notes, reset scripts sometimes target shared resources, and offline work fails after package caches are cleared. Build a local-only development contract with synthetic data; no shared staging system or production credentials are supplied. **Field:** DevOps. **Suggested stack:** TypeScript, Containers, PowerShell and POSIX shell, Local services. **Engineer value:** Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. **Company value:** Reduce onboarding and support cost while making local dependencies and destructive operations explicit. **Delivery agreement:** Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook. ### Setup prerequisites - Environment variables - Service health - Database migrations ### Make the delivery contract visible Replace implicit workflow assumptions with reviewable inputs and outcomes. #### DDEV-101 — Turn the setup notes into one preflight report **Task · Medium priority · Foundational** noCV practice brief v5 · DDEV-101 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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 new developer follows six documents and reaches application startup before learning that the required runtime version is unsupported. Acceptance criteria - Preflight checks runtime, package manager, container engine, ports, and required files - Each result says detected, required, and remediation - Checks are read-only and return one aggregate status Implementation constraints - Do not install software or change host settings from preflight. Verification - Run against a complete declared fixture environment. - Simulate multiple missing dependencies and report all of them in one pass. Deliverables - Read-only preflight command and environment fixtures Rollout and recovery: Link preflight from the existing setup guide before removing manual checks. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-102 — Start local services only after validating port ownership **Bug · Medium priority · Foundational** noCV practice brief v5 · DDEV-102 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DDEV-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Platform 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. Bootstrap sees a port in use and assumes the expected database is running, but the listener belongs to another application. Acceptance criteria - Readiness validates protocol and fixture service identity - Port collision names the port without terminating the owner - Bootstrap records which processes or containers it started Implementation constraints - Never kill an unknown process or bind beyond loopback in this exercise. Verification - Reuse a healthy owned fixture service and start a missing one. - Place an unrelated listener on the port and fail with remediation. Deliverables - Service identity probes and collision tests Rollout and recovery: Require identity checks before automated startup. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-103 — Apply migrations exactly once during concurrent bootstrap **Story · Medium priority · Intermediate** noCV practice brief v5 · DDEV-103 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Make the delivery contract visible. Depends on: DDEV-102. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Two local application processes start together and both run the same migration, leaving one failed and the schema state unclear. Acceptance criteria - Migration ownership uses the database-supported lock - Waiters observe the final applied version - Failure leaves the migration retryable and visible Implementation constraints - Use migrations; do not replace the workflow with schema push. Verification - Start two bootstrap processes against an empty fixture database. - Interrupt the migration owner and verify a later run can safely resolve state. Deliverables - Migration coordination and concurrent-start test Rollout and recovery: Keep manual migration available until the bootstrap path is repeatable. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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 change and failure Add bounded concurrency, authority checks, and restart-safe transitions. #### DDEV-104 — Seed deterministic accounts without creating duplicates **Chore · Medium priority · Intermediate** noCV practice brief v5 · DDEV-104 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · 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. Every bootstrap appends another demo organization and screenshots depend on whichever duplicate is returned first. Acceptance criteria - Seed identities are stable and unique - Repeated seed reconciles declared values idempotently - User-owned local additions remain untouched Implementation constraints - Synthetic fixtures must be clearly labeled and never selected outside local Demo mode. Verification - Seed twice and compare identities, counts, and relations. - Change one fixture revision and verify an intentional update without duplicate rows. Deliverables - Versioned seed reconciler and repeat-run tests Rollout and recovery: Require explicit local Demo mode before seeding. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-105 — Reset only resources created by this workspace **Task · High priority · Advanced** noCV practice brief v5 · DDEV-105 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-102, DDEV-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A cleanup command deletes every container with a generic project label, including another checkout's database. Acceptance criteria - Workspace identity is stable, explicit, and included on owned resources - Reset previews exact absolute targets and service identities - Foreign and ambiguous resources are refused Implementation constraints - The command operates only on generated local fixtures and requires an explicit reset flag. Verification - Preview and reset one isolated fixture workspace. - Add a second workspace and an ambiguous unlabeled resource, then prove both survive. Deliverables - Scoped reset command and cross-workspace safety tests Rollout and recovery: Ship preview-only first and document recovery limits. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-106 — Report readiness by dependency instead of waiting blindly **Bug · High priority · Advanced** noCV practice brief v5 · DDEV-106 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-102, DDEV-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. Bootstrap sleeps thirty seconds, then starts the application even if object storage is still initializing or the database failed permanently. Acceptance criteria - Each dependency has a bounded identity-aware readiness probe - Transient and terminal failures have separate retry behavior - Overall report shows ready, waiting, failed, and skipped dependencies Implementation constraints - Use injected time and local probes; fixed sleep is not readiness. Verification - Start dependencies with staggered readiness and complete when all required services pass. - Return a permanent schema error and stop retrying with an actionable report. Deliverables - Dependency readiness graph and timing tests Rollout and recovery: Display reports beside the existing startup path before enforcing them. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-107 — Support an offline bootstrap from a verified local cache **Story · High priority · Expert** noCV practice brief v5 · DDEV-107 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Control change and failure. Depends on: DDEV-101, DDEV-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 60% · Developer tooling 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. Developers lose network access during an incident rehearsal and bootstrap cannot tell which packages and service images are already available locally. Acceptance criteria - Offline manifest lists exact package and image digests - Bootstrap verifies every cached artifact before use - Missing items produce a complete acquisition list without partial startup Implementation constraints - Do not bypass integrity checks or contact a network when offline mode is selected. Verification - Bootstrap from a complete verified cache with network access denied. - Remove and corrupt separate artifacts and report both before starting services. Deliverables - Offline manifest, verifier, and disconnected tests Rollout and recovery: Treat offline support as explicit mode with a generated cache preparation step. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. ### Operate and improve Measure the workflow, rehearse recovery, and document ownership. #### DDEV-108 — Keep Windows and POSIX commands behaviorally equivalent **Chore · High priority · Advanced** noCV practice brief v5 · DDEV-108 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DDEV-101, DDEV-105, DDEV-106. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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 PowerShell reset resolves symlinks differently from the POSIX script and deletes a fixture path the other implementation refuses. Acceptance criteria - Both entry points call one typed cross-platform core - Path, quoting, exit status, and signal differences have contract tests - Unsupported platform behavior fails visibly Implementation constraints - Tests use temporary directories and do not invoke destructive commands through another shell. Verification - Run the shared fixture matrix through both thin entry points. - Use paths with spaces, links, and metacharacters and compare safe outcomes. Deliverables - Cross-platform command core and parity report Rollout and recovery: Keep platform scripts as wrappers and review every behavioral difference. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-109 — Diagnose local startup without collecting source or secrets **Task · High priority · Expert** noCV practice brief v5 · DDEV-109 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DDEV-106, DDEV-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 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. A support bundle recursively archives the workspace to explain startup failures, capturing source files and environment secrets. Acceptance criteria - Bundle allowlist contains tool versions, bounded health results, safe config identities, and recent bootstrap events - Source, environment values, tokens, database rows, and payload logs are excluded - User previews exact included files and fields Implementation constraints - Use sentinel secrets and synthetic source fixtures to prove exclusion. Verification - Generate a useful bundle for a failed readiness probe. - Place sentinels in every prohibited source and confirm none appear in archive bytes. Deliverables - Redacted support bundle and leak regression suite Rollout and recovery: Keep bundle generation local and user initiated. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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. #### DDEV-110 — Prove onboarding from a clean machine profile **Bug · Medium priority · Intermediate** noCV practice brief v5 · DDEV-110 · Make local development reproducible without hiding dependencies Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Operate and improve. Depends on: DDEV-104, DDEV-107, DDEV-108, DDEV-109. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: DevOps 70% · Developer tooling 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 setup succeeds only on long-lived developer machines that already contain undeclared packages and cached service state. Acceptance criteria - Test starts from a declared clean profile with empty workspace-owned state - Online and prepared-offline paths produce the same fixture application behavior - Duration report separates downloads, builds, migrations, seeds, and readiness Implementation constraints - The profile is a local disposable fixture, not a production host image. Verification - Complete onboarding twice from clean profiles and compare outcomes. - Remove one declared prerequisite and verify preflight fails before mutation. Deliverables - Clean-profile onboarding rehearsal and timing report Rollout and recovery: Use the rehearsal in documentation review before changing team onboarding policy. Project prerequisites: Environment variables Service health Database migrations Engineer value: Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality. Company value: Reduce onboarding and support cost while making local dependencies and destructive operations explicit. 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.