dev-review

# Dev Review Run final pre-push review for configured AI docs features. Before changing docs or code, propose the concrete review plan and wait for user approval unless the user already approved the exact phase plan. ## Phase Contract 1. Run `npx ai-devkit@latest lint` before phase work. 2. If working on a named feature, run `npx ai-devkit@latest lint --feature <name>`. 3. Check `git status -sb` and `git diff --stat`. 4. Read feature docs and relevant changed files before findings. 5. Apply the `verify` skill before claiming readiness. 6. If parent `dev-lifecycle` established usable task tracing, emit review phase, progress, blocker/finding, next-step, and final evidence/readiness events per `task`. ## Code Review Use for Phase 9. Take a holistic review stance: findings first, ordered by severity, grounded in file/line references. 1. Gather context: feature description, modified files, design docs, risky areas, tests already run. 2. Verify design alignment by summarizing architectural intent and checking implementation matches. 3. For each modified file, grep exported names to trace callers and dependents. Read relevant signatures, call sites, and type definitions. 4. Check consistency against 1-2 similar modules. 5. Search for existing utilities the new code could reuse or now duplicates. Flag near-matches honestly; do not force a wrong abstraction. 6. Verify contract integrity at API, type, config, and schema boundaries. 7. Check dependency health, including circular ...