Phase 2 (ATLAS-WP-0003): read-only discovery connectors reusing repo-scoping's scanner/candidate/approval pipeline — connector contract, repo-scoping fact ingestion, git-config scanner, feature-control flag connector, stale/unowned detection. Phase 3 (ATLAS-WP-0004): effective-config explain + knowledge graph — static override-path resolver, config explain tool, config-typed edges to the State Hub graph, blast-radius view, determinism tests. File-first per ADR-001; state_hub ids to be written by fix-consistency. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
4.7 KiB
id, type, title, domain, repo, status, owner, topic_slug, created, updated
| id | type | title | domain | repo | status | owner | topic_slug | created | updated |
|---|---|---|---|---|---|---|---|---|---|
| ATLAS-WP-0003 | workplan | Discovery connectors | infotech | config-atlas | ready | codex | custodian | 2026-06-26 | 2026-06-26 |
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; T02–T04 (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
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
candidatestatus + provenance.
repo-scoping fact ingestion connector
id: ATLAS-WP-0003-T02
status: todo
priority: high
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
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
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-flagcandidate 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
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