The Second Build Was Mostly Wiring

My first series, Your agent might actually lie to you, is about one shape of GuardianKane: a Claude Code Stop hook that will not let the agent finish until Kane CLI has checked the work in a real browser. That shape placed 2nd in the TestMuAI Kane CLI hackathon, and four paired experiments stand behind it. It is not what GuardianKane is today. The hook is still there, but it is one piece of a larger system: a reviewed PRD, a phase model, a live scope guard, a file lock, a secret scan, and a dashboard with graph views and a chat panel wired into the running Claude Code session. This is the story of how it got there. Part 2 is the tour of what it looks like.

Three shapes, one repo

The repo's JOURNEY.md records each shape against the commits that built it.

Era 1 was a planning tool. The first four commits are a design spec, an implementation plan, a task-tracker library, and a Claude Code skill with a thin kane-cli wrapper. You gave it a PRD and got back a task-tracker.md: tasks with ids, titles, PRD references, and dependencies. Nothing checked whether a task marked done was done.

Era 2 was the gate. The same afternoon, 896bc57 added the Stop and PostToolUse hooks with the full decision table, and a day of running the loop against real apps turned it into the product the first series describes: scripted replay, a defect sweep, bug memory, an installer, and the four paired experiments. Two demo videos come from this era, a 14-minute walkthrough and a 3-minute cut.

Era 3 started five days later. It opens with a new dashboard on August 26 and then runs through twelve numbered phases, each with its own design spec and implementation plan under docs/superpowers/. The current build has its own demo video.

Why rebuild something that worked

The v2 design spec opens with the problem, and it is not "the gate was broken". It is that asking a coding agent to generate tests for a system produces "on the order of hundreds of assertions, all green", that do not exercise real browser behaviour and do not map to what the PRD asked for. The spec calls these AI-slop tests and names two separate things wrong with them.

The first is that they are push-based. The agent reads the PRD once, generates everything it can think of, and stops. v2 makes verification pull-based: a person (or later the Stop hook) selects concrete nodes in a graph of the codebase, and only those nodes' claims get tested. The spec is careful about how much that buys, and I want to keep that care here. An earlier draft said v2 fixed both problems "by construction". An independent review caught it, and the spec now says pull-based targeting narrows scope, not depth. A vague instruction fed to the same browser agent can still produce a shallow pass. What v2 guarantees is that verification is aimed at something a person deliberately pointed at, not that any given run is rigorous.

The second problem is no memory of where. Era 2's bug memory could say "this looks like a bug we have seen before" by comparing failure text, but it never recorded which files were involved, so it could not say "this exact set of files was fixed on the 20th and has regressed". v2 keys its knowledge memory by the set of graph nodes under test.

The phase that fixed every fresh install

Before any new feature, the plan for Era 3 audited what Kane CLI already did and what GuardianKane was duplicating. Its conclusion became the architecture: GuardianKane's job narrowed to orchestration. Kane owns the claim graph, coverage, reconcile, and explanations; GuardianKane owns tasks, phases, the gate, and the dashboard.

The same audit found the bug that became Phase 0. Kane CLI will not generate tests for a use case that has not been reviewed. It refuses with uc-1 is unreviewed, and the fix is kane-cli context review --approve. The plan records that context review was "never called anywhere in the current codebase". So on any fresh install, test design failed on the first use case. I do not have data on why my Era 2 runs never tripped over it.

Phase 0 (39aaeaa) wires the review step in, so every grilled use case and every generated test is approved before it counts. That is also the honest version of what "PRD grilling" means in the current build: a requirement is extracted, questioned, and reviewed before anything is built against it.

Twelve phases, and what most of them had in common

Phase	What it added	Built on
0	Review gate	a Kane command nothing called
1	Per-AC evidence and tamper detection	Kane's sealed evidence packs
2	Phase model in the tracker	the existing tracker schema
3	Context injection before a task starts	context explain / design explain, which make no model calls
4	Live scope guard	the PostToolUse hook's file-touch record