Back to Details

end-state-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

End-State Review

最终状态评审

Reconstruct the target as if the settled requirements had been known from the start. Remove history-shaped complexity from the proposal without erasing real contracts, migrations, or rollout obligations.
Default to review-only. After explicit approval, update planning artifacts only. Do not modify implementation in this workflow; leave code changes to a separate implementation request.
从一开始就明确既定需求的角度重构目标。在不删除真实契约、迁移或上线义务的前提下，移除方案中因历史原因产生的复杂内容。
默认仅进行评审。获得明确批准后，仅更新规划工件。在此工作流中不得修改实现；代码变更需提交单独的实施请求。

Resolve the Review Target

确定评审目标

  1. Review the user-named plan, roadmap item, specification, change, diff, or migration. When no artifact is named, infer the smallest plausible target from the current discussion and repository planning state. Ask when materially different targets remain plausible.
  2. Read the target completely. Inspect governing requirements, direct user decisions, relevant implementation, callers, tests, history, and external contracts only far enough to test the proposed final shape.
  3. Keep direct user intent, planning claims, implementation evidence, and external obligations distinct. A proposal does not prove an obligation, and absence from the plan does not prove that a deployed contract is dead.
  4. Bound the review to complexity introduced, retained, or locked in by the target. Mention unrelated debt only when it invalidates the proposal; do not absorb it into the review.
  1. 评审用户指定的计划、路线图条目、规范、变更、差异或迁移内容。当未指定具体工件时，从当前讨论和仓库规划状态中推断最合理的最小目标。若存在多种差异较大的合理目标，需向用户确认。
  2. 完整研读目标内容。仅需查阅相关的主导需求、用户直接决策、相关实现、调用方、测试、历史记录和外部契约，以验证拟议的最终形态。
  3. 明确区分用户直接意图、规划声明、实现证据和外部义务。方案本身不能证明义务的存在，计划中未提及也不能证明已部署的契约已失效。
  4. 将评审范围限定在目标引入、保留或锁定的复杂性上。仅当无关技术债务会使方案失效时才提及，不得将其纳入评审范围。

State the End-State Contract

明确最终状态契约

Describe in a few sentences what should be true when the work is finished:
  • the user-visible outcome;
  • the domain rules and ownership boundaries that must survive;
  • the public, persisted-data, migration, security, or rollout obligations that constrain the design;
  • material non-goals.
Ask only when a missing answer could materially change that contract. Do not choose a cleaner architecture by silently changing product behavior.
用几句话描述工作完成后应达到的状态：
  • 用户可见的结果；
  • 必须保留的领域规则和所有权边界；
  • 对设计构成约束的公开契约、持久化数据、迁移、安全或上线义务；
  • 明确的非目标内容。
仅当缺失的答案会实质性改变该契约时才询问。不得通过悄悄更改产品行为来选择更简洁的架构。

Separate Residue from Obligations

区分遗留内容与义务

Inspect modes, flags, wrappers, aliases, fallbacks, duplicated policy, parallel flows, temporary schema, transitional names, and workaround plan steps. For each consequential candidate, record its evidence and classify it as:
  • Remove — no current consumer, contract, or migration need remains.
  • Consolidate — the behavior is real but its rules or ownership are duplicated.
  • Retain temporarily — a current rollout or migration requires it; name the exit condition.
  • Retain permanently — a domain or external contract justifies the cost.
  • Unresolved — evidence or a user decision is still required.
Search real callers before recommending deletion, but do not treat an empty repository search as proof when use may be dynamic, reflective, configured, persisted, or external. Require stronger evidence in proportion to the cost of being wrong.
检查模式、标志、包装器、别名、回退机制、重复策略、并行流程、临时 schema、过渡名称和临时方案步骤。对每个重要的候选项，记录其依据并归类为：
  • 移除 — 无当前消费者、契约或迁移需求。
  • 合并 — 行为真实存在，但规则或所有权存在重复。
  • 临时保留 — 当前上线或迁移需要该内容；需明确退出条件。
  • 永久保留 — 领域或外部契约证明其成本合理。
  • 未解决 — 仍需补充依据或用户决策。
建议删除前需查找真实的调用方，但当使用可能是动态、反射、配置化、持久化或外部调用时，仓库搜索为空不能作为证明。错误成本越高，所需的依据就越充分。

Reconstruct the Coherent Shape

重构连贯形态

Design from the end-state contract rather than replaying the sequence of earlier decisions.
  • Prefer one clear product path over mode flags or parallel implementations.
  • Give each shared rule, such as permissions, routing, URL state, feature gating, or command naming, one evident owner.
  • Integrate with an existing sound boundary before adding a side channel, adapter, or new abstraction.
  • Split a surface only when state, lifecycle, layout, control, or domain ownership creates a durable boundary.
  • Prefer product-intent names over names that preserve implementation history.
  • Do not invent a framework for one current use or preserve machinery for an imagined future.
  • Keep staged rollout and backward compatibility when evidence shows they are live obligations.
  • Keep the proposed rework no broader than necessary to make the target coherent.
基于最终状态契约进行设计，而非重复之前的决策流程。
  • 优先选择清晰单一的产品路径，而非模式标志或并行实现。
  • 为每个共享规则（如权限、路由、URL 状态、功能开关或命令命名）指定明确的所有者。
  • 在添加侧信道、适配器或新抽象之前，优先与现有合理边界集成。
  • 仅当状态、生命周期、布局、控制或领域所有权形成持久边界时，才拆分对外接口。
  • 优先使用符合产品意图的名称，而非保留体现实现历史的名称。
  • 不为单一当前用途发明框架，也不为想象中的未来保留机制。
  • 当有证据表明分阶段上线和向后兼容是当前义务时，需予以保留。
  • 拟议的重构范围仅需足以使目标连贯即可，不应过度扩大。

Reconcile the Target

协调目标

For a planning target, identify obsolete steps and propose the smallest set of replacements needed to express the coherent end state. Preserve approved scope, non-goals, acceptance conditions, and sequencing that reflects real dependencies rather than historical discussion order.
For an implementation target, describe the desired code shape, likely deletions, and affected consumers. Stop at recommendations even when a fix looks safe. Code mutation requires a separate request.
Map each end-state outcome and retained obligation to validation. Include tests for deleted assumptions when navigation, permissions, persistence, external consumers, or rollout behavior could regress.
对于规划目标，识别过时步骤，并提出表达连贯最终状态所需的最小替换集。保留已批准的范围、非目标、验收条件，以及反映真实依赖关系而非历史讨论顺序的执行顺序。
对于实现目标，描述理想的代码形态、可能的删除内容和受影响的消费者。即使修复看起来安全，也仅停留在建议层面。代码修改需提交单独请求。
将每个最终状态结果和保留的义务映射到验证环节。当导航、权限、持久化、外部消费者或上线行为可能出现回归时，需包含针对已删除假设的测试。

Apply the Planning Gate

应用规划闸门

Keep the repository unchanged during the initial review. Treat an explicit instruction such as 
apply these plan changes
or 
update the plan
as approval to edit only the reviewed planning artifacts. Acknowledgement, continued discussion, or agreement with the analysis is not edit approval.
When applying an approved planning revision:
  1. Replace superseded proposal text instead of appending a conversation log.
  2. Record the end-state outcome, retained obligations and exit conditions, material non-goals, validation, and the next implementation action. Link to an existing contract source instead of duplicating requirements that it owns.
  3. Preserve the planning system's ownership and queue invariants.
  4. Re-read the touched files and verify that no old step contradicts the approved final shape.
  5. Stop without starting implementation or changing code.
初始评审期间保持仓库不变。仅当收到明确指令（如
apply these plan changes
或
update the plan
）时，才批准编辑已评审的规划工件。仅对分析表示认可、继续讨论或达成一致并不等同于编辑批准。
应用已批准的规划修订时：
  1. 替换已过时的方案文本，而非附加对话日志。
  2. 记录最终状态结果、保留的义务和退出条件、明确的非目标、验证方式，以及下一步实施动作。链接到现有契约源，而非重复其负责的需求内容。
  3. 保留规划系统的所有权和队列规则。
  4. 重新阅读修改过的文件，验证是否存在与已批准最终形态相矛盾的旧步骤。
  5. 停止操作，不得启动实施或修改代码。

Report

报告

Return only sections that carry information:
  • End state — the reconstructed final contract.
  • Residue and obligations — candidates, evidence, and disposition.
  • Proposed shape — the coherent design and material tradeoffs.
  • Plan amendments — replacements needed or approved edits made.
  • Verification — behavior and deleted assumptions to prove.
  • Decisions required — unresolved load-bearing choices.
  • Scope boundary — relevant work deliberately left outside the review.
A defensible conclusion that the target is already coherent is valid. Do not manufacture debt or claim that any review can guarantee zero technical debt.
仅返回包含有效信息的部分：
  • 最终状态 — 重构后的最终契约。
  • 遗留内容与义务 — 候选项、依据和处理方式。
  • 拟议形态 — 连贯的设计和重大权衡。
  • 计划修订 — 所需的替换内容或已完成的批准编辑。
  • 验证 — 需要验证的行为和已删除的假设。
  • 待决策事项 — 未解决的关键选择。
  • 范围边界 — 故意排除在评审之外的相关工作。
若得出目标已连贯的合理结论，该结论同样有效。不得编造技术债务，也不得声称任何评审能保证零技术债务。