Skip to content
PETROVA

The canary is a purpose-built repo, not a borrowed one

Date: 2026-08-12 Status: open Supersedes: docs/decisions/2026-08-12-pwplz-as-write-probe-canary.md (withdrawn same day, never countersigned) Superseded-by: none — current

Context

Section titled “Context”

The earlier record designated pwplz as the canary on the strength of P0 evidence calling it “the most inert” of three role: placeholder registry entries. That was wrong on the facts. pwplz is a live product at pwplz.com, the operator’s first open-source project, a public repo with stars at Dev4rno/pwplz (last pushed 2025-03-13), the subject of a published post at devarno.com/downlink/password-please, and the intended base of a SaaS build with a fresh pwplz GitHub org already created for it.

The error is worth more than the correction. Inertness was inferred from the absence of a url: field in registry.yaml. A missing field is not evidence of a missing surface; the registry was silent, and silence was read as emptiness. The identical inference had already disqualified the runner-up without anyone noticing: downlink-hq maps to devarno.com/downlink, the operator’s live blog section. Two of three “inert” candidates turned out to be live products, which means the shortlisting method — not the shortlist — was the defect.

This matters beyond canary selection: registry.yaml carries no field that distinguishes nothing is here from nothing is recorded here, and D-16 already showed capability existing outside governed inventory. The registry can be silent about a live surface, and nothing in the control plane currently notices.

Decision

Section titled “Decision”

The canary is a repository created for the purpose, and nothing else is ever promoted into the role. No existing repo — product, scaffold, placeholder, or archived — becomes the canary, however dormant it appears.

The canary must satisfy all of:

  1. Created to be a canary, with a name that says so, so no future reader mistakes it for product. Recommended: petrova-canary.
  2. Empty of anything worth keeping. No published surface, no domain, no package, no stars, no inbound links, no history anyone would miss.
  3. Registered in registry.yaml with role: canary and its real url:, so the probe exercises the true registry → App-auth → write-verb path rather than simulating it. An ungoverned repo would prove the verb works in a vacuum and would reproduce D-16.
  4. Reachable by exactly one credential — a GitHub App installed on it and on no other repository, per the five conditions in docs/findings/20260811-2027-ptv-scf-0001-credential-scope.md §“What a conforming P3 credential would look like”.
  5. Disposable. If a probe corrupts it, the remedy is deletion and recreation, with nothing to recover.

pwplz is explicitly disqualified, and its registry.yaml entry should be annotated as a live product so the mistake cannot recur. downlink-hq is disqualified on the same grounds. thrustr-io remains merely unexamined.

Alternatives considered

Section titled “Alternatives considered”
  • thrustr-io — the last placeholder with no evidence against it. Rejected: after two of three “inert” candidates proved to be live products, absence of evidence in registry.yaml is precisely the signal that misled the first ruling. Confirming it inert costs more than creating a repo, and leaves a candidate that could acquire a surface later.
  • pwplz, scoped to a throwaway branch — rejected: branch scoping is a convention, and the P0 credential audit already established that conventions in one code path are not capability boundaries (see the PRIVILEGED_PATH_RE cross-finding). A defective probe with contents: write reaches main.
  • A repo in the new pwplz org — rejected: it would tie the canary to a product namespace, which is how a canary quietly acquires value and stops being one.
  • No canary; dry-run only forever — rejected: it leaves PTV-VCRM-DEBT-01 permanently undischarged. Six requirements are marked T-verified with no executing test, and only an applied write settles them.

Consequences

Section titled “Consequences”

For code:

  • P3’s probe resolves its target from registry.yaml by role: canary, never from a literal slug, so the canary can be replaced by ratified supersession rather than by editing code.
  • role: canary is a new registry role and needs whatever validation the schema applies to roles.

For docs:

  • registry.yaml gains the canary entry and an annotation on pwplz:764-775 recording that it is a live product and permanently ineligible. Registry edits are PR-only — this record does not authorise a direct edit.
  • Q-CANARY-1 reopens and re-closes against the new target in docs/findings/20260811-1749-ptv-scf-0001-p0-open-questions.md.

For in-flight phases:

  • P3 stays blocked, on repo creation plus the scoped installation. It is not more blocked than before — the previous unblock was based on a false premise, so no ground is lost.
  • P4/P5 unaffected; those turn on the n8n credential (Q-CRED-3, non-conforming).

For invariants:

  • INV-1’s “designated canary” gains a referent that is disposable by construction, which is what the invariant assumed all along.
  • INV-1 remains violated regardless: C-1, C-3 and now C-5 are ambient and estate-wide. A canary bounds intent, not capability.
  • No MR added, modified, or repealed.
  • Method rule, worth carrying forward: a missing registry field is not evidence about the world. Any claim of the form “this repo is inert” must cite a positive check — no domain, no published package, no inbound links — not an empty column.

References

Section titled “References”
  • docs/decisions/2026-08-12-pwplz-as-write-probe-canary.md — the withdrawn record, retained with its error stated.
  • docs/findings/20260811-2027-ptv-scf-0001-credential-scope.md — the five credential conditions; the candidate evidence now known to be misread.
  • docs/findings/20260811-1749-ptv-scf-0001-p0-delta-register.md — D-16 (capability outside inventory), and D-19 (the registry cannot distinguish absent from unrecorded).
  • docs/PETROVA-SDD-BASELINE.md §8.1 — PTV-VCRM-DEBT-01.
  • https://pwplz.com, https://github.com/Dev4rno/pwplz, https://devarno.com/downlink/password-please — the surfaces that disqualify it.

Sign-off

Section titled “Sign-off”
  • Subagent: PTV-SCF-0001 P1 (session 2026-08-12)
  • Human countersign — that the canary is a purpose-built repository meeting the five conditions above, that pwplz and downlink-hq are permanently ineligible, and that no existing repo is promoted into the role