Files
config-atlas/workplans/ATLAS-WP-0003-discovery-connectors.md
tegwick 3b909338cb
Some checks failed
validate-registry / validate (push) Has been cancelled
feat(explain): implement ATLAS-WP-0004 T01+T02 — effective-config resolver + config explain
Activate WP-0003 and WP-0004. Add tools/effective_config.py (deterministic,
order-independent override-path resolver — path only, never a value) and
tools/config_explain.py + `make explain` to render the layer path, winning
layer, validator, owner, consumers, and secret references for any surface.*.
Verified on all 4 seeded surfaces; order-independent; no values/secrets leak.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-27 00:05:01 +02:00

5.0 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-0003 workplan Discovery connectors infotech config-atlas active codex custodian 2026-06-26 2026-06-27 e4400d9c-021a-4e44-8e9b-719f94a9561a

Discovery connectors

Grow the configuration-surface registry from automated discovery instead of only hand authoring — by reusing repo-scoping's scanner → candidate → approval machinery rather than building bespoke scanners.

This is Phase 2 of specs/ArchitectureBlueprint.md §6 and realizes PRD FR-8 (specs/ProductRequirementsDocument.md). Connectors are read-only and stateless: they emit candidate surface entries for human/agent PR review and never write any source system or auto-merge (docs/ecosystem-boundaries.md §2.4).

Depends on: ATLAS-WP-0002 (surface schema, registry layout, CI gate). The candidate → approval → registry-truth state machine and source-linked evidence model are reused from repo-scoping, not reinvented.

Exit condition: at least one connector produces candidate surfaces that enter via PR, validate against the schema, and can be promoted to entries; stale/unowned surfaces are reported. No connector mutates a source system.

Sequencing: T01 (contract) first; T02T04 (connectors) depend on T01 and may proceed in parallel; T05 (stale/unowned) depends on having connector-produced data.

Define the connector contract and candidate workflow

id: ATLAS-WP-0003-T01
status: todo
priority: high
state_hub_task_id: "e7b03e49-7e49-4629-ada1-facdf596569b"

Specify the read-only connector contract and the candidate lifecycle. Define the candidate entry format (a surface entry with status: candidate + provenance) and its location (registry/surfaces/candidates/), and the connector → candidate YAML → PR → validate → promote/merge flow. Reuse repo-scoping's Scope→…→Evidence→Fact provenance and candidate→approval model (~/repo-scoping/docs/scope-md-spec.md, src/repo_scoping/candidate_graph/). Document in docs/discovery-connectors.md.

  • Acceptance: a documented contract (inputs, candidate output shape, promotion rules); connectors are specified as stateless and non-mutating; the candidate schema reuses the surface-entry schema with a candidate status + provenance.

repo-scoping fact ingestion connector

id: ATLAS-WP-0003-T02
status: todo
priority: high
state_hub_task_id: "2447547b-1776-4225-af4f-f73680ccb2df"

Build the connector that consumes repo-scoping observed facts/evidence as input and emits candidate configuration surfaces, adding only the config-kind and layer classification on top (ecosystem-boundaries §2.4 option a). Map repo-scoping facts about config files/env/params to surface.* candidates with kind, scope, and sources[] populated.

  • Acceptance: running the connector against a registered repo's repo-scoping facts emits valid candidate surfaces (schema-valid) with source links; zero writes to repo-scoping or the scanned repo.

git-config deterministic scanner

id: ATLAS-WP-0003-T03
status: todo
priority: medium
state_hub_task_id: "ddfb8eaf-46b4-4b15-9719-b167538c15fb"

Build a deterministic scanner over repository config surfaces — env files, YAML/TOML config, Kubernetes ConfigMap/Secret references, and Helm values*.yaml overlays — emitting candidate entries with inferred kind and layer role per source. Secret references become secret-ref candidates (reference only, never values).

  • Acceptance: scanning a sample repo emits candidates classified by kind, with Helm overlays mapped to layer roles; secret references carry no values.

feature-control flag connector

id: ATLAS-WP-0003-T04
status: todo
priority: medium
state_hub_task_id: "9e2f5893-7b98-4ca6-89d7-94d093d6bd4b"

Build a connector that inventories feature-control keys and emits feature-flag surfaces that link to the feature-control key (sources[].role: feature-control-key) and contain no evaluation logic (PRD FR-12; reinforces the delegation boundary). Surface stale flags as a signal.

  • Acceptance: feature-control keys appear as feature-flag candidate surfaces linking to the authoritative key; config-atlas holds no flag-evaluation logic.

Stale and unowned surface detection

id: ATLAS-WP-0003-T05
status: todo
priority: medium
state_hub_task_id: "ddcf070c-a863-47df-8c99-61c1980a8d18"

Add a report that flags surfaces with no resolvable owner (against domain-tree) and surfaces whose sources were not seen in the latest scan (stale/drift signal), using evidence.last_seen. Wire it into the validation tooling (tools/).

  • Acceptance: the report lists unowned and stale surfaces; an unowned or unseen-since-N-days surface is surfaced for review.

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

make fix-consistency REPO=config-atlas