easd-review

Review an EASD implementation

Repository contract

Read .evoflux/easd/config.json and its rules_file before phase work. Treat the injected EASD context as the authoritative current Run; when the owning runtime is accessible, corroborate it under runtime_directory. An isolated worktree intentionally has no checkout-local runtime copy. Confirm the common specs/ revision and Run-local accepted snapshot have the same hash. Inspect affected living features/, architecture/, and reference/ documents plus existing project docs at their original paths. Repository documents are the shared source of truth. Stop on a missing tracked contract, stale hash, generation conflict, or unavailable injected runtime; never reconstruct authority from chat memory or a stale database-only projection. Review is mandatory for both direct and planned; independence remains risk-driven.

Act as an independent, read-only challenger. Review the actual integrated change against the exact accepted spec hash; do not treat the implementer's handoff or test summary as the source of truth.

State gate

Re-read the run, accepted Spec hash, delivery flow, assigned review ACs, integrated revision/diff, optional accepted Plan hash, and current evidence. Review only while the run is reviewing; active waits for the user's Run review action and verifying belongs to the next Skill. If an applicable hash or reviewed snapshot changes during the pass, invalidate the verdict and restart against the new snapshot; do not patch an old verdict forward.

Review protocol

1. Confirm the run ID, accepted hash, assigned ACs, risk tier, affected repositories/paths, and whether reviewer independence is required. If you authored the change and independence is required, stop and request a fresh reviewer.
2. Read the accepted contract and inspect the integrated diff and owning files directly. Review the integrated revision, not an abandoned worktree or a parent summary.
3. Trace each in-scope AC through observable behavior, implementation, tests, interfaces, and current documentation. Check applicable happy, error, authorization, domain-invariant, recovery/concurrency, and cross-layer paths.
4. Audit responsibility boundaries and dependency direction. Flag changes outside accepted impact targets, hidden coupling, undeclared shared ownership, or a local task that silently became cross-layer work.
5. Cite every finding with an AC or contract reference plus repository path and line/source evidence. Separate blocking correctness/security/scope findings from non-blocking suggestions; drop claims that cannot be sourced.
6. Return an explicit per-AC verdict and list the evidence inspected, checks not run, uncertainty, and required remediation. After fixes, review the new diff afresh rather than assuming the prior finding was resolved.