Skip to content
PETROVA

2026-09-26 — Correct stale mary-wiki registry notes; record the door-vault gap

rank: decision outranks: []

Section titled “rank: decision outranks: []”

2026-09-26 — Correct stale mary-wiki registry notes; record the door-vault gap

Section titled “2026-09-26 — Correct stale mary-wiki registry notes; record the door-vault gap”

Date: 2026-09-26 Status: ratified Verb: petrova_act_registry_edit Slug: mary-wiki MR-compliance: MR-7, MR-12

Rationale

Section titled “Rationale”

registry.yaml:1067’s mary-wiki entry notes described the repo’s pre-onboarding placeholder state (2026-08-03 discovery: zero repos, url omitted, contract_sha absent by design, all five integrations not_applicable) — but the entry’s own machine fields already reflected onboarding having completed: url is populated (https://github.com/mary-wiki/mary), contract_sha: 7f86b2e56096 (verified this session against origin/main:.petrova/contract.yaml — matches exactly), and integrations_applicability.rocky: required. The prose had gone stale since at least 2026-08-04 (when cairnet_emission wired per DEC-APEX-0017) without anyone updating the notes to match.

Separately, investigating “how does PETROVA/IRINA automation reach mary-wiki’s apex model” (this session’s originating question) surfaced a real gap worth recording rather than silently working around: mary-wiki’s own docs/door-vault.json (DW-APEX-03 enforcement — every MCP endpoint needs a DOOR-* record) has DOOR-PEBBLE-REGISTRY (endpoint_ref: petrova, safety_class: C, status: active) authorizing exactly three intents: audit mary-wiki, audit petrova-codes, report registry. All read-only. No petrova.act.* write intent and no IRINA-trigger intent is declared. Per mary-wiki’s own DW-APEX-03, an undeclared intent should refuse even through an already-active door — so fleet write-automation against mary-wiki (or reasoning about PETROVA write verbs from the apex model’s perspective) currently has no authorized path, independent of fleets_allowed on the petrova-codes side.

This doc does not attempt to close that door-vault gap — it is mary-wiki’s own artefact (docs/door-vault.json), not petrova-codes’. Recording it here so the correction is grounded in the actual blocking reason, not just “role stays scaffold.”

Change summary

Section titled “Change summary”

registry.yaml > repos[mary-wiki].notes:

  • Removed claims that url is omitted / contract_sha is absent / all integrations are not_applicable (all false as of this session).
  • Added a dated correction: onboarding completed 2026-08-03, contract_sha verified, cairnet_emission wired 2026-08-04, actual applicability state per the contract (rocky:required; others not_applicable, all status: pending — declared, not yet verified).
  • Added the door-vault finding (read-only intents only; no write path authorized yet).
  • role unchanged (scaffold) — no phase-close/verification-round evidence exists to promote it; that remains open, separate from the prose fix.

No change to url, contract_sha, integrations_applicability, role, profile, or fleets_allowed — only the notes prose.

Open follow-up

Section titled “Open follow-up”
  • mary-wiki’s docs/door-vault.json needs new intents declared (or an explicit status: proposed refusal-door, mirroring its own DOOR-TOLL pattern) before any petrova.act.* write verb or IRINA trigger can be said to route through the apex model correctly. This is mary-wiki’s own decision to make, not petrova-codes’.
  • role: scaffold promotion for mary-wiki is untouched by this doc — separate gap, needs its own phase-close evidence.

Sign-off

Section titled “Sign-off”

Human merge required per MR-12 — this PR is opened with the awaiting-human-merge label and does not auto-merge.