# REUSE-WP-0017-T04 review summary

> **Update 2026-07-07:** `inter-hub` has been retired (Haskell/IHP
> build-chain problems) and superseded by `core-hub` (Python/FastAPI/Postgres).
> Its capability entry was reassessed and marked `deprecated` — see
> `history/2026-07-07-inter-hub-retirement.md`. The D3/A1/C1/R0 vector in
> the table below is now stale for that one row; current vector is
> D5/A1/C3/R0.

Prepared for the T05 human-review-and-publish-pass checkpoint. Everything
below is generated from the actual files committed in each sibling repo
(not from drafting notes), so it reflects what would actually get pushed
and published.

**Coverage: 61/61.** 48 repos have a capability entry, 13 have an explicit
`registry/NO_CAPABILITIES.md` marker, 0 remain unclassified.

**What's new this session (T02–T04):** 30 sibling repos got a first commit —
13 no-capability markers (T03) and 17 newly drafted capability entries
(the first two T04 cohorts + this final cohort — see per-cohort commit
messages in `workplans/REUSE-WP-0017-capability-coverage-campaign.md` for
the exact 10/10/17 split). The other 18 `has` rows below already existed
before this workplan (activity-core, audit-core, config-atlas,
feature-control, flex-auth, identity-canon, ops-warden, repo-seed,
reuse-surface, shard-wiki, state-hub, plus the ones drafted in cohorts
1–2 — see the table for the full picture; cohort provenance is in the
workplan file, not repeated here).

**Everything below is committed locally only.** Nothing has been pushed to
any sibling repo's remote. T05 is where you review, then push +
publish-check + hub refresh + `federation compose` happen.

## How to review a single entry

```bash
cd ~/<repo-slug>
git log -1 --stat          # see exactly what was added
git show HEAD               # full diff
cat registry/capabilities/<id>.md   # or registry/NO_CAPABILITIES.md
```

To push everything after review (per-repo, once you're satisfied):

```bash
git -C ~/<repo-slug> push origin main
```

## Things worth a closer look before pushing

1. **`the-custodian`** — the repo root carries an NDA/confidentiality
   notice. The entry (`capability.agents.custodian-runtime-tooling`) is
   deliberately scoped to only the non-confidential `runtime/` agent
   framework and `tools/` repo-classification scripts; canon/memory content
   is explicitly excluded in `discovery.excludes` and
   `consumer_guidance.not_recommended_for`. Please double-check this
   scoping is exactly right before pushing — this is the one entry where
   getting the boundary wrong has real consequences.
2. **`vergabe-teilnahme`** — its own `SCOPE.md` is an unfilled template, so
   the entry is honestly low (D1/A1/C0/R0) with a limitation note that
   filling in SCOPE.md should happen before further promotion.
3. **`markitect-main`** — registered as a *superseded legacy platform*,
   with `consumer_guidance.not_recommended_for` pointing new consumers at
   its three successors (`markitect-tool`, `infospace-bench`,
   `kontextual-engine`). Worth confirming that's the framing you want on
   the record.
4. **`issue-core`** — migrated its own pre-existing
   `CAPABILITY-issue-tracking.yaml` (a rich, non-standard capability
   manifest with 109 tests / 61% coverage documented) into the standard
   `registry/capabilities/` location, rather than drafting fresh. Worth
   confirming nothing was lost in translation.
5. **Stale repo-seed-template READMEs** — `inter-hub`, `open-reuse`, and
   `vantage-point` all still show the generic `repo-seed` bootstrap README
   at their repo root; I used each repo's `SCOPE.md`/`INTENT.md` instead
   (noted in each entry's discovery rationale) since those are accurate.
   The stale READMEs themselves are a small, separate cleanup — not fixed
   here, out of scope for this workplan.
6. **Forgejo-transition tooling surfaced along the way** — `railiance-enablement`
   (`tools/promote-repo-to-forgejo.sh`), `railiance-apps`
   (`tools/forgejo-smoke.sh`), and `the-custodian`
   (`tools/patch-forgejo-remote-urls.sh`) all ship tooling directly relevant
   to REUSE-WP-0019's host-migration inventory (T01) — worth cross-referencing
   when that workplan starts.
7. **Two pre-existing roster rows had a stale `seed_capability_ids: []`**
   despite having real, already-published entries: `activity-core`
   (`capability.activity.event-coordinate`) and `ops-warden`
   (`capability.security.ssh-certificate-issuance`). Fixed as a small
   incidental correction in the roster — not new drafts, just a bookkeeping
   gap from before this workplan.
8. **`config-atlas`** remains `publish_check: fail` (303 error) — tracked
   separately as REUSE-WP-0017-T06, likely related to the Gitea→Forgejo
   transition (REUSE-WP-0019-T01).

## All 48 capability entries

| Repo | Capability ID | Vector (D/A/C/R) | Summary |
|---|---|---|---|
| `activity-core` | `capability.activity.event-coordinate` | D3/A1/C1/R0 | Coordinate structured responses to cross-domain events through activity workflows and automation. |
| `artifact-store` | `capability.infotech.artifact-store` | D3/A1/C1/R0 | Generic artifact registry and storage gateway for generated outputs, evidence packages, reports, logs, snapshots, exports, and release artifacts. |
| `audit-core` | `capability.audit.event-retain` | D4/A2/C2/R1 | Collect, normalize, retain, and search audit events with integrity evidence across tenants. |
| `can-you-assist` | `capability.agents.cli-assistant` | D2/A2/C1/R0 | Console-native, backend-agnostic assistant CLI that expresses user intent in natural language and returns safe, explainable, context-aware help. |
| `citation-engine` | `capability.infotech.citation-engine` | D3/A1/C1/R0 | Core domain model and engine services for the citation-evidence ecosystem — shared vocabulary, in-memory repositories, orchestration services, event bus, and citation card renderers. |
| `citation-evidence` | `capability.infotech.citation-evidence-workspace` | D4/A1/C1/R0 | Document-centered evidence workspace for capturing, managing, presenting, and re-opening citations — the umbrella application over the citation-evidence six-package design. |
| `config-atlas` | `capability.infotech.config-surface-atlas` | D5/A0/C2/R2 | Read-first, cross-kind map and evidence layer for configuration surfaces — what configures a system, who owns it, its scope, and where the source of truth lives. |
| `email-connect` | `capability.infotech.email-connector` | D2/A1/C1/R0 | Headless, provider-neutral email communication and evidence service; first slice scans a mailbox or fixture directory and produces timestamped CSV evidence reports. |
| `feature-control` | `capability.feature-control.evaluate` | D5/A4/C3/R3 | Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context. |
| `flex-auth` | `capability.authorization.policy-evaluate` | D4/A2/C2/R1 | Evaluate access decisions from policy-as-code rules for subjects, resources, and actions. |
| `guide-board` | `capability.communication.compliance-evidence-framework` | D2/A2/C1/R0 | Framework that turns standards, conformance, regulatory, and repository-quality claims into structured, reviewable, repeatable, comparable evidence via a pluggable extension architecture. |
| `hub-core` | `capability.infotech.hub-core-library` | D2/A1/C1/R1 | Reusable FastAPI, SQLAlchemy, and MCP primitives extracted from the State Hub for use by other FOS (Federation of Services) hubs. |
| `identity-canon` | `capability.identity.subject-resolution` | D3/A0/C1/R0 | Resolve who or what is acting in a context by mapping principals, accounts, actors, and identifiers to a stable subject model. |
| `info-tech-canon` | `capability.infotech.canon-service` | D2/A2/C1/R0 | Concrete service surface (CLI, importable functions, read-only local HTTP API) over the InfoTechCanon information-processing infospace, backed by infospace-bench. |
| `infospace-bench` | `capability.communication.infospace-workspace` | D3/A1/C2/R1 | Workspace and service for creating, developing, evaluating, and inspecting structured knowledge spaces (infospaces); application-layer successor to the infospace work begun in markitect-main. |
| `inter-hub` | `capability.infotech.interaction-hub-framework` | D3/A1/C1/R0 | Specification and reference implementation of a governed, observable interaction substrate connecting rendered UI widgets to structured feedback, requirements, decisions, implementation changes, and observed outcomes. |
| `issue-core` | `capability.infotech.issue-tracking` | D4/A2/C2/R1 | Unified Python/CLI interface for issue tracking across Gitea, GitHub, and GitLab, preventing direct platform API usage and credential sprawl for coordinating agents. |
| `kaizen-agentic` | `capability.agents.kaizen-framework` | D3/A2/C1/R0 | AI agency framework providing 18 specialized deployable agent instruction sets plus persistent, project-scoped memory and cross-agent coordination via a Coach meta-agent. |
| `key-cape` | `capability.iam.key-cape` | D4/A2/C2/R1 | Lightweight-mode implementation of the NetKingdom IAM Profile (versioned OIDC/PKCE contract), orchestrating Authelia, LLDAP, and privacyIDEA so applications integrate against the profile, not against implementation internals. |
| `kontextual-engine` | `capability.communication.context-engine` | D4/A1/C1/R0 | Headless knowledge-operations engine turning heterogeneous information assets into persistent, contextual, governed, retrievable, transformable, and agent-operable knowledge. |
| `llm-connect` | `capability.agents.llm-connector` | D3/A2/C2/R1 | Provider-neutral Python/CLI LLM adapter library supporting OpenRouter, Gemini, OpenAI, and the Claude Code CLI out of the box, with a clean abstract interface for adding new providers. |
| `markitect-filter` | `capability.communication.markitect-source-adapters` | D2/A1/C1/R0 | Concrete source-format adapters (EPUB3, PDF) converting external document formats into canonical Markitect Markdown, implementing the markitect-tool source adapter contract. |
| `markitect-main` | `capability.communication.markitect-legacy-platform` | D3/A1/C1/R0 | Intelligent markdown engine and information-management platform treating documents as structured, queryable information spaces with schema validation, transclusion, and LLM-driven evaluation; the legacy umbrella now being split into markitect-tool, infospace-bench, and kontextual-engine. |
| `markitect-quarkdown` | `capability.communication.markitect-quarkdown-adapter` | D3/A1/C1/R0 | Concrete Quarkdown render/export adapter for Markitect, mapping Markitect profiles to Quarkdown profiles and running controlled Quarkdown CLI execution plans without forking or reimplementing Quarkdown. |
| `markitect-tool` | `capability.communication.markitect-toolkit` | D4/A2/C2/R1 | Markdown-native toolkit and CLI (mkt) for turning semi-structured Markdown into structured, queryable, reusable knowledge artifacts; syntax-layer successor to markitect-main. |
| `net-kingdom` | `capability.security.iam-tooling-suite` | D3/A2/C1/R1 | Dynamic, self-optimizing security platform for Kubernetes-deployed IT infrastructure; owns canonical IAM/security standards and executable conformance tooling (IAM profile conformance, playbook capability contract validation, security bootstrap console). |
| `open-cmis-tck` | `capability.cmis.tck` | D2/A1/C1/R0 | CMIS conformance-preparation extension for guide-board, keeping CMIS-specific runner code, profiles, capability mappings, and workplans outside the generic compliance framework. |
| `open-reuse` | `capability.infotech.oss-integration-continuity` | D2/A1/C1/R0 | Turns proven open-source integrations into structured, maintainable, continuously managed assets with clear boundaries and update loops, so they remain robust and transparent as upstream evolves. |
| `ops-bridge` | `capability.ops.tunnel-bridge` | D3/A2/C2/R1 | CLI that manages named SSH reverse tunnels keeping remote execution environments connected to the local Custodian State Hub, with auto-reconnect, health checks, and structured audit events. |
| `ops-warden` | `capability.security.ssh-certificate-issuance` | D4/A3/C3/R2 | Issue short-lived CA-signed SSH certificates for adm, agt, and atm actors through a stable cert_command CLI interface; steward operational access routing across NetKingdom security lanes. |
| `phase-memory` | `capability.memory.phase-planning` | D3/A1/C1/R0 | Interprets Markitect memory profiles as runtime plans, modeling memory phases and producing deterministic dry-run actions for retention, refresh, compaction, stabilization, and activation. |
| `railiance-apps` | `capability.railiance.workload-deployment-tooling` | D3/A2/C1/R1 | S5 Workloads and Experience Endpoints layer of the Railiance OAS Stack — application Helm releases, Kubernetes workload manifests, deployment guardrails, and smoke-test/check tooling for user-facing services. |
| `railiance-cluster` | `capability.railiance.cluster-bootstrap` | D3/A2/C1/R0 | Cluster runtime entry point of the Railiance Infrastructure-as-Code framework: from two bare Linux servers, a Git repo, and credentials, rebuilds a fully automated Kubernetes-based environment. |
| `railiance-enablement` | `capability.railiance.ci-enablement` | D3/A2/C2/R1 | S4 Developer Enablement layer of the Railiance OAS Stack — reusable CI/CD workflow templates, developer portal paths, platform templates, SDKs, and buildpacks, using forge capabilities without owning forge runtime. |
| `railiance-fabric` | `capability.railiance.fabric-graph` | D3/A1/C1/R0 | Models the durable infrastructure-responsibility graph of the Railiance netkingdom: schemas, discovery tools, registry services, graph queries, and State Hub export contracts for services, machines, repos, deployables, endpoints, ownership, dependencies, and bindings. |
| `railiance-forge` | `capability.railiance.forge-infrastructure` | D3/A1/C1/R0 | Source forge, registry, and automation-runner infrastructure for Railiance, separated out from railiance-apps/railiance-enablement; covers current Gitea operation, the Forgejo migration, container/package registries, and Actions runner substrate. |
| `railiance-infra` | `capability.railiance.infra-provisioning` | D4/A2/C2/R1 | Git-driven server provisioning and convergence for Hosteurope/Hetzner Cloud using Terraform, cloud-init, and Ansible, with SOPS+age encrypted in-repo secrets and a servers.yaml inventory as source of truth. |
| `railiance-platform` | `capability.railiance.platform-services` | D3/A2/C1/R0 | S3 Platform Services layer of the Railiance OAS Stack — shared cluster services: PostgreSQL HA, Valkey cache, secret management, identity integration, and object storage. |
| `repo-scoping` | `capability.agents.repo-scoping-service` | D2/A2/C1/R0 | Maps repositories from usefulness to implementation (Ability -> Capability -> Feature -> Evidence -> Code location) via a Python registry core, FastAPI HTTP API, and curator UI. |
| `repo-seed` | `capability.infotech.repo-template` | D3/A3/C2/R2 | Bootstrap new git repositories with agent instructions, registry scaffold, and State Hub onboarding conventions. |
| `reuse-surface` | `capability.registry.register` | D3/A4/C2/R3 | Register a new capability so it becomes visible for planning and implementation reuse. |
| `shard-wiki` | `capability.wiki.shard-orchestration` | D5/A2/C2/R1 | Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history. |
| `state-hub` | `capability.statehub.progress-log` | D4/A4/C3/R3 | Record progress events, decisions, and session notes against workstreams and tasks in State Hub. |
| `the-custodian` | `capability.agents.custodian-runtime-tooling` | D2/A1/C1/R0 | Generic tooling from The Custodian's runtime and ecosystem-management surface: an agent runtime framework (context, actions, tool adapters, policies) and repo-classification batch tooling used across the workstation's 61 repos. |
| `user-engine` | `capability.identity.user-engine` | D4/A1/C2/R0 | Headless, multi-application, multi-tenant user management engine covering registration, identity/factor models, entitlement claims, hats/realms/services/assets access profiles, and onboarding journeys. |
| `vantage-point` | `capability.graph.nbgm-spec` | D2/A0/C1/R0 | Generic system and versioned protocol specification for exploring dependency structures as network-based graph models (NBGM), unifying entity/relationship inspection and reasoning across arbitrary domains. |
| `vergabe-teilnahme` | `capability.procurement.vergabe-teilnahme` | D1/A1/C0/R0 | Django application (with a Vite/Tailwind frontend) for managing German public-procurement (Vergabe) tender participation — Ausschreibungs- und Teilnahme-Management-System. |
| `whynot-design` | `capability.design.whynot-system` | D3/A2/C2/R1 | Framework-agnostic visual language for whynot prototype/market-signal artefacts: design tokens, drop-in CSS, Lit-based web components usable from React/Django/Vue/plain HTML, and Django template adapters. |

## All 13 explicit no-capability markers

| Repo | Reason |
|---|---|
| `agentic-resources` | INTENT/SCOPE are aspirational HR-for-agents vision prose; no src/, no package manifest — vision-stage only, nothing implemented to reuse. |
| `citation-work` | Only INTENT/SCOPE/registry/workplans describing a review workbench; no source implementing it yet. |
| `coordination-engine` | Ambitious coordination-framework prose in INTENT, but only history/spec/registry dirs exist — no runtime code yet. |
| `domain-tree` | Only registry/workplans; SCOPE explicitly defers ownership of implementation to State Hub. |
| `evidence-anchor` | Only INTENT/SCOPE/registry/workplans; the anchoring/highlighting layer is described but not implemented. |
| `evidence-binder` | Only INTENT/SCOPE/registry/workplans; the binding model is described but not implemented. |
| `evidence-source` | Only INTENT/SCOPE/registry/workplans; the ingestion/extraction layer is described but not implemented. |
| `helix-forge` | Draft-status (intent_version 0.1.0) capability-ecosystem vision; only design assets and standards docs exist, no packaged implementation. |
| `human-resources` | Aspirational HR-for-humans intent prose plus registry/workplans; no implementation. |
| `ihp-railiance-probe` | Self-described in its own INTENT as a probe, not a product — a pipeline-validation canary app, not intended for reuse. |
| `ops-hub` | Only a single diagnostic bootstrap-API probe script exists; the described operational-truth surface (hosts/services/incidents/runbooks) isn't implemented yet. |
| `tegwick-control` | Personal life/company planning notes (areas/, agent-tasks/) — a private portfolio-tracking meta-repo, not a reusable product component. |
| `whynot-control` | Business-signal/beta-tracking scaffolding (betas/, prototypes/, offers/, signals/) with only README stubs — no independent reusable component. |

## Next steps (T05)

1. Review the flagged items above, especially #1 (the-custodian confidentiality scoping).
2. Spot-check a sample of entries against the actual repos if you want deeper confidence beyond this summary.
3. Push the sibling-repo commits (30 repos have new commits this session; see `git log --oneline -1` in each).
4. `establish --publish-check` per repo where the raw URL needs confirming.
5. `reuse-surface federation compose` + catalog + graph regeneration in this repo.
6. Then T06 (config-atlas 303 fix) can proceed independently.