Back to Details

review-post-task

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Post-Task Two-Pass Code Review

任务完成后两轮代码评审

Execute mandatory two-pass review protocol after completing code changes. Focus: $ARGUMENTS
完成代码变更后，必须执行两轮评审流程。 重点：$ARGUMENTS

Summary

概述

Goal: Two-pass code review ensuring all changes follow EasyPlatform standards before commit.
StepActionKey Notes
1Pass 1: ReviewGather 
git diff
, check task correctness + code standards + security
2Pass 1: CorrectionsFix issues found; set 
PASS_1_MADE_CHANGES
flag
3Pass 2: Re-reviewOnly if Pass 1 made changes; verify corrections didn't introduce issues
4Final reportSummary with issues found/fixed, remaining concerns, ready-for-commit status
Key Principles:
  • 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
目标： 在提交前通过两轮代码评审确保所有变更符合EasyPlatform规范。
步骤操作关键说明
1第一轮：评审获取
git diff
，检查任务正确性 + 代码规范 + 安全性
2第一轮：修正修复发现的问题；设置
PASS_1_MADE_CHANGES
标记
3第二轮：复评审仅在第一轮有修改时执行；验证修正未引入新问题
4最终报告汇总发现/修复的问题、剩余关注点、是否可提交状态
核心原则：
  • 两轮评审确保修正不会引入新问题
  • 在
    /cook
    、
    /fix
    、
    /code
    工作流后自动触发
  • 检查底层逻辑、BEM类、
    untilDestroyed()
    、平台验证模式

Protocol Overview

流程总览

This review ensures ALL code changes follow best practices and project conventions. Two passes guarantee corrections don't introduce new issues.
本评审确保所有代码变更遵循最佳实践和项目约定。 两轮评审确保修正不会引入新问题。

Pass 1: Initial Review

第一轮：初始评审

Step 1.1: Gather Changes

步骤1.1：收集变更

bash
undefined
bash
undefined

Get unstaged changes summary

获取未暂存变更摘要

git diff --stat
git diff --stat

Get detailed changes

获取详细变更

git diff
undefined
git diff
undefined

Step 1.2: Review Checklist

步骤1.2：评审检查清单

Task Correctness:
  • Changes achieve the intended task objective
  • No unrelated/unnecessary modifications
  • Edge cases handled appropriately
  • Error handling is complete
Code Standards (EasyPlatform):
Backend:
  • 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
Frontend:
  • Extends appropriate base class (AppBaseComponent, AppBaseVmStoreComponent, AppBaseFormComponent)
  • Uses PlatformVmStore for state management
  • Uses .pipe(this.untilDestroyed()) for subscriptions
  • All template elements have BEM classes
Architecture:
  • Logic placed in lowest appropriate layer (Entity > Service > Component)
  • No cross-service direct database access
  • Follows existing patterns found in codebase
Understanding Verification (soft prompts):
  • 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?
Security:
  • No hardcoded secrets or credentials
  • Input validation at boundaries
  • Proper authorization checks
任务正确性：
  • 变更达成了预期的任务目标
  • 无无关/不必要的修改
  • 已适当处理边缘情况
  • 错误处理完整
代码规范（EasyPlatform）：
后端：
  • 使用平台仓库（IPlatformQueryableRootRepository）
  • 使用PlatformValidationResult流式API（.And(), .AndAsync()）
  • 副作用在实体事件处理器中，而非命令处理器
  • DTO通过MapToEntity()/MapToObject()实现自身映射
  • 命令 + 结果 + 处理器在同一个文件中
前端：
  • 继承合适的基类（AppBaseComponent、AppBaseVmStoreComponent、AppBaseFormComponent）
  • 使用PlatformVmStore进行状态管理
  • 对订阅使用.pipe(this.untilDestroyed())
  • 所有模板元素都有BEM类
架构：
  • 逻辑放置在最合适的底层（实体 > 服务 > 组件）
  • 无跨服务直接数据库访问
  • 遵循代码库中已有的模式
理解验证（软提示）：
  • 你能否用2句话解释每个修改文件的变更原因？
  • 如果撤销此变更，会有什么功能受影响？
  • 此变更依赖哪些假设？
安全性：
  • 无硬编码密钥或凭证
  • 在边界处进行输入验证
  • 正确的权限检查

Step 1.3: Execute Corrections

步骤1.3：执行修正

If any issues found:
  1. Fix each issue directly
  2. Mark 
    PASS_1_MADE_CHANGES = true
  3. Proceed to Pass 2
If no issues found:
  1. Mark 
    PASS_1_MADE_CHANGES = false
  2. Skip to Final Report
如果发现任何问题：
  1. 直接修复每个问题
  2. 标记
    PASS_1_MADE_CHANGES = true
  3. 进入第二轮评审
如果未发现问题：
  1. 标记
    PASS_1_MADE_CHANGES = false
  2. 跳至最终报告

Pass 2: Re-Review (Conditional)

第二轮：复评审（条件触发）

ONLY EXECUTE IF PASS 1 MADE CHANGES
仅在第一轮有修改时执行

Step 2.1: Verify All Changes

步骤2.1：验证所有变更

bash
undefined
bash
undefined

Check updated changes

检查更新后的变更

git diff --stat git diff
undefined
git diff --stat git diff
undefined

Step 2.2: Full Re-Review

步骤2.2：完整复评审

Repeat Pass 1 checklist on ALL current changes (original + corrections).
Focus areas:
  • 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

步骤2.3：最终修正

If issues found:
  • Apply minimal, targeted fixes
  • Document any trade-offs made
如果发现问题：
  • 应用最小化、针对性的修复
  • 记录任何做出的权衡

Final Report

最终报告

Summary Template

汇总模板

markdown
undefined
markdown
undefined

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]
任务： [简要描述] 第一轮结果： [无问题 / 修复了N个问题] 是否需要第二轮： [是/否] 第二轮结果： [不适用 / 无问题 / 修复了N个问题]

Changes Summary

变更汇总

  • [List of files modified]
  • [Key changes made]
  • [修改的文件列表]
  • [关键变更内容]

Issues Found & Fixed

发现并修复的问题

  1. [Issue]: [Fix applied]
  2. ...
  1. [问题]：[应用的修复]
  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

快捷命令

bash
undefined
bash
undefined

View changes for review

查看待评审的变更

git diff --stat && git diff
git diff --stat && git diff

Check specific file

检查特定文件

git diff path/to/file.ts
git diff path/to/file.ts

Fix a problematic change

修复有问题的变更

Use 
/fix
workflow to apply fixes instead of manual git checkout

使用
/fix
工作流应用修复，而非手动git checkout

Stage reviewed changes

暂存已评审的变更

git add -p # Interactive staging

---
git add -p # 交互式暂存

---

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
  • 此命令由工作流编排系统在
    /cook
    、
    /fix
    、
    /code
    后自动触发
  • 可随时用
    /review-post-task
    手动调用
  • 对于PR评审，请使用
    /review-codebase
  • 对于需要深度分析的复杂评审，使用
    code-reviewer
    子代理

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
  • 始终规划并拆分多个小型待办任务
  • 始终添加一个最终评审待办任务，在结束时检查已完成的工作，以发现任何需要修复或优化的内容