Skip to content

feat(doctor): environment readiness pre-checks — Docker daemon and WSL credential-store traps #28

Description

@PeterGuy326
schemaVersion: requirement-record.v1
revision: R1
status: needs-design
priority: P0
productOwner: "@PeterGuy326"
technicalOwner: "Tech P9"
userOutcome: "Before any image pull or build side effect, a new user gets a one-command readiness verdict for Docker — including the two known Windows/WSL traps — with actionable next steps instead of a dead end."
requirements:
  - REQ-001
  - REQ-002
  - REQ-003
acceptanceCriteria:
  - AC-001
  - AC-002
  - AC-003
parent: null
dependencies: []
supersedes: []
lastDecisionAt: null

User problem and observable outcome

Ops dogfood hit two mandatory traps on the official doc up --build path (both reproduced and logged 2026-08-29): (1) Docker Desktop not running → docker unavailable, full stack cannot start; docs only say "requires Docker" without a readiness check; (2) WSL + Docker Desktop: ~/.docker/config.json credsStore: desktop.exe causes fork/exec docker-credential-desktop.exe: exec format error, breaking even public image pulls — doc up --build dies at step one; ops verified recovery after removing credsStore. Both traps apply to any WSL user running doc or mem. Implementation truth belongs to Tech P9.

Observable outcome: one readiness command decides Docker health; both trap patterns are detected with stable codes and actionable guidance; pre-checks run before the first side-effectful step.

Requirements

  • REQ-001: Docker daemon readiness self-check — one command determines daemon availability; failure yields a stable code plus actionable guidance (start Docker Desktop / enable WSL integration), and onboarding docs carry the same precondition.
  • REQ-002: WSL credential-store trap detection — the credsStore: desktop.exe exec-format failure pattern is detected (or the pull failure is diagnosed to it) with a stable code and actionable remediation (credsStore removal steps); troubleshooting docs carry the entry.
  • REQ-003: Pre-effect ordering — readiness checks execute before the first side-effectful step of doc up --build (no partial pulls/builds before the verdict); fail-closed ordering is asserted.

Acceptance criteria

  • AC-001: Daemon-down fixture — readiness check fails with stable code + actionable guidance; no side effects occur before the verdict.
  • AC-002: CredsStore-trap fixture (simulated config) — detected with stable code + remediation guidance; the documented fix restores pulls (ops-verified recovery as evidence input).
  • AC-003: Ordering fixture — a failing readiness state prevents the first pull/build step; docs/troubleshooting entries present.

Non-goals and forbidden shortcuts

  • No Docker Desktop automation (no auto-start of the daemon); detection + guidance only.
  • No changes to image composition or compose topology.

Lifecycle, status, priority, blockers, and open decisions

  • status=needs-design; priority P0; technicalOwner=Tech P9.
  • Blockers: none.
  • Open decision: mem-side cross-link — the same traps hit mem onboarding; this record lives in doc (the doc doctor surface) and mem onboarding docs cross-reference it (see the mem onboarding companion issue), unless tech adjudication prefers a shared tooling home.

Evidence plan

  • Fixtures plus docs entries; ops reproduction logs (docker_cfg_fix.log) as evidence input.

Decisions

  • DEC-DOC-28-001 (2026-08-29T02:26:00Z): issue created per founder-approved dogfood intake (2026-08-29); ops reproduction logs are evidence input; implementation truth belongs to Tech P9.

Revision history

  • R1 (2026-08-29T02:26:00Z): initial record created per founder-approved draft B (dogfood P0 environment readiness).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:infraStorage, migrations, security, and operationspriority:p0Required for the next shared product proofstatus:blockedCannot progress until the documented dependency is resolvedtype:featureA focused user-facing capability

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions