workplans: record controlled SBOM canary
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

This commit is contained in:
codex 2026-08-23 00:29:37 +02:00
parent b762f6b8e5
commit 8a481414ec
3 changed files with 32 additions and 11 deletions

View file

@ -76,7 +76,7 @@ Forgejo administrator PAT.
```task
id: CUST-WP-0064-T02
status: progress
status: done
priority: high
state_hub_task_id: "2029e525-0573-5fea-881c-d3a418b91c9d"
```
@ -111,11 +111,20 @@ projects the full-SHA reference, verifies Nexus returns it unchanged, and
projects no workstation path. T03 therefore waits only on the Nexus/package
dark canary rather than new Repo Manager implementation.
**Done (2026-08-23):** corrected application digest
`sha256:1da0f4f008643a0dec3f00bbad15f287103aa4b469577b78cfe1d67f8b3cbe31`
is live at migration `0002 (head)`. The package enforces migration-before-
runtime ordering, Forgejo-only egress, bounded ephemeral storage, and a dark
feature default. The first promotion exposed an Alembic `SET ROLE` outer-
transaction rollback; the runtime was restored immediately, the defect gained
a regression test, and the corrected migration committed before retry rollout.
Process/database health, repository reads, and zero-restarter startup all pass.
## Retarget bounded catch-up without widening it
```task
id: CUST-WP-0064-T03
status: wait
status: progress
priority: high
state_hub_task_id: "6c645778-be59-57b1-bf44-d974a3a1e49f"
```
@ -126,11 +135,16 @@ than `catch_up_limit`, reuse the same targets and operation ids across retries,
and record terminal unsupported/failed inputs without advancing into a second
batch.
Repo Manager projected `sbom-nexus` with `checkout_path: null` and exact
`forgejo-archive-v1` revision
`b1fd3ec131666e5300aa98abcdddd46219303edb`; Nexus returned it unchanged.
Activity Core's bounded scheduled invocation remains to be proved live.
## Prove real daily freshness improvement
```task
id: CUST-WP-0064-T04
status: wait
status: progress
priority: medium
state_hub_task_id: "664d90b0-1169-58fa-9a77-df53e739f957"
```
@ -141,11 +155,18 @@ id, and licence summary; zero spawned tasks; cleanup of transient source; and
truthful `last_success_at` / State Hub compatibility projection. Record the
remaining `never_count` and operator disable/rollback controls.
The attended operation created snapshot
`04f5c0ba-d073-4577-ba2d-0854346ac7be` with 33 entries, exact revision and
archive provenance, zero errors, identical replay for the same durable key,
and an empty transient directory before and after. The feature was returned
dark without deleting the snapshot. A normal scheduled fire and fleet summary
remain the final proof.
## Acceptance
- [ ] Production scans consume a controlled, revision-pinned source input
- [ ] No workstation filesystem is mounted or implicitly trusted
- [ ] Nexus remains the only authoritative snapshot writer
- [x] Production scans consume a controlled, revision-pinned source input
- [x] No workstation filesystem is mounted or implicitly trusted
- [x] Nexus remains the only authoritative snapshot writer
- [ ] One fire remains bounded to its original N targets across retries
- [ ] At least one normal scheduled fire produces real ingested snapshots
- [ ] Source cleanup, provenance, failure evidence, and rollback are verified