Skip to content
PETROVA

Decision: petrova-hq canary self-entry — all integrations not_applicable

date: 2026-04-30 status: accepted title: petrova-hq self-entry marks all four integrations not_applicable supersedes: []

Section titled “date: 2026-04-30 status: accepted title: petrova-hq self-entry marks all four integrations not_applicable supersedes: []”

Decision: petrova-hq canary self-entry — all integrations not_applicable

Section titled “Decision: petrova-hq canary self-entry — all integrations not_applicable”

Context

Section titled “Context”

Sub-project A introduces a uniform integration contract surface for every PETROVA-governed repo. The control plane (petrova-hq) registers itself in registry.yaml with role: control-plane, and per spec §10 Tier 1 it acts as the canary that dogfoods the schema before any consumer repo is required to adopt it.

The four integrations the spine governs (ARES, Traceo, CRUMB, LORE+CAIRNET) are exercised by consumer repos, not by the playbook itself:

  • ARES observes consumer-repo CI workflows. The playbook has CI (linting, schema-drift, canary-doctor) but it is meta-CI about the governance machinery, not product CI.
  • Traceo + Ariel baseline product requirements + verification trace matrices. The playbook has no product requirements; its requirements are the meta-rules in core/templates/META-RULES.md.
  • CRUMB generates flashcards from product guidance docs. The playbook’s guidance docs describe the playbook itself; flashcards belong with the product they explain, not with the playbook that governs many products.
  • LORE + CAIRNET ingest agentic content (findings, ADRs, campaigns, agent-2-agent prompts) emitted by product work. The playbook’s findings and decisions are about the playbook (control-plane meta-content); routing them into LORE alongside product agentic content would conflate two distinct corpora.

Decision

Section titled “Decision”

petrova-hq/.petrova/contract.yaml declares all four integrations as status: not_applicable with this decision doc as the not_applicable_decision_doc reference. Each block carries an integration-specific not_applicable_reason (above) and a not_applicable_review_by: 2027-04-30 re-evaluation date.

registry.yaml::petrova-hq.integrations_applicability mirrors this with all four governance values set to not_applicable. This means both intent (consumer-side declaration) and applicability (governance) agree — no conflict, no failing cell on the dashboard.

Consequences

Section titled “Consequences”
  • Canary self-entry remains green (4 not_applicable cells) on the CASA dashboard from spine launch onward.
  • The 2027-04-30 review-by is a forcing function: at that date, the operator must either re-ratify these not_applicable claims or open a new decision doc that promotes one or more integrations to pending / wired (e.g. if the playbook starts emitting product-level findings that should flow into LORE).
  • This decision is narrowly scoped to petrova-hq self-entry. It does NOT establish a precedent that other control-plane-shaped repos automatically inherit not_applicable for all four integrations.

Approvals

Section titled “Approvals”
  • Operator: alex@devarno.com — approved 2026-04-30 in fix-pass commit preceding the integration-spine PR.