feat(registry): complete ATLAS-WP-0002 T02, T03, T06
Some checks failed
validate-registry / validate (push) Has been cancelled

T02: remove inherited capability.infotech.repo-template and template consumer
docs (statehub-register, template-validation-checklist); add
capability.infotech.config-surface-atlas and rewrite capabilities.yaml.

T03: seed 4 configuration surfaces (state-hub api-config, ops-warden
routing-catalog, reuse-surface federation-sources, ops-bridge tunnel-config)
with registry/indexes/surfaces.yaml; source-linked, no values, secret deps by
reference.

T06: add tools/validate_registry.py (schema + index gate), Makefile (make
validate), and .github/workflows/validate.yml (GitHub + Gitea Actions);
document in stack-and-commands. Verified malformed entries are rejected.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
2026-06-26 23:19:18 +02:00
parent 79c02eed4b
commit 72bbdad2c8
14 changed files with 495 additions and 336 deletions

View File

@@ -0,0 +1,128 @@
---
id: capability.infotech.config-surface-atlas
name: Configuration Surface Atlas
summary: 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.
owner: config-atlas
status: draft
domain: infotech
tags:
- configuration
- registry
- control-plane
- effective-config
- evidence
maturity:
discovery:
current: D5
target: D6
confidence: medium
rationale: >
Intent, scope, layering model, competitive landscape, and a control-plane
research digest are documented (INTENT, SCOPE, research/, wiki/, PRD,
ArchitectureBlueprint). Boundaries vs sister repos are explicit.
availability:
current: A0
target: A2
confidence: medium
rationale: >
Markdown/YAML registry with a JSON Schema for entries; no runtime resolver
or API (intentionally — resolution is delegated). Consumed informationally
and by agents; a source-module validator exists under tools/.
external_evidence:
completeness:
level: C2
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- configuration-surface entry schema (schemas/surface-entry.schema.json)
- scope/precedence/merge model (docs/configuration-surface-schema.md)
- canon mapping to InfoTechCanon (docs/canon-mapping.md)
- seed configuration surfaces (registry/surfaces/)
broken_expectations: []
out_of_scope_expectations:
- runtime effective-value resolution
- configuration delivery or control execution
- secret value storage
reliability:
level: R2
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- schema and surface seed are early; coverage is partial
- ownership resolution to domain-tree not yet wired
discovery:
intent: >
Make the distributed configuration surface of the ecosystem discoverable,
explainable, and governable — map the territory before controlling it.
includes:
- configuration-surface registry and entry schema
- scope/layer ordering and explicit merge semantics
- cross-repo relationship and effective-config path modelling
- canon alignment and sister-repo boundary documentation
excludes:
- runtime resolver, delivery, or control plane
- secret values or live configuration values
- feature-availability runtime control (feature-control owns it)
assumptions:
- downstream repos remain authoritative for their own config
- reuse-surface federation and the State Hub graph are available
use_cases: []
research_memos:
- research/configuration-control-plane.md
- docs/configuration-surface-schema.md
availability:
current_level: A0
target_level: A2
current_artifacts:
- registry/surfaces/
- schemas/surface-entry.schema.json
- docs/configuration-surface-schema.md
- docs/canon-mapping.md
- tools/validate_registry.py
consumption_modes:
- informational
- source module
relations:
depends_on:
- capability.statehub.workstream-coordinate
supports: []
related_to:
- capability.registry.register
evidence:
documentation:
- INTENT.md
- SCOPE.md
- specs/ProductRequirementsDocument.md
- specs/ArchitectureBlueprint.md
- docs/ecosystem-boundaries.md
tests:
- tools/validate_registry.py
consumer_guidance:
recommended_for:
- discovering what configures a system and who owns it
- reasoning about defaults, precedence, and cross-repo config relationships
not_recommended_for:
- storing or resolving live configuration values
- secret management or feature-flag runtime control
known_limitations:
- early-stage schema and partial surface coverage
- effective-value resolution is out of scope by design
---
# Configuration Surface Atlas
config-atlas indexes **configuration surfaces** — bounded, named places where
configuration is defined, read, or overridden — as source-linked registry entries
with ownership, kind, scope, and evidence. It is the read-first map and evidence
layer of a configuration control plane; it does not resolve, deliver, or control
configuration (see `SCOPE.md`, `docs/ecosystem-boundaries.md`).
See `docs/configuration-surface-schema.md` for the entry model and
`docs/canon-mapping.md` for InfoTechCanon alignment.

View File

@@ -1,121 +0,0 @@
---
id: capability.infotech.repo-template
name: Coulomb Repository Template
summary: Bootstrap new git repositories with agent instructions, registry scaffold, and State Hub onboarding conventions.
owner: repo-seed
status: draft
domain: infotech
tags:
- template
- bootstrap
- state-hub
- onboarding
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: >
Template purpose, consumer guide, and validation checklist are documented.
Scope boundaries are explicit in SCOPE.md.
availability:
current: A3
target: A4
confidence: medium
rationale: >
Consumers clone or copy repo-seed and run statehub register. Template
files are markdown/git artifacts without a hosted provisioning API.
external_evidence:
completeness:
level: C2
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- agent instruction scaffold (AGENTS.md, CLAUDE.md, .claude/rules/)
- registry directory scaffold
- statehub register consumer documentation
- template validation checklist for bootstrap verification
- bootstrap workplan pattern (WP-0001)
broken_expectations: []
out_of_scope_expectations:
- automated repo creation on Gitea
- runtime application code generation
reliability:
level: R2
confidence: medium
basis: consumer_quality_signals
known_reliability_risks:
- register output evolves with state-hub releases; checklist must be revalidated
- LLM inference path depends on llm-connect availability
discovery:
intent: >
Give new Coulomb repositories a consistent starting point for agent
coordination, capability registry growth, and State Hub workplan tracking.
includes:
- git template files for agent instructions and registry scaffold
- documentation for statehub register usage
- consumer validation checklist
- bootstrap workplan convention
excludes:
- application runtime implementation
- owning downstream project code
assumptions:
- consumers have access to state-hub CLI and API
- workplans remain canonical in repo files (ADR-001)
use_cases: []
research_memos:
- docs/statehub-register.md
- docs/template-validation-checklist.md
availability:
current_level: A3
target_level: A4
current_artifacts:
- README.md
- AGENTS.md
- CLAUDE.md
- .claude/rules/
- registry/
- docs/statehub-register.md
- docs/template-validation-checklist.md
consumption_modes:
- git clone
- informational
relations:
depends_on:
- capability.statehub.workstream-coordinate
supports: []
related_to:
- capability.registry.register
evidence:
documentation:
- docs/statehub-register.md
- docs/template-validation-checklist.md
- SCOPE.md
tests: []
consumer_guidance:
recommended_for:
- bootstrapping new Coulomb domain repositories
- standardizing agent onboarding and workplan conventions
not_recommended_for:
- repos that already have mature agent instructions and hub registration
- application templates with heavy code generation requirements
known_limitations:
- register must be run separately after cloning
- fix-consistency requires operator access to state-hub checkout
---
# Coulomb Repository Template
`repo-seed` is the canonical git template for new Coulomb repositories. Clone it,
run `statehub register`, complete the bootstrap workplan, and sync with
`make fix-consistency`.
See `docs/statehub-register.md` for the consumer workflow and
`docs/template-validation-checklist.md` for verification steps.