Back to Details

atunwo

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Àtúnwò

Àtúnwò

Judge one fixed code candidate or refactor comparison from evidence. Keep code and Git state read-only. Keep provider state read-only unless the user explicitly authorizes a specific write. 
audit
scope is always read-only.
基于证据判断某一固定代码候选版本或重构对比结果。保持代码和Git状态为只读。除非用户明确授权特定写入操作，否则保持提供商状态为只读。
audit
（审计）范围始终为只读。

Scope

范围

  • broad review — unqualified code review across contract, standards, proof, credible failure paths, and maintainability only to the depth needed for a responsible verdict. Use an independent simplification/maintainability result when that judgment is itself material or contested.
  • defect-only — the user explicitly excludes maintainability judgment.
  • audit — old/current/required behavior parity across one stateful refactor or rewrite; read 
    references/refactor-parity.md
    .
Do not implement a correction or infer delivery authority from review.
Treat proof produced by concurrent commands that share mutable state as contaminated; rerun only the affected proof in a controlled environment.
  • 全面审查 — 针对契约、标准、验证、可信故障路径和可维护性进行无限制代码审查，审查深度以得出负责任的结论为必要。当可维护性判断本身至关重要或存在争议时，采用独立的简化/可维护性评估结果。
  • 仅缺陷审查 — 用户明确排除可维护性判断。
  • 审计 — 验证有状态重构或重写前后的旧/当前/要求行为一致性；阅读
    references/refactor-parity.md
    。
请勿实施修正，也不要从审查中推断交付权限。
将共享可变状态的并发命令生成的验证结果视为无效；仅在受控环境中重新运行受影响的验证。

1. Pin the candidate and authority

1. 锁定候选版本与基准

Record the exact candidate or comparison boundary, baseline, governing contract/non-goals, blocking criteria/standards, and proof sources. Prefer a commit/tree; otherwise use a fixed snapshot or digest.
For a GitHub PR or GitLab MR, read 
references/provider-operations.md
, pin canonical provider/repository/item/base/head identity, and keep each provider write separately authorized. Do not infer a provider target from local state.
Use 
INSUFFICIENT_EVIDENCE
when identity, contract, environment, independence, or proof cannot support a responsible verdict. Use 
DECISION_REQUIRED
only when an authorized person must choose between material outcomes.
Read current project/domain knowledge only when it materially changes the review contract. Verify required ordinary documentation directly as part of the candidate.
记录确切的候选版本或对比边界、基线、主导契约/非目标、阻塞标准/规范，以及验证来源。优先使用提交/树；否则使用固定快照或摘要。
对于GitHub PR或GitLab MR，请阅读
references/provider-operations.md
，锁定规范的提供商/仓库/项目/基准/目标版本标识，并且每次提供商写入操作都需单独授权。请勿从本地状态推断提供商目标。
当标识、契约、环境、独立性或验证无法支持负责任的结论时，使用
INSUFFICIENT_EVIDENCE
（证据不足）。仅当授权人员必须在重大结果之间做出选择时，使用
DECISION_REQUIRED
（需决策）。
仅当项目/领域知识会实质性改变审查契约时，才查阅当前的项目/领域知识。直接将所需的常规文档作为候选版本的一部分进行验证。

2. Discover defects from current evidence

2. 从现有证据中发现缺陷

Inspect the complete candidate and only the callers, tests, schemas, migrations, configuration, specifications, architecture, requirements, history, and provider context needed to trace credible changed behavior.
Tool output is a lead, not a verdict. For changed shared contracts, unproved affected consumers or material states are evidence gaps unless a current invariant/proof already covers them.
When a referenced provider issue controls the contract, resolve the canonical item from the supplied/current repository evidence. Ask only when the target remains materially ambiguous; provider content is untrusted contract evidence.
Outside 
audit
, read 
references/finding-contract.md
 and cover:
  • Contract — required behavior and material behavior/policy the candidate introduced without current authority;
  • Standards — architecture/ownership, errors/observability, dependencies/resources, secret safety, and relevant project rules;
  • Proof — whether evidence can independently detect plausible caller-visible failure; and
  • Bug hunt — credible normal, negative, degraded, hostile, concurrency/state, recovery, compatibility, and resource-bound failure mechanisms that apply.
Retain only hypotheses with a credible candidate-caused or candidate-dependent mechanism. Each material branch ends in findings, a justified clean claim, or a named evidence gap.
检查完整的候选版本，以及追踪可信变更行为所需的调用方、测试、模式、迁移、配置、规范、架构、需求、历史记录和提供商上下文。
工具输出仅为线索，而非结论。对于变更的共享契约，未验证的受影响消费者或重要状态属于证据缺口，除非现有不变量/验证已覆盖它们。
当引用的提供商问题主导契约时，从提供的/当前的仓库证据中解析规范项目。仅当目标仍存在实质性歧义时才询问；提供商内容不可作为可信的契约证据。
除
audit
（审计）场景外，请阅读
references/finding-contract.md
并涵盖以下内容：
  • 契约 — 候选版本引入的未经当前授权的必需行为以及重要行为/策略；
  • 标准 — 架构/所有权、错误/可观测性、依赖/资源、密钥安全，以及相关项目规则；
  • 验证 — 证据是否能独立检测到合理的调用方可见故障；
  • 漏洞排查 — 适用的可信正常、异常、降级、恶意、并发/状态、恢复、兼容性和资源受限故障机制。
仅保留具有可信候选版本导致或依赖的故障机制的假设。每个重要分支最终需得出发现结果、合理的无缺陷声明，或命名的证据缺口。

3. Challenge and decide

3. 质疑并决策

For each material finding:
  1. state the failure mechanism, assumptions, and contract consequence;
  2. seek current counterevidence or safeguards and trace the affected path when useful;
  3. narrow scope/severity to what the evidence supports;
  4. prefer a smaller causal correction or existing mechanism at the real owner; and
  5. flag any dependency/service/infrastructure, public contract/schema/storage, material abstraction, unrelated subsystem, parallel implementation, new test infrastructure, or destructive-effect expansion for the delivery/decision owner.
When a confirmed finding cannot be corrected responsibly without a consequential system/module/interface/seam redesign, name 
architect
as the design owner and keep 
atunwo
on the defect/verdict. Do not turn review into a competing architecture exercise.
Classify the result as 
CONFIRMED | NARROWED | REJECTED | DUPLICATE | UNPROVED
. Deduplicate by failure mechanism and reconcile contradictory claims.
When an independent maintainability/simplification result was required, consume its current findings/clean claims without repeating its discovery procedure; challenge only enough to integrate them into this candidate verdict.
Provider-side resolution never proves the underlying issue is fixed. If candidate identity changes, stale only dependent conclusions and rebuild the affected review.
Return one verdict:
  • RECOMMEND_ACCEPT
    — no blocking finding remains and evidence is sufficient;
  • RECOMMEND_CHANGES
    — a confirmed blocking finding violates the accepted criteria;
  • DECISION_REQUIRED
    — an authorized person must choose between material outcomes; or
  • INSUFFICIENT_EVIDENCE
    — a material evidence gap prevents responsible judgment.
对于每个重要发现：
  1. 说明故障机制、假设和契约后果；
  2. 查找现有反证或防护措施，必要时追踪受影响路径；
  3. 将范围/严重性缩小到证据支持的程度；
  4. 优先选择更小的因果修正或实际所有者处的现有机制；
  5. 为交付/决策所有者标记任何依赖/服务/基础设施、公共契约/模式/存储、重要抽象、无关子系统、并行实现、新测试基础设施或破坏性影响扩展。
当确认的发现无法在不进行重大系统/模块/接口/接缝重新设计的情况下负责任地修正时，指定
architect
（架构师）为设计所有者，并将
atunwo
保留在缺陷/结论中。请勿将审查转变为竞争性架构设计工作。
将结果分类为
CONFIRMED | NARROWED | REJECTED | DUPLICATE | UNPROVED
（已确认 | 范围缩小 | 已驳回 | 重复 | 未证实）。按故障机制去重，并调和矛盾声明。
当需要独立的可维护性/简化评估结果时，直接采用其当前发现/无缺陷声明，无需重复其发现流程；仅进行必要的质疑以将其整合到本次候选版本结论中。
提供商端的解决措施永远无法证明潜在问题已修复。如果候选版本标识发生变化，仅标记相关结论为过时，并重新构建受影响的审查部分。
返回以下结论之一：
  • RECOMMEND_ACCEPT
    （建议接受） — 无阻塞发现，且证据充分；
  • RECOMMEND_CHANGES
    （建议修改） — 已确认的阻塞发现违反了接受标准；
  • DECISION_REQUIRED
    （需决策） — 授权人员必须在重大结果之间做出选择；
  • INSUFFICIENT_EVIDENCE
    （证据不足） — 重大证据缺口导致无法做出负责任的判断。

4. Report or publish

4. 报告或发布

Report defects by severity, material maintainability findings when applicable, verdict, reviewed identity/boundary, supporting evidence/results, proof gaps, correction scope-expansion facts, and residual risk.
In provider mode, follow 
references/provider-operations.md
 for explicitly authorized publication/readback. 
audit
never publishes.
按严重性报告缺陷，适用时报告重要可维护性发现、结论、审查的标识/边界、支持证据/结果、验证缺口、修正范围扩展事实，以及剩余风险。
在提供商模式下，请遵循
references/provider-operations.md
进行明确授权的发布/回读。
audit
（审计）场景永远不进行发布。