generated from coulomb/repo-seed
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:
@@ -4,27 +4,36 @@ title: Domains — Reference
|
||||
|
||||
# Domains — Reference
|
||||
|
||||
The Domains page shows all registered project domains and the repositories
|
||||
associated with each one. Domains are the top-level organisational unit of the
|
||||
Custodian ecosystem.
|
||||
The Domains page shows the **14 fixed market domains** from the Repo
|
||||
Classification Standard. These replaced the old ad-hoc coordination domains
|
||||
(custodian, railiance, markitect, …) in STATE-WP-0065.
|
||||
|
||||
---
|
||||
|
||||
## What is a domain?
|
||||
|
||||
A domain corresponds to one of the six tracked project areas:
|
||||
A domain is an intended **market / user segment** — not a project org unit.
|
||||
Each registered repo has exactly one primary domain (from its
|
||||
`.repo-classification.yaml`), stored on `managed_repos.domain_id`.
|
||||
|
||||
| Slug | Project |
|
||||
| Slug | Segment |
|
||||
|------|---------|
|
||||
| `custodian` | The Custodian agent system itself |
|
||||
| `railiance` | DevOps & infrastructure reliability |
|
||||
| `markitect` | Knowledge artifact management |
|
||||
| `coulomb_social` | Co-creation marketplace |
|
||||
| `personhood` | Rights & obligations framework |
|
||||
| `foerster_capabilities` | Agency capability taxonomy |
|
||||
| `infotech` | Developers, platforms, internal tooling users |
|
||||
| `financials` | Finance, trading, payments |
|
||||
| `communication` | Messaging, social, collaboration |
|
||||
| `consumer` | General consumers |
|
||||
| `health` | Healthcare, wellness |
|
||||
| `industrials` | Manufacturing, logistics |
|
||||
| `energy` | Energy sector |
|
||||
| `utilities` | Utilities infrastructure |
|
||||
| `materials` | Materials / commodities |
|
||||
| `realestate` | Property, housing |
|
||||
| `crypto` | Crypto / web3 |
|
||||
| `agents` | AI-native agent users |
|
||||
| `space` | Space industry |
|
||||
| `government` | Civic, public sector |
|
||||
|
||||
Each domain has a slug (URL-friendly identifier), a human-readable name, an
|
||||
optional description, and a status.
|
||||
Canon: `the-custodian/canon/standards/repo-classification-standard_v1.0.md`
|
||||
|
||||
---
|
||||
|
||||
@@ -32,63 +41,21 @@ optional description, and a status.
|
||||
|
||||
| Status | Meaning |
|
||||
|--------|---------|
|
||||
| **active** | Live domain — topics, workstreams, and tasks are being tracked |
|
||||
| **archived** | Soft-deleted; no active work. Fails to archive if active topics exist |
|
||||
| **active** | Live domain — repos and workplans may reference it |
|
||||
| **archived** | Retired; no new registrations |
|
||||
|
||||
---
|
||||
|
||||
## KPI row
|
||||
## Relationship to repos and workplans
|
||||
|
||||
Four counters at the top of the page:
|
||||
|
||||
| Counter | Meaning |
|
||||
|---------|---------|
|
||||
| Total domains | All registered domains regardless of status |
|
||||
| Active | Domains with status `active` |
|
||||
| Total repos | Sum of all registered repositories across all domains |
|
||||
| Newest domain | Name of the most recently created domain |
|
||||
- **Repos** are the primary anchor — classification file is source of truth.
|
||||
- **Workplans** require `repo_id`; market domain is derived from the repo.
|
||||
- **Topics** are optional legacy tags; workplan frontmatter `domain:` may still
|
||||
use old coordination slugs — the consistency checker maps these to market domains.
|
||||
|
||||
---
|
||||
|
||||
## Domain cards
|
||||
## Related
|
||||
|
||||
One card per domain showing:
|
||||
|
||||
- **Slug** — monospace identifier
|
||||
- **Status badge** — green `active` or grey `archived`
|
||||
- **Name** — display name
|
||||
- **Description** — first 160 characters
|
||||
- **Repos** — list of registered repositories for this domain, each showing name, local path, and remote URL
|
||||
|
||||
---
|
||||
|
||||
## RecentlyOnScope
|
||||
|
||||
The `Domains / RecentlyOnScope` page generates deterministic Markdown digests
|
||||
for a selected domain. The range parameter defaults to `1h` and accepts compact
|
||||
durations such as `15m`, `6h`, or `1d`.
|
||||
|
||||
Generated reports are written under the configured State Hub report directory,
|
||||
defaulting to `reports/recently-on-scope/<domain_slug>/`. The dashboard lists
|
||||
those Markdown files and previews the raw report content.
|
||||
|
||||
---
|
||||
|
||||
## Managing domains
|
||||
|
||||
Via MCP:
|
||||
|
||||
```
|
||||
create_domain(slug="my_project", name="My Project", description="…")
|
||||
rename_domain(slug="old_slug", new_slug="new_slug", new_name="New Name")
|
||||
archive_domain(slug="my_project") # fails if active topics exist
|
||||
```
|
||||
|
||||
Via Makefile:
|
||||
|
||||
```bash
|
||||
make add-domain SLUG=my_project NAME="My Project"
|
||||
make rename-domain OLD_SLUG=my_project NEW_SLUG=myproject NEW_NAME="My Project"
|
||||
```
|
||||
|
||||
*Domains are never hard-deleted — only archived.*
|
||||
- **[Repos](/docs/repos)** — portfolio view with category / capability filters
|
||||
- **[Repo Integration](/docs/repo-integration)** — onboarding with classification 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>
|
||||
```
|
||||
Reference in New Issue
Block a user