Skip to content
PETROVA

2026-09-26 — Reconcile yao-agent's `.petrova/contract.yaml` path collision, register contract_sha

rank: decision outranks: []

Section titled “rank: decision outranks: []”

2026-09-26 — Reconcile yao-agent’s .petrova/contract.yaml path collision, register contract_sha

Section titled “2026-09-26 — Reconcile yao-agent’s .petrova/contract.yaml path collision, register contract_sha”

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

Rationale

Section titled “Rationale”

IRINA’s tracked-set audit flagged yao-agent’s .petrova/ shape as non-standard — a claim_index structure instead of the contract schema. Investigation found the real cause: packages/yao-core/scripts/ project-petrova-contract.js in asgard-codes/yao-agent deliberately writes this repo’s own CRUMB claim-index (derived from marketing/campaigns/addy-cognitive-harness/campaign-addy-sources-*.yaml via claim-index-projector.js) to .petrova/contract.yaml — the exact path petrova-codes’ fleet governance reserves for the per-repo contract schema (contracts/contract.schema.json: schema_version/slug/ generated_at/integrations). This has been true since the repo’s bootstrap; the collision only surfaced now because yao-agent had never actually gone through petrova_onboard (registry notes already said “integrations_applicability pending petrova_onboard; contract_sha set at onboard time”).

Fixed upstream in asgard-codes/yao-agent#242 (merged 2026-09-26):

  • Claim-index projector output moved to content/crumb/petrova-claim-index.yaml (byte-identical content, new path — this is yao-agent’s own product feature, unrelated to fleet governance, and keeps working unchanged).
  • A real .petrova/contract.yaml authored: all five integrations not_applicable — matches this repo’s actual state (no ARES/Traceo wiring, no CAIRNET/LORE emission, no eva-hq boot-kit install, and its own CRUMB claim-index tooling is self-scoped, not a wired fleet CRUMB integration).
  • Validated against petrova-codes’ own contracts/contract.schema.json via the real loadContract() code path (cli/src/contract.ts), not a hand-rolled check.

contract_sha computed the same way cli/src/verbs/doctor.ts does (sha256(raw file bytes).slice(0,12)): ffdcf0c4caf2.

Open follow-up

Section titled “Open follow-up”
  • packages/yao-core/src/guidance-resolver.js and @asgard/contracts’ petrova-contract.js/claim-index-contract.js implement a generic “claim gate” that validates any target repo’s .petrova/contract.yaml as a claim_index — this is yao-agent’s own product surface (works on an arbitrary repo argument, not hardcoded to yao-agent itself) and shares the same path convention as fleet governance by design, not by mistake. Not touched here — a real fix, if one is needed, is asgard-codes’ product-architecture call, not a petrova-codes registry concern.
  • This unblocks adding yao-agent to IRINA’s tracked set (separate item — IRINA’s qualifying rule is fleets_allowed.length > 0 && role !== "canary"; yao-agent already has content-contracts-bump in fleets_allowed and role: production, so it should already qualify once contract_sha is present).

Sign-off

Section titled “Sign-off”