feat: harden work-record and SBOM client contracts

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d
This commit is contained in:
tegwick 2026-08-22 23:19:36 +02:00
parent 2577379e36
commit 84952c5212
16 changed files with 605 additions and 30 deletions

View file

@ -288,6 +288,25 @@ two older workplans still carry production-absent random UUIDs and remain T04
work; T02 therefore stays `wait`. Evidence:
`docs/evidence/RMGR-WP-0005-rail-kubernetes-registrar-2026-08-22.md`.
**Standalone-record and duplicate-source hardening (2026-08-22):** owner
feedback exposed that the governed top-level `intakes.md`/`decisions.md`
filenames were absent from Repo Manager's explicit record-file allowlist.
Consequently an intake-only reconciliation could return `noop`; it happened to
work only when another missing record caused State Hub's broader pass to run.
The scanner now recognizes both lowercase and uppercase governed filenames,
and a direct scan of the Custodian source returns exactly `CUST-IN-0014` as
missing.
The registrar and conformance paths now also implement the Custodian kind
registry's identity-reconciliation ruling. Repeated canonical id plus the same
non-null UUID is one indexed record with all source occurrences retained and a
governed cleanup warning; conflicting or incomplete UUID assignments fail
closed. The grandfathered `MASON-0001` and `MASON-0001-TNN` forms are loaded
from the machine-readable canon mapping instead of being rewritten. Live proof
against `ops-mason` indexes `MASON-0001-T01` once, preserves both task-block
locations, and emits the cleanup diagnostic. T02 remains `wait` because its
original pre-derivation reconciliation inventory is not yet exhausted.
## Derive identifiers deterministically
```task