Trade-offs accepted

PETROVA’s design optimises for audit trail and review checkpoint, not speed. This page enumerates what we gave up and why each trade is the right one.

1. Latency over consistency-of-state

Chose	Gave up
Verb round-trips through GitHub API (~30s).	Sub-second writes a database would give.

Concrete example: a fleet wants to update 10 milestones across 3 repos. PETROVA: ~5 minutes (10 verbs, ~30s each). A central database would be ~10 ms.

Why right: the verb’s purpose is each milestone change is a reviewable PR. A 30-second write that produces a reviewable PR beats a 10ms write that doesn’t. The latency is the audit checkpoint.

See no central database.

2. Narrow verb surface over flexibility

Chose	Gave up
Nine fixed verbs covering enumerable petrova-shaped operations.	Generic “update anything” capability.

Concrete example: a fleet notices a typo in a consumer’s README.md. There is no fix_readme_typo verb. The closest fit is request_review with the new file contents.

Why right: every operation that isn’t in the catalogue is a gap that should surface to a human. New verbs are decision events (MR-6) — adding capability is deliberate, not improvised.

3. Dry-run-default over efficiency

Chose	Gave up
Every write defaults to dry-run; `--apply` is explicit.	Single-step “just do it” execution.

Concrete example: a fleet running an automated remediation loop runs each verb twice — dry-run for diff preview, then apply.

Why right: the dry-run output is the human-reviewable hand-off point. Skipping it is occasionally legitimate (standing-instruction loops) but the default forces a checkpoint at every novel operation.

See dry-run vs apply.

4. Schema rigidity over expressiveness

Chose	Gave up
Every verb input validates against a JSON Schema before any side effect.	Free-form arguments and “just figure it out” semantics.

Concrete example: propose_fix requires mr_grounding[].kind to be one of five enum values. Inventing kind: "operator-judgment" fails with FIELD_ENUM at validation time, before any GitHub call.

Why right: the schema is the contract. A loose contract drifts; a rigid contract evolves through deliberate edits with a paper trail (via schema fingerprints).

5. Registry-as-source over inference

Chose	Gave up
`registry.yaml` declares every governed repo by hand.	Auto-discovery via “scan the org and onboard everything.”

Concrete example: a new repo in the kahn-hq org doesn’t become petrova-governed automatically. It needs an explicit request_review PR adding it to registry.yaml.

Why right: the registry is the security boundary. Auto-discovery would mean any new repo in the org silently gains write capability exposure. Explicit registration forces an intent gate.

6. PRs over direct pushes (even from the operator)

Chose	Gave up
Every write — including operator-led control-plane edits — goes through PR review.	Speed of “just push the fix” for trivial changes.

Concrete example: the operator wants to fix a typo in META-RULES.md. The mechanism is still a PR (potentially auto-merge on a permissive-profile repo, but PETROVA-HQ itself is strict, so human review).

Why right: the absence of a “trusted operator” bypass is itself the point. An audit trail with holes isn’t an audit trail.

7. Human-in-the-loop persistence

Chose	Gave up
Strict-by-default profiles; auto-merge is explicit, scoped, and never on the control plane.	Hands-off agent operation across the entire fleet.

Concrete example: even with kahn-implementer listed in fleets_allowed for kahn-hq, that fleet can only request_merge_when_green (auto-merge) on permissive-profile repos. kahn-hq is standard, so the fleet’s PRs need a human approver.

Why right: the system’s purpose is disciplined execution, not autonomous execution. Trade was deliberate.