Admission of a fleet identity to `petrova-canary`

rank: decision outranks: [] doc_id: PTV-DEC-0025 title: Admission of a fleet identity to petrova-canary — the ruling the write probe’s apply path waits on date: 2026-08-28 status: open — UNRATIFIED, no effect until countersigned owner: petrova-codes scaffold: PTV-SCF-0001 phase: P3 supersedes: none amends: none depends_on: docs/decisions/2026-08-12-purpose-built-canary-supersedes-pwplz.md

Admission of a fleet identity to `petrova-canary`

Status: UNRATIFIED. This record changes nothing. registry.yaml is not edited by it, and no code reads it. It exists so that the reason two built hops cannot run is written down rather than inferred.

1 · The ruling sought

Admit one named fleet identity to petrova-canary’s fleets_allowed, for the PTV-SCF-0001 A2 write probe and nothing else.

2 · The mechanism it changes

Two mechanisms currently agree, and the agreement is deliberate:

registry.yaml:787 — petrova-canary carries fleets_allowed: []. Its own note says why the list is empty rather than unset: “admitting a fleet is its own decision and no record makes it yet.”
cli/src/verbs/_helpers.ts:145-170 — [] is control-plane lockdown. Every fleet: actor is refused FLEETS_ALLOWED_EMPTY. The sole escape is a human: actor with PETROVA_ALLOW_HUMAN_OVERRIDE=1.
cli/src/probes/write-probe/index.ts — the admission_refuses hop’s recovery path names that same environment variable as the thing that must not be set in a probe environment.

This is not an oversight to be patched. It is a lockdown and a probe that refuses the lockdown’s only bypass, agreeing with each other.

3 · What the ruling would permit

An applied write, a branch and a pull request against petrova-canary by the admitted fleet. Bounded by:

the GitHub App installation’s grant — petrova-canary-probe, installation 153988870, contents and pull-request write only;
the canary’s branch protection — 1 required approving review, require_last_push_approval: true — which blocks merge, so the credential cannot land its own PR.

4 · What it costs

fleets_allowed: [] refuses everything. A list refuses everything not on it, and lists drift. The canary stops being categorically locked and becomes conditionally locked, and the condition is a file anyone with merge rights can extend.

The supersession triggers in the canary’s registry note — a star, a fork, an inbound link — are unchanged by this ruling and remain the remedy.

5 · The alternative, refused explicitly

PETROVA_ALLOW_HUMAN_OVERRIDE=1 is available today. Setting it would make the write probe green today, with no ruling, no PR and no countersign.

It is refused. The probe names it as the thing that must not be set, and a green obtained by setting it would be a green over a bypassed gate — the exact confidence PTV-VCRM-DEBT-01 was raised against. cli/src/verbs/_helpers.ts:72-90 already stamps a Petrova-Override: trailer into the emitted artefact precisely so that a bypassed gate can be told from a cleared one; this record is the matching refusal in writing.

A refusal that is not written down is not a refusal. It is a thing nobody happened to do yet.

6 · Blocked on a decision, not on code

One category. One corrective action: someone decides, and nothing in the repo changes until they do.

blocked	decision awaited	where
`G-P3-7`, `G-P3-8`	reword the gate, or change the environment	`PTV-DEC-0024` §fork
`apply`, `pr_emission` hops	this record	here
SR-0008’s artefact reading — files, or preview	pick a reading	M3.3 spec §1, F-58 shape
SR-0002 inside `petrova` itself	pay for Pro, make public, or record convention as the enforcement	`PTV-FND-0065`

Kept as one table because three pending rows with three remedies invites three separate partial attempts.

7 · Countersign

Ratified by a human. Countersigned by alex@devarno.com on 2026-08-28.

What the ratification determines, which §1 deliberately left open. §1 sought admission for “one named fleet identity” and named none, because naming it was not the decision being asked for. The identity is fixed by the code rather than chosen here: cli/src/index.ts ships fleet:petrova-probe as the probe-run verb’s default actor, and checkFleetsAllowed compares the bare id, so the entry is petrova-probe.

Scope of the grant. petrova-canary only. No other registry entry is touched, and no other fleet identity is admitted. The bounds named in §3 are unchanged and are what keep this narrow: the App installation grants contents and pull-request write and nothing else, and the canary’s branch protection requires one approving review, so the credential cannot merge what it opens.

What is still refused. §5 stands. PETROVA_ALLOW_HUMAN_OVERRIDE=1 remains the thing that must not be set in a probe environment. This ratification admits a fleet through the front door; it does not soften the bypass, and a green obtained by setting that variable would still be a green over a bypassed gate.

What this does not do. It does not make G-P3-2 or G-P3-4 pass. Nothing has run. The probe’s apply, pr_emission and metadata_parse_back hops move from “cannot be exercised” to “not yet exercised”, which is a different sentence and a smaller one. Three consecutive green full-stage runs, cited by identifier in a round record, are what G-P3-2 asks for and none exists.