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

@ -4,7 +4,7 @@ type: workplan
title: "SBOM Nexus production client and explicit preview semantics"
domain: infotech
repo: repo-manager
status: ready
status: active
owner: codex
topic_slug: infotech
quality_dor: DoR-Ok
@ -13,6 +13,7 @@ updated: "2026-08-22"
parent_workplan: SBOM-WP-0002
related:
- CUST-WP-0062
- CUST-WP-0064
- RMGR-WP-0008
state_hub_workstream_id: "a6cd9248-e591-51fc-82b0-a0f3799c3939"
---
@ -36,7 +37,7 @@ for callers that require authoritative state.
```task
id: RMGR-WP-0011-T01
status: todo
status: done
priority: high
state_hub_task_id: "b3b0f4d9-de14-5429-bc4d-a14d014491b0"
```
@ -46,6 +47,15 @@ authoritative service routes. Treat additive fields as compatible, reject an
unknown schema, and do not couple Repo Manager to Nexus database tables or
migration internals.
**Result (2026-08-22):** `docs/sbom-nexus-client-contract_v1.md` pins the
accepted `sbom-nexus.snapshot.v1` envelope and the Nexus-owned repository,
ingest/skip, latest-snapshot, immutable-history, and licence-report routes.
Additive response fields remain compatible; unknown schemas and missing
required fields produce deterministic contract errors. The source handoff now
joins `CUST-WP-0064`: Repo Manager supplies repository identity and revision,
while the authoritative scan consumes a controlled revision-pinned source. A
workstation filesystem must never be mounted into the cluster.
## Add the authoritative Nexus service client
```task
@ -64,7 +74,7 @@ introduced through the platform path, must never enter files, output, or logs.
```task
id: RMGR-WP-0011-T03
status: todo
status: done
priority: high
state_hub_task_id: "5cd717de-d696-5676-9abe-f1a701e48e7e"
```
@ -75,6 +85,13 @@ non-authoritative, and not persisted. The compatibility aliases must not imply
that a preview advanced `last_attempt_at`, `last_success_at`, or snapshot
history.
**Result (2026-08-22):** both compatibility aliases now identify every success
and error as `mode: local-preview`, `authoritative: false`, `persisted: false`,
and explicitly state that no last-attempt, last-success, or snapshot-history
state advances. Saving preview JSON remains optional local evidence and cannot
be interpreted as an ingest receipt. CLI help, operator documentation, and
contract tests carry the same semantics.
## Prove cutover and remove ambiguity
```task