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

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
REUSE-WP-0017	workplan	Capability coverage campaign: seed or explicitly close all empty scaffolds	infotech	reuse-surface	active	claude-code	helix-forge	2026-07-06	2026-07-07	a2d83504-fcd0-4561-8688-b77a01cb7f06

Capability coverage campaign: seed or explicitly close all empty scaffolds

The federation infrastructure is complete (61/61 repos established and hub-registered, WP-0014/0015), but 51 of 61 roster repos publish zero capabilities. The federated index carries 24 capabilities, concentrated in a handful of custodian-core repos. A registry that answers most queries with "nothing found" trains agents to stop querying — content coverage is the prerequisite for the consumption loop (REUSE-WP-0018) and the automation loop (REUSE-WP-0019).

Goal: every roster repo either publishes ≥1 capability entry or carries an explicit, machine-readable no-reusable-capability marker with a rationale. "Empty" becomes informative instead of ambiguous.

Baseline: 10/61 repos with ≥1 capability; 51 empty scaffolds; 7 seed-ready (gap report 2026-07-06). Target: 0 ambiguous scaffolds; coverage ratio surfaced in report gaps and CI.

Approach

1. Classify before drafting. Sweep the 51 empty scaffolds and bucket each: has-capability (draft entries) vs no-capability (mark explicitly — experiments, forks, canon/docs-only repos, probes).
2. Draft with existing tooling. reuse-surface establish --discover + llm-connect per repo produces first-pass entries at honest low maturity (typically D1–D2 / A0–A1); no invented evidence.
3. Human review gate. Drafts land as branches/commits flagged for review; nothing publishes to the federated index without a human pass (same pattern as CUST-WP-0050 repo classification).
4. Publish + recompose. After review: publish-check, hub state refresh, federation compose, catalog/graph regeneration.

Dependencies

Dependency	Owner	Notes
llm-connect	llm-connect	drafting backend for establish --discover
local-repo-roster.yaml	reuse-surface	61-repo roster, sweep source of truth
.repo-classification.yaml	the-custodian	classification signals for the no-capability bucket
config-atlas publish fix	config-atlas	303 publish blocker (T06)
Sibling repo write access	Bernd	drafts commit into sibling checkouts at ~/<slug>/

Design decisions

• no-capability marker format: a registry/NO_CAPABILITIES.md file with frontmatter (reason, reviewed, revisit) in the sibling repo, plus a capability_status: none field in the roster row. report gaps treats marked repos as resolved, not empty.
• Honest maturity floor: first-pass entries never claim above D2/A2/C2/R1 without cited on-disk evidence (WP-0016 evidence gates apply).
• Batch execution: repos are processed in cohorts of ~10 via /ralph-workplan; each cohort ends with validate + gap-report delta.

---

Extend Gap Report And Roster For Explicit No-Capability Status

id: REUSE-WP-0017-T01
status: done
priority: high
state_hub_task_id: "90fe5bf2-7c03-4af5-bc4a-e5d608c7e879"

• Add capability_status: has | none | pending to roster schema and local-repo-roster.yaml handling (default pending for empty scaffolds)
• report gaps: split "Empty scaffolds" into "Unclassified" and "Explicitly none (n)"; add a coverage ratio headline (repos with capabilities or explicit none / total)
• Define registry/NO_CAPABILITIES.md template in templates/
• Pytest coverage for both report paths

Classification Sweep Of The 51 Empty Scaffolds

id: REUSE-WP-0017-T02
status: done
priority: high
state_hub_task_id: "17ea8783-1344-4d04-8f7f-f93859ae4a20"

• For each empty-scaffold repo: read INTENT/SCOPE/README + top-level layout, bucket has-capability vs no-capability with a one-line rationale
• Output: history/2026-07-06-coverage-classification.md table (repo, bucket, rationale, candidate capability ids for the has bucket) — done, 37 has-capability / 13 no-capability / 0 missing
• Cross-check against .repo-classification.yaml where available
• Human review checkpoint: Bernd confirms the bucket split before T03/T04

Mark No-Capability Repos

id: REUSE-WP-0017-T03
status: wait
priority: medium
state_hub_task_id: "3465cebf-84f9-4d67-8d8a-cca9771f2f06"

For each confirmed no-capability repo:

• Write registry/NO_CAPABILITIES.md from template into the sibling checkout — done, 13/13
• Set capability_status: none in the roster — done
• Commit in sibling repo with a uniform message referencing this workplan — done, 13 commits made locally; push held back pending explicit confirmation (auto-mode declined to push to 13 sibling repos' default branches without it)

Draft Capability Entries For Has-Capability Repos

id: REUSE-WP-0017-T04
status: done
priority: high
state_hub_task_id: "20d67516-331b-46bd-8a90-1170139313c2"

Note: establish --discover requires a running llm-connect backend, which isn't up on this workstation; spinning up a new inference service was out of scope for this task. Entries are instead drafted directly by the implementing agent, grounded in each repo's actual README/docs/tests (no invented evidence), which better matches the "no invented evidence" design principle anyway.

Cohort 1 (10/37 done): artifact-store, can-you-assist, citation-engine, citation-evidence, email-connect, guide-board, hub-core, info-tech-canon, infospace-bench, inter-hub. All validate; no overlap with the existing 24 federated capabilities. Committed locally in each sibling repo (push held for T05). Coverage 24/61 -> 34/61.

Cohort 2 (20/37 done): issue-core (migrated its existing CAPABILITY-issue-tracking.yaml into the standard registry location rather than drafting fresh), kaizen-agentic, key-cape, kontextual-engine, llm-connect, markitect-filter, markitect-main (registered honestly as a superseded legacy platform pointing at its three successor repos, not a forward-looking target), markitect-quarkdown, markitect-tool, net-kingdom. All validate; no overlap with existing federated capabilities. Committed locally (push held for T05). Coverage 34/61 -> 44/61. Also fixed a stale empty_scaffold_count >= 40 test threshold in tests/test_reports.py — no longer meaningful once the coverage campaign started shrinking that number by design.

Cohort 3 / final (17/17 done): open-cmis-tck, open-reuse, ops-bridge, phase-memory, railiance-apps, railiance-cluster, railiance-enablement, railiance-fabric, railiance-forge, railiance-infra, railiance-platform, repo-scoping, the-custodian, user-engine, vantage-point, vergabe-teilnahme, whynot-design. All validate; no overlap with existing federated capabilities. Committed locally (push held for T05). Coverage 44/61 -> 61/61 — full coverage, T04 complete.

Notable calls in this cohort:

• the-custodian: repo root is confidential/proprietary (NDA notice in its README). Entry is deliberately scoped only to the non-confidential runtime/ agent framework and tools/ repo-classification scripts; canon/memory content is explicitly excluded from the entry's includes and called out in consumer_guidance.not_recommended_for.

• vergabe-teilnahme: its own SCOPE.md is an unfilled template, so discovery is honestly D1/C0 — flagged in known_limitations that filling in SCOPE.md is the natural next step before further promotion.

• markitect-main (cohort 2) and vantage-point/railiance-forge patterns repeat here: several repos (open-reuse, vantage-point) have a stale repo-seed-template README; SCOPE.md/INTENT.md were used as the authoritative source instead, noted per-entry.

• railiance-enablement, railiance-apps, the-custodian: each surfaced tooling directly relevant to REUSE-WP-0019 (Forgejo promotion script, forgejo-smoke.sh, patch-forgejo-remote-urls.sh) — worth cross- referencing when that workplan starts its host-migration inventory (T01).

• reuse-surface establish --discover with llm-connect per repo

• Manual tightening: id namespace (capability.<domain>.<verb>), scope boundary, honest vectors, relations to existing federated capabilities

• reuse-surface validate + overlaps check per cohort (no duplicate semantics vs the existing 24)

• Drafts committed in sibling repos, flagged for human review; roster capability_status: has

Human Review And Publish Pass

id: REUSE-WP-0017-T05
status: progress
priority: high
state_hub_task_id: "56b68b6f-4dca-4fed-925f-d20783dc40d9"

• Bernd reviews drafted entries per cohort (maturity honesty, scope, ids)
• After approval: sibling repos push; establish --publish-check per repo; hub registrations refreshed where raw URLs changed
• reuse-surface federation compose + catalog + graph regeneration in this repo

Started 2026-07-07. Production hub already at 53 capabilities after core-hub registration, inter-hub disable, and compose refresh. Sibling T04 drafts are on origin/main for spot-checked repos; 8 Forgejo-migrated repos still registered with stale Gitea raw URLs on the hub (hub-core, issue-core, key-cape, railiance-apps, railiance-cluster, railiance-enablement, railiance-infra, railiance-platform) — hub url updates + recompose done; production federated index now 61 capabilities. Human review checklist: history/2026-07-07-t05-review-checkpoint.md (extends T04 summary).

Fix config-atlas Publish Blocker

id: REUSE-WP-0017-T06
status: done
priority: medium
state_hub_task_id: "1a04b60a-b982-4b5f-ae20-955bc88d4204"

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.

Resolved 2026-07-07. A routing catalog entry (reuse-surface-hub-write-token) appeared in ~/ops-warden/registry/routing/catalog.yaml pointing at the token's actual home: a Kubernetes Secret (reuse-surface-env in namespace reuse on the Railiance01 cluster), not an OpenBao/Vault lane. Registration was completed through that channel (by a separate concurrent session, not this one — this session verified the result, not the credential itself, per the credential-routing rule against exploring live cluster secrets directly). config-atlas is now present among the 61 sources at https://reuse.coulomb.social/v1/federated. Roster corrected: hub_registered: true, publish_sweep 2026-07-07.

• Diagnose the 303 (resolved — not a current blocker, code already follows the redirect)
• Local publish-check target: 61/61 pass
• Complete hub registration for config-atlas — done 2026-07-07, 61/61 hub-registered

Closeout: Coverage Metrics, Docs, SCOPE Update

id: REUSE-WP-0017-T07
status: wait
priority: low
state_hub_task_id: "24ac37bf-2509-4077-9aa3-c09a599dd644"

• report gaps shows 0 unclassified scaffolds; record final coverage ratio
• Update SCOPE.md Current State (capability count, coverage), regenerate docs/CapabilityCatalog.md, graph, search catalog
• history/ milestone note; progress event + fix-consistency

---

Acceptance

• Every roster repo is has or none — zero pending
• All none repos carry a reviewed registry/NO_CAPABILITIES.md
• Federated index capability count reflects the seeded entries; 0 collision warnings
• 61/61 publish pass (config-atlas unblocked)
• Coverage ratio visible in report gaps and CI output
• No entry claims maturity without on-disk evidence citations

Out of scope

• Consumption/plan-check tooling (REUSE-WP-0018)
• Forgejo webhooks/automation (REUSE-WP-0019)
• Maturity promotions beyond honest first-pass levels
• Multi-domain federation (all entries remain helix_forge)