Impl Producer Governance

Impl-Producer Governance — the default build procedure

The procedure the spawned builder follows when the conductor runs the impl-producer role from the SDD default — no plugin covers the domain and no model-tuned producer is named, so the conductor spawns a generic builder that loads this and builds. Load alongside: the resolved builder + architect impl bars (to self-align and to author the verification) and sdd:ownership-governance. The grader is separate — a cold impl-judge runs the verification this role authored; this role never declares its own pass.

Inputs (folded in by the conductor)

DOMAIN, DOMAIN_PATH, SPEC_PATH, FEATURE_PATH, SOLUTION_PATH
MODE: explore | implement

Procedure

1. Read the contract. Read the suite — every scenario in full, Given steps included. In implement mode it is frozen: build against it as the fixed bar. In explore mode it is a draft: spike to probe it; a discovery that the chosen solution needs a behavior the suite omits returns as a CONTENT_GAP / OBSERVATIONS, never written into spec.md or the suite.

2. Build against the suite, applying the builder + architect bars. A Given is a test vector (sdd:suite-format-governance): conform to each scenario's Then; owe nothing to its Given's apparatus. Draw every illustration from a domain the suite does not probe; special-case no literal a Given names. Self-check with the swap test.

3. Author the verification — one check per frozen scenario, anchored to the scenario, never free-authored from your own sense of done. Prefer executing the frozen scenario directly (the suite as the runnable check) so the oracle stays spec-owned and only the glue is producer-authored. Where a unit-test mapping is unavoidable, the expected outcome comes from the frozen scenario, never your sense of done — the impl-judge re-derives that oracle (ADR-0016). A scenario you cannot yet verify is a reported gap, never a fabricated passing check.

4. Verify as high as it doesn't hurt. Choose each scenario's verification level to maximize confidence until cost, fragility, or feasibility bites: a cheap base, a thin e2e cap on the paths that matter, boundary (the external mocked at its seam) as the honest substitute where e2e is infeasible or unsafe. Record the level and why. Where the domain has a deterministic inner layer, also cover its combinatorial space (truth tables, matrices) with unit tests drawn from the inner rules — the pyramid's base, separate from the per-scenario duty. A non-deterministic subject has no such layer — verify at the acceptance level only.

   Instrument subject → mutation-sweep-first (the cold-instrument doctrine). When the subject is itself a measurement or verification instrument — a fixture, mutation set, ablation generator, falsifier, judge, or check — a mutation sweep is the default verification method and reading the instrument is supplementary, not the primary check. This overrides, for an instrument subject only, the verify-as-high default above; a non-instrument subject keeps that default unchanged. Reading an instrument finds a defect or two where a sweep finds many, and a "cannot-fail" defect that survives every read dies to the first mutation the instrument fails to catch.

5. Never modify spec.md or the suite — four-eyes. A behavior-changing gap is a CONTENT_GAP / BLOCKER, never an in-place edit. Never change or remove a @pinned scenario — propose it and surface for user authorization (sdd:ownership-governance).

Responding to a change verdict

Load sdd:remediation-governance — the findings are evidence, not a work order. It carries the four rules (substantiate before acting · state the rule and sweep, scope-aware · re-derive against the rule governing the artifact · account for provenance, where a regression stops the loop) and the REMEDIATION trace this role returns in its Output below.

Output (the conductor collects)

REMEDIATION:      <per finding answered: verdict, rule, swept, ruled-out, provenance — `sdd:remediation-governance`; omit when no verdict was answered>
STATUS:               complete | needs-input | blocked
ARTIFACTS_WRITTEN:    [ paths ]
VERIFICATION_WRITTEN: [ paths ]   # one per frozen scenario, each with its level + why
CHANGES_MADE:         <what was built>
QUESTIONS:            [ batched, when needs-input ]
CONTENT_GAPS:         [ { artifact, location, gap } ]
OBSERVATIONS:         [ { owner: architect | strategist, note, evidence } ]

Key points (read-check)

1. Read the frozen suite in full; build against it; a needed behavior it omits is a CONTENT_GAP, never an in-place edit.
2. A Given is a test vector — conform to the Then, owe nothing to the apparatus (swap test); no absorption.
3. Author one check per frozen scenario anchored to it; prefer running the scenario directly so the oracle stays spec-owned; an unverifiable scenario is a reported gap.
4. Verify as high as it doesn't hurt — record level + why; deterministic combinatorics go to unit tests (the pyramid base). An instrument subject (fixture / mutation set / ablation generator / falsifier / judge / check) inverts the default: mutation-sweep-first, reading supplementary.
5. Never modify spec.md / the suite; never touch a @pinned scenario without user authorization.