2026-08-17 — Backfill contract_sha for traceo-mcp-server

---

rank: decision outranks: []

2026-08-17 — Backfill contract_sha for traceo-mcp-server

Date: 2026-08-17 Status: proposed Verb: request_review Slug: traceo-mcp-server MR-compliance: MR-12

Rationale

traceo-mcp-server has carried no contract_sha since admission on 2026-04-30, while .petrova/contract.yaml exists on traceo-cat/traceo-mcp-server@main and the sweep has been reading it. The state file has therefore recorded actual_contract_sha: 0c3008e90309 against contract_drift: null — a probed value with nothing to compare it to.

Value: 0c3008e90309, the 12-char git-blob-sha1 of .petrova/contract.yaml at traceo-cat/traceo-mcp-server@main, per the method ratified in docs/decisions/2026-05-24-contract-sha-hash-method-fix-hermes.md.

Verified two independent ways, which that decision exists precisely because of:

Source	Value
GitHub contents API .sha	0c3008e90309797ddac537cbf24b8c42891a7395
sha1("blob <len>\0" + content) recomputed locally (1969 bytes)	0c3008e90309797ddac537cbf24b8c42891a7395

Neither value is copied from state/traceo-mcp-server.yaml. The sweep’s actual_contract_sha agrees, but it is the thing this entry will be compared against, so it cannot also be the source.

Effect

contract_drift for this slug moves null → false on the next sweep. It is currently null because sweep_state.ts:161 requires repo.contract_sha to be truthy before it will compare anything — absence yields no comparison, not a failed one.

Why this PR is deliberately small

.github/workflows/registry-slug-scope.yml (#317) has never run against a real pull request: #317 does not itself touch registry.yaml, so its own paths: filter correctly skipped it. This is the first PR that fires it, and it was chosen to be one whose correct outcome is known in advance — a single slug, a single added key, no rename, no removal. The guard should report exactly:

registry.yaml — 1 slug(s) touched
  changed traceo-mcp-server
      added   contract_sha: now "0c3008e90309"
OK

If it reports anything else, the guard is wrong and the next registry PR should not rely on it. Sequencing it ahead of the registry-edit.ts rebuild fix keeps a guard misfire and a rebuild-logic change from landing in the same commit, where either could explain a surprise.

Related

• PTV-FND-0045 — a whole-file rebuild reverts every edit it did not make.
• #315 — the same backfill for tektree-io, after #246 deleted it.
• #317 — the slug-scope guard this PR exercises.