Template / output-contract enforcement per label

[MeatPopSci1972]

Output contracts: per-label template enforcement

Part of Issue Contracts (umbrella: #57).
Depends on **Issues #58, #59, and #60 ** being complete.

Context

/verify-issue (issue #58) checks that for_cowork issues have required sections (## Steps, ## Done when, ## Do not touch). That's the starting point of template enforcement.

This issue extends the idea: each routing label has an output contract — a defined shape that issues carrying that label must match. The verification endpoint enforces the shape. Issue bodies that don't match get flagged as contract violations.

The output contracts

rfc output contract

An RFC issue must contain:

• Problem statement — what's broken or unclear
• Proposed design — the architectural move, not implementation details
• Gate condition — what triggers promotion out of RFC
• Out of scope — what this RFC is deliberately not addressing

An RFC without a gate condition has no exit criteria. An RFC without "out of scope" will expand in review. Both are contract violations.

for_cowork output contract

A cowork issue must contain (already in #58 , extended here):

• Context — why this issue exists
• Steps — concrete, tool-call-referencing actions
• Done when — machine-checkable criteria (gate URLs, pass counts, file existence)
• Do not touch — explicit file/scope exclusions
• Out of scope — what's deliberately deferred to follow-up

for_session output contract

A session issue must contain:

• Context — the situation requiring judgment
• Decision point — the explicit question or choice
• Options — at least two defensible paths
• Constraints — what limits the decision

regression / hotfix output contract

A regression/hotfix issue must contain:

• Reproduction — steps or gate URL that shows the failure
• Expected behavior — what should happen instead
• Observed in version — SF_VERSION where the failure appeared
• Blast radius — what's affected, what isn't

Verification extensions

Add to /verify-issue universal checks (new template-compliance profile):

Check	Severity	Description
Template compliance	warn for new labels, error for stable labels	Body must contain all required sections for the label's output contract.

Severity is nuanced: for a freshly-adopted label taxonomy (like rfc before it was codified), enforcing is aggressive. For the current stable set, violations are errors.

Steps

1. Define output contracts in code as a LABEL_TEMPLATES object — keys are label names, values are arrays of required section headers
2. Implement checkTemplateCompliance(issueBody, label) returning { missing_sections, ok }
3. Wire into existing /verify-issue profile for each routing label
4. Create template files in templates/ folder:
   • templates/rfc.md
   • templates/for_cowork.md
   • templates/for_session.md
   • templates/regression.md
5. Link templates from HANDOFF.md Issue Contracts section
6. Optional: add GitHub issue templates (.github/ISSUE_TEMPLATE/) that match the output contracts
7. Audit existing open issues — flag ones that fail template compliance
8. Fix or label existing issues that fail

Done when

• LABEL_TEMPLATES defined in server code
• Template compliance check wired into /verify-issue for all routing labels
• Template files exist in templates/ folder
• HANDOFF.md links to templates
• Suite 16 tests pass under GET /test
• Audit report: all currently open issues either comply or have remediation plan
• At least one new issue created via the template to validate the shape

Do not touch

• Label colors (finalized in issue Label color-coding + HANDOFF.md workflow update markdown #60 )
• Endpoint response shape beyond adding template-compliance entries
• Issue bodies that are already compliant

Out of scope

• Forcing compliance retroactively on closed issues
• Natural-language template detection (exact section header match only for now)
• Multi-label template merging (an issue with both rfc and for_cowork is rare; cross that bridge if it appears)

Why this completes the umbrella

Issue #58 verifies the AI can safely engage. Issue #59 tells it how. Issue #60 communicates contracts visually. Issue #61 makes the contracts enforceable at authoring time — so issues are well-formed before an AI ever sees them.

The full Issue Contracts system: labels control engagement, knowledge guides the work, templates enforce the shape. At that point, the AI picking up an issue has structural guarantees about what it's reading, what's required, what principles apply, and how to proceed.