Skip to content

2026-09-29 — Per-consumer decision front matter; mary-wiki opts in (F-080 upstream)


2026-09-29 — Per-consumer decision front matter; mary-wiki opts in (F-080 upstream)

Section titled “2026-09-29 — Per-consumer decision front matter; mary-wiki opts in (F-080 upstream)”

Date: 2026-09-29 Status: closed Verb: petrova_act_registry_edit (plus a code change to cli/src/decision-doc.ts) Slug: mary-wiki MR-compliance: MR-7, MR-12 Supersedes: none Superseded-by: none — current

Every decision doc a petrova verb emits (open_decision, start_phase, close_phase, verify_round) starts at the H1 with no YAML front matter. mary-wiki’s publication law (PUB-SPEC §1) fails closed on a document with no classification, and a merge to its main is its production deploy. mary-wiki recorded this as its finding F-080 on 2026-08-12 and has worked around it since by stamping each emitted doc by hand before merge.

The manual step failed on 2026-09-27/28. Three emitted decisions merged unstamped, and mary-wiki’s pub-gate has refused main on every push since 2026-09-28 05:36Z. Nothing has published there since. (mary-wiki is private without branch protection, so a red gate does not block merge.) F-080 names the upstream fix as its disposition 2: “Ask petrova to emit front matter … it would have to be configurable, since classification is MARY’s field and not every consumer has one.” It also notes that the fix is not MARY’s to perform (FR-011: repairs flow one way). This document is that fix, on petrova’s side of the seam.

  1. registry.yaml repo entries gain an optional decision_front_matter map (lower-snake keys, single-line string values; registry.schema.json). The field is governance-owned and edited like any other registry field.
  2. renderDecisionDoc writes that map as a YAML front-matter block when it is present, adding title and status from the verb input unless the map sets them. The house bold header (**Status:** etc.) is still written below it, so repo-walker’s status read and every existing parser behave as before. When the map is absent, output is byte-identical to today, so no other consumer changes.
  3. mary-wiki opts in with classification: INTERNAL, rank: decision. These are the fail-closed default PUB-SPEC already assumes for an unmarked document, and exactly what the manual F-080 stamp adds. petrova asserts nothing about mary-wiki’s classification that mary-wiki does not.
  • Keep the manual stamp (F-080 disposition 1). Rejected. It failed three times in two days, and each failure blocks a production deploy.
  • Always emit front matter for every consumer. Rejected. classification is MARY’s vocabulary, not the fleet’s, and most consumers’ docs would gain fields nothing reads.
  • Read the field from the consumer’s .petrova/contract.yaml. Rejected for now. Contracts are generated (“DO NOT hand-edit”), and the verbs already hold the registry entry (build.repoEntry) without a network read. This can be revisited if consumers need to self-declare it.
  • cli/src/decision-doc.ts: front_matter? input and renderFrontMatter.
  • cli/src/verbs/{open_decision,start_phase,close_phase,verify_round}.ts: pass build.repoEntry.decision_front_matter through.
  • cli/src/types.ts, registry.schema.json: the optional field.
  • registry.yaml: repos[mary-wiki].decision_front_matter.
  • cli/tests/decision-doc-front-matter.test.ts: absent → unchanged; present → parseable YAML with the consumer’s fields plus title/status; consumer overrides win; mary-wiki declares classification.
  • The host on Railway serves the verbs, so the fix takes effect for MCP callers only after the host is redeployed.
  • mary-wiki still has to clear the three already-merged unstamped documents itself. That is proposed in mary-wiki’s docs/decisions/2026-09-29-pub-gate-red-on-main-proposed.md (local draft, pending FLIGHT). Once this lands, mary-wiki can decide whether F-080 closes.
  • Subagent: Claude Opus 5.5, 2026-09-29 (drafted; code and registry edit in the same PR)
  • Human: flight@arno.host