Files
config-atlas/workplans/ATLAS-WP-0002-registry-foundation.md
tegwick a52b77a0e7 feat(registry): complete ATLAS-WP-0002 T04 (canon mapping) + T01 (surface schema)
T04: add docs/canon-mapping.md mapping config-atlas concepts to InfoTechCanon
(itc-gov/data/devsecops/land/org/access/sec/tag) and sibling repos with
consume/reference/align/own ownership, plus gaps, validation hooks, and
extension candidates. Resolves the (planned) refs in PRD and ecosystem-boundaries.

T01: add schemas/surface-entry.schema.json (Draft 2020-12, additionalProperties
false to forbid inline values/secrets), docs/configuration-surface-schema.md
(fields, kind taxonomy, L0-L9 ordering, explicit merge rules), a validating seed
entry (surface.infotech.state-hub.api-config), and expand registry/README.md.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-26 22:47:40 +02:00

7.4 KiB
Raw Blame History

id, type, title, domain, repo, status, owner, topic_slug, created, updated, state_hub_workstream_id
id type title domain repo status owner topic_slug created updated state_hub_workstream_id
ATLAS-WP-0002 workplan Configuration atlas registry foundation infotech config-atlas ready codex custodian 2026-06-26 2026-06-26 27b42720-1bd7-4755-ab2f-59a6d095a2c3

Configuration atlas registry foundation

Establish config-atlas's Canon and registry foundation — the surface-entry schema, the canon mapping, the replacement of inherited repo-seed artifacts, the first seeded surfaces, federation, and CI validation.

This realizes Phase 0 (Canon) + Phase 1 (seed) of specs/ArchitectureBlueprint.md §6 and the MVP of specs/ProductRequirementsDocument.md §11. It owns only the map and evidence layers — no resolver, no delivery, no control (see SCOPE.md and .claude/rules/repo-boundary.md).

Exit condition: a real surface.* entry validates in CI; inherited template artifacts are gone; docs/canon-mapping.md exists; the surface.* namespace is reserved under reuse-surface federation.

Sequencing: T04 (canon mapping) and T01 (schema) come first; T02 (cleanup) is independent; T03 (seed) and T06 (CI) depend on T01; T05 (federation) depends on the surface.* id scheme defined in T01. Later phases (connectors, explain & graph — blueprint Phases 23) will be separate workplans, not tasks here.

Author canon mapping (consume, don't redefine)

id: ATLAS-WP-0002-T04
status: done
priority: high
state_hub_task_id: "e96f00bc-d858-4cfa-be6c-10de8de7b529"

Result 2026-06-26: Authored docs/canon-mapping.md mirroring feature-control's pattern, using real ITC ids (itc-gov/data/devsecops/land/org/access/sec/tag). Entity + relationship mapping (consume/reference/align/own), read-model surface, gaps, validation hooks, extension candidates, and ITC artifact references. Resolves the (planned) links in PRD §5 and ecosystem-boundaries §2.3.

Create docs/canon-mapping.md mapping config-atlas terms to InfoTechCanon and sibling repos: consume ITC-GOV (policy/decision/evidence), ITC-DATA (schema/contract/classification), ITC-DEVSECOPS (delivery/mutability), ITC-LAND (env/deployment); reference ITC-ORG ownership via domain-tree; align the scope vocabulary with feature-control EvaluationScope; own the configuration surface, the L0L9 layering order, and the cross-kind map. Mirror the pattern of ~/feature-control/docs/canon-mapping.md. Resolves the dangling (planned) references in PRD §5 and docs/ecosystem-boundaries.md §2.3.

  • Acceptance: docs/canon-mapping.md exists with an entity table marking each term consumed / referenced / aligned / owned; PRD §5 and ecosystem-boundaries §2.3 links resolve.

Define configuration-surface schema

id: ATLAS-WP-0002-T01
status: done
priority: high
state_hub_task_id: "125a4ad3-ddd4-4aee-bb94-9433a5fa4651"

Result 2026-06-26: Added schemas/surface-entry.schema.json (JSON Schema Draft 2020-12; additionalProperties:false throughout to forbid inline values), docs/configuration-surface-schema.md (fields, kind taxonomy, L0L9 ordering, explicit merge rules), and a validating seed entry registry/surfaces/surface.infotech.state-hub.api-config.md. Expanded registry/README.md. Verified: schema is valid Draft 2020-12, the example entry validates, and a forbidden inline value field is correctly rejected. CUE deferred (PRD open question 4).

Author the machine-checkable surface-entry schema and the layering/merge model. Add schemas/surface-entry.schema.json (JSON Schema; evaluate CUE per PRD open question 4) matching the entry shape in ArchitectureBlueprint §3 / PRD §10: id (surface.<domain>.<system>.<name>), kind (closed taxonomy), scope (allowed_layers over L0L9, default_layer), mutability, security_class, schema (contract, no values), sources[] (with layer role), relations, evidence. Expand registry/README.md and add docs/configuration-surface-schema.md documenting the L0L9 order and explicit merge rules.

  • Acceptance: one real example surface.* entry validates against the schema; schema forbids literal values and secret values; layer names match the shared scope vocabulary (no new scope names).

Replace inherited template registry

id: ATLAS-WP-0002-T02
status: todo
priority: high
state_hub_task_id: "2d8e41e9-ba93-4a1a-862b-993da03df1f9"

Remove capability.infotech.repo-template and other repo-seed artifacts from registry/. Add the config-atlas capability entry and update registry/indexes/capabilities.yaml. Relocate or delete inherited template consumer docs (docs/template-validation-checklist.md, docs/statehub-register.md) — those belong to repo-seed, not here. Update any references (e.g. registry/README.md points at reuse-surface templates).

  • Acceptance: no repo-template/statehub-register/template-validation artifacts remain; capabilities.yaml lists only config-atlas-owned entries; reuse-surface validate --root . passes.

Establish registry layout and seed initial surfaces

id: ATLAS-WP-0002-T03
status: todo
priority: medium
state_hub_task_id: "9b8bb1c2-a6ee-4b6e-91a4-2cd902fb52ff"

Create registry/surfaces/ and registry/indexes/surfaces.yaml. Hand-author 35 high-value configuration surfaces already present in the ecosystem (e.g. State Hub API config, warden routing catalog, reuse-surface registry layout) with surface.* ids, classified by kind and scope, source-linked, never duplicating values. This is the start of the Phase 1 seed (target 1020).

  • Acceptance: ≥3 surface.* entries exist and validate; each links to canonical source files; an owner is set on each and resolves to a domain-tree identity (or is flagged unknown); no entry contains a literal or secret value.

Reserve surface.* namespace and federate under reuse-surface

id: ATLAS-WP-0002-T05
status: todo
priority: medium
state_hub_task_id: "2a27434b-4eed-419a-b903-07cff9027bd6"

Reserve the surface.* id namespace in the reuse-surface federation roster so the configuration-surface registry interoperates with the capability surface without collision (PRD FR-10; ecosystem-boundaries §2.6). Treat the surface entry as a typed sibling of the capability entry, federated by the same hub — not a new federation mechanism. Coordinate via reuse-surface federation docs (~/reuse-surface/docs/RegistryFederation.md).

  • Acceptance: surface.* is reserved in the federation roster; config-atlas surface entries are discoverable via reuse-surface federation; no id collision with capability entries.

Wire CI validation

id: ATLAS-WP-0002-T06
status: todo
priority: medium
state_hub_task_id: "da6e44a7-ed87-433e-b183-f926e7e0caf8"

Wire registry validation to run on every change: reuse-surface validate --root ., surface-entry schema validation (T01), and git diff --check (PRD FR-9, NFR-6). Document the check in AGENTS.md / .claude/rules/stack-and-commands.md so agents and CI run the same gate.

  • Acceptance: a malformed entry blocks the check; a well-formed seed entry passes; the command sequence is documented for both agents and CI.

After workplan or registry file updates, sync from ~/state-hub:

make fix-consistency REPO=config-atlas