review

Topics in the source

• Review Workflow
• Steps
• Step 1: Understand intention
• Step 2: Check engineering standards compliance
• Step 3: Check functional correctness
• Step 4: Check test coverage
• Step 5: Check operational readiness
• Step 6: Filter and produce the output

CANARY: review-loaded-2026-05-19-da60b2aa44b817de Reads status/specification.md (the statement of intent) and audits the diff against it, surfacing drift between spec and implementation. Record every finding with a severity and a confidence, including low ones; deciding which findings block or get dropped is a separate step at the verdict, so nothing is filtered out before it is seen. Read PR description/ticket. State the intention in one sentence before proceeding. If the intention is unclear, ask before reviewing code. If engineering standards exist in the host repo (a project-level engineering-standards skill or equivalent), verify: [ ] Code structure follows repo conventions [ ] Tech stack follows the approved stack [ ] Code conventions (naming, async patterns, type hints, no hardcoded secrets) [ ] API versioning (backwards compatible? New version if breaking?) [ ] Security (auth on new endpoints, input validation, audit logging, no sensitive data in logs) [ ] Configuration (URLs via env vars, safe defaults) Does the code actually solve the stated problem? Are there edge cases not handled? Are error paths handled correctly (not silently swallowed)? Is the data flow correct (inp

This is an excerpt. Refer to the complete source and its current requirements.