qstack-plan-adherence-review

/qstack-plan-adherence-review

Audit the implementation against the plan. Treat the plan as the contract, the code and test results as ground truth, and the execution record as supporting evidence that must itself be checked.

This is report-only work. Do not edit the plan, execution record, code, tests, or repository instructions. Do not commit or push. Write an adherence-review.md only when the user explicitly asks for a saved artifact; otherwise report in the final response.

Resolve the evidence

1. Use a plan path supplied by the user.
2. Otherwise use a plan clearly referenced in the conversation.
3. Otherwise inspect qstack/compound_engineering/plans/*/plan.html, then legacy compound-engineering/plans/*/plan.html and plan.md. Never select .template/. Use the only plausible candidate; ask when multiple candidates remain.
4. In the plan directory, prefer execution.md. Also read executor.md and legacy implementation-notes.md when present; do not discard history merely because a newer filename exists.
5. Read board-events.js beside them when it exists. Run node --check, then skip its required format header and fold the remaining qstackBoardEvent({...}); calls in file order for each card's final status, owner, refs, and files. Stop on broken JavaScript. Agents write the board while they work, so it has the same standing execution.md already has here. It is evidence to be checked against the code, never trusted on its own. When only the retired board.jsonl exists, fold its raw JSON lines without editing it. If both board files exist, report the conflict and trust neither.

Read repository instruction files and the whole authoritative plan. Record the plan status. A draft or proposed plan may be reviewed, but state that it lacked implementation authority.

Determine the implementation range before judging it. Prefer, in order:

1. a base ref, reviewed fingerprint, or commit range explicitly recorded in the execution record;
2. a base supplied by the user;
3. the merge base with the repository's target branch, normally origin/main;
4. a range reconstructed from plan history and relevant commits.