reuse-surface/history/2026-07-06-coverage-classification.md

# Coverage classification sweep (REUSE-WP-0017-T02)

Classification of the 51 empty-scaffold repos identified in the 2026-07-06
gap report, bucketed into `has-capability` (candidate for a drafted registry
entry) vs `no-capability` (candidate for an explicit
`registry/NO_CAPABILITIES.md` marker). Produced by an Explore-agent survey of
each repo's INTENT/SCOPE/README and top-level layout; rationale is grounded
in what was actually read, not guessed.

**Status: confirmed by Bernd 2026-07-06.** Proceeding to T03/T04 with the two
data-quality adjustments noted below applied.

**Summary:** 37 has-capability, 13 no-capability, 0 missing (all 51
directories exist and are valid git repos).

| Repo | Bucket | Rationale | Candidate capability id |
|---|---|---|---|
| agentic-resources | no-capability | INTENT/SCOPE are aspirational HR-for-agents vision prose; no src/, no package manifest, only docs/registry/workplans | |
| artifact-store | has-capability | Real Python service (67 files, pyproject, migrations, schemas) implementing a generic artifact registry/storage gateway with provenance & retention | `capability.artifact.store` |
| can-you-assist | has-capability | Real `cya` CLI package (45 files, pyproject) — console-native LLM assistant with history/memory | `capability.cli.assistant` |
| citation-engine | has-capability | TS package (45 files) implementing the citation-evidence domain model/API contracts | `capability.citation.engine` |
| citation-evidence | has-capability | TS/Vite app (90 files) — integration shell/reference implementation coordinating the citation-evidence subsystems | `capability.citation.evidence-workspace` |
| citation-work | no-capability | Only INTENT/SCOPE/registry/workplans; no src or code implementing the described review workbench | |
| coordination-engine | no-capability | Ambitious framework prose in INTENT, but only history/spec/registry dirs — no runtime code | |
| domain-tree | no-capability | Only registry/workplans; SCOPE explicitly defers ownership to State Hub, no implementation | |
| email-connect | has-capability | Real Python service (24 files, pyproject, config, spec) — headless email send/track/evidence service with coordination-engine adapter contract | `capability.email.connector` |
| evidence-anchor | no-capability | Only INTENT/SCOPE/registry/workplans; anchoring/highlighting layer described but not implemented | |
| evidence-binder | no-capability | Only INTENT/SCOPE/registry/workplans; binding model described but not implemented | |
| evidence-source | no-capability | Only INTENT/SCOPE/registry/workplans; ingestion/extraction layer described but not implemented | |
| guide-board | has-capability | Real Python package (40 files, pyproject, extensions, profiles) — certification/compliance evidence framework with extension architecture | `capability.compliance.evidence-framework` |
| helix-forge | no-capability | Draft-status (intent_version 0.1.0) capability-ecosystem vision; only design assets, standards docs, and one bootstrap script, no packaged implementation | |
| hub-core | has-capability | Real Python library (81 files, pyproject) providing reusable FastAPI/SQLAlchemy/MCP primitives shared across FOS hub services | `capability.hub.core-library` |
| human-resources | no-capability | Only aspirational HR-for-humans intent prose plus registry/workplans; no implementation | |
| ihp-railiance-probe | no-capability | Self-described in its own INTENT as "a probe — not a product," purely a pipeline-validation canary app | |
| info-tech-canon | has-capability | Real Python service (18 files, pyproject, canon.yaml) implementing a concrete "infospace" service surface (CLI, importable functions, read-only HTTP API) on top of the canon corpus | `capability.canon.info-tech` |
| infospace-bench | has-capability | Real Python workspace/CLI (75 files, pyproject, examples) for creating/evaluating structured "infospaces" | `capability.knowledge.infospace-workspace` |
| inter-hub | has-capability | Haskell/IHP app implementing the Interaction Hub Framework (IHF) — governed interaction substrate with Main.hs, Application, Web, contracts, specs | `capability.hub.interaction-framework` |
| issue-core | has-capability | Real Python package (45 files) already carrying its own `CAPABILITY-issue-tracking.yaml` and `.capability/` dir — issue-tracking service | `capability.issue.tracking` |
| kaizen-agentic | has-capability | Real Python package (57 files, pyproject) — 18-agent library plus agency/memory/coordination framework for deployed project agents | `capability.agent.kaizen-framework` |
| key-cape | has-capability | Real Python service (56 files, spec, config) implementing the lightweight-mode NetKingdom IAM profile (OIDC/PKCE via Authelia/LLDAP/privacyIDEA) | `capability.iam.key-cape` |
| kontextual-engine | has-capability | Large Python package (123 files, pyproject, tpsc.yaml) — context engine with examples/docs | `capability.context.engine` |
| llm-connect | has-capability | Real Python package (62 files, pyproject, contracts) — provider-neutral LLM connector library | `capability.llm.connector` |
| markitect-filter | has-capability | Small but real Python package (10 files, pyproject, examples) — markdown filtering component of the Markitect family | `capability.markitect.filter` |
| markitect-main | has-capability | Large legacy platform (application/domain/services dirs, pyproject, package.json) — markitect umbrella product, now being split into successor repos | `capability.markitect.platform` |
| markitect-quarkdown | has-capability | Small real Python package (adapter.py, pyproject) — Quarkdown integration adapter for Markitect | `capability.markitect.quarkdown-adapter` |
| markitect-tool | has-capability | Large Python package (144 files, pyproject, sbom-tools.yaml) — markdown-native toolkit/CLI, syntax-layer successor to markitect-main | `capability.markitect.tool` |
| net-kingdom | has-capability | Real tooling under tools/ (playbook-capability-contract, security-bootstrap-console, iam-profile-conformance, each with README+py) plus canon schemas — IAM/security tooling suite, despite no top-level src/pyproject | `capability.security.iam-tooling` |
| open-cmis-tck | has-capability | Real Python package (14 files, pyproject, adapters/runners/runtime) — CMIS technology compatibility kit | `capability.cmis.tck` |
| open-reuse | has-capability | Real Python package (cli.py, registry.py, validate.py) — reuse-registry CLI/validator (the tool underlying this very classification workflow) | `capability.reuse.registry-cli` |
| ops-bridge | has-capability | Real Python CLI (36 files, pyproject) — SSH reverse-tunnel lifecycle manager keeping remote nodes connected to the State Hub (matches the "bridge" skill) | `capability.ops.tunnel-bridge` |
| ops-hub | no-capability | Only a single diagnostic bootstrap-API probe script (interhub_gate_probe.py) exists; the described "operational truth surface" (hosts/services/incidents/runbooks) isn't implemented yet | |
| phase-memory | has-capability | Real Python package (59 files, pyproject) — profile-driven memory operating layer producing deterministic dry-run retention/compaction actions | `capability.memory.phase-store` |
| railiance-apps | has-capability | Real helm charts, k8s manifests, and reusable smoke-test/check tooling (tools/*.sh) for deploying/verifying Railiance workloads | `capability.railiance.k8s-deploy-tooling` |
| railiance-cluster | has-capability | Real bin/railiance CLI, lib/ scripts, and ansible playbooks (bootstrap/harden) for standing up Railiance cluster nodes | `capability.railiance.cluster-bootstrap` |
| railiance-enablement | has-capability | Real promote-repo-to-forgejo.sh tool plus reusable CI workflow templates (container-build-push, ci-smoke) | `capability.railiance.ci-enablement` |
| railiance-fabric | has-capability | Real Python package (44 files, pyproject, schemas) — railiance_fabric catalog/export tooling | `capability.railiance.fabric-catalog` |
| railiance-forge | has-capability | Real runner-management tools/scripts (gitea/forgejo runner status/activation) and helm values for the CI runner substrate | `capability.railiance.runner-ops` |
| railiance-infra | has-capability | Real ansible/terraform/scripts (Hetzner provisioning, SSH CA bootstrap, playbooks) plus a capabilities/ playbooks dir — infra-as-code automation | `capability.railiance.infra-automation` |
| railiance-platform | has-capability | Extensive real scripts/ (OpenBao/Vault apply/verify, credential-change Python tooling) — secrets/credential platform automation | `capability.railiance.secrets-platform` |
| repo-scoping | has-capability | Real Python package (88 files, pyproject, migrations) — repo scoping/classification service | `capability.repo.scoping` |
| repo-seed | has-capability | Already publishes a real capability entry (`registry/capabilities/capability.infotech.repo-template.md`) — git repo template with State Hub onboarding scaffold | `capability.infotech.repo-template` |
| tegwick-control | no-capability | Personal life/company planning notes (areas/, agent-tasks/) — a private portfolio-tracking meta-repo, not a reusable component | |
| the-custodian | has-capability | Real Python runtime (runtime/agent.py + pyproject) and tools/ scripts (classification batching, Gitea SSH inventory) — the custodian control-plane agent | `capability.custodian.runtime-agent` |
| user-engine | has-capability | Real Python package (36 files, pyproject, migrations) — user/identity domain service | `capability.identity.user-engine` |
| vantage-point | has-capability | Substantial draft protocol spec (nbgm-spec-v0.1.md) defining the Network-Based Graph Model — a well-defined, versioned data model spec, even without code yet | `capability.graph.nbgm-spec` |
| vergabe-teilnahme | has-capability | Full Django application (413 files, manage.py, vergabe_teilnahme package, vite frontend) for German public-procurement (Vergabe) tender participation | `capability.procurement.vergabe-teilnahme` |
| whynot-control | no-capability | Business-signal/beta-tracking scaffolding (betas/, prototypes/, offers/, signals/) with only README stubs — no independent reusable component | |
| whynot-design | has-capability | Real JS design-system package (9+ src files: elements/atoms, chrome, layout, icons, styles) with adapters/tokens — cross-framework design system | `capability.design.whynot-system` |

## Notes on borderline calls

- **repo-seed** already has a capability entry (`capability.infotech.repo-template`)
  in the federated index — it shouldn't have been in the empty-scaffold list at
  all; the roster's `capability_count` for it is stale. Flag as a data-quality
  fix alongside T03/T04, not a fresh draft.
- **issue-core** already carries its own `CAPABILITY-issue-tracking.yaml` and
  `.capability/` directory outside the standard `registry/` layout — likely a
  pre-existing capability description in a non-standard location that needs
  migrating into `registry/capabilities/`, not a from-scratch draft.
- **vantage-point** has no code yet, only a versioned protocol spec — flagged
  `has-capability` on the strength of the spec itself (D-axis can be honest
  and non-zero for a documented model; A-axis should stay low/A0 until there's
  an implementation).
- **net-kingdom** and **railiance-*** repos generally lack a top-level
  `pyproject.toml`/package manifest but do have real, runnable tooling under
  `tools/`/`scripts/` — maturity vectors for these should reflect
  script-level availability (likely A1–A2), not assume packaged distribution.
- 13 no-capability repos cluster into two patterns: **vision-only** (INTENT/SCOPE
  prose with no implementation — agentic-resources, citation-work,
  coordination-engine, domain-tree, evidence-anchor, evidence-binder,
  evidence-source, human-resources, helix-forge, ops-hub) and **explicitly
  out-of-scope for reuse** (ihp-railiance-probe is a self-described probe,
  tegwick-control and whynot-control are personal/business tracking, not
  product components).

## Next steps (blocked on review)

- **T03** (mark no-capability): write `registry/NO_CAPABILITIES.md` into the
  13 confirmed no-capability repos, set `capability_status: none` in the
  roster.
- **T04** (draft entries): run `establish --discover` for the 37 (35, net of
  the two data-quality fixes above) confirmed has-capability repos in cohorts
  of ~10, honest low-maturity first pass.

**Awaiting Bernd's confirmation of this bucket split before T03/T04 proceed**,
per the workplan's human-review-checkpoint design principle.