docs(workplans): prepare identifier batch and SBOM client follow-up

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a023c0-a0a3-7c03-b395-5a0d2757214d
This commit is contained in:
tegwick 2026-08-22 22:25:11 +02:00
parent bc0ee85ffa
commit 062a45fc58
6 changed files with 2579 additions and 0 deletions

View file

@ -0,0 +1,48 @@
# RMGR-DEC-2026-003 — Railiance Cluster identifier cutover batch
```yaml
id: RMGR-DEC-2026-003
kind: decision
title: Approve deterministic identifier batch 0004 for railiance-cluster
status: open
decision_type: pending
owner: Bernd Worsch
repo: repo-manager
workplan: RMGR-WP-0005
workplan_task: RMGR-WP-0005-T04
requested_dispositions:
- approved
- revised
- rejected
source_plan: docs/evidence/RMGR-WP-0005-helixforge-uuid-migration-plan-2026-08-22-v3.json
source_plan_sha256: b155d8f193ae3496765b1964e51f9918a3a55b1993793cc7fd3ceb3b18d12ad0
batch_manifest: docs/evidence/RMGR-WP-0005-batch-0004-railiance-cluster.json
batch_sha256: 554c6cbe119e13738efc6e2836254ddae00ea870f1cb99f2b5603336160e308d
scope:
repositories: [railiance-cluster]
replacements: 6
assignments: 0
apply_authorized: false
approval_effect: >-
Approved authorizes one repository-atomic forward cutover of exactly the
pinned batch in both current projections and the authoritative repository
file, subject to repeated no-drift and restore-point checks. Revised or
rejected authorizes no mutation.
rollback: >-
Reverse the file transaction if written, then reverse production and
workstation projection transactions using their durable aliases.
evidence: docs/evidence/RMGR-WP-0005-batch-0004-railiance-cluster-readiness-2026-08-22.md
created: "2026-08-22"
updated: "2026-08-22"
```
## Decision requested
Approve, revise, or reject the exact batch manifest named above. Approval is
limited to `railiance-cluster`, `RCLUSTER-WP-0007`, and its five live mapped
tasks; it does not authorize the two cancelled task identifiers or any later or
broader batch.
The manifest remains fail-closed: any Git, source-fingerprint, projection, or
plan-seal drift before execution voids the approval and requires a new batch
hash.

View file

@ -0,0 +1,87 @@
# RMGR-WP-0005 batch 0004 readiness
**Observed at:** `2026-08-22T20:23:10Z`
**Scope:** `railiance-cluster` only
**Decision:** `RMGR-DEC-2026-003`
## Outcome
The next deterministic-identifier batch is sealed and ready for an explicit
approval decision. No database or repository identifier was changed.
Source plan:
`RMGR-WP-0005-helixforge-uuid-migration-plan-2026-08-22-v3.json`, SHA-256 seal
`b155d8f193ae3496765b1964e51f9918a3a55b1993793cc7fd3ceb3b18d12ad0`.
Batch manifest:
`RMGR-WP-0005-batch-0004-railiance-cluster.json`, SHA-256 seal
`554c6cbe119e13738efc6e2836254ddae00ea870f1cb99f2b5603336160e308d`.
## Mappings
| Kind | Record | Current UUID | Derived UUID |
| --- | --- | --- | --- |
| Workplan | `RCLUSTER-WP-0007` | `9e208376-23f1-40c7-9813-fac1f7d6ad3b` | `16da36fe-5a10-522b-b6d6-02dbb6de6c14` |
| Task | `RCLUSTER-WP-0007-T01` | `1f8a8668-31eb-4d79-bbcd-50f6430a8d66` | `9d1f463f-e4d1-5e75-97fd-e57b833bc2b9` |
| Task | `RCLUSTER-WP-0007-T02` | `b1d4e0fa-da41-4b13-a7d6-34dd040cb605` | `a1f4fa2b-69a7-5de4-8c44-15e8f9baf0b2` |
| Task | `RCLUSTER-WP-0007-T05` | `68315a40-dd5b-4032-a9e7-1152e38f9807` | `02cc3adb-9d42-5540-9f32-4e5f1198b79e` |
| Task | `RCLUSTER-WP-0007-T06` | `f658aa6a-1c48-4660-88fa-35eaa0137e12` | `4f033381-24aa-5773-bca6-337ccacc0e7a` |
| Task | `RCLUSTER-WP-0007-T07` | `70f6c8ab-a700-4fb2-893e-cf5a40615044` | `b45b3086-3beb-56d4-a028-6bf651834992` |
The batch contains six replacements, no assignments, and no unchanged records.
`railiance-cluster` is clean, exactly synchronized with `origin/main`, and uses
the Forgejo lineage. The source plan pins HEAD
`41fdfd9d086f52eda399ddb4c740297dc0094129` and source fingerprint
`485b518216f6a731837e8ba62b9d11b154b362da3e635501c7a76e773235f468`.
Tasks `RCLUSTER-WP-0007-T03` and `RCLUSTER-WP-0007-T04` are cancelled and are
outside the live-record migration plan. Their task UUIDs remain unchanged; the
workplan foreign-key update carries both rows to the derived parent UUID.
## Projection preflight
Read-only checks against the workstation and production projections found the
same source and target rows:
| Check | Workstation | Production |
| --- | ---: | ---: |
| Current workplan UUID rows | 1 | 1 |
| Derived workplan UUID rows | 0 | 0 |
| Current mapped task UUID rows | 5 | 5 |
| Derived mapped task UUID rows | 0 | 0 |
| All tasks linked to current workplan | 7 | 7 |
| Progress events linked to current workplan | 14 | 12 |
| Decisions linked to current workplan | 1 | 1 |
| Progress events linked to mapped tasks | 5 | 5 |
Dynamic inspection of every current foreign key into `workplans` and `tasks`
found no other non-zero references to the mapped rows. The workstation schema
has 22 such foreign keys and production has 20; every one uses `ON UPDATE
CASCADE`. The two-event workplan-history difference is existing projection
history and must be preserved independently in each database.
## Approved execution interface
If `RMGR-DEC-2026-003` is approved against the exact batch hash:
1. Re-run batch/source/Git and projection preflight; stop on any drift.
2. Retain fresh, verified workstation and production database restore points.
3. Apply the repository transaction to workstation and production projections.
4. Apply the sealed authoritative file transaction for `railiance-cluster`.
5. Commit and push only the mapped workplan file.
6. Run consistency twice against each projection and require old/new API
lookups of 404/200 for all six mapped records.
7. Require all seven tasks, each projection's original workplan progress count,
its one decision, and the five mapped-task progress references to remain
linked after the cutover.
8. Require the two cancelled task UUIDs to remain unchanged beneath the derived
parent workplan UUID.
9. On failure after database apply, reverse written files if necessary, then
reverse production and workstation projection transactions through their
durable aliases.
The decision does not authorize another repository, the two cancelled task
identifiers, an assignment-only batch, or restoration of the disabled
production sweep.

View file

@ -0,0 +1,47 @@
{
"schema": "repo-manager.identifier-migration-batch.v1",
"ok": true,
"ready_for_approval": true,
"apply_authorized": false,
"approval_required": true,
"namespace": "helixforge",
"source_plan_sha256": "b155d8f193ae3496765b1964e51f9918a3a55b1993793cc7fd3ceb3b18d12ad0",
"batch_policy": "repository-atomic, sequential, stop on first failure",
"rollback_order": "reverse files if written, then reverse central projection",
"generated_at": "2026-08-22T20:17:48.348074Z",
"totals": {
"repositories": 1,
"records": 6,
"replace": 6,
"assign": 0,
"unchanged": 0
},
"repositories": [
{
"repo": "railiance-cluster",
"path": "/home/worsch/railiance-cluster",
"planned_head_sha": "41fdfd9d086f52eda399ddb4c740297dc0094129",
"source_fingerprint": "485b518216f6a731837e8ba62b9d11b154b362da3e635501c7a76e773235f468",
"source_verified": true,
"git_preflight": {
"ok": true,
"head_sha": "41fdfd9d086f52eda399ddb4c740297dc0094129",
"expected_head_sha": "41fdfd9d086f52eda399ddb4c740297dc0094129",
"upstream": "origin/main",
"behind": 0,
"ahead": 0,
"origin": "forgejo-remote:coulomb/railiance-cluster.git",
"errors": []
},
"mapping_counts": {
"records": 6,
"replace": 6,
"assign": 0,
"unchanged": 0
},
"ready": true
}
],
"errors": [],
"batch_sha256": "554c6cbe119e13738efc6e2836254ddae00ea870f1cb99f2b5603336160e308d"
}

File diff suppressed because it is too large Load diff

View file

@ -487,6 +487,23 @@ and pre-existing conformance warnings are in
`docs/evidence/RMGR-WP-0005-batch-0003-markitect-cutover-2026-08-22.md`. T04
remains in progress for separately sealed and approved fleet batches.
**Batch 0004 prepared (2026-08-22):** `railiance-cluster` is the smallest next
replacement batch represented in both current projections. Its clean source is
published and synchronized at `41fdfd9`; the refreshed fleet plan and source
fingerprint verify without drift. The batch replaces `RCLUSTER-WP-0007` and
five live task UUIDs. Its two cancelled task UUIDs remain outside the live
migration plan and follow the replaced parent through the database cascade.
Both projections contain the old six mapped rows and none of the targets. Each
retains seven child tasks, one decision, and five progress references to mapped
tasks; workstation and production retain their existing 14 and 12 workplan
progress events respectively. Every current foreign key into workplans/tasks
uses `ON UPDATE CASCADE`. The fail-closed batch hash is
`554c6cbe119e13738efc6e2836254ddae00ea870f1cb99f2b5603336160e308d`.
`RMGR-DEC-2026-003` is the directly actionable approval interface; no
identifier mutation has run. Evidence:
`docs/evidence/RMGR-WP-0005-batch-0004-railiance-cluster-readiness-2026-08-22.md`.
## Retire the interim rule
```task

View file

@ -0,0 +1,95 @@
---
id: RMGR-WP-0011
type: workplan
title: "SBOM Nexus production client and explicit preview semantics"
domain: infotech
repo: repo-manager
status: ready
owner: codex
topic_slug: infotech
created: "2026-08-22"
updated: "2026-08-22"
parent_workplan: SBOM-WP-0002
related:
- CUST-WP-0062
- RMGR-WP-0008
---
# SBOM Nexus production client and explicit preview semantics
## Goal
Complete Repo Manager's caller cutover to SBOM Nexus without reintroducing a
second SBOM product. Repo Manager retains repository identity, active status,
and checkout-path authority; SBOM Nexus owns `sbom-nexus.snapshot.v1`, ingest
outcomes, licence evaluation, freshness, and immutable history.
RMGR-WP-0008 already removed Repo Manager's duplicate scanner and changed the
legacy commands into thin delegates to the Nexus CLI. This workplan addresses
the remaining production boundary: distinguish a persisted Nexus operation
from a local, non-authoritative preview and provide a configured service client
for callers that require authoritative state.
## Pin the consumer contract
```task
id: RMGR-WP-0011-T01
status: todo
priority: high
```
Document and test the consumed `sbom-nexus.snapshot.v1` fields and the
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.
## Add the authoritative Nexus service client
```task
id: RMGR-WP-0011-T02
status: todo
priority: high
```
Provide an explicitly configured HTTP client for the Nexus repository
projection, ingest, latest-snapshot, and licence-report surfaces needed by Repo
Manager. Preserve bounded timeouts and actionable failures; credentials, when
introduced through the platform path, must never enter files, output, or logs.
## Make local scanning an explicit preview
```task
id: RMGR-WP-0011-T03
status: todo
priority: high
```
Keep repository-source scanning usable through the Nexus-owned CLI when the
service is unavailable, but mark the result unambiguously as local,
non-authoritative, and not persisted. The compatibility aliases must not imply
that a preview advanced `last_attempt_at`, `last_success_at`, or snapshot
history.
## Prove cutover and remove ambiguity
```task
id: RMGR-WP-0011-T04
status: todo
priority: medium
```
Add contract, failure, and CLI compatibility tests; update operator docs; and
prove by source inspection that Repo Manager has no scanner implementation,
snapshot store, freshness evaluation, catch-up policy, or licence classifier.
Capture the exact production handoff evidence required by SBOM-WP-0002.
## Acceptance
- Authoritative mode talks to SBOM Nexus and returns its pinned snapshot
contract without local persistence.
- Preview mode is visibly non-authoritative and cannot be mistaken for an
ingest receipt.
- Existing `rmgr sbom scan|licence-report` users receive a documented migration
path and deterministic errors.
- Repo Manager remains authoritative only for repository identity and paths;
SBOM Nexus remains the sole durable SBOM owner.