issue

issue — 愿望变成能判真假的条目

产物是一条 GitHub issue，其 body 按 assets/issue_template.md 的段落序呈现（这是产物序—— 第 5 格——出口可检，不是流程）。本文件写：issue 在世界里是什么、什么算写对、原语与出口、 建之前的门。怎么问、怎么组织材料是你的份额。

缺口（Judgment + Capability + Control）

deletion 测试：撤掉本 skill，引擎会把需求原文当 body 直接建 issue——"让搜索更快""把审核做对"。 这样的 issue 任何实现都能"通过"，下游 done_when 没有源头，review 判"越界"没有基准。缺的是 判据（可证伪长什么样）、原语（verify_issue.py 把判据的机械半边编译掉）、门 （建 issue 是公开动作：先给人看）。

世界（Σ）

• issue 是 TASK 的雏形，不是契约本身。 契约（done_when.yaml v2）由 /acceptance-spec 或 /sdlc 从这里的 AC 内联生成；issue 里的 AC 已经是 v2 形状，所以两边不会漂移。
• 三种入口，同一模板：feature（需求）、bug（复现 + 期望 + 实际，AC 就是"复现不再 发生"+ 回归守卫）、escape（合入后发现的缺陷：多一段"归因层 / 为什么该层的门没拦住"， 同时追加到 escape-defects.md——它是世界层唯一的外部校准源）。
• 两条轨道。 语义份额 × 变化率高、实现原语难度低 → PSL 轨（先 /psl 建世界 → G1 人签， 再回来建 issue）；确定性主导 → TASK 轨直接建。混合需求只对体验性内核走 PSL。速判：把需求 交给不了解产品的工程师照字面做，会不会做出"技术正确、产品错误"的东西？会 → PSL。 客观触发：--dos dos.yaml 时，依赖 DOS: 字段里出现 dos.yaml 解析不了的概念 → 强制 PSL 轨（脚本判，不靠自评）。详见 references/dual-track.md。
• 范围段四项（做 / 不做 / 硬约束 / 成功度量）是人写的："做到哪儿为止"agent 推不出来。 你可以起草，但每项都要让用户确认或改。
• 假设台账：澄清最多 3 轮；答不上来的承重槽不默认填，写进台账：假设 · 绑定的 REQ/AC · 风险 · 到期验证点（哪个 AC 或哪道门验证它）。超时不是失败，是带风险签字继续。
• 关于用户的 Σ："快一点""稳定""大部分"是日常语言，不是判据——把它翻译成数字时，数字 的来源要么是用户给的、要么是 SLO/KPI、要么是一次真实失败；没有来源就 needs_threshold_source 标出来问，不编。

判据（φ）：什么算写对了

• 可证伪或不进：AC 的 expect / statement 里出现模糊量词（快 / 慢 / 稳定 / 大部分 / 合理 / 友好 / fast / reliable / most / better…）而没有数字阈值 → 不是验收条件。
• happy 带 unhappy 孪生：每条事件型 AC（"当 X 时系统应 Y"）配一条 unwanted（"当 <边界 / 恶意 / 失败输入> 时系统应 <拒绝 / 降级 / 报错>"）。未定义的失败语义正是被钻的缝。
• AC v2 形状：kind: mechanical 必有 observe（route / cli / ui data-test / db_field / event）
  • given + expect；kind: human 必有 statement + judge ∈ {product, design, tech} + evidence ∈ {checklist, demo}。详见 references/acceptance-shape.md。
• observe 是观察边界，不是实现结构：出现 src/…、.ts/.py/… 文件名、函数名 → 拒（契约不该 规定实现结构；文件级存在性下放到任务卡）。
• 范围四项非空；轨道已判定（psl | task）；依赖 DOS 字段存在（可为 none，但要写）。
• bug 类：复现步骤 ≥ 1 条、期望 vs 实际都在、至少一条 AC 是回归守卫。
• escape 类：归因层 ∈ {card, plan, task, ontology, world} + "为什么该层的门没拦住"一句。
• 残差（机器不判，路由到人）：这些 AC 是不是这次最窄的可证伪条件；阈值是否反映 KPI 而非 空气；unhappy 孪生盖的是不是对的边。脚本给 needs_semantic_review，不裁决。