Default to passing. Your starting assumption should be that a criterion passes. Only fail it when you can point to a specific, concrete problem that would cause a developer to build the wrong thing or be unable to verify their work. "This could be more detailed" is an optional improvement, not a failure.
Redundant implementation ACs: If a ticket has a mix of user-facing ACs and one implementation-detail AC (like "saved to the database"), the ticket still passes criteria 4 (user-verifiable). Note the redundant AC as an optional cleanup in your assessment, but do not fail the criterion. Only fail criterion 4 when the ticket has NO user-verifiable ACs.
Borderline ACs: If an AC communicates the expected behavior clearly enough that a developer would know what to build, it passes criteria 1 and 3 -- even if the wording is informal or could be more precise. "Dragging changes order in the UI" is clear. "Results update correctly" is not (what does "correctly" mean?).
Infrastructure + user value: If a ticket combines infrastructure work with a user-facing deliverable, it passes criterion 5.
Implied data models: If the ticket doesn't explicitly say "create a new model" but the feature clearly requires one (e.g., "users can leave comments on tasks" implies a Comment model), flag the missing data model definition under criterion 6.
Relationships vs. new models: Adding a foreign key to establish a relationship between existing models (e.g.,
on tasks) does NOT trigger criterion 6. The criterion is about new entities with user-facing fields that need form validation, not about database-level relationship plumbing.
Artificial splits: If a ticket references another ticket for essential details (e.g., "Status values are defined in TICKET-4"), flag this under criterion 2. The ticket should be self-contained or explicitly declare the dependency.
Nearly Ready threshold: Use this when the ticket fails exactly 1 criterion and the fix is small (< 30 minutes of refinement). Two or more failing criteria means Not Ready, even if each fix is individually small.
默认通过：初始假设是标准通过。仅当能指出具体、明确的问题（会导致开发人员构建错误功能或无法验证工作成果）时，才判定不通过。“此处可更详细”属于可选优化建议，而非不通过理由。
冗余的实现类验收标准：若工单混合了面向用户的验收标准和一项实现细节类验收标准（如“保存到数据库”），工单仍通过标准4（可通过UI由用户验证）。在评审中注明冗余的验收标准为可选清理项，但不要判定标准不通过。仅当工单没有任何可由用户验证的验收标准时，才判定标准4不通过。
边界验收标准：只要验收标准能清晰传达预期行为，让开发人员知道要构建什么，就通过标准1和3——即使表述非正式或可更精确。“拖拽可更改UI中的排序”是清晰的；“结果会正确更新”则不清晰（“正确”指什么？）。
基础设施+用户价值：若工单结合了基础设施工作和面向用户的交付内容，则通过标准5。
隐含的数据模型：若工单未明确说明“创建新模型”，但功能显然需要新模型（例如“用户可在任务下发表评论”隐含Comment模型），则在标准6下标记缺失的数据模型定义。
关联 vs 新模型：添加外键以建立现有模型间的关联（如任务表中的
）不会触发标准6。此标准关注的是带有面向用户字段（需要表单验证）的新实体，而非数据库层面的关联配置。
人为拆分：若工单引用其他工单获取关键细节（例如“状态值定义在TICKET-4中”），则在标准2下标记此问题。工单应独立完整，或明确声明依赖关系。
接近就绪的阈值：当工单仅未通过1项标准且修复工作耗时短（<30分钟）时，使用此结论。即使每个修复都很简单，若未通过2项及以上标准，仍判定为未就绪。