Skip to content

What is PETROVA?

PETROVA is a control plane for the petrova line — a set of repositories you run with disciplined, MR-compliant methodology (decisions, milestones, verification rounds, append-only ledgers) and want to operate consistently across.

It centralises how you work — methodology, action verbs, the registry of governed repos — and leaves what each repo is for inside that repo. Every action it takes against a governed repo becomes a reviewable PR with a stable audit trail.

┌───────────────────────┐
│ Agent fleet │ diagnose, plan, draft proposals
└──────────┬────────────┘
│ verb call
┌───────────────────────┐
│ PETROVA control plane│ schema-validate · check registry ·
│ │ enforce dry-run · emit PR
└──────────┬────────────┘
│ PR (with audit metadata, idempotency key)
┌───────────────────────┐
│ Consumer repo │ branch protection, CI, review gate
└───────────────────────┘

See the full boundary diagram for what crosses each arrow.

  1. Duplication. Methodology files (META-RULES, agent-fleet shape, prompt conventions) used to be copied into each consumer repo and drift. PETROVA centralises them.
  2. No cross-repo visibility. No aggregate view of phase status, open decisions, or milestones across the fleet. PETROVA provides petrova status and petrova dashboard.
  3. No agent-fleet write path. Agent fleets could diagnose but had no disciplined, MR-compliant way to act. PETROVA’s nine verbs are exactly that path.

PETROVA’s value lives in three meta-rules every operation upholds:

  • MR-7 — decision docs are append-only, dated, in-repo. The verbs never edit closed decisions; supersession is via a new dated doc.
  • MR-10 — verification rounds are mandatory at every phase close. The verify_round verb and the close_phase verb encode this together.
  • MR-12CLAUDE.md is a projection, not a source. Project intent lives in docs/north-star/; the doc site projects from there but never invents.

See load-bearing invariants for concrete examples drawn from PETROVA’s own evolution.