REUSE-WP-0017-T06: diagnose config-atlas publish blocker

Two conflated issues: (1) the raw-URL 303 redirect is already followed
correctly by establish.py's urllib-based probe -- re-running
publish-check now passes; the stale roster fail was from the 2026-06-16
sweep, not a live issue. (2) config-atlas was never actually registered
with the production hub (absent from the 60 sources at
reuse.coulomb.social/v1/federated despite hub_registered: true in the
roster) -- corrected to false. Local publish pass is now 61/61; hub
registration itself is blocked on REUSE_SURFACE_TOKEN, which has no
routing catalog entry -- needs Bernd to provide or route it.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

registry/federation/local-repo-roster.yaml

@@ -9,10 +9,10 @@ summary:
   established: 61
   pending: 0
   with_reuse_surface_seed: 8
-  hub_registered: 61
-  publish_pass: 60
-  publish_fail: 1
-  publish_sweep: '2026-06-16'
+  hub_registered: 60
+  publish_pass: 61
+  publish_fail: 0
+  publish_sweep: '2026-07-06'
   capability_status_has: 48
   capability_status_none: 13
   capability_status_pending: 0
@@ -111,9 +111,14 @@ repos:
   seed_from_reuse_surface: false
   seed_capability_ids:
   - capability.infotech.config-surface-atlas
-  hub_registered: true
-  publish_check: fail
-  publish_note: 303 not published (same block as state-hub/feature-control)
+  hub_registered: false
+  publish_check: pass
+  publish_note: local publish-check now passes (2026-07-06); Gitea's raw-URL
+    303 redirect (/raw/main/... -> /raw/branch/main/...) is followed
+    correctly by the current establish --publish-check code. hub_registered
+    corrected to false -- config-atlas is absent from the 60 sources in
+    https://reuse.coulomb.social/v1/federated; registration blocked on
+    REUSE_SURFACE_TOKEN (see REUSE-WP-0017-T06).
   batch: B02
 - slug: coordination-engine
   path: /home/worsch/coordination-engine

tests/test_reports.py

@@ -97,7 +97,7 @@ def test_collect_gap_report_from_roster():
     roster = root / "registry/federation/local-repo-roster.yaml"
     report = collect_gap_report(roster)
     assert report["summary"]["total"] == 61
-    assert len(report["publish_fail"]) == 1
+    assert len(report["publish_fail"]) == 0
     assert report["unclassified_count"] + report["explicit_none_count"] == report["empty_scaffold_count"]
     assert "/" in report["coverage_ratio"]
 

workplans/REUSE-WP-0017-capability-coverage-campaign.md

@@ -205,17 +205,41 @@ state_hub_task_id: "56b68b6f-4dca-4fed-925f-d20783dc40d9"
 
 ```task
 id: REUSE-WP-0017-T06
-status: todo
+status: progress
 priority: medium
 state_hub_task_id: "1a04b60a-b982-4b5f-ae20-955bc88d4204"
 ```
 
-- Diagnose the 303 on the config-atlas raw index URL (same block class as the
-  earlier state-hub/feature-control issue)
-- Note: likely interacts with the Gitea→Forgejo host transition
-  (REUSE-WP-0019-T01); if the new Forgejo raw URL scheme fixes it, record that
-  and close here
-- Target: 61/61 publish pass
+**Diagnosis complete — two separate issues, conflated in the original note:**
+
+1. **The 303 itself was not actually a live blocker.** Gitea's raw-URL
+   scheme is `/raw/main/<path>` -> 303 redirect -> `/raw/branch/main/<path>`
+   -> 200. `establish.py`'s `_probe_raw_url` uses `urllib.request.urlopen`,
+   which already follows redirects transparently (verified: HEAD request to
+   the `/raw/main/...` URL resolves to 200 today). Re-running
+   `establish --publish-check` for config-atlas now returns **PASS**. The
+   roster's `publish_check: fail` was stale data from the 2026-06-16 sweep,
+   not a reproducible current failure — corrected in the roster (publish
+   pass now 61/61).
+2. **config-atlas was never actually registered with the production hub.**
+   Diffing `https://reuse.coulomb.social/v1/federated` (60 sources) against
+   the local roster (61 repos) shows config-atlas is the only mismatch —
+   present in `sources.yaml` and locally claimed `hub_registered: true`
+   (from the config-atlas registration commit), but genuinely absent from
+   the hub. Corrected the roster's `hub_registered` to `false` for
+   config-atlas (summary count 61 -> 60) to reflect reality.
+
+**Blocked on a credential I should not obtain informally:** completing the
+hub registration needs `reuse-surface hub register --repo config-atlas
+--url ... REUSE_SURFACE_TOKEN=<write-token>`. No catalog entry exists yet
+in `~/ops-warden/registry/routing/catalog.yaml` for this token (checked via
+`warden route find`) — it isn't a generic OpenBao/Vault lane, it's
+reuse-surface's own hub write credential. **Needs Bernd to either provide
+the token or point at where it's routed.**
+
+- [x] Diagnose the 303 (resolved — not a current blocker, code already follows the redirect)
+- [x] Local publish-check target: 61/61 pass
+- [ ] Complete hub registration for config-atlas (blocked on `REUSE_SURFACE_TOKEN`)
 
 ## Closeout: Coverage Metrics, Docs, SCOPE Update