reuse-surface/history/2026-06-16-wp0014-remaining-work-by-repo.md

REUSE-WP-0014 — remaining work by repo

Date: 2026-06-16
Context: Workplan archived; 60/60 established, 48/60 publish pass, 60/60 hub registered. This note is the operator/agent checklist for follow-up outside the closed workplan.

2026-06-16 (WP-0015 follow-up): hub-core publish pass; 12 Gitea blockers remain. Dedup complete (reuse-surface index: 3 entries).

Roster: registry/federation/local-repo-roster.yaml
Dedup plan: history/2026-06-16-federation-deduplication-plan.md

---

1. Gitea publish blockers (12 repos)

Federation cannot fetch these indexes until Gitea raw URLs return HTTP 200.

hub-core — resolved (2026-06-16)

Gitea repo coulomb/hub-core created; push and publish-check pass. Roster publish_check: pass.

activity-core — seeded capability

| Issue | Gitea repo/page 404; has capability.activity.event-coordinate locally | | Action | Fix Gitea visibility (below), confirm publish, then remove duplicate from reuse-surface per dedup plan (reuse-surface still canonical until owner index fetches).

SSH push OK, raw URL 404 (11 repos)

Pattern: git push origin main succeeds but https://gitea.coulomb.social/coulomb/<slug>/raw/main/registry/indexes/capabilities.yaml returns 404. Typical causes: private repo without anonymous raw access, repo exists only on SSH mirror, or wrong org/path on web.

Slug	Suggested repo work
ihp-railiance-probe	Confirm Gitea project visibility; enable public read or document auth for federation auth_env
inter-hub	Same; likely hub/interconnect doc repo — add INTENT note linking federation membership
net-kingdom	Same; when published, consider first capability entry for network topology discovery
railiance-apps	Railiance family — align with railiance-platform visibility policy (batch fix)
railiance-cluster	Document cluster capability stubs when ready; fix Gitea with other railiance repos
railiance-enablement	Enablement/runbooks repo — optional registry entries for ops capabilities
railiance-infra	Infra repo — high value for D4+ infra capabilities once indexed
railiance-platform	Platform umbrella — prioritize publish fix for federation discoverability
tegwick-control	Control-plane repo — publish + optional feature-control relation entries
whynot-control	Pair with whynot-design; fix both Gitea entries together
whynot-design	Design canon — add capability entries when design primitives stabilize

Operator batch procedure (per slug):

1. Open https://gitea.coulomb.social/coulomb/<slug> — create repo if missing.
2. Set visibility so raw URLs work without login (or configure auth_env in sources.yaml).
3. Confirm default branch is main and registry/indexes/capabilities.yaml exists on remote.
4. Verify: curl -sL -o /dev/null -w '%{http_code}\n' '<raw-url>' → 200
5. Update roster publish_check: pass; re-run federation compose.

---

2. Owner repos — deduplicate from reuse-surface (6 repos)

Publish pass; reuse-surface still holds duplicate index rows. Remove from reuse-surface in separate commits per owner after confirming federation compose shows the owner row.

Owner repo	Capability IDs to drop from reuse-surface	Suggested owner-repo work
audit-core	capability.audit.event-retain	Promote maturity; add consumer evidence
flex-auth	capability.authorization.policy-evaluate	Link to policy modules; raise A level
feature-control	evaluate, rollout, visibility	Keep index as canonical SDK surface
identity-canon	subject-resolution, vocabulary-canonicalize	Expand canon docs; relations to identity-canon consumers
state-hub	progress-log, workstream-coordinate	Meta-registry for hub API capabilities
shard-wiki	8× capability.wiki.*	Wiki federation entries are primary product surface

reuse-surface PR template (per owner):

# After owner publish confirmed in compose
# Edit registry/indexes/capabilities.yaml — remove owner rows
# Delete registry/capabilities/capability.<domain>.<name>.md for those IDs
reuse-surface validate --relations
reuse-surface federation compose   # duplicate warnings should drop
reuse-surface graph --check

---

3. Empty scaffolds — optional capability growth (47 repos)

Established with capability_count: 0. No WP-0014 follow-up required unless the repo gains reusable behavior worth registering.

Suggested priority (repos with clear product boundaries):

Repo	Suggestion
llm-connect	Register LLM bridge / provider capabilities (feeds establish --discover)
ops-bridge	Tunnel/ops capabilities; relations to ops-hub, ops-warden
repo-seed / repo-scoping	Registry bootstrap meta-capabilities
open-reuse	Open-reuse policy and contribution capabilities
the-custodian	Custodian orchestration capabilities
helix-forge	Domain umbrella entries for cross-repo patterns

Low-friction growth path:

cd ~/<slug>
reuse-surface establish --discover --dry-run   # optional LLM_CONNECT_URL
reuse-surface validate --root .
git add registry/ && git commit -m "Add capability entries" && git push origin main
reuse-surface establish --publish-check --raw-url <gitea-raw-url>

---

4. Cross-cutting (reuse-surface)

Item	Action
Roster hygiene	After each fix, patch local-repo-roster.yaml summary counts
Hub manifest	reuse-surface hub sync --merge after URL or membership changes
Federation	reuse-surface federation compose — target 0 duplicate warnings post-dedup
Observability	reuse-surface stats --roster registry/federation/local-repo-roster.yaml --federation-ready
CI	Consider informational roster stats step when publish_fail > 0

---

5. Verification checklist (when all blockers cleared)

• Roster publish_fail: 0
• federation compose — 0 remote fetch warnings
• federation compose — 0 duplicate-ID warnings (after reuse-surface dedup)
• reuse-surface hub list — 60 enabled registrations
• Federated capability count reflects unique owner entries (~21+ as owners grow)