spec-producer-governance

name	spec-producer-governance
description	Partial Skill: invoke by name only — the SDD default spec-producer procedure. Loaded in-session by the conductor when it runs the spec-producer role inline, not user-triggered.
user-invocable	false

Spec-Producer Governance — the default authoring procedure

The procedure the conductor follows when it runs the spec-producer role from the SDD default — i.e. no plugin covers the domain and no model-tuned producer agent is named for the slot, so the conductor loads this governance and authors inline in its own warm context (recorded produced-by.spec-producer: sdd:automaton). The grader is separate — a cold spec-judge (sdd:sdd-spec-judge or the plugin's judge) always reviews the output; this governance never judges its own work.

Load alongside this governance: sdd:spec-format-governance (the required ## Use Cases section and the spec.md enrichment / human-readability rule), sdd:suite-format-governance (the .feature format bar and scenario-ordering convention), and the resolved oracle, builder, and architect actor bars — forward face — to self-align before writing (scope and kill-or-ship, testability/coverage, structural fit). These are exactly the bars the spec-judge grades backward at the spec gate, so the producer self-aligns to the same lens set it will be graded against. Load sdd:ownership-governance for the write-ownership matrix — which fields the spec-producer may write and which belong to the conductor or the gate skill.

Track every governance you load. The spec-judge cannot otherwise tell a skipped pre-flight from a correctly run one — both look like the same output gap. Keep a running list of each governance name as you load it (this governance plus every bar named above) and declare the full list as governances_loaded in your structured output — a required field, listed even when empty, and never written into spec.md or the .feature.

Inputs (folded in by the conductor)

DOMAIN, DOMAIN_PATH, SPEC_PATH
COMMAND_SURFACE:  <command syntax / signatures / events — or null>
DESIGN_DECISIONS: <known choices — or null>
USER_INPUT:       <What / Why / command surface for a new feature — or null>
BACKFILL:         <true if implementation already exists>
JUDGE_FEEDBACK:   <spec-judge SCENARIOS_FAILING / BLOCKER from a prior pass — or null>
USER_ANSWERS:     <answers to previously returned QUESTIONS — or null>

Procedure

1. Gather intent, grilling breadth-first and depth one-at-a-time. First scan the request holistically and summarize every issue; then drive the single most important to resolution before the next — one deep thread, not many shallow. For BACKFILL, read source, tests, and history and infer What / Why / decisions / surface; otherwise use USER_INPUT. A required input that is missing and cannot be inferred becomes a CONTENT_GAP (an <!-- open: --> marker), never an invention. Revision pass (JUDGE_FEEDBACK non-null): fix only the failing scenarios / sections; fold in USER_ANSWERS. Settle the prose before touching the suite — scenarios authored against unsettled prose chase a moving target.

2. Reconcile contradictions toward the correct answer, not the popular one. When grilling surfaces a conflict — between the spec.md body and the .feature, between either and the design rules or the implementation, or between two rules — do not guess, and do not just count which reading more files repeat. Zoom out and reason about which is actually right given the design's intent and the whole model; weigh the evidence (the canonical definition, what the implementation does, which decision is most recent and authoritative) to find the coherent answer. Edit the side that is wrong; never reword a rule merely because more files echo it. If the correct answer cannot be established, return a CONTENT_GAP rather than picking a direction.

3. Write the spec.md body per sdd:spec-format-governance. That bar owns the required structure — the ## Use Cases section (subject, non-goals, and per use case its actor / goal, entry point, and extensions, plus the surface-element trace) and the enrichment rules; follow it rather than re-listing sections here (a hardcoded list drifts from the bar).

   Find the use cases before you name them. A use case is discovered from the situation the change serves, not derived from the interface you already have in mind — deriving it from the surface reproduces the surface and calls it a requirement. Enumerate by actor, never by entry point (sdd:spec-format-governance owns the ordering): walking the interface returns only the use cases it already implies and is blind to the one nobody built. List the actors first — every person in a role, sibling capability, scheduler, or operator that reaches this capability, plus whoever is affected by its outcome without invoking it (the reviewer, the on-call, the next agent). they arrive with — their result, not the call they make; where the answer restates the mechanism ("the caller wants to call it"), you have renamed the function, not found the use case, and the honest move is a , never a plausible actor you invented. , and report both mismatches: a goal with no entry point is a way in the capability lacks or a goal another node owns, and an entry point serving no listed goal is surface nobody asked for. On the source yields only the use cases by construction — recover the unserved ones from the request history, the issue tracker, and recurring workarounds, and record where each came from rather than presenting an inferred set as complete. — walk each use case for . That criterion decides membership; the recurring kinds (the refusal, the error, the boundary, the partial result, the contended or absent input) are a ( owns the criterion — a divergence matching none of them still belongs, and a kind that cannot arise is not owed a row). Where nothing can diverge, write , so the claim is visible and contestable rather than absent. — take each element the capability exposes (flag, option, parameter, prop, event) and name the use case that needs it and the elements it may not be combined with. An element you cannot attribute to a use case is the finding, not an oversight to fill in: raise it, because the Oracle bar's verdict on it is cut-or-justify.

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
SCENARIOS_WRITTEN:  <count>
NOTES:              <what was written / revised>
GOVERNANCES_LOADED: [ every governance name loaded before writing — required, [] when none, never written into spec.md or the .feature ]
QUESTIONS:          [ batched, when needs-input ]
CONTENT_GAPS:       [ { artifact, location, gap } ]   # become <!-- open: --> markers
OBSERVATIONS:       [ { owner: architect | strategist, note, evidence } ]