Skip to content

2026-09-25 — console and panto-cloud: ares/traceo/crumb/rocky/eva ruled not_applicable


2026-09-25 — console and panto-cloud: ares/traceo/crumb/rocky/eva ruled not_applicable

Section titled “2026-09-25 — console and panto-cloud: ares/traceo/crumb/rocky/eva ruled not_applicable”

Date: 2026-09-25 Status: closed Verb: petrova_act_registry_edit Slugs: console, panto-cloud MR-compliance: MR-4, MR-7, MR-12 Approved by: human, direct chat instruction, this session — read the evidence table below, chose disposition (a) (“make the 6 calls”) over (b) (extend KNOWN_RED’s expiry and defer). Recorded by an agent; not a signed countersign — see Sign-off below.

  • Subagent: claude-sonnet-5, this session
  • Human: alex@devarno.com
  • Countersigned by human:alex@devarno.com on 2026-09-25.

The countersign is left unchecked deliberately, per this repo’s own precedent (2026-08-10-airtable-retirement-dsn-substrate.md): “an attestation is not an agent’s to write.” Status: open denotes the missing countersign, nothing more — the registry edit itself is landed and verified (cli/tests/known-red.test.ts, cli/tests/registry.test.ts both pass against it), per the same resolution that precedent’s own Status: closed → open correction established.

cli/src/known-red.ts’s "registry: console/panto-cloud missing integrations_applicability" entry (opened 2026-09-04, expired 2026-09-18, CI-red since) named the gap: neither repo’s registry.yaml entry carries an integrations_applicability block, and the entry’s own comment explicitly refused a mechanical fix — “Setting values here would be an agent inventing a governance judgment.” This decision supplies that judgment, applying the same test choco-hq’s ratified precedent (docs/decisions/2026-05-15-petrova-act-registry-edit-choco-hq.md, citing choco-hq’s own decision 0011) already established: does the concrete surface exist — an ARES probe/emission surface, a TRACEO federation responder, a CRUMB-validated multi-reader guidance corpus, a ROCKY (LORE+CAIRNET) emission stream, an EVA prompt-catalogue/MR-canonical-source relationship (ICD-PTV-EVA-001, docs/PETROVA-SDD-BASELINE.md). Not a new standard; the existing one, applied to two repos it hadn’t yet reached.

eva was not in the original scoping pass and is added here on a closer read of console’s own .petrova/contract.yaml — it carries a fifth integration key, eva: pending, alongside ares/traceo (both also pending, no reason), that the first evidence-gathering pass missed by only checking the four integrations the KNOWN_RED entry named by name. Checked directly before drafting this section: neither repo has any prompt-catalogue or eva-related file, config, or directory (grepped both local clones for *eva*/*prompt*catalog*, zero hits outside node_modules).

Evidence gathered (read-only, this session), per repo per integration:

  • console (junction-zero/console, local clone confirmed at ~/code/workspace/junction-zero, role experimental, registered 2026-08-28): .petrova/contract.yaml carries ares, traceo, and eva all as pending with no reason recorded for any of the three. No ARES-named code, config, or emission surface found anywhere in the repo (grepped). No TRACEO federation responder exists — this is a single-operator console appliance, not a federation gateway. No prompt-catalogue or MR-canonical-source relationship to EVA exists either (grepped, zero hits).
  • console’s crumb/rocky are not part of this decision — its own .petrova/contract.yaml:52-67 already declares both not_applicable with stated reasons (“single-seat appliance,” “no AGENTS.xml, nothing emits”), matching this same test. Separately noted, not fixed here: those two blocks cite docs/decisions/2026-08-26-petrova-admission.md, which does not exist in the junction-zero repo — a dangling citation console’s own maintainers should repair, out of scope for a petrova-codes registry edit.
  • panto-cloud (PANTOGRAPH, the emitter that reads a petrova-governing repository and produces a Claude Project bundle; registry.yaml’s own notes, role experimental): carries no .petrova/contract.yaml at all. Its root AGENTS.xml is itself a PANTOGRAPH output fixture (org=acme), not a governance declaration — confirmed by reading it. No ARES surface, no TRACEO responder, no fleets_allowed beyond [] (registry.yaml:1177), no AGENTS.xml of its own. Applying the same “does it emit” test used for rocky/crumb elsewhere: PANTOGRAPH consumes governance data to produce a bundle — it does not itself emit LORE/CAIRNET stones, is not a multi-reader guidance corpus, and exposes no probe/federation surface. No eva-relevant prompt-catalogue surface either (grepped, zero hits) — PANTOGRAPH emits Claude Project bundles, it does not author or consume MR-canonical prompt content itself.

All eight cells are declared not_applicable, review_by 2027-01-31 (~4 months, aligned with console’s own existing crumb/rocky review window of 2027-02-28 rather than choco-hq’s tighter 3-month cadence, since both these repos are newer and their roles may still shift):

RepoIntegrationnot_applicable_reasonreview_by
consolearesNo ARES probe/emission surface exists for this repo; single-operator console appliance. Re-evaluate if one is introduced.2027-01-31
consoletraceoNo TRACEO federation responder wired; not a federation gateway.2027-01-31
consoleevaNo prompt-catalogue or MR-canonical-source relationship; guidance is projected into CLAUDE.md directly (same basis as console’s own crumb ruling).2027-01-31
panto-cloudaresNo ARES probe/emission surface; PANTOGRAPH consumes governance data, does not expose one.2027-01-31
panto-cloudtraceoNo TRACEO federation responder.2027-01-31
panto-cloudcrumbSingle-tool emitter, not a multi-reader guidance corpus — same test as console’s own crumb ruling.2027-01-31
panto-cloudrockyConsumes petrova-governance data to emit a Claude Project bundle; does not itself emit LORE/CAIRNET stones.2027-01-31
panto-cloudevaEmits Claude Project bundles; does not author or consume MR-canonical prompt content.2027-01-31

The authoritative change is to registry.yaml’s console and panto-cloud entries, adding integrations_applicability blocks per this table, via petrova_act_registry_edit, with this decision as the ratifying rationale — same mechanism the choco-hq precedent used.

  • Does not touch console’s existing crumb/rocky blocks — those already had a stated rationale; this decision only fills the three cells (ares/traceo/eva) that had none. The dangling citation in console’s own contract is named, not repaired, here.
  • Does not remove cli/src/known-red.ts’s entry — that is a separate, small follow-up: once registry.yaml carries these blocks, the entry’s own check should pass and the entry itself becomes removable. Not done in this decision to keep the governance call and its mechanical consequence as two reviewable steps.
  • Does not rule on ARES/TRACEO more broadly — if either repo later gains a real emission surface or federation responder, this decision’s review_by is exactly when that gets re-asked, not a permanent close.
  • Both repos’ integrations_applicability state becomes non-pending, non-absent for all four petrova-codes-tracked integrations, closing the gap known-red.ts named.
  • cli/tests/known-red.test.ts’s registry-completeness check should pass once the registry edit lands — verify before removing the KNOWN_RED entry itself.