# PETROVA > Control plane for the petrova line of repos. Centralises methodology > (META-RULES, agent-fleet shape, prompts) and a typed verb surface; > leaves project truth (north-star, decisions, milestones) in each > consumer repo. Every write is PR-emitting, idempotency-keyed, and > dry-run by default. Built around three load-bearing invariants: > MR-7 (decisions are append-only), MR-10 (verification rounds are > mandatory), MR-12 (CLAUDE.md is a projection, not a source). ## Skills (drop-in, agent-actionable) > **For agents:** load any of the gists below directly to gain > capability for that operation. Each gist is a complete SKILL.md > with workflow, refusal conditions, and cross-references. Works > in any repo (PETROVA-governed or not). | Skill | When to use | Direct link (secret gist) | |---|---|---| | `petrova-act` | performing a write verb (open_decision, update_milestone, start_phase, close_phase, verify_round, request_review, request_merge_when_green, propose_fix) — composes typed JSON, dry-runs, emits PR | [Dev4rno/e8cabaec2ddc8dc55fc7c3125d123156](https://gist.github.com/Dev4rno/e8cabaec2ddc8dc55fc7c3125d123156) | | `petrova-status` | read-only inspection — cross-repo dashboard, single-repo diagnose, MR/convention validate | [Dev4rno/8557317a13e1eb2ccd1387a8d5625b85](https://gist.github.com/Dev4rno/8557317a13e1eb2ccd1387a8d5625b85) | | `petrova-onboard` | registering a new repo into the petrova line — composes registry-update PR with role/profile/fleets_allowed derivation | [Dev4rno/39e20117322d700a17d9106247e42c3a](https://gist.github.com/Dev4rno/39e20117322d700a17d9106247e42c3a) | | `petrova-decide` | recording a non-trivial decision in PETROVA format — date-stamped, ≥2 alternatives, supersession-aware, sign-off block | [Dev4rno/507546b0eb9a616cb430c78c29c860f5](https://gist.github.com/Dev4rno/507546b0eb9a616cb430c78c29c860f5) | | `petrova-phase-cycle` | phase boundary — runs verify_round → close_phase → optional start_phase as one disciplined chain (MR-2 + MR-10 enforcement) | [Dev4rno/ff0999472bc19ced0f1f206250c9254f](https://gist.github.com/Dev4rno/ff0999472bc19ced0f1f206250c9254f) | | `petrova-mr-audit` | auditing any repo against MR-1..MR-12 — read-only PASS/WARN/FAIL table with per-rule evidence citations | [Dev4rno/43b72ecece09d1430809a6c576add671](https://gist.github.com/Dev4rno/43b72ecece09d1430809a6c576add671) | | `petrova-drift-check` | detecting drift — methodology drift, projection drift (MR-12), north-star alignment drift (MR-1) in one report | [Dev4rno/9cbf049556ec250258059e4e6e91317c](https://gist.github.com/Dev4rno/9cbf049556ec250258059e4e6e91317c) | | `petrova-boundary-check` | auditing capability boundaries — finds every script/workflow writing to privileged paths without PR review | [Dev4rno/89755680f80d994a7d5d145649eb41ac](https://gist.github.com/Dev4rno/89755680f80d994a7d5d145649eb41ac) | | `petrova-recover` | verb returned failed or --apply errored — maps error code to recovery playbook, drafts finding doc when warranted | [Dev4rno/efc08287454609e9ad5f67ca0b6d32bf](https://gist.github.com/Dev4rno/efc08287454609e9ad5f67ca0b6d32bf) | | `petrova-plan` | planning any feature/refactor with PETROVA discipline — taskset sequencing, halt gates, reuse-first scan, drift-risk callouts | [Dev4rno/34a7a9fe357c0ee18e4c63375100543e](https://gist.github.com/Dev4rno/34a7a9fe357c0ee18e4c63375100543e) | | `petrova-realign` | responding to detected drift — surveys recent work vs north-star, drafts realignment decision doc with measurable gate | [Dev4rno/d3625c1c4718d7b1cb0c660cf7e61d4a](https://gist.github.com/Dev4rno/d3625c1c4718d7b1cb0c660cf7e61d4a) | **Skill chains (common compositions):** - New repo onboarding: `petrova-onboard` → `petrova-mr-audit` → `petrova-drift-check` - Phase boundary: `petrova-status` (diagnose) → `petrova-phase-cycle` (round + close + open) - Failure response: `petrova-recover` (triage) → `petrova-decide` (record) → `petrova-plan` (sequence fix) - Quarterly audit: `petrova-mr-audit` + `petrova-drift-check` + `petrova-boundary-check` + `petrova-realign` - Feature start: `petrova-plan` (sequence) → `petrova-act` (per-taskset emission) Skill source-of-truth lives at `petrova-hq/skills//SKILL.md`; rendered docs at `https://petrova.devarno.cloud/skills/`. ## Start here - [PETROVA](https://petrova.devarno.cloud/index/): The PETROVA control plane — methodology, verbs, registry, fleets. ## Overview > What PETROVA is and how to start. - [Overview](https://petrova.devarno.cloud/overview/): PETROVA's introduction. Read What is PETROVA? first, then pick a path: - [Quickstart](https://petrova.devarno.cloud/overview/quickstart/): End-to-end from zero to a successful dry-run, in ≤5 minutes. This walks the read path; auth is needed only for --apply (last step). - [The control-plane decision](https://petrova.devarno.cloud/overview/control-plane-decision/): On 2026-04-29, after a brainstorming round weighing how to address duplication, cross-repo visibility, and agent-fleet write capability, the operator opened a d… - [Three load-bearing invariants](https://petrova.devarno.cloud/overview/load-bearing-invariants/): PETROVA upholds twelve meta-rules (MR-1 through MR-12). Three are load-bearing — without them, the system falls apart even if the others hold. This page gives e… - [What is PETROVA?](https://petrova.devarno.cloud/overview/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 … ## Concepts > Mental model: control plane, registry, verbs, fleets, profiles, idempotency. - [Boundary diagram](https://petrova.devarno.cloud/concepts/boundary-diagram/): The single most load-bearing mental model. PETROVA is a capability boundary between agent fleets and the repos they govern. Reads flow freely; writes go through… - [Concepts](https://petrova.devarno.cloud/concepts/): The mental model. Read top to bottom for first-time understanding; each page is independently load-bearing. - [Control plane vs source-of-truth](https://petrova.devarno.cloud/concepts/control-plane-vs-source-of-truth/): PETROVA splits two things most documentation systems conflate: methodology (how you work) and project truth (what the work governs). - [Dry-run vs apply](https://petrova.devarno.cloud/concepts/dry-run-vs-apply/): Every write verb defaults to dry-run. --apply is opt-in and requires authentication. The dry-run output is byte-identical to what apply would emit — the only di… - [Fleets](https://petrova.devarno.cloud/concepts/fleets/): A fleet is an agent-side identity that PETROVA admits to a repo's verb surface. Fleets diagnose and plan locally; they emit PRs through the verb layer. The flee… - [Idempotency keys](https://petrova.devarno.cloud/concepts/idempotency-keys/): An idempotency key is a 64-character hex string that uniquely identifies a verb invocation by its inputs. Re-running a verb with the same key against the same t… - [Profiles](https://petrova.devarno.cloud/concepts/profiles/): A profile is a per-repo declaration of how strict the merge gate is. It lives in registry.yaml and gates which verbs can act without explicit human approval. - [Registry](https://petrova.devarno.cloud/concepts/registry/): registry.yaml is the single declarative list of repos governed by the petrova control plane. Every verb invocation looks up its target here first. A repo absent… - [Schema fingerprints](https://petrova.devarno.cloud/concepts/schema-fingerprints/): A schema fingerprint is the first 12 hex chars of the SHA256 of a verb's schema file. Every emitted PR includes the fingerprint of the verb that produced it. Fi… - [Verbs](https://petrova.devarno.cloud/concepts/verbs/): A verb is a typed, schema-validated action that emits a PR. PETROVA's entire write surface is the nine verbs catalogued at /verbs/ — there is no other path to c… ## Verb reference > The 9-verb action surface (typed JSON in, PR out). - [close_phase](https://petrova.devarno.cloud/verbs/close_phase/): > Close an open phase. Requires a paired verificationround decision doc and explicit friction classification for every surfaced item. Marks the phase's decision… - [Common envelope](https://petrova.devarno.cloud/verbs/common-envelope/): Shared types referenced by every verb schema. Single source of truth for cross-cutting types. - [diagnose](https://petrova.devarno.cloud/verbs/diagnose/): > Read-only collection of cross-cutting context across a target repo: current phase, open milestones, recent decisions, recent findings, failing CI checks. Retu… - [open_decision](https://petrova.devarno.cloud/verbs/open_decision/): > Open a new dated decision doc in the target repo's docs/decisions/. Creates a PR adding a single file conforming to the repo's decision-doc template. The doc … - [PR body template](https://petrova.devarno.cloud/verbs/pr-body-template/): Every write verb renders this template into the PR body. The YAML block is parsed by re-run detection — do not edit it manually on emitted PR… - [propose_fix](https://petrova.devarno.cloud/verbs/propose_fix/): > Draft a fix PR grounded in a preceding diagnose run. Composes requestreview under the hood, but adds a hard binding to a diagnosisid and requires explicit MR-… - [request_merge_when_green](https://petrova.devarno.cloud/verbs/request_merge_when_green/): > Open a PR (same surface as requestreview) AND mark it for auto-merge once branch protection / CI gates pass. Profile-restricted: only permitted on registry pr… - [request_review](https://petrova.devarno.cloud/verbs/request_review/): > Generic write surface: open a PR with arbitrary file changes and request review. The lower-level primitive other write verbs may compose. Does NOT mark auto-m… - [start_phase](https://petrova.devarno.cloud/verbs/start_phase/): > Open a new phase. Composes opendecision (writes phase-N-open.md) plus updatemilestone seeding for declared sub-milestones. Predecessor phase must be closed. - [update_milestone](https://petrova.devarno.cloud/verbs/update_milestone/): > Add a new milestone or transition an existing one in the target repo's MILESTONES.md. State transitions are restricted: planned → active → complete | deferred… - [Verb catalogue](https://petrova.devarno.cloud/verbs/): The nine action verbs the petrova control plane exposes. Each verb is schema-validated, idempotency-keyed, dry-run by default, and PR-emitting. - [verify_round](https://petrova.devarno.cloud/verbs/verify_round/): > Record the output of a phase-close verification round. Creates a dated decision doc capturing surfaced items prior to classification (closephase consumes this… ## CLI > Install, auth, command reference, configuration, output formats. - [Auth](https://petrova.devarno.cloud/cli/auth/): --apply requires GitHub credentials. Read verbs (status, diagnose, validate, dashboard, verbs) work without auth — they read local clones. Dry-run write verbs a… - [CLI](https://petrova.devarno.cloud/cli/): The PETROVA CLI is the primary surface for invoking verbs. Everything in this section walks you through installing it, configuring credentials, and using it day… - [Command reference](https://petrova.devarno.cloud/cli/command-reference/): Every PETROVA CLI command, with synopsis, flags, and exit codes. - [Configuration](https://petrova.devarno.cloud/cli/configuration/): Every PETROVA configuration knob is an environment variable. There is no config file — config-as-code wouldn't survive the registry shape, and config-as-flags w… - [Install](https://petrova.devarno.cloud/cli/install/): The PETROVA CLI is a Node.js + TypeScript package living at petrova-hq/cli/. It builds to a self-contained dist/ and links as a global binary. - [Output formats](https://petrova.devarno.cloud/cli/output-formats/): PETROVA CLI commands support up to three output formats. The default varies by command; the format is chosen via flags. ## Skills > Claude Code skill wrappers (see Skills section above for direct URLs). - [Install skills into a consumer repo](https://petrova.devarno.cloud/skills/install/): Two skills that surface the petrova CLI to Claude Code sessions in any governed repo: - [petrova-act](https://petrova.devarno.cloud/skills/petrova-act/): You are about to invoke a Petrova write verb. Every write verb produces a PR against the target repo, never a direct push. The PR body carries an idempotency ke… - [petrova-status](https://petrova.devarno.cloud/skills/petrova-status/): Read-only inspection of one or more petrova-line repos. Three commands back this skill, all hitting local clones (no GitHub auth required): - [Refusal conditions](https://petrova.devarno.cloud/skills/refusal-conditions/): These conditions cause petrova-act and petrova-status to refuse the action and surface the reason to the user. They are deliberate — refusal is correct behaviou… - [Skill helper scripts](https://petrova.devarno.cloud/skills/scripts/): Utility scripts the skills shell out to. Source-of-truth for each is the file itself; the documented header (first 12 lines) appears here. ## Integrations > Contracts for external systems (KAHN agent fleets). - [diagnose then fix](https://petrova.devarno.cloud/integrations/example-diagnose-then-fix/): A complete fleet run from triggering signal to merged PR. Numbers in brackets reference the steps in docs/integrations/kahn-fleet.md's end-to-end flow section. - [failure modes](https://petrova.devarno.cloud/integrations/example-failure-modes/): Each scenario below shows the verb invocation, the structured failure output, and the fleet's recovery path. These are the cases CI fixtures should exercise onc… - [Integration contracts](https://petrova.devarno.cloud/integrations/): How outside systems (agent fleets, CI pipelines, audit harnesses) interact with the petrova control plane. Each file in this directory is a contract: the rules,… - [KAHN agent fleets ↔ PETROVA](https://petrova.devarno.cloud/integrations/kahn-fleet/): How KAHN-style fleets call petrova verbs to act on consumer repos without violating MR-6 (subagent additions go in AGENTS.xml), MR-7 (decisions are append-only,… ## Meta-rules > MR-1 through MR-12 — the cross-cutting invariants. - [Changing a meta-rule](https://petrova.devarno.cloud/meta-rules/changing-an-mr/): Meta-rule changes are the highest-stakes documentation event in the petrova line. They ripple through every consumer repo's CLAUDE.md projection, every verb's u… - [Meta-rules (MR-1 ... MR-12)](https://petrova.devarno.cloud/meta-rules/): > Cross-cutting invariants for the doc/agent system itself. These are > meta — they govern the docs that govern the code. If one of these is > violated, the sys… - [MR-1 — North-star outranks the backlog](https://petrova.devarno.cloud/meta-rules/mr-1/): If a proposed change does not serve the north-star intent and is not load-bearing infrastructure (auth, storage, deploy, schema, contract), it goes to docs/back… - [MR-10 — The verification round is mandatory at phase close](https://petrova.devarno.cloud/meta-rules/mr-10/): No phase closes without one. Even if the phase felt smooth. Even if nothing surfaced during the work. - [MR-11 — Anti-shapes are named, catalogued, and watched](https://petrova.devarno.cloud/meta-rules/mr-11/): Every project drifts toward one or two anti-patterns. They get named during bootstrap and live in docs/north-star/intent.md under driftwatches:. - [MR-12 — The CLAUDE.md is the projection, not the source](https://petrova.devarno.cloud/meta-rules/mr-12/): CLAUDE.md is what a fresh agent reads first. It is a projection of content from docs/north-star/, MILESTONES.md, and the spec. It does not introduce content not… - [MR-2 — Friction surfaced in phase N's verification round becomes phase N+1's input](https://petrova.devarno.cloud/meta-rules/mr-2/): This is the rule that cost the source project the most clarity to discover. It is mechanical now. - [MR-3 — Sibling files stay sibling](https://petrova.devarno.cloud/meta-rules/mr-3/): When two files exist as a pair (wire-contract emitter + agent-emitter; forward-migration + rollback-migration; OSS-mode-config + cloud-mode-config), do not merg… - [MR-4 — Dates are absolute](https://petrova.devarno.cloud/meta-rules/mr-4/): Every dated artefact uses ISO format: - [MR-5 — Direct push for small fixes; PR for checkpoints](https://petrova.devarno.cloud/meta-rules/mr-5/): PR ceremony for two-line CSS is waste. PR ceremony for a multi-file feature is a checkpoint you'll thank yourself for. - [MR-6 — Subagents read from `AGENTS.xml`, not from inferred patterns](https://petrova.devarno.cloud/meta-rules/mr-6/): If an orchestrating Claude session needs to delegate but the right subagent isn't in AGENTS.xml, the correct response is add it to the XML, not improvise a dele… - [MR-7 — Decision docs are append-only](https://petrova.devarno.cloud/meta-rules/mr-7/): You do not edit a closed decision doc to "fix" what it said. You write a new decision doc that supersedes it. The new doc references the old: - [MR-8 — Invariants are numbered and stable](https://petrova.devarno.cloud/meta-rules/mr-8/): Project invariants in CLAUDE.md are I-1, I-2, … . Once assigned, the number is stable forever. If an invariant is repealed, the number is not reused — it gets m… - [MR-9 — Don't invent invariants](https://petrova.devarno.cloud/meta-rules/mr-9/): A subagent (or a human in agent mode) must not propose a new invariant without a spec citation or an explicit human ratification. The bootstrap prompt enforces … ## Operator runbooks > Onboarding, auth, submodule bumps, failure recovery, fleet audits. - [audit fleet activity](https://petrova.devarno.cloud/runbooks/audit-fleet-activity/): When you need to know what a fleet has been doing — for a quarterly review, an incident response, or before broadening its fleetsallowed scope — this runbook wa… - [auth setup](https://petrova.devarno.cloud/runbooks/auth-setup/): Step-by-step provisioning of credentials for petrova --apply. The user-facing summary is at /cli/auth/ — this page is the operator runbook with troubleshooting.… - [onboard repo](https://petrova.devarno.cloud/runbooks/onboard-repo/): The end-to-end flow for admitting a new repo to the petrova control plane. After a successful run, the repo is reachable via every verb, visible in petrova stat… - [submodule bump](https://petrova.devarno.cloud/runbooks/submodule-bump/): PETROVA-HQ has two submodules: - [verb failure recovery](https://petrova.devarno.cloud/runbooks/verb-failure-recovery/): You ran a verb and got failed (or --apply errored before emission). This runbook is the operator-shaped recovery playbook, mapped to the errors[].code returned … ## Templates > Bootstrap-time templates copied into consumer repos. - [AGENTS.xml template](https://petrova.devarno.cloud/templates/agents-xml/): The template the bootstrap agent (core/prompts/00-bootstrap.md) copies into a consumer repo. <> tokens are replaced from Phase-1 spec reading and P… - [CLAUDE.md template](https://petrova.devarno.cloud/templates/claude-md/): The template the bootstrap agent (core/prompts/00-bootstrap.md) copies into a consumer repo. <> tokens are replaced from Phase-1 spec reading and P… - [docs/ scaffold](https://petrova.devarno.cloud/templates/docs-scaffold/): Every petrova-line consumer repo inherits a standard docs/ shape on bootstrap. This page describes each directory's purpose and the rank graph that connects the… - [MILESTONES.md template](https://petrova.devarno.cloud/templates/milestones-md/): The template the bootstrap agent (core/prompts/00-bootstrap.md) copies into a consumer repo. <> tokens are replaced from Phase-1 spec reading and P… - [shared/ namespace](https://petrova.devarno.cloud/templates/shared-namespace/): --- rank: shared outranks: [] --- - [shared/agent-fleet-methodology](https://petrova.devarno.cloud/templates/shared-agent-fleet-methodology/): AGENTS.xml is the schema — who exists, what they read and write, how they hand off. This file is the grammar — the narrative rules that govern how the schema is… - [shared/conventions](https://petrova.devarno.cloud/templates/shared-conventions/): Conventions that apply to every petrova-line repo. Project-specific conventions live in each repo's CLAUDE.md § "Conventions specific to this repo". - [shared/documentation-hierarchy](https://petrova.devarno.cloud/templates/shared-documentation-hierarchy/): Every petrova-line repo organises docs/ by rank. The rank graph is a DAG declared in front-matter (MR-1); the drift-watcher subagent reads it when adjudicating … - [shared/meta-rules](https://petrova.devarno.cloud/templates/shared-meta-rules/): The twelve MR-N cross-cutting invariants live at the canonical path core/templates/META-RULES.md and are copied verbatim into each consumer repo at bootstrap (t… - [shared/navigation-index](https://petrova.devarno.cloud/templates/shared-navigation-index/): Standard navigation cheatsheet. Identical across petrova-line repos. - [shared/north-star-methodology](https://petrova.devarno.cloud/templates/shared-north-star-methodology/): How to write and maintain a north-star doc. The how, never the what — project intent never lives in shared/. Each consumer repo owns its own docs/north-star/int… - [shared/phase-discipline](https://petrova.devarno.cloud/templates/shared-phase-discipline/): Phases are the unit of progress. Acceptance-gated; closed only when their gates pass. This file codifies the rules that the phase prompts (01-phase-open, 02-pha… - [Templates overview](https://petrova.devarno.cloud/templates/): Templates the bootstrap agent copies into a consumer repo on day 1. Top-level files become the consumer's control-loop documents; shared/ becomes the consumer's… ## Prompts > Paste-into-Claude-Code prompts that drive the control loop. - [Bootstrap prompt — paste into Claude Code on day 1](https://petrova.devarno.cloud/prompts/00-bootstrap/): > What this is. A single prompt that turns a bare-bones scaffolded repo > (with detailed spec docs in docs/) into an agent-powered repo by > generating CLAUDE.m… - [Drift-check prompt](https://petrova.devarno.cloud/prompts/04-drift-check/): > Paste when something feels off — a PR that doesn't quite serve the > intent, a doc that contradicts another, a phase scope that pulled > toward a named anti-s… - [Onboarding prompt — register a repo in the petrova line](https://petrova.devarno.cloud/prompts/05-petrova-onboard/): > What this is. A single prompt that walks Claude Code through admitting > an existing repo to the petrova control plane: deriving the registry > entry, opening… - [Phase-close prompt](https://petrova.devarno.cloud/prompts/02-phase-close/): > Paste when a phase has met its acceptance gates and is ready to close. > This prompt enforces MR-2 (friction → next phase, never retrofit) and > MR-10 (verifi… - [Phase-open prompt](https://petrova.devarno.cloud/prompts/01-phase-open/): > Paste at the start of each phase. The agent verifies entry criteria, > writes the phase-open decision doc, and triggers phase.open > downstream. - [Prompt library](https://petrova.devarno.cloud/prompts/): Paste-into-Claude-Code prompts that drive the petrova control loop: - [Verification round prompt](https://petrova.devarno.cloud/prompts/03-verification-round/): > Invoked from prompts/02-phase-close.md (or standalone if the human > wants a mid-phase friction probe). Produces a list of surfaced friction > items for the r… ## Decisions > Append-only decision ledger for petrova-hq itself. - [Decision ledger](https://petrova.devarno.cloud/decisions/): Petrova-hq's own append-only decision record. Every architectural call against the control plane lands here, dated, with sign-off. Append-only per MR-7; superse… - [Petrova evolves into a control plane with a thin centre](https://petrova.devarno.cloud/decisions/2026-04-29-petrova-control-plane/): Date: 2026-04-29 Status: closed Supersedes: none Superseded-by: none — current ## Architecture > Why the system is shaped the way it is. - [Architecture](https://petrova.devarno.cloud/architecture/): The why behind the design. Each page is the readable companion to a specific architectural decision; together they explain the trades that shape the system. - [Three concentric rings](https://petrova.devarno.cloud/architecture/three-rings/): PETROVA's topology is three concentric rings. Each owns specific responsibilities; each crosses its inward boundary only through a narrow contract. The same dia… - [Trade-offs accepted](https://petrova.devarno.cloud/architecture/tradeoffs/): 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. - [Why a thin centre](https://petrova.devarno.cloud/architecture/why-thin-centre/): The 2026-04-29 control-plane decision was the architectural choice that shaped everything since. This page is the readable companion: why the system has a thin … - [Why API-first (not local-clone-write)](https://petrova.devarno.cloud/architecture/api-first/): When PETROVA's verbs need to write to a consumer repo, they do so via the GitHub Contents API, not by editing a local clone and pushing. This page explains why.… - [Why no central database](https://petrova.devarno.cloud/architecture/no-central-database/): PETROVA explicitly rejects a central database (Postgres or otherwise) as a source-of-truth for project guidance. Decisions, milestones, findings, and north-star… ## Roadmap > Tasksets executed, deferred work, future tasksets. - [Deferred work](https://petrova.devarno.cloud/roadmap/deferred-work/): Items that came up during Tasksets 1–8 and were intentionally deferred to a future taskset rather than absorbed in scope. Per MR-2, deferred friction is next-ph… - [Future tasksets](https://petrova.devarno.cloud/roadmap/future-tasksets/): Tasksets that are conceptually drafted but not yet opened. Each gets a one-paragraph sketch with explicit "decision needed before opening" criteria. - [Tasksets 1–8 (executed)](https://petrova.devarno.cloud/roadmap/tasksets-1-8/): The eight-step evolution that built the petrova control plane. Each taskset is a single commit (or commit pair when a submodule was bumped). ## Full content - [llms-full.txt](https://petrova.devarno.cloud/llms-full.txt): every page concatenated, ~50k words. Use when context budget allows.