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

---
id: REUSE-WP-0017
type: workplan
title: "Capability coverage campaign: seed or explicitly close all empty scaffolds"
domain: infotech
repo: reuse-surface
status: active
owner: claude-code
topic_slug: helix-forge
created: "2026-07-06"
updated: "2026-07-06"
state_hub_workstream_id: "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

```task
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

```task
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

```task
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

```task
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

```task
id: REUSE-WP-0017-T05
status: wait
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

## Fix config-atlas Publish Blocker

```task
id: REUSE-WP-0017-T06
status: progress
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.

**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

```task
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`)