foundation-audit

Lane 1 of the four-dimension foundation audit — architecture, layering and boundaries, including the violations structural linters STRUCTURALLY CANNOT see: a value smuggled across a layer via specialArgs, an overlay, a string-interpolated path, or a runtime-built store path. Also god-file seams, where naming what must stay FUSED matters as much as naming what splits. Use when running the foundation audit, or when asked directly "does this repo's layering actually hold", "what boundary violations would a linter miss", or "which of these big files should be split". Returns findings, a CONFIRMED-SOUND list, and mandatory UNKNOWNS.

Lane 4 of the four-dimension foundation audit — dead surface and doc drift. Hunts options declared and never read, unreachable outputs and entry points, guardrails whose pattern can no longer match anything (nothing anywhere reports a rule that never fires), and the only doc drift that counts: a step, path, count, flag or URL a reader would ACT on and be wrong. Past-tense history in a comment is explicitly NOT drift. Use when running the foundation audit, or when asked "what here is dead", "are our rules actually armed", or "are the docs still true". Returns findings, a CONFIRMED-SOUND list, and mandatory UNKNOWNS.

Lane 2 of the four-dimension foundation audit — duplication and redundancy judged by PURPOSE, not by text. Three hunts: two executables for the same job even when they share no code; one fact (a port, a path, a label, a URL, a UID) declared in two places that can silently disagree; and custom code that an upstream dependency already ships, proved by grepping the PINNED input's option surface and citing the result. Use when running the foundation audit, or when asked "what is redundant here", "are we reinventing something upstream has", or "where can these two configs drift apart". Returns findings, a CONFIRMED-SOUND list, and mandatory UNKNOWNS.

Lane 3 of the four-dimension foundation audit — validation, failure modes and blast radius. Classifies every activation, setup, bootstrap and deploy step into four buckets: cannot-fail, fails loud-and-early, fails MID-WAY leaving mixed state, or fails SILENTLY. The last two are the findings, and the silent one is where the real damage lives (an upstream `exit 0` inside a concatenated activation script ends the WHOLE script reporting success). Read-only: it never runs an activation, and says so in UNKNOWNS. Use when running the foundation audit, or when asked "what happens if this half-applies", "can this fail without telling me", or "what is the blast radius".

Orchestrates a four-dimension foundation audit of a config monorepo — is this repo solid enough to build on? Builds ONE calibration brief, fans out four lane-scoped agents in parallel (architecture/boundaries, duplication-by-purpose, validation and failure modes, dead surface and doc drift), each told what the others cover so it stays in its lane, then RE-VERIFIES the top findings itself before relaying a ranked report. Use when the user asks "is this repo solid enough to build on", "audit the foundations", "what would bite us later", "full architecture review", or before committing to a large piece of work on top of an existing config repo. Finds what eval gates, structural linters, dead-code linters and CI structurally cannot see.