feat(classification-spine): implement STATE-WP-0065 repo-anchored model

Replace the ad-hoc coordination-domain spine with the Repo Classification
Standard: 14 market domains, classification columns on managed_repos, and
workplans anchored by repo_id (topic_id optional).

- Add Alembic migration d8e9f0a1b2c3 with data backfill and workstream→workplan rename
- Add api/classification.py validation and register-from-classification tooling
- Expose workplan-first REST/MCP surface with legacy workstream aliases
- Add C-24 consistency rule and legacy domain frontmatter mapping
- Update dashboard repos page with category/capability/stake filters
- Update orientation docs; mark STATE-WP-0065 finished
This commit is contained in:
2026-06-22 13:52:13 +02:00
parent 279be4ffbd
commit 0949d4c0d8
84 changed files with 4494 additions and 1111 deletions

View File

@@ -5,18 +5,25 @@ title: Repos — Reference
# Repos — Reference
The Repos page shows every repository registered in the Custodian ecosystem,
their SBOM ingestion status, and a domain-grouped coverage map.
their **classification** (category, market domain, capabilities, business stake),
SBOM ingestion status, and a domain-grouped coverage map.
---
## What is a managed repo?
A managed repo is a git repository that has been registered with the state hub
via `custodian register-project` or `register_repo()`. Registration records the
repo's slug, domain, local path, and optional remote URL. Once registered, the
repo receives a `CLAUDE.custodian.md` integration suggestion, an onboarding
workstream with 4 tasks for the repo agent, and is eligible for SBOM ingestion
and the ADR-001 workplan validator.
A managed repo is a git repository registered with State Hub. Registration is
**classification-driven**:
1. Commit `.repo-classification.yaml` per the Repo Classification Standard.
2. Run `make register-from-classification REPO=<slug>` (or use the MCP tool
`register_repo_from_classification`).
The file is the source of truth; the hub stores a validated copy on
`managed_repos` (category, domain, capability_tags, business_stake, provenance).
Legacy `custodian register-project` still works for agent onboarding but should
be followed by classification registration.
For the full onboarding journey see **[Repo Integration](/docs/repo-integration)**.
@@ -27,69 +34,56 @@ For the full onboarding journey see **[Repo Integration](/docs/repo-integration)
| Card | Meaning |
|------|---------|
| **Registered Repos** | Active repos only (status = active) |
| **Domains** | Count of distinct domain slugs across registered repos |
| **Market Domains** | Distinct primary domains across registered repos |
| **Categories** | Distinct work categories (experimental, tooling, product, …) |
| **SBOM Ingested** | Repos with at least one SBOM snapshot |
| **SBOM Gaps** | Repos with no ingested SBOM — red border when > 0 |
---
## Coverage Map
## Portfolio by Category
Groups repos by domain. Each domain block shows:
- **Domain name** with SBOM, EP, and TD chip indicators
- **SBOM chip** — green ✓ if all repos in the domain are ingested, amber ⚠ if any gap exists
- **EPs chip** — count of open/in-progress extension points for this domain
- **TDs chip** — count of open/in-progress technical debt items for this domain
- **Repo table** — one row per repo with SBOM status, package count, and local path
Rows with no SBOM are highlighted in amber.
Groups repos by `category` (experimental, research, project, tooling, product,
business). Each block shows domain, capabilities, business stake, and who
classified the repo (`human` vs `migration`).
---
## Filters
## Coverage Map
Groups repos by **market domain**. Each domain block shows SBOM, EP, and TD
chips plus per-repo classification columns.
---
## Filters (All Repos Table)
| Filter | Effect |
|--------|--------|
| **Domain** | Show repos for a single domain only |
| **Gaps only** | Toggle to show only repos without an ingested SBOM |
| **Market domain** | Primary domain slug |
| **Category** | Repo work category |
| **Capability** | Repos tagged with a capability |
| **Business stake** | Repos affecting a business responsibility area |
| **DoI tier** | Definition of Integrated tier |
| **Gaps only** | Repos without ingested SBOM |
---
## Consistency (C-24)
The ADR-001 consistency checker warns when a registered repo lacks a valid
`.repo-classification.yaml` on disk. Migration-derived rows (`classified_by:
migration`) get an explanatory note until a human-reviewed file is committed.
---
## Onboarding a new repo
See **[Repo Integration](/docs/repo-integration)** for the full journey.
Quick reference:
Use the **Add Repo** form or:
```bash
# From the repo root — registers, writes CLAUDE.custodian.md, creates onboarding tasks
custodian register-project --domain <slug>
```
## Ingesting a repo's SBOM
```bash
# Auto-detects lockfile at repo root
cd ~/state-hub
make ingest-sbom REPO=<slug> REPO_PATH=/absolute/path
# Multi-ecosystem repo — scan all lockfiles recursively
make ingest-sbom REPO=<slug> SCAN=1 REPO_PATH=/absolute/path
```
Supported lockfile formats: `uv.lock`, `requirements.txt`, `package-lock.json`,
`yarn.lock`, `Cargo.lock`, `.terraform.lock.hcl`.
---
## Infra-only repos
Repos with no lockfile (Ansible, shell scripts) can be registered for inventory
purposes. The SBOM gap is expected and can be left as-is. Terraform providers
are auto-detected via `.terraform.lock.hcl` when using `--scan`.
---
*SBOM snapshots are replaced on each ingest — not appended. The last ingestion
timestamp is recorded on the managed_repo row.*
# 1. Author classification file in the repo
# 2. Register / reclassify
make register-from-classification PATH=/path/to/repo
make fix-consistency REPO=<slug>
```