Close REUSE-WP-0011 follow-ups: archive, docs, A4 promotion

- Archive workplan to workplans/archived/260615-REUSE-WP-0011-*.md
- Document browser landing page routing in FederationHubAPI and deploy docs
- Promote capability.registry.register to A4 (hosted hub API evidence)
- Update SCOPE finished workplan list

SCOPE.md

@@ -90,8 +90,8 @@ See `tools/README.md` for command reference.
 - Remote federation: HTTP URL sources with cache in `registry/federation/cache/`.
 - Hosted federation hub: `https://reuse.coulomb.social` (REUSE-WP-0011, image
   `gitea.coulomb.social/coulomb/reuse-surface`).
-- Finished workplans: `REUSE-WP-0001` through `REUSE-WP-0010`; `REUSE-WP-0011`
-  active (deploy + dogfood).
+- Finished workplans: `REUSE-WP-0001` through `REUSE-WP-0011` (hub archived
+  2026-06-15).
 - **Self-assessed vector:** `D5 / A3 / C4 / R3` (see gap analysis).
 
 ## Repository Layout

docs/deploy/reuse-kubernetes.md

@@ -26,6 +26,16 @@ Mount a PVC at `/data` for persistence. Inject secrets via Kubernetes Secret
 
 - Liveness/readiness: `GET /health` on port `8000`
 
+## Browser landing page
+
+Production ingress routes HTTPS `/` to a static landing Deployment
+(`reuse-surface-landing`, **RAILIANCE-WP-0008**). API paths are unchanged:
+
+- `/health` and `/v1/*` → hub service container
+- `/` → informational HTML for browser visitors (no login, no secrets)
+
+Agents and CLI clients should target `/health` and `/v1/*` only, not `/`.
+
 ## Public URL and DNS
 
 | Item | Value |

registry/capabilities/capability.registry.register.md

@@ -20,12 +20,14 @@ maturity:
       registry model is bounded in INTENT.md, but concrete promotion workflows
       are not yet grounded in registry artifacts.
   availability:
-    current: A3
-    target: A3
+    current: A4
+    target: A5
     confidence: medium
     rationale: >
-      Registration and maintenance are automatable through the reuse-surface CLI
-      for validate, query, and export workflows.
+      Local registry workflows use the reuse-surface CLI (A3). Federation repo
+      registration is also available through the hosted hub HTTP API at
+      reuse.coulomb.social (POST/PATCH /v1/repos), deployed and dogfood-tested
+      on Railiance01 (REUSE-WP-0011).
 
 external_evidence:
   completeness:
@@ -38,6 +40,7 @@ external_evidence:
       - maturity vectors can be recorded at registration time
       - CLI validate, query, and export support registry workflows
       - promotion history can be recorded in entries
+      - federation repo registration via hosted hub API and hub CLI
     broken_expectations:
       - no automated duplicate detection yet
     out_of_scope_expectations:
@@ -76,17 +79,22 @@ discovery:
     - specs/ProductRequirementsDocument.md
 
 availability:
-  current_level: A3
-  target_level: A3
+  current_level: A4
+  target_level: A5
   current_artifacts:
     - templates/capability-entry.template.md
     - registry/indexes/capabilities.yaml
     - reuse_surface/cli.py
-  target_artifacts: []
+    - reuse_surface/hub/
+    - specs/FederationHubAPI.md
+    - https://reuse.coulomb.social
+  target_artifacts:
+    - packaged container release with documented SLO
   consumption_modes:
     - informational
     - markdown authoring
     - cli
+    - service API
 
 relations:
   depends_on: []
@@ -100,7 +108,10 @@ evidence:
   documentation:
     - INTENT.md
     - specs/UseCaseCatalog.md
-  tests: []
+    - specs/FederationHubAPI.md
+    - docs/deploy/reuse-kubernetes.md
+  tests:
+    - tests/test_hub.py
   consumer_feedback: []
   bug_reports: []
   incidents: []
@@ -135,6 +146,14 @@ promotion_history:
     to: A3
     rationale: reuse-surface CLI shipped validate, query, and export commands.
     author: reuse-surface
+  - date: "2026-06-15"
+    dimension: availability
+    from: A3
+    to: A4
+    rationale: >
+      Hosted federation hub live at reuse.coulomb.social; hub register/update
+      via HTTP API and reuse-surface hub CLI; production deploy on Railiance01.
+    author: reuse-surface
 ---
 
 # Capability Registration
@@ -147,12 +166,15 @@ documentation exists elsewhere.
 
 ## Current reuse mode
 
-Humans and agents add Markdown entries under `registry/capabilities/` and update
-`registry/indexes/capabilities.yaml`. This is informational reuse (A0): read,
-plan, and author entries.
+**Local registry (A3 CLI):** add Markdown entries under `registry/capabilities/`,
+update `registry/indexes/capabilities.yaml`, run `reuse-surface validate`.
+
+**Federation registration (A4 API):** register published index URLs on the hosted
+hub (`reuse-surface hub register`, `POST /v1/repos`) for cross-repo discovery
+via `GET /v1/federated`.
 
 ## Next promotion steps
 
 1. Attach concrete use cases and actors to reach D5.
-2. Add a CLI validator to reach A3.
+2. Package hub as a versioned container release with operator SLO (A5).
 3. Record consumer expectations and broken expectations as external evidence.

registry/indexes/capabilities.yaml

@@ -94,13 +94,13 @@ capabilities:
   - id: capability.registry.register
     name: Capability Registration
     summary: Register a new capability so it becomes visible for planning and implementation reuse.
-    vector: D3 / A3 / C2 / R2
+    vector: D3 / A4 / C2 / R2
     domain: helix_forge
     status: draft
     owner: reuse-surface
     path: registry/capabilities/capability.registry.register.md
     tags: [registry, governance, meta]
-    consumption_modes: [informational, markdown authoring, cli]
+    consumption_modes: [informational, markdown authoring, cli, service API]
 
   - id: capability.registry.validate
     name: Registry Entry Validation

specs/FederationHubAPI.md

@@ -13,7 +13,21 @@ The federation hub is a hosted coordination service that records which
 repositories publish capability indexes and serves a composed federated index
 for agent discovery. It does **not** store capability entry Markdown bodies.
 
-Companion deployment workplan: `railiance-apps` **RAILIANCE-WP-0007**.
+Companion deployment workplans: `railiance-apps` **RAILIANCE-WP-0007** (Helm
+release), **RAILIANCE-WP-0008** (browser landing page).
+
+### Browser vs API routing
+
+Production ingress (owned by `railiance-apps`) splits paths:
+
+| Path | Handler |
+|---|---|
+| `GET /` (HTTPS) | Static landing page (`reuse-surface-landing`) — humans only |
+| `GET /health`, `GET /v1/*` | Hub API (`reuse-surface` service) |
+
+The landing page does not implement registration or federation; clients and
+agents should use `/health` and `/v1/*` only. See
+`railiance-apps/docs/reuse-surface-on-railiance01.md`.
 
 ---
 
@@ -262,3 +276,5 @@ Run locally: `reuse-surface serve`. Global client flags: `--base-url`, env
 - Probe path: `/health`
 - Persistence: PVC at `/data` (SQLite + fetch cache)
 - Helm release: `railiance-apps` RAILIANCE-WP-0007
+- Landing page at `/`: `railiance-apps` RAILIANCE-WP-0008 (disable via
+  `landing.enabled: false` in Helm values)

workplans/archived/260615-REUSE-WP-0011-federation-hub-on-railiance01.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Federation hub service on railiance01 and hub CLI"
 domain: helix_forge
 repo: reuse-surface
-status: finished
+status: archived
 owner: codex
 topic_slug: helix-forge
 created: "2026-06-15"