Path updated for v0.7.0 — detect-config.md moved to plugins/archcore/skills/_shared/grounding/. The gap is unchanged.
Problem
The init config-detection step is required to record environment-variable names and purpose only, never values, so secrets never land in Git. _shared/grounding/detect-config.md states it three times — a bold security header ("EMIT NAMES AND PURPOSE ONLY, NEVER VALUES", with "strip everything right of the first ="), step 3 ("Read names, never values"), and the secret-marking rule ("the marker never licenses printing the value").
The test that guards it is static: test/structure/init-skill.bats:41, "detect-config enforces the never-emit-values security boundary", greps the catalog for its own authoring rule. It never runs the flow and never inspects a produced config document, so an actual leak would pass CI.
Expected result
A runtime test that runs the config-detection path against a fixture with a populated .env.example — including a value that a developer "pasted by mistake", which is the exact case the catalog calls out — and asserts the produced config document contains variable names and purpose only, with no values.
Impact
Turns a documented authoring rule into an enforced guarantee, protecting users from .env values leaking into version control through onboarding.
Proposed approach
Acceptance criteria
- A config document generated from a populated
.env.example contains no values; the test fails if any value appears.
References
Design rationale: .archcore/plugin/magic-first-day-init.plan.md (M6, acceptance criterion 5). Code: plugins/archcore/skills/_shared/grounding/detect-config.md, test/structure/init-skill.bats:41. Depends on a config fixture (see #11).
Problem
The init config-detection step is required to record environment-variable names and purpose only, never values, so secrets never land in Git.
_shared/grounding/detect-config.mdstates it three times — a bold security header ("EMIT NAMES AND PURPOSE ONLY, NEVER VALUES", with "strip everything right of the first="), step 3 ("Read names, never values"), and the secret-marking rule ("the marker never licenses printing the value").The test that guards it is static:
test/structure/init-skill.bats:41, "detect-config enforces the never-emit-values security boundary", greps the catalog for its own authoring rule. It never runs the flow and never inspects a produced config document, so an actual leak would pass CI.Expected result
A runtime test that runs the config-detection path against a fixture with a populated
.env.example— including a value that a developer "pasted by mistake", which is the exact case the catalog calls out — and asserts the produced config document contains variable names and purpose only, with no values.Impact
Turns a documented authoring rule into an enforced guarantee, protecting users from
.envvalues leaking into version control through onboarding.Proposed approach
.env.example(reuse the init fixtures from Add repo-shape fixtures and init-modes.bats runtime tests for /archcore:init (scale x depth) #11 where possible).*_URLwith embedded credentials and a*_TOKEN, which the catalog marks(secret).Acceptance criteria
.env.examplecontains no values; the test fails if any value appears.References
Design rationale:
.archcore/plugin/magic-first-day-init.plan.md(M6, acceptance criterion 5). Code:plugins/archcore/skills/_shared/grounding/detect-config.md,test/structure/init-skill.bats:41. Depends on a config fixture (see #11).