Post-Task Two-Pass Code Review

Summary

git diff

PASS_1_MADE_CHANGES

• Two passes guarantee corrections don't introduce new issues
• Auto-triggered after

  /cook

  ,

  /fix

  ,

  /code

  workflows
• Check logic in lowest layer, BEM classes,

  untilDestroyed()

  , platform validation patterns

Protocol Overview

Pass 1: Initial Review

Step 1.1: Gather Changes

# Get unstaged changes summary
git diff --stat

# Get detailed changes
git diff

Step 1.2: Review Checklist

• Changes achieve the intended task objective
• No unrelated/unnecessary modifications
• Edge cases handled appropriately
• Error handling is complete

• Uses platform repository (IPlatformQueryableRootRepository)
• Uses PlatformValidationResult fluent API (.And(), .AndAsync())
• Side effects in Entity Event Handlers, not command handlers
• DTOs own mapping via MapToEntity()/MapToObject()
• Command + Result + Handler in ONE file

• Extends appropriate base class (AppBaseComponent, AppBaseVmStoreComponent, AppBaseFormComponent)
• Uses PlatformVmStore for state management
• Uses .pipe(this.untilDestroyed()) for subscriptions
• All template elements have BEM classes

• Logic placed in lowest appropriate layer (Entity > Service > Component)
• No cross-service direct database access
• Follows existing patterns found in codebase

• Can you explain in 2 sentences why each modified file was changed?
• What would break if this change were reverted?
• What assumption does this change rely on?

• No hardcoded secrets or credentials
• Input validation at boundaries
• Proper authorization checks

Step 1.3: Execute Corrections

1. Fix each issue directly
2. Mark

   PASS_1_MADE_CHANGES = true

3. Proceed to Pass 2

1. Mark

   PASS_1_MADE_CHANGES = false

2. Skip to Final Report

Pass 2: Re-Review (Conditional)

Step 2.1: Verify All Changes

# Check updated changes
git diff --stat
git diff

Step 2.2: Full Re-Review

• Original task still correctly implemented
• Corrections are valid and complete
• No new issues introduced by corrections
• Code is production-ready

Step 2.3: Final Corrections

• Apply minimal, targeted fixes
• Document any trade-offs made

Final Report

Summary Template

## Post-Task Review Complete

**Task:** [Brief description]
**Pass 1 Result:** [Clean / N issues fixed]
**Pass 2 Required:** [Yes/No]
**Pass 2 Result:** [N/A / Clean / N issues fixed]

### Changes Summary
- [List of files modified]
- [Key changes made]

### Issues Found & Fixed
1. [Issue]: [Fix applied]
2. ...

### Remaining Concerns (if any)
- [Concern]: [Reason not addressed / Recommended follow-up]

### Verification
- [ ] Task objective achieved
- [ ] Code follows project conventions
- [ ] No security vulnerabilities
- [ ] Ready for commit

Quick Commands

# View changes for review
git diff --stat && git diff

# Check specific file
git diff path/to/file.ts

# Fix a problematic change
# Use `/fix` workflow to apply fixes instead of manual git checkout

# Stage reviewed changes
git add -p  # Interactive staging

Integration Notes

• This command is auto-triggered by workflow orchestration after

  /cook

  ,

  /fix

  ,

  /code

• Can be manually invoked anytime with

  /review-post-task

• For PR reviews, use

  /review-codebase

  instead
• Use

  code-reviewer

  subagent for complex reviews requiring deeper analysis

IMPORTANT Task Planning Notes

• Always plan and break many small todo tasks
• Always add a final review todo task to review the works done at the end to find any fix or enhancement needed