Fleet Ops Review Protocol

Step 3: Read the PR (if exists)

• Conventional commits? (type(scope): description [task:XXXXXXXX])
• PR body has changelog, diff table, references?
• Code changes match what was claimed?

Step 4: Verify the Trail

• Are stage transition events recorded in board memory?
• Did the task go through ALL required stages for its type?
  • epic: conversation → analysis → investigation → reasoning → work
  • story: conversation → reasoning → work
  • task: reasoning → work
  • bug: analysis → reasoning → work
• MISSING TRAIL = finding ("No trail events — methodology compliance cannot be verified")

Step 5: Verify Contributions

• For the task type and delivery phase, what contributions were REQUIRED? (Check synergy matrix via the review data)
• Were they received? Check typed comments:
  • **Contribution (design_input)** from architect
  • **Contribution (qa_test_definition)** from qa-engineer
  • **Contribution (security_requirement)** from devsecops-expert
• MISSING REQUIRED CONTRIBUTION = finding

Step 6: Check Phase Standards

• What delivery phase is this task? (poc/mvp/staging/production)
• Does the work meet that phase's standards from config/phases.yaml?
  • poc: happy path tests, readme, no secrets
  • mvp: main flows + edges, setup docs, auth + validation
  • staging: comprehensive tests, full docs, dep audit
  • production: complete everything
• Work below phase standard = finding

Step 7: Compare Work to Verbatim (Criterion by Criterion)

• For EACH acceptance criterion in the verbatim:
  • Is it addressed in the implementation?
  • Can you point to specific code/commit/test?
  • Not "probably covered" — EVIDENCE
• Unaddressed criterion = finding

Step 8: Check QA Validation (if QA contributed)

• Did QA validate their predefined TC-XXX criteria?
• Is there a qa_validation typed comment?
• Did all TC-XXX pass? Or are there flagged gaps?

Step 9: Check Security (if DevSecOps contributed)

• Did DevSecOps do a security review?
• Is security_hold set? If so, it BLOCKS your approval.
• Were security requirements addressed?

Step 10: Decision

On Rejection

Your rejection comment MUST include:

1. What specifically failed (which step, which criterion)
2. Why it failed (what was expected vs what was found)
3. What to fix (specific action the agent should take)
4. Which stage to return to (readiness regresses, stage may regress)

The system automatically:

• Regresses readiness
• Regresses task stage (back to reasoning)
• Signals the doctor (repeated rejections → pattern detection)
• Posts to IRC #reviews
• Records trail

Red Flags (Immune System Watches For)

• Approval in < 30 seconds (didn't read the work)
• "Looks good" without specifics (rubber stamp)
• Approving without trail verification (skipped step 4)
• Approving with missing required contributions (skipped step 5)
• Approving below phase standards (skipped step 6)

Using pr-review-toolkit

For PRs, you have 6 parallel sub-agents via /review-pr:

• code-reviewer — CLAUDE.md compliance, style, bugs (0-100 score)
• code-simplifier — clarity, consistency, maintainability
• comment-analyzer — comment accuracy, doc completeness
• pr-test-analyzer — behavioral coverage, test gaps (1-10 rating)
• silent-failure-hunter — error handling audit
• type-design-analyzer — type encapsulation, invariants (1-10)

These handle the TECHNICAL review dimensions. YOU handle the METHODOLOGY