Dark-Alex-17
48753eaa46
FIX A: run_checks.py passed no env= to Popen, so verification commands
inherited the live GRAPH_STATE/GRAPH_STATE_FILE. Every suite script's
load_state() prefers GRAPH_STATE_FILE, so when the adversary reviews a repo
whose own tests exec these scripts (this repo's R5 tests) the leaked file
silently overrode the test state -> false failures. Popen now gets an env
with all GRAPH_STATE* keys removed. The five sibling script-test helpers
(review-gauntlet, code-reviewer, finding-verifier, step-runner,
deep-research) gain .env_remove("GRAPH_STATE_FILE") for hermeticity. New
R5 test loads state via GRAPH_STATE_FILE and asserts a shell-neutral
python3 -c probe sees both vars UNSET.
FIX B: the depth check compares the child's absolute depth against the
SPAWNER's own max_agent_depth (root = 0), so under
architect(0)->sisyphus(1)->review-gauntlet(2)->code-reviewer(3) the
code-review lane faulted "Max agent depth exceeded (4/3)". Limits are now
child depth + 1 headroom along the documented chains, with the chain in a
comment next to each key: code-reviewer 3->5, domain-reviewer 2->6,
architecture-reviewer 2->4, step-runner default->4 (explicit),
review-gauntlet stays 4. domain-reviewer's file-reviewer hop is documented
but inert (can_spawn_agents unset) - left unwired by decision; noted in
config and pinned via a DOCUMENTED_BUT_UNWIRED exemption in the new
bundled-config test, which pins every value and asserts per-hop headroom +
reachability along four chains.
Architecture Reviewer
An on-demand architecture improvement scout. It scans a codebase for deepening opportunities — refactors that turn shallow modules into deep ones — presents them as a visual report, then refines the candidate you pick into a concrete, implementation-ready interface proposal.
Two things it is deliberately not:
- Not a completion gate. The review stack (
code-reviewer,adversary,security-reviewer) judges changes before a task finishes. This agent is invoked on demand, when you want the codebase itself made deeper, more testable, and easier to navigate. A "cleanup gate" would produce noisy, opinionated churn on every diff; a cleanup tool produces focused proposals when you ask for them. - Not an implementer. It proposes; you (or a
coderyou delegate to) implement. Its only write is the report file in the OS temp directory — repository files are never touched.
How it works
Driven by the codebase-design skill — the shared
deep-module vocabulary (module, interface, depth, seam, adapter, leverage,
locality) and its principles (the deletion test, "the interface is the test surface", "one
adapter = hypothetical seam, two = real").
- Scope by git history (YAGNI). Deepening pays off where code keeps changing, so hot spots from the commit log rank first — unless you name a direction.
- Explore for friction. Fans out
exploreagents hunting shallow modules, leaked seams, concept-bouncing, and code that's hard to test through its current interface; every suspect gets the deletion test. - Report candidates. 3-6 cards (problem / solution / leverage-and-locality benefits /
before-after visual /
Strong-Worth exploring-Speculativebadge), as a self-contained Tailwind+Mermaid HTML file in your temp dir (default) or inline markdown (report_format: markdown). Ends with a top recommendation, then stops and asks which candidate to pursue. - Refine via design-it-twice. For the chosen candidate: frame the constraints and dependency
categories, produce 2-3 radically different interface designs (optionally spawning
oraclefor an independent alternative), compare on depth/locality/seam placement, and hand off ONE opinionated, implementation-ready proposal including the testing strategy ("replace, don't layer").
Usage
# Scan the current repo, HTML report
coyote -a architecture-reviewer "Find deepening opportunities"
# Aim it at a pain point, inline report
coyote -a architecture-reviewer --agent-variable report_format markdown \
"The billing/entitlements code is painful to test - what should be deepened?"
Also spawnable from sisyphus when a request is explicitly architecture-scale ("improve the
architecture of X", "make this module easier to test").
Related
codebase-design— the vocabulary and principles it runs on.oracle— advisory design review; also loadscodebase-designfor the shared vocabulary.explore— the codebase walkers it fans out.
Credits
Adapted from the codebase-design and improve-codebase-architecture skills in
mattpocock/skills (MIT), which build on ideas from John
Ousterhout's A Philosophy of Software Design and Michael Feathers' Working Effectively with
Legacy Code.