Skip to content
PETROVA

2026-05-24 — Correct hermes contract_sha to git-blob-sha1; surface substrate inconsistency

Status: open MR-compliance: MR-4, MR-7, MR-12 Supersedes: none (corrects the value set in docs/decisions/2026-05-24-petrova-act-registry-edit-hermes.md which used the wrong hash family)

Context

Section titled “Context”

After hermes PR #9 merged (Phase 1f close), petrova sweep-state --slug hermes reported drift sha=2cb484f11800 against a registry pin of 4dd1b98dde8f. Investigation showed two different CLI verbs are computing contract_sha with different hash families:

VerbHash familyOutput
petrova doctorcrypto.createHash("sha256")4dd1b98dde8f
petrova sweep-statecrypto.createHash("sha1") over a blob <len>\0 header + content (git hash-object semantics)2cb484f11800
git hash-object .petrova/contract.yamlgit-blob-sha1 (canonical)2cb484f11800

The registry’s contract_sha field is a 12-char git short sha by convention — every other entry in registry.yaml matches this format (kahn-hq=38f111f68e59, devarno-cloud=433b9aca8afc, petrova-codes=da448f23ed8f, etc). The post-merge canonical value for hermes is therefore 2cb484f11800.

The prior PRs that touched this field used the doctor-emitted sha256 value:

  • PR #146 (closed): tried to set fa18fd8607b4 (sha256 of pre-eva-migration contract)
  • PR #147 (merged): set 4dd1b98dde8f (sha256 of post-eva-migration contract)

Both were correct relative to the operator’s reasoning (doctor said so) but wrong relative to the substrate’s drift-detection authority (sweep-state).

Decision

Section titled “Decision”

  1. Set repos[hermes].contract_sha in registry.yaml to 2cb484f11800 via a direct PR (not via petrova_act_registry_edit — that verb hit FILE_ALREADY_EXISTS because its ADR filename template ${date}-${verb}-${slug}.md collides with the already-merged ADR from PR #147 on the same day, with no built-in disambiguation suffix).

  2. File this ADR as the MR-7 paper trail for the direct registry edit.

  3. Flag the underlying substrate inconsistencies (separately) for follow-up — not in scope for this PR:

    • petrova doctor should emit git-blob-sha1, not sha256, so the value it surfaces to operators matches the registry contract.
    • petrova_act_registry_edit should add a disambiguation suffix (or accept a --decision-doc-slug-override) so same-day re-edits of the same slug are not blocked.

Alternatives considered

Section titled “Alternatives considered”
  • Wait until 2026-05-25 and re-run petrova_act_registry_edit so the date collision clears. Rejected — leaves the drift signal in the scheduled sweep board for ~16 hours, and the substrate inconsistency would still bite the next operator who re-uses doctor’s value.
  • Patch the doctor verb in this PR to also use git-blob-sha1. Rejected — substrate cross-verb fix is larger scope than a data correction; deserves its own PR + test coverage + decision doc. Leave as documented follow-up.
  • Edit the existing PR #147’s ADR rationale post-merge to reference 2cb484. Rejected — violates MR-7 (append-only decision ledger; edits add a Superseded-by: field only).

Consequences

Section titled “Consequences”
  • Next petrova sweep-state --slug hermes reports drift=false.
  • Phase 1 closes cleanly on the substrate side.
  • Two substrate bugs remain documented and unresolved (this ADR is the pointer; separate decision docs should open them).
  • Future contract_sha bumps for hermes should use git hash-object .petrova/contract.yaml (or equivalently petrova sweep-state --slug hermes and read the emitted sha), not petrova doctor’s output.

Sign-off

Section titled “Sign-off”