Skip to content
PETROVA

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.

The shape

Section titled “The shape”
%%{init: {'flowchart': {'htmlLabels': false, 'curve': 'linear', 'nodeSpacing': 60, 'rankSpacing': 70, 'padding': 14}}}%%
flowchart TD
    subgraph FLEET["agent side · proposes"]
      A["Agent fleet
diagnose · plan · draft"]
    end

    GATE{{"PETROVA
validate · gate · emit PR"}}

    subgraph REPO["repo side · enforces"]
      C["Consumer repo
branch protection · CI · review"]
    end

    A -. "verb call · unprivileged" .-> GATE
    GATE == "signed PR
audited · idempotent" ==> C

    classDef peer fill:transparent,stroke-width:1px;
    classDef gate fill:#c8631f,stroke:#7a3a10,color:#fffaf2,font-weight:600;
    class A,C peer;
    class GATE gate;

See the full boundary diagram for what crosses each arrow.

The three pains it addresses

Section titled “The three pains it addresses”
  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.

Three load-bearing invariants

Section titled “Three load-bearing invariants”

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-12 — CLAUDE.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.

Where to go next

Section titled “Where to go next”