Skip to content

Forcing function: register a change's new dependencies in pdca doctor (don't discover them as cryptic build failures) #263

Description

@eduralph

Routed from a downstream Act review (getwyrd/wyrd-pdca, 2026-07-07).

Principle

When a change introduces a dependency a human must install or provide — a build tool, a system lib, a runtime service, a required capability — the system must register it: list it in pdca doctor (with an install hint) and prompt the human, rather than letting it surface mid-cycle as a cryptic build/runtime failure. Registration should be a forcing function, not best-effort.

Evidence — the reactive-registration gap

The brief template already softly directs this — the External dependencies field says "enumerated at Plan so they preflight (seed the render's [[doctor.checks]] where you can)" — but "where you can" is not a forcing function, so registration kept happening reactively.

Proposed scope (implementation later)

  1. Brief template (templates/brief.md.tpl, External dependencies): make doctor registration mandatory — every declared external dependency a human installs/provides MUST have a matching [[doctor.checks]] row (a cmd that detects it + an install hint); a declared dep with no row is a Plan-exit gap.
  2. Builder skill (agents/builder.md): when Do discovers/introduces a dependency, it must also propose its [[doctor.checks]] row (id / detect-cmd / hint / level) in build-notes.md, alongside the existing NEEDS-HUMAN external dependency marker.
  3. Reviewer skill (agents/reviewer.md): raise NEEDS-HUMAN when a build/runtime dependency the bundle relies on — a brief External dependencies entry, a newly-enabled Cargo feature/dep, or a Do-discovered prereq — has no matching [[doctor.checks]] row ("register before accept").
  4. (Stretch — mechanism): pdca doctor / the driver reconciles declared External dependencies (and/or added Cargo deps) against the registered doctor rows and warns on any unregistered one; optionally surface the install hint as an actionable prompt.

Downstream instance follow-up (getwyrd/wyrd-pdca)

Once the convention lands, register the concrete already-known deps: protoc (etcd feature build, WARN — parallel to the existing docker/openssl rows) and audit that docker/openssl coverage is complete.

Related (this project): the doctor rows live in pdca.toml (instance data, getwyrd/wyrd-pdca#96 added docker+openssl); this issue is the generic template + skills + mechanism side.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions