diff --git a/config/workplan-prefix-registry.yaml b/config/workplan-prefix-registry.yaml index f2668b1..abb666c 100644 --- a/config/workplan-prefix-registry.yaml +++ b/config/workplan-prefix-registry.yaml @@ -62,6 +62,9 @@ owners: WHYNOT-WP: whynot-design OPS-WP: ops-hub WNCTL-WP: whynot-control + CORE-WP: core-hub + DISCTL-WP: disaster-control + REPO-WP: repo-seed historical_collisions: - id: RAILIANCE-WP-0015 repos: [railiance-platform, railiance-apps] diff --git a/docs/evidence/2026-10-03-publisher-registry-refresh.md b/docs/evidence/2026-10-03-publisher-registry-refresh.md new file mode 100644 index 0000000..8410b33 --- /dev/null +++ b/docs/evidence/2026-10-03-publisher-registry-refresh.md @@ -0,0 +1,47 @@ +# Publisher registry image refresh — 2026-10-03 + +Work: RMGR-WP-0018. Deployment acceptance: RAPPCOREHUB-WP-0003-T05. + +The incoming 121 accepted / 2 errors report comes from the September 1 image +`sha256:a78fa953815b7abe78afb63ce43a29da9f09f609ace9aad2aeb98a746544e849`. +The repository already corrected identity-canon → commerce-canon in ca7dcad +and flex-auth → access-engine in d66d474. `Containerfile` embeds the registry, +so pushing those commits did not update the running publisher. + +## Verified identities + +| Canonical source | Forge ID | Preserved repository UUID | Observed default-branch commit | +| --- | --- | --- | --- | +| coulomb/commerce-canon | 46 | 8c82baea-bb40-435d-ac42-ec7a7c20dbb8 | 2e230e7d3e163d925f040d49143426a7e622aca6 | +| coulomb/access-engine | 42 | fda8ad85-a7d7-4055-8f21-902a533e59df | 424f1e500962470bfbe6f5ac4200ce200ecdb73e | + +Public Forgejo metadata and the State Hub direct `/repos/` reads agree +with the committed registry. Both sources were observed through +`ForgejoClassificationClient.observe` on the workstation and again inside the +built image. Exact identity checks remain enabled; both classifications parse. +The old identity-canon API coordinate returns the commerce-canon identity. + +## Published artifact + +- Clean build source: `03869ff30493455820ca9c4b845574ffd4c59b44`. +- Build: `make container-build IMAGE_TAG=03869ff30493455820ca9c4b845574ffd4c59b44`. +- Published tag: `forgejo.coulomb.social/coulomb/repo-manager:03869ff30493455820ca9c4b845574ffd4c59b44`. +- Immutable image: `forgejo.coulomb.social/coulomb/repo-manager@sha256:69d00898cfa1ff0a4b7db8cdc86d15f5f4bea4526915019d3ca82b6f5574354c`. +- `docker push` succeeded and reported that digest. +- Embedded registry: 123 entries, containing commerce-canon and access-engine; + neither retired slug remains. +- Packaged `rmgr publisher api` starts; `/readyz` returns HTTP 200 and + `{"status":"ok","repository_count":123}`. +- `make test`: 196 passed, one existing Starlette/httpx deprecation warning. + +## Remaining live acceptance + +The container smoke test verifies the packaged registry, runtime, and two +renamed sources. It does not claim a 123/0 production scan: the dedicated +private-source credential remains with the deployed service. + +rapp-core-hub must pin the digest above, deploy through its approved release +procedure, and run `make verify-publisher`. Track the resulting 123 accepted / +0 errors receipt under RMGR-WP-0018-T03 and RAPPCOREHUB-WP-0003-T05. Enabling +`publisher.connectCandidate` remains the wrapper's separate step. No cluster +resources were changed in this session. diff --git a/docs/repository-classification-publisher.md b/docs/repository-classification-publisher.md index 49179f9..6cd6f2c 100644 --- a/docs/repository-classification-publisher.md +++ b/docs/repository-classification-publisher.md @@ -50,6 +50,26 @@ The import is a migration/bootstrap path. Normal governed registration must maintain the committed UUID-to-Forgejo mapping after State Hub registrar retirement. The publisher contract does not change. +### Deliver registry corrections + +`Containerfile` copies the committed registry into the publisher image. A Git +push or `rmgr sync` updates source/work-record projections; it does not refresh +the registry in an already running publisher. After a repository rename: + +1. Verify the canonical Forgejo `full_name` and preserve the registrar UUID. +2. Update the registry coordinates, commit, and build an image from that clean + commit with `make container-build IMAGE_TAG=`. +3. Verify the embedded registry and observe the renamed sources from the image, + then push the image and record its immutable digest. +4. Track the deployment in the consuming wrapper (`rapp-core-hub`). Pin the new + digest and deploy through its approved release procedure, then run + `make verify-publisher` before enabling `publisher.connectCandidate`. + +Keep the exact identity check strict: an old Forgejo URL redirecting to a new +repository name is evidence to update the registry, not permission to silently +change published identity. Source correction and live rollout need separate +completion evidence. The October 3 refresh is tracked in `RMGR-WP-0018`. + ## Run Set runtime configuration through the environment: diff --git a/intakes/intakes.md b/intakes/intakes.md index 0729c10..bc28b2d 100644 --- a/intakes/intakes.md +++ b/intakes/intakes.md @@ -37,7 +37,7 @@ description: Before any new workplan is allocated under WHYNOT-WP, OPS-WP, or RE finished/archived files remain frozen. Re-run rmgr prefix-uniqueness and identifier preflight after assignment. created: '2026-08-21T20:34:42.177493+00:00' -updated: '2026-09-09T20:42:09.617881Z' +updated: '2026-10-03T08:32:00Z' state_hub_intake_id: "01a02611-a663-7712-bd4b-e39c13e7bf20" notes: - content: >- @@ -50,6 +50,16 @@ notes: CORE-WP for core-hub, DISCTL-WP for disaster-control, and REPO-WP for repo-seed; finalize these registry assignments before reuse. author: codex + - content: >- + 2026-10-03: registered CORE-WP to core-hub, DISCTL-WP to disaster-control, + and REPO-WP to repo-seed after checking their current AGENTS.md declarations + and the fleet prefix scan. No new ownership mismatch or reused identifier. + Registry assignment is complete. This intake stays open because + whynot-control/AGENTS.md still advertises WHYNOT-WP rather than its registered + WNCTL-WP; that repository must align its instructions before allocation. + The broader audit still reports pre-existing CUST-WP/RAILIANCE-WP sharing + and NET-WP/RAILIANCE-WP retirement findings; historical files remain frozen. + author: codex ``` ## RMGR-IN-0003 — Scope normal sync identity validation to actionable records diff --git a/workplans/ADHOC-2026-10-03.md b/workplans/ADHOC-2026-10-03.md new file mode 100644 index 0000000..76aef83 --- /dev/null +++ b/workplans/ADHOC-2026-10-03.md @@ -0,0 +1,27 @@ +--- +id: RMGR-WP-ADHOC-2026-10-03 +type: workplan +title: "Complete pending repository prefix registrations" +domain: infotech +repo: repo-manager +status: finished +owner: codex +created: "2026-10-03" +updated: "2026-10-03" +--- + +## Register the existing declared owners + +```task +id: RMGR-WP-ADHOC-2026-10-03-T01 +status: done +priority: medium +``` + +Added CORE-WP → core-hub, DISCTL-WP → disaster-control, and REPO-WP → repo-seed +to `config/workplan-prefix-registry.yaml`, as already declared by those owners. +Fleet prefix audits before and after are identical: none of these prefixes is +shared, misowned, or reused. Existing unrelated audit findings remain visible. +Full suite: 196 passed. The remaining whynot-control instruction correction is +tracked by the existing live residual intake RMGR-IN-0002 (origin +RMGR-WP-0004); it remains open. diff --git a/workplans/RMGR-WP-0018-publisher-registry-image-refresh.md b/workplans/RMGR-WP-0018-publisher-registry-image-refresh.md new file mode 100644 index 0000000..851a993 --- /dev/null +++ b/workplans/RMGR-WP-0018-publisher-registry-image-refresh.md @@ -0,0 +1,68 @@ +--- +id: RMGR-WP-0018 +type: workplan +title: "Deliver publisher registry corrections for renamed repositories" +domain: infotech +repo: repo-manager +status: blocked +owner: codex +created: "2026-10-03" +updated: "2026-10-03" +--- + +# Deliver publisher registry corrections for renamed repositories + +Inbox requests 067710ae-825a-4a13-b3f8-60ee3ef60aab and +706d014b-1aee-4a51-988e-8ec6dd4330ce report two identity mismatches in the +deployed publisher. Both source corrections already exist, but the runtime +still uses the September 1 image. Track source/package completion separately +from the consuming wrapper's live acceptance gate. + +## Verify both canonical registry identities + +```task +id: RMGR-WP-0018-T01 +status: done +priority: high +``` + +Forgejo reads on October 3 confirm identity-canon redirects to commerce-canon +(Forge ID 46), and access-engine resolves with Forge ID 42. State Hub direct +identity reads confirm the existing UUIDs match the committed registry. +The corrections landed in ca7dcad (September 6) and d66d474 (September 30). +Both sources pass the strict publisher observation path with exact commit and +classification fingerprints. No UUID reassignment or archived evidence edit. + +## Package and verify the corrected registry + +```task +id: RMGR-WP-0018-T02 +status: done +priority: high +``` + +Build the publisher from clean source commit +03869ff30493455820ca9c4b845574ffd4c59b44, verify its embedded registry and runtime, +and publish an immutable digest for the wrapper. Document the image refresh +requirement so a source-only correction is not mistaken for live completion. + +Published image: +`forgejo.coulomb.social/coulomb/repo-manager@sha256:69d00898cfa1ff0a4b7db8cdc86d15f5f4bea4526915019d3ca82b6f5574354c`. +The container holds 123 entries, observes both renamed sources successfully, +and serves `/readyz` with HTTP 200. Full suite: 196 passed. +Evidence: `docs/evidence/2026-10-03-publisher-registry-refresh.md`. + +## Track deployment and full publisher acceptance + +```task +id: RMGR-WP-0018-T03 +status: wait +priority: high +blocking_reason: "rapp-core-hub must pin and deploy the corrected publisher image through its approved release procedure, then verify 123 accepted / 0 errors." +``` + +The deployment owner is rapp-core-hub, tracked by RAPPCOREHUB-WP-0003-T05. +This repository session packages the correction; it does not authorize a live +cluster rollout. After deployment, retain the 123/0 receipt here and in the +wrapper before claiming live completion. Candidate connection remains the +wrapper's separate acceptance step.