Meta-Rules MR-1..MR-15 Invariants

ELI5

The meta-rules are the constitution sitting above each project’s local laws. Local invariants I-N describe what your specific code must do; meta-rules MR-N describe how docs, decisions, agents, and phases must behave so the system that governs the code does not rot underneath it.

Technical Deep Dive

The 15 rules at a glance

classDiagram
  class MetaRules {
    +version: 1.1
    +scope: cross-project
  }
  class Rank {
    MR-1 north-star outranks backlog
    MR-12 CLAUDE.md is projection not source
  }
  class Phase {
    MR-2 friction → next phase, never retrofit
    MR-10 verification round mandatory at close
    MR-11 anti-shapes named + watched
  }
  class Decisions {
    MR-4 ISO dates absolute
    MR-7 decision docs append-only
    MR-8 invariants numbered + stable
    MR-9 do not invent invariants
  }
  class Agents {
    MR-3 sibling files stay sibling
    MR-5 PR vs direct-push boundary
    MR-6 subagents read AGENTS.xml not patterns
  }
  class Observation {
    MR-13 intent != observation state
    MR-14 probes auto-demote, never auto-promote
    MR-15 schema is the source of bootstrap questions
  }
  MetaRules --> Rank
  MetaRules --> Phase
  MetaRules --> Decisions
  MetaRules --> Agents
  MetaRules --> Observation

Load-bearing trio

Three rules carry most of the weight (cited in petrova-hq/CLAUDE.md as “load-bearing invariants”):

1. MR-1 (rank graph) — every doc declares rank: and outranks: in front-matter; the outranks graph must be a DAG. Drift-watcher and CI both consult it.
2. MR-7 (append-only) — closed decision docs are never edited. To revise a verdict, write a new dated doc with ## Supersedes and prepend a > **Superseded** by ... blockquote to the old one. Both lineage halves remain readable.
3. MR-10 (verification round) — every phase close runs prompts/03-verification-round.md, even when the phase felt smooth. The reviewer subagent has a <refusal_condition> for closing without one.

The phase-close pair: MR-2 + MR-10

These two rules together prevent the most common failure mode — letting a closing phase absorb new friction:

• MR-10 forces the round to run.
• MR-2 classifies its output: closed (trivial only), in-budget (acceptable carry, justified inline), deferred (must be assigned M(N+1).x.y in the same commit as the phase-close decision doc). You do not extend the closing phase to absorb friction.

Observation rules (1.1, ratified 2026-04-30)

MR-13/14/15 entered with version 1.1. They defend against the integration-spine subsystem mixing intent with observation:

• MR-13 — .petrova/contract.yaml declares intent; petrova-hq/state/<slug>.yaml records observation. They MAY disagree; the dashboard surfaces the delta. Conflating them is how dashboards start to lie.
• MR-14 — petrova doctor may demote current_status (ok → degraded → failing) but MUST NOT promote a consumer’s contract from pending → wired. Promotion requires a human PR pasting evidence; the next probe round confirms.
• MR-15 — bootstrap questions in 00-bootstrap.md Phase 6 are generated from contracts/contract.schema.json. Hand-editing the prompt without a corresponding schema change is a CI failure. The schema is canonical; if a question can’t be grounded in it, the prompt is asking something it can’t validate later.

Enforcement layers

Updating a meta-rule

Changing one is heavier than changing a project invariant: open a decision doc, get explicit human approval, update referencing prompts and CI, bump the version in META-RULES.md’s footer. No agent self-modification of meta-rules.

Key Terms

• MR-N — a meta-rule, applies across all phases, all subagents, all consumer repos. Numbered to distinguish from project invariants I-N.
• Outranks graph — the directed graph implied by every doc’s outranks: front-matter; required to be a DAG (MR-1).
• Friction budget — the ## Friction budget section of every phase-close decision doc; the place MR-2 classifications land.

Q&A

Q: What’s the difference between an MR-N and a project’s own I-N invariant? A: MR-N is cross-cutting (applies to every petrova-line repo). I-N is project-local — KAHN’s “I-1: Scope writes only under .kahn/archive/” is meaningful only inside KAHN. MRs are governed by petrova-hq; I-N is governed by the consumer’s own decision-doc lifecycle.

Q: Which two MRs together prevent a closed phase from being silently retrofitted? A: MR-10 forces a verification round; MR-2 forces friction items to either close (trivial only), justify in-budget, or get a milestone ID in phase N+1 within the same commit as the close. Skipping either re-opens the retrofit door.

Q: How do MR-13 and MR-14 separate intent from observation? A: MR-13 puts contract (intent) in the consumer repo and probe state in petrova-hq’s state/. MR-14 says probes may auto-demote observation but never auto-promote intent — promotion is human-only via PR. Together they guarantee the dashboard’s declared and observed columns can disagree without either silently rewriting the other.

Examples

A reviewer is closing Phase 6 of KAHN. The verification round surfaces three items: a typo in a runbook (closed — trivial), a partial telemetry seam they accepted as acceptable carry (in-budget — one-sentence justification), and a redesign of the live-dot UI they cannot finish in this phase (deferred — gets M7.2.1 written into MILESTONES.md before the phase-close decision doc commit lands). MR-2 + MR-10 enforced mechanically.