game-audit-workflow

name	game-audit-workflow
description	BoardGame 规则审计与证据链流程。用于规则、卡牌、技能、状态、交互的描述-实现对照，以及审计报告和测试证据。

全游戏审计流程（Game Audit Workflow）

概览

本技能用于所有游戏的审计工作：从权威规则/图片/说明出发，对实现做全链路对照，并按 D 维度库输出可复查审计证据（含测试/截图链路）。

必读权威维度索引：docs/ai-rules/testing-audit-dimensions.md；按命中维度再打开对应主题分卷。

• 审计入口与证据分层读：docs/ai-rules/testing-audit.md。
• fail-close、全面审计完成定义、交互入口语义矩阵和技能完整流程矩阵读：docs/ai-rules/testing-audit-core-principles.md。
• 需要时可先打开本技能 references：references/dimensions.md（索引/提示）。

默认执行口径（强制）

• 审计不是录入，默认不回卡图（强制）：审计阶段的默认输入是当前项目里已经存在的规则文档、配置、实现、测试、evidence、已建立的数据合同或用户当轮明确提供的材料；不得把“继续审计”解释成重新读图、重新 OCR、重新查 Wiki、重新抄文本包或重新录入数据。只有用户当轮明确要求“录入/复核录入/核图/核索引”，或当前任务本身就是新增数据录入，才进入数据录入 workflow。
• 先查已有录入合同，不得默认判“没录入”（强制）：当用户质疑数据是否已录入，或审计发现规则原文、对象归属、能力描述存在缺口时，第一动作必须是在当前仓库既有录入合同、规则原文矩阵、source map、crop manifest、evidence 和状态文件里检索该对象；只有确认这些入口都没有对应记录，才允许说“未找到录入”。若找到的是 blocked/disputed/待建合同，结论必须写成“已有录入入口但合同未锁定/归属未裁定”，不得说成“用户没录入数据”或“需要重新录入”。
• 中文录入优先中文汇报（强制）：若录入合同、卡图、i18n、用户截图或用户故事里的对象名/能力名/规则描述是中文，审计和修复汇报必须优先展示中文对象名、中文能力名和中文规则描述/合同原文；英文官方名、英文原文、能力 id、代码标识只作为附证或定位补充。禁止只给英文原文、英文能力名或代码 id，让用户自己反推中文能力。
• 原文列必须填原文，不得用状态句顶替（强制）：凡表格列名包含“规则原文 / 合同原文 / 中文规则描述 / 能力描述”，该单元格只能填已录入的逐字原文或明确写“未找到原文记录”。不得填“已有录入入口”“合同未锁定”“对象归属未裁定”“待裁定候选线索”“规则原文/归属未锁定”这类状态句来冒充原文。若原文未找到，必须另列“已查入口/合同状态/下一步”，把状态和原文分开。
• 审计发现来源问题只能登记缺口，不得现场补录入（强制）：如果审计中发现规则来源不足、对象归属不清、配置与已有证据冲突，只能把该对象标成 blocked/disputed 并写清缺的是哪一类证据；不得在审计流程里临时查 Wiki、网页资料、在线文本包、旧脚本 bundle 或第三方数据库来补成“权威结论”，也不得直接因此改机制代码。
• 录入来源优先级只属于录入阶段（强制）：本地清晰卡图、完整单对象图、用户截图、在线文本包、Wiki、网页文本、OCR、翻译文案、实现字段、旧测试和代码注释之间的优先级裁定，是数据录入/合同建立阶段的事情；审计阶段不得重新排序这些来源。审计只能消费已经落地的合同/证据；没有合同就标缺口，不把卡图读取变成审计必经步骤。
• 已有证据先于新增真相源（强制）：当对象已有 locked、实现矩阵、测试证据或历史 evidence 时，普通续跑先消费这些现有材料进入实现对照、真实入口、负向断言、回放/重复消费和 L3/L4 补证。只有能点名具体缺失字段、冲突对象或用户要求复核，才允许单独开录入复核任务；不得用“数据录入可能不扎实”作为泛化理由倒退阶段。
• 图片/子代理只按当前需求返回结论（强制）：审计中需要读图、OCR 或让子代理看图时，交给它的是当前业务需求里依赖图片回答的那一部分，不是让它接管整轮任务。若需求是录入，返回原文、子句、结构化字段和合同状态；若需求是验收或对比，返回是否满足用户预期、失败点和最小证据。不得把图片读取结果写成过程文档，也不得让子代理产出泛泛缺口清单，除非当前需求本身就是制作缺口清单。
• 普通续跑顺序（强制）：当用户说“继续”“更新后继续”“数据录入要做好”时，先读当前 evidence/矩阵/状态文件确定现有状态；若对象已有可消费证据，就继续实现审计，不重读图片、不 OCR、不重新录入。若证据缺失或冲突，只写明缺口并停在 blocked/disputed，等待明确进入录入复核；不能把缺口处理伪装成审计继续。
• 图片链路只能由录入任务触发（强制）：safe-image-reading、atlas 裁图、OCR、图片子代理、卡图逐字读取，只能在数据录入/素材核对/用户明确要求核图时触发；普通机制审计不得主动启动这些链路。
• 修复汇报必须同时附规则原文和现有实现（强制）：凡修复、候选修复、撤销修复或降级某个卡牌/技能/token/状态能力，最终汇报和 evidence 必须同时写清：中文对象名、代码标识、能力中文名、能力 id、中文规则描述/已消费合同原文、必要的英文官方原文附证、现有实现行为、这次改了什么、当前状态（已证实修复/候选改动/disputed/blocked）和验证证据。禁止用“现有实现描述”替代规则原文；若规则原文尚未找到，原文列必须写“未找到原文记录”，并把合同状态单独标为候选或 disputed，不得称为已证实修复。
• 合同状态变更必须回写 evidence（强制）：任何对象从 blocked 转 locked、从 locked 降级为 disputed，或从待建合同进入实现审计，都必须写入 evidence/<gameId>/ 的审计文档；临时矩阵可以辅助，但不能替代正式 evidence。
• 高风险对象先过 fail-close 审计门禁（强制）：凡对象涉及 phase/阶段推进、pending/continuation、共享伤害链、共享状态/token 消费链、选择支付/拒绝、来源例外、攻击后续结算，正式判定“已审过/已收口”前，必须先逐项回答下面四问；缺任一项，默认继续审，不得收口：
  1. 最终权威状态问：这条对象最终要落到什么权威状态，证据是 HP/资源/token/区域/阶段/final state 哪一项？若当前只看到 prompt/overlay/pending/sourceAbilityId/currentChoice 之类中间态，只能算命中了流程中段，不能算完成。
  2. 流程收口问：这次交互或结算结束后，phase/queue/interaction/pending/continuation 是否按规则收口？必须至少补 1 条负向断言，明确证明“不会误跳阶段 / 不会残留 pending / 不会卡在 halt / 不会吞后续链”中的至少一项。
  3. 共享链来源问：若效果进入 shared helper / shared resolver / shared consumer，必须写清“谁授予、谁持有、谁消费、谁清理”，并证明“缺少该来源时不会误生效”。只看最终数值对了，不算通过。
  4. 来源例外问：若该对象属于共享家族但规则里存在特定来源、特定时机或特定目标例外，必须单列“这个来源不应被家族共性自动外推”的断言；没有这条断言，不得判通过。
• 审计默认就是全量审计当前范围：用户或文档只说“审计 / 补审 / 重审 / 收口审计”时，默认含义是把当前明确范围内的对象、子句、共享链路和适用维度做完整审计，而不是只做抽样、代表链或局部核对。若实际只做专项或抽样，必须显式写明“专项审计 / 抽样审计 / L1-L2 静态审计”。
• “全面审计”具体做什么必须服从审计文档，不得口头缩写：只要任务、evidence 标题或对外汇报里用了“审计 / 全面审计 / 深入审计 / 收口审计 / 做到底 / 已审计完成”，就必须以 docs/ai-rules/testing-audit.md、docs/ai-rules/testing-audit-core-principles.md、docs/ai-rules/testing-audit-dimensions.md 和 docs/ai-rules/audit-evidence-template.md 作为动作清单真相源；执行者不得自行发明“链审计”“代表链差不多看过了”“我这轮主要补了几条测试所以算全面审计”之类缩写口径来替代对象全集、子句矩阵、D 维度、L1-L4、共享链判等和旧结论回写。
• 漏审可机器发现时必须补脚本（强制）：如果本轮发现的漏审点可以由 evidence 结构提前暴露，例如缺全面审计自检表、缺对象全集、缺 C1/C2 规则子句、缺实现入口、缺 L0-L4、缺 D 维度、缺最终状态、缺负向断言、缺真实入口或旧结论未回写，则不能只更新文档和当前 bug。必须同步补 scripts/verify/audit-evidence-completeness.mjs 或同级机器门禁，并在审计后用本轮 evidence 复跑 npm run audit:evidence:selfcheck -- <evidence 文件>；否则只能汇报“规则已补，但审计后自检未补”，不得说防再犯已完成。该自检不默认阻塞发布。
• 房间/场地效果必须作为独立审计对象（强制）：当当前范围包含房间、地图格、区域、场地、事件触发点或等价非卡牌对象时，审计清单不得只列空间数据、门位、朝向、楼层、图集帧或可渲染状态；凡对象带有规则效果，必须单独列“房间/场地效果”矩阵，逐项覆盖触发时机、目标、掷骰/支付、状态写入、持续时间、清理、负向断言和最终玩家可见结果。
• 卡牌审计必须显式包含具体效果实现（强制）：当当前范围包含物品、预兆、事件、行动牌、装备牌、状态牌或等价牌对象时，审计矩阵必须在同一对象下同时列出“对象真相/牌堆归属”和“具体效果实现”。前者用于确认审的是正确对象，后者才证明规则生效；只证明牌名、正面图、atlas 格位、抽取顺序、持有区渲染、数量不重复，不得替代该对象的效果实现维度。
• 每回合一次按钮必须审使用后 UI 状态（强制）：当对象存在“每回合一次 / once per turn / usesPerTurn”且通过按钮或按钮后目标选择发动时，审计证据必须覆盖首次效果、使用次数/资源写入、使用后按钮隐藏或禁用、重复按钮命令不再打开选择与不二次结算。只证明第一次效果落地，不得判该按钮链路已收口。
• 系统交互必须审真实 UI 可见入口（强制）：当实现创建 sys.interaction.current、simple-choice、prompt、状态横幅或等价交互时，不能只把系统状态存在当成 L3 证据。必须继续证明真实 Board/PromptOverlay/StatusBanners/手牌区/棋盘区显示了对应按钮、候选或高亮，并且点击提交的是同一份 optionId/value；缺这条只能写“领域交互已创建”，不得写 UI 链路已收口。
• 图片读取只服务需求，不作为交付物（强制）：当卡图、房间图、规则页截图或其它图片素材是录入/审计真相源时，可以把图片文件直接交给子代理做视觉读取或校验；交给子代理的是业务需求，不是单独看图。需求交接只写当前要补的数据或要验证的判断，例如“从这张卡图录入牌名、规则文本、子句和 locked 状态”或“校验这张房间图是否满足已锁合同”。子代理默认只返回需求结果：录入类返回详细数据；校验类返回是否满足预期、差异和阻塞字段。不得要求子代理单独汇报过程信息；若无法完成，只返回阻塞的具体字段、判断点或交付点。
• 教程/新手引导默认要对齐真实游玩交互（强制）：只要当前范围包含 tutorial / 新手引导 / 教学步骤 / onboarding，审计时必须把每一步提示的“点击对象/高亮目标/按钮文案”与正式牌桌或正式流程里的真实交互承接点逐项对照。禁止出现“正式游玩点按钮，教程却让人点牌堆”“正式游玩点手牌，教程却高亮说明面板”这类分叉；也不得因为底层命令相同，就把教程里错误的点击对象判成通过。
• 教程默认还要审“有没有真正教会玩家”（强制）：只要当前范围包含 tutorial / 新手引导 / 教学步骤 / onboarding，除了交互一致，还必须同步阅读 docs/ai-rules/tutorial-design.md，逐项核对：是否先讲赢法、是否解释行动收益、是否有真实案例、是否让玩家看到计分或等价结果反馈。只能证明“教程能走通/按钮点对了”，不得判为教程合格。
• 教程审计结论写回通用层前，必须先过“未来很多游戏”自检（强制）：如果本轮准备把教程审计结论回写到项目通用 skill、docs/ai-rules/** 或其它通用层，必须先确认这条结论约束的是“怎么识别教程问题”，而不是在替当前这个游戏预写“哪章合并、哪章先教、哪条路线更适合示范”。离开当前游戏就不成立的内容，只能下沉到该游戏专项文档、覆盖矩阵或教程实现，不得借“审计经验”之名抬升成通用规则。
• 教程审计一旦开始抽象结论，就立刻做“未来很多游戏”分层，不要事后补判（强制）：只要审计结论已经开始讨论“教程结构该怎么收”“哪类章节应该合并”“哪种教学顺序更合理”，默认当场先判断这到底是跨游戏判断方法，还是当前游戏的专项答案。后者只能落到该游戏专项文档、覆盖矩阵或实现，不能先写进通用审计规则再回头解释。
• 教程像规则书或按钮说明书时必须直接打回（强制）：只要当前范围包含 tutorial / 新手引导 / 教学步骤 / onboarding，如果文案主要在复述完整规则、堆术语、解释按钮顺序，或离开长段文案后玩家仍不知道为什么这么做，审计结论必须直接判为“不合格/需重写教学结构”；不得因为步骤能推进、断言能通过，就降格判成“教程基本可用”。
• 教程不得靠长段说教替玩家下判断（强制）：只要当前范围包含 tutorial / 新手引导 / 教学步骤 / onboarding，审计时必须额外核对教程关键步骤是否把主要判断交给了真实局面本身，而不是靠长段文案直接告诉玩家“现在该拿哪张/该丢哪张”。若去掉这段长说明后，牌面自身无法解释强弱，默认判为案例设计缺陷，不得用“文案已经解释清楚了”收口。
• 教程里的“判断提示”和“操作提示”不得混成一步（强制）：只要当前范围包含 tutorial / 新手引导 / 教学步骤 / onboarding，必须额外核对：说明步是不是只在提醒玩家该看什么，动作步是不是只在教玩家点哪里。若一个 requireAction 步同时在替玩家下结论、解释收益、又指挥点击对象，默认判为教学结构失焦，需要拆步或重写。
• 教程与正式流程凡涉及一级行动顺序时，必须先审“交互合同”而不是先改文案（强制）：只要当前范围包含 tutorial / 新手引导 / 教学步骤 / onboarding，并且争议涉及“先选行动还是先选目标”“先点按钮还是先点地图/卡牌”“横幅是不是交互入口”“为什么教程从某个地区起手”，审计必须先产出一张 一级交互审查表。至少写清：规则书回合骨架、正式 UI 当前一级行动入口、后续目标/地区/支付入口、提示 UI 与真实交互载体的区别，以及教程是否把它们教反。没有这张表，不得进入教程实现或给出“教程已修好”的结论。
• 一级交互不得按当前显眼入口抽样（强制）：只要当前范围在审“基础回合 / 一级行动 / 主循环入口 / 所有交互”，一级交互审查表 就必须先按规则或权威真相源列出同层一级行动的完整全集，再逐项映射到当前 UI。不得只因为某几个入口当前更显眼、案例正好走到、E2E 更容易拍，就跳过同层别的一级入口，例如 打牌、升级军备、势力行动、轮盘行动、结束、公开区拿牌、桌面对象直点 等。
• 若正式 UI 与规则顺序冲突，不得只改教程粉饰（强制）：只要审计结论已经证明“规则是先选一级行动，当前实现或文案却把后续目标选择提前成了首入口”，必须把它明确记为正式流程实现问题、交互合同问题或两者兼有；不得只重写教程文案，把正式流程的问题留在运行态里继续误导玩家。
• 默认预选不等于玩家已决策（强制）：只要正式 UI 在某阶段一进入就带有默认选中的地区、卡牌、轮盘项、行动项或候选目标，审计必须明确区分三层语义：默认预选、真实可点击对象、玩家已确认选择。不得把默认预选写成“玩家先选了这里”，也不得因为画面上已有高亮，就跳过“这一步真正承接点击的是谁”的核对。
• 默认聚焦不得伪装成已确认（强制）：只要某个高亮只是默认焦点、默认候选或系统便捷起点，而玩家还没实际点击、确认、支付或进入执行阶段，审计就必须把它标成“弱聚焦”，不能接受 UI 用“已锁定 / 当前执行 / 强确认描边 / 强确认底色”去呈现它。若视觉层把默认焦点和已确认态混成一个样式，直接判为交互合同错误。
• 后续目标阶段不得反写已锁来源对象（强制）：只要某条交互已经完成了一级动作决策，并且真实运行态已经锁定 来源区 / 出发对象 / 支付对象 / 已确认主动作对象，后续地图点击、列表重聚焦、逻辑区切换或默认高亮变化都只能改变“当前焦点/当前候选”，不能反向改写这份已锁来源。审计时必须单列：当前焦点对象、已锁来源对象、真实提交对象；三者混成一个字段或一个 UI 语义时，直接判为交互合同错误。
• 后续步骤摘要不得冒充一级入口（强制）：只要当前已经进入 支付 / 弃牌 / 二级目标 / 地图目标 / 战后 / 年度结算 这类后续步骤，任何不承接点击的摘要卡、步骤标题、状态条、右侧说明、横幅文案，都不得再把 默认焦点 / 默认候选 / 已锁来源区 / 当前候选区 包装成“现在第一步先点它/从这里开始/进攻这里/查看这里”。这类文案只能说明当前动作层、当前步骤目的、剩余次数、结果约束；若一个非点击摘要同时承担了“点击指令 + 地区主语 + 步骤主语”，直接判为交互合同错误。
• 主要交互默认要做全清单审查（强制）：用户要求“所有交互都要审查”“继续收口交互合同”“教程和正式流程一起重审”时，默认不是抽两条代表链，而是至少列出：开局公共推进、一级行动入口、支付/弃牌、二级目标选择、地图目标选择、待结算战斗、战后选择、年度/阶段结算。任一类目未落表，不得声称“主要交互已审完”。
• 基础回合/端到端默认先补“首回合动作顺序表”（强制）：当用户要求“基础回合”“完整回合”“基本流程端到端”“看出这个游戏怎么运作”时，除了一级交互审查表，还必须先补一张 首回合动作顺序表。至少写清：规则书从正式主入口开始要求玩家依次决定什么、当前正式局每一步首先暴露的真实对象、哪些属于一级动作、哪些只是后续目标/支付/确认、默认预选在该步只是弱聚焦还是已经进入正式确认。没补这张表前，不得把任何教程开场步骤或正式流程入口判成正确。
• 首教动作必须先落在当前玩家真实可选层（强制）：若某个阶段只是强制公共推进、低信息前置、纯进入壳层或系统自动过场，而当前玩家尚未在这里做会影响后续理解的真实判断，审计时必须把它标成“经过点/前置层”，不能把它误判成首个正式决策入口。只要下一层已经是当前玩家真正有选择权的一级动作层，教程首个主操作和正式主提示都必须回到这一层的真实承接物。
• 第一步入口不得靠最后成功点击倒推（强制）：只要当前争议涉及“第一步该点哪里”“为什么会被教成先选地区”“横幅是不是交互”“按钮和地图谁是主入口”“默认高亮是不是已选”，就必须再补一张 当前屏幕可见可点对象盘点。必须把该阶段玩家第一眼能看到并可能尝试点击的对象逐项标成 一级动作入口 / 二级目标 / 支付对象 / 确认控件 / 提示UI / 非当前步骤对象；不得只按最后成功点击的那个对象，反推这一步的主入口。
• 玩家文案不得用作者旁白腔替代规则语义（强制）：教程文案、正式进行页短提示、步骤标题、摘要卡若主要依赖“这一步 / 下一步 / 这里 / 这次 / 现在先”来串步骤，而没有点明规则动作、对象或结果，审计必须直接记为文案失真。短提示可以说明阶段，但不能用流程旁白腔代替规则概念。
• 压结构不得静默删覆盖（强制）：只要本轮在合并教程章节、删除隐藏续章、收口审计目录、把多条链并成一条基础流程，审计必须先补一张“覆盖差异表”，写清旧覆盖点、旧截图链、旧正式入口证明在新结构里的对应落点。若任何核心规则点、真实交互链或正式入口证明被删掉而未被等价替代，结论必须明确降级为“覆盖退化/仍有缺口”，不得继续使用“更精炼/更收口”口径。
• 提示横幅与交互入口必须分列审计（强制）：顶部横幅、步骤卡、状态条、地图短提示只要不承接点击，就必须在审计表里单列为“提示 UI”；不得和按钮、地图区域、卡牌本体、轮盘格这类真实承接物混成一列。
• 实施前映射/脚本草案不是运行态证据（强制）：implementation-map / 覆盖矩阵 / 教程脚本草案 / 目录重组草案 / 实施前映射 只能证明“计划怎么改”，不能证明“当前正式局已经这样工作”。只要结论里出现“正式进行页已有这个入口/这一章已实现/新游戏可收工”，证据必须来自当前 worktree 的正式源码、当前运行态截图或真实 E2E，而不是计划文档。
• 运行态专项审计真相源优先于计划文档（强制）：如果当前游戏同时存在 primary-interaction-audit / formal-flow-audit / runtime-closeout-audit 这类明确面向运行态的专项审计文档，以及 implementation-map / 覆盖矩阵 / 教程脚本草案 这类计划文档，那么凡是“正式局当前有没有这个入口”“当前还能不能报收工”的判断，一律以运行态审计文档为准；计划文档只能作为待实施输入，不得反压运行态审计结论。
• 运行态专项审计真相源一旦被代码改动打旧，必须先回写（强制）：如果本轮已经修改了正式入口、交互承接物、提示文案、默认聚焦语义或教程/正式局一致性，而现有 primary-interaction-audit / formal-flow-audit / runtime-closeout-audit 仍保留旧状态，默认动作必须是先把这份运行态审计文档回写到当前真相，再继续用它指导后续实现、教程判断或收工结论；不得一边知道文档已失真，一边继续引用里面的旧句子推进任务。
• 入口状态不得被过时文档二值化（强制）：如果正式局已经对部分真实对象接上了一级入口、但仍受低保真对象、覆盖面或真相源缺口限制，审计状态必须写成“局部真实可用 / 仅限已识别对象 / 仍有正式缺口”这类精确状态；不得继续沿用“当前无正式入口”“手牌完全不承接”这类已经被当前代码证伪的旧口径。
• 正式进行页一级入口必须单独核对（强制）：当用户要求“所有交互都要审查”“新游戏收工”“给我一个能看出游戏怎么运作的基本流程”时，除了教程表和交互清单，还必须再补一张“正式进行页一级入口核对表”，逐项把规则书同层一级动作标成 真实可用 / 抽象替代 / 教程注入专供 / 尚未实现。没补这张表前，不得用“正式流程已具备”口径。
• 审查表不是完成证据（强制）：一级交互审查表 / 首回合动作顺序表 / 当前屏幕可见可点对象盘点 / 正式进行页一级入口核对表 / 主要交互清单表 只能证明“缺口被锁定”，不能单独证明“问题已解决”。只要表里仍有 抽象替代 / 尚未实现 / 文案误导顺序 / 提示 UI 冒充交互 / 默认聚焦语义错误 / 教程与正式局不一致，执行者必须继续回到当前源码、当前门禁和当前截图链处理；不得停在审计文档或口头结论。
• 更新 skill 后必须继续做运行态（强制）：当用户明确要求“skill 先更新一下再继续”“不要再犯低级错误”“所有交互都要审查”，补 skill 只是防再犯动作，不是本轮主要交付。更新完通用 skill 后，必须立刻继续当前游戏的运行态审查、实现修正和验证；不得把“skill 已更新”当成本轮收口理由。
• 全交互清单必须从运行态全集反推，不得从截图抽样倒推（强制）：当用户要求“所有交互都要审查”时，交互全集必须同时从 规则书同层动作 / 当前状态字段 / command 或 event / builder / reducer / 当前 E2E 入口 反查出来；截图只能验证已列出的行，不能用几张图反推出“主要交互只有这些”。若没有逐项覆盖这些运行态来源，不得说“所有交互已审完”。
• 每个交互行必须点名真实承接物和提示 UI（强制）：全交互表的每一行都必须分别写出“真正消费点击/选择的对象”和“只是提示的 UI”。如果这一行只能写出横幅、步骤卡、摘要、状态条，却说不出按钮、卡牌、地图区域、轮盘格、列表项或系统交互入口，默认说明承接物未锁定，不能实施或收口。
• 全交互审查必须分流到执行队列（强制）：主要交互清单、一级入口表或当前屏幕可点对象盘点完成后，必须逐行标成 可立即真修 / 需要建模或真相源补齐 / 明确暂不处理且说明原因。可立即真修 行必须继续落到源码、语言包、测试或截图链；需要建模或真相源补齐 行必须点名缺的是对象真相、素材合同、状态字段拆分、交互承接物还是阶段收口。没有这层分流，不得说“所有交互已审完”。
• 同层一级动作有缺口时不得拿示范链顶交（强制）：只要正式进行页一级入口核对表里仍存在 抽象替代 / 教程注入专供 / 尚未实现 的同层一级动作，就不得把某条教程示范链、某个隐藏续章、某个默认预选路线或某个局部 E2E，包装成“基础流程完整”“正式局已经能看出怎么运作”或“新游戏已收工”。审计结论必须同时保留这些正式入口缺口，并继续回到真实承接物实现。
• 低保真或错素材对象不得冒充正式入口（强制）：如果某个一级动作当前依赖的可见对象仍是 低保真预览 / 错 atlas / 混入别类对象 / 没有规则级身份，审计状态只能写成 低保真替代 / 局部真实可用 / 正式缺口，不得记成“正式入口已具备”。
• 对象集合混类必须直接打回真相源（强制）：这里的“混入别类对象”包括但不限于：人物牌、纪年卡、剧本卡、牌背、帮助卡、占位壳，或其它不属于该一级动作对象集合的可见对象。一旦命中，默认动作不是补文案或补高亮，而是先回到 素材清单 / atlas 裁切合同 / cardDefId 真相表 / 规则级对象映射 锁真相。
• 局部 seam 不能越权外推正式入口（强制）：就算当前代码已经让少量已识别对象、少量注入态对象或某个抽象按钮链能走通，也只能证明“局部真实可用”；在同类对象全集仍未完成规则级识别前，不得把这条 seam 外推成“该一级动作已正式实现”。
• 截图验收必须真的开图（强制）：只要当前结论依赖“关键截图看起来是否达标”“图里是否仍有重复提示/错误高亮/错误交互载体”，执行者就必须实际打开当前 worktree 下的关键截图逐张核图；只报截图路径、文件名或“E2E 通过”都不算完成。
• 用户明确说‘打开图/看图’时不得只报路径（强制）：当用户直接要求打开某张图、看图确认或逐图说明点击点位时，审计动作必须包含实际开图；不得把“我已经有截图绝对路径”当成等价交付。
• 新游戏“收工/完成”不得只凭教程或局部链路宣布（强制）：如果用户目标已经升级为“新游戏收工”“要一个能看出游戏怎么运作的基本流程”“教程证明这个游戏已具备正式玩法”，审计必须同时给出两层结论：① 教程/示范链是否成立；② 正式进行页是否已经具备同口径的一级入口、真实承接物和结果反馈。只要其中任一层仍依赖注入态、隐藏技术入口、抽象按钮替代、低保真对象替代或局部 E2E 代表链，就只能判为“局部流程已验证，正式流程仍缺口”，不得使用“新游戏完成/收工”口径。
• 正式规则仍是固定序列或占位实现时不得判完成（强制）：只要当前游戏的正式局内仍存在 固定顺序房间池 / 固定顺序牌堆 / 固定遭遇池 / 假随机结果 / 占位房间对象 / 占位卡牌对象 / 教程注入专供入口 / 调试入口替代正式入口 这类实现，审计结论必须明确降级为“正式规则未完成”。即便教程、截图或代表性 E2E 已跑通，也不得写成“游戏完成 / 第一剧本完成 / 可归档”。
• “测试固定”与“正式逻辑固定”必须强制分开写（强制）：如果某条链路为了 E2E 稳定而固定随机种子、固定首抽、固定布局，审计文档必须单列说明这是测试夹具；并额外核对正式局内同一规则对象是否仍是固定序列。两者若被混写，默认判为结论失真，不得收口。
• 新增批次默认全面审计留档，不再追问：如果任务语义是“新增派系 / 新英雄 / 新角色 / 新对象接入 / 从素材做到可玩”，且用户没有明确把范围缩成“只录入 / 只修一个 bug / 只做静态接入”，则默认交付就包含对象级全面审计 + evidence 留档。不得再反问“要不要补审 / 要不要留档 / 要不要做全面审计”。
• 不能拿局部证据冒充全面审计完成：如果当前只有代表性 E2E、局部截图、局部对象修复、单维度专项复核或少量自动化测试补齐，而没有达到审计文档要求的对象级和批次级收口，结论只能如实降级为“专项审计 / 抽样审计 / 代表性玩法已验证 / 仍有残余范围”，不得继续使用“全面审计完成”口径。
• 发现同维度漏项后必须继续扩审兄弟对象：如果当前审计命中的是共享消费合同、同类技能 family、同类 UI 入口、同类时机或同类资源链的漏项，默认必须把同批兄弟对象一起纳入复审，并同步回写旧 evidence / rule。不得只修用户点名对象后停下，再把“其余对象要不要继续补审”抛回用户。
• 状态/token 家族不能只凭对象级直证收口：如果同一新英雄/新派系里有多个对象写入同一状态/token，或用户反馈集中在某个状态 family，默认必须继续拆出该状态的 写入 seam -> 共享消费者 -> 清理/后续 -> 已验证入口。只证明“多张牌都能写这个状态”不等于状态家族已到 L4；至少要继续查 stack limit / accept-decline / upkeep / passiveTrigger / transfer / cleanup 这些共享消费者。
• 点入口 / 点变体不等于已结算：对真实玩家板槽位、变体 modal、simple-choice、攻击修正或其他交互入口，看到 SELECT_ABILITY、按钮点击或 modal 选择，只能证明对象进入了流程，不能直接算对象级 L3。若真合同是“先建 pendingAttack，再由 ADVANCE_PHASE / Continue / 选择确认收口”，审计必须把这两段都补齐。
• 不可防御必须同时审“声明层 + 共享消费层”：看到 damage(unblockable=true) 或文案写“不可防御”时，不能直接判定收口。还必须反查 isDefendable 的共享来源是 ability/variant tags、choice effect patch、ATTACK_MADE_UNDEFENDABLE 还是其他 seam，并补证据证明真实流程不会误开防御窗口。
• 停止条件只能是收口或用户显式缩范围：只要当前范围内还存在未回写旧结论、未补对象矩阵、未补关键 L3/L4、或未澄清的共享链判等，就不能把任务表述成“已审完”。只有矩阵收口，或用户明确把范围缩小，才允许停止推进。

工作流总览（Workflow-Based）

Step 0：前置检查（必须）

1. 读取根 AGENTS.md（项目级规则）。
2. 明确游戏范围（gameId）、模块范围（卡牌/技能/状态/交互/UI/系统）。
3. 如果当前审计对象属于新增派系 / 新英雄 / 新角色 / 新批次接入，默认必须按对象级全面审计 + evidence 留档 + 批次矩阵收口执行，不能退化成抽样核对或只审用户点名单对象；除非用户当轮明确把范围缩成局部修复/局部录入。对这类任务，不需要再次追问“要不要补审 / 要不要把其他能力一起审 / 要不要留档”。
4. 若已有审计文档：必须回写同一文档（见 Step 5），禁止新建重复审计。

Step 1：权威来源与真相源

1. 明确权威来源：
   • src/games/<gameId>/rule/*.md（规则/录入核对/真相源表）
   • 本地图片/提示板/规则书截图（若用户指定优先级）
2. 图片可判定合同时的职责边界：
   • 只要真相源里有清晰图片、玩家板、棋盘、卡图、图集、布局图，且这些材料能直接回答“对象在哪个槽/区域、哪格是空、哪格 display-only、哪格可交互”，审计必须先读取录入阶段已经建立的可视合同表。
   • 如果合同表不存在、缺字段，或与权威图片矛盾，判定为数据录入缺陷；审计应记录这一缺陷并停止把该对象判为已收口，而不是把“补建合同表”误写成审计本职。
   • 审计仍要直接看图核对合同是否可信，但角色是“复核描述/合同”，不是替代录入建合同。
3. 权威来源优先级（强制）：
   • 用户当前对话给出的卡牌/技能/token 原文（含清晰截图或原文描述） > 卡牌/英雄技能/指示物（token/status）自身的描述文本 > 通用规则文档 > 项目“默认裁定/历史实现”。
   • 若“技能/卡牌/token 描述”与规则文档或代码行为冲突：默认以描述文本为准，并在审计文档写清：
     1. 冲突点（不超过 25 字引用）
     2. 你的裁决（以描述为准的原因）
     3. 对应代码落点与需要补的测试/证据链
   • 这条优先级必须在审计文档的“权威来源清单”里显式写出来，避免后续复盘争议。
4. 特殊游戏规则：
   • smashup：若需校对数据/描述，必须按 scripts/scrape-wiki-with-descriptions.mjs → scripts/final-wiki-code-comparison.mjs 流程执行（除非用户指定以本地图为准）。
5. 记录“权威来源清单”，写入审计文档。

Step 2：全链路对照（D3 强制）

逐项核对：定义 → 注册 → 执行 → 状态 → 验证 → UI → i18n → 测试。

• 定义：卡牌/技能/状态配置
• 注册：registry / customAction handler / 事件定义
• 执行：execute / reducer / systems
• 验证：validate/commandValidation
• UI：渲染/交互/门控逻辑
• i18n：文案一致性
• 测试：已有用例覆盖情况

房间/场地效果审计表（强制）：

• 当对象属于房间、地图格、区域、场地或等价空间对象时，必须补一张 空间对象 -> 规则效果 -> 实现入口 -> 证据等级 表。
• 这张表至少写清：
  1. 对象全集：当前范围内每个房间/场地对象，不能只列已实现或已发现的代表样本
  2. 空间合同：门位、朝向、楼层适用性、连接边、图集帧、背面资源
  3. 效果合同：进入/停留/离开/翻开触发、目标、掷骰或支付、成功/失败分支、状态写入、持续时间、清理
  4. 运行态证据：触发入口、命令/handler、最终状态、玩家可见反馈、至少一条负向断言
  5. 当前状态：已打穿 / 仅空间合同 / 仅资源合同 / 效果未审 / 录入缺合同 / 阻塞
• 没有这张表时，不得把“发现池房间已审计”“房间系统已收口”说成全面审计完成。

卡牌具体效果实现审计表（强制）：

• 当对象属于物品、预兆、事件、行动牌、装备牌、状态牌或等价牌对象时，必须补一张 卡牌对象 -> 文本子句 -> 具体效果实现 -> 证据等级 表。
• 这张表至少写清：
  1. 牌对象全集：当前范围内每张牌，含牌堆、发现池、持有区、弃牌区或一次性事件牌
  2. 对象真相与牌堆归属：卡图、名称、原文、atlas 格位、牌堆归属、抽取/弃置位置
  3. 具体效果实现：使用时机、候选生成、目标、资源消耗、成功/失败分支、弃置/保留/持续、清理与最终权威状态
  4. 运行态证据：UI 入口、命令/handler、状态变化、玩家可见反馈、至少一条负向断言
  5. 当前状态：已打穿 / 仅对象真相 / 仅牌堆归属 / 效果实现未审 / 录入缺合同 / 阻塞
• 没有这张表时，不得把“卡牌已进发现池”“卡图已显示”“持有区能渲染”说成卡牌具体效果实现已审计。

教程交互对齐表（强制）：

• 当对象属于教程/新手引导时，至少补一张 教程提示动作 -> 正式游玩承接点 对照表，逐步写清：
  1. 教程当前让玩家点什么现实对象
  2. 正式游玩这一步真正承接命令的是哪个现实对象
  3. 两者是否一致
  4. 若不一致，差异落在哪个文件（教程 manifest / Board / 文案 / E2E）
• 没做这张表前，不得把“教程能推进到下一步”直接判成“教程正确”。

一级交互审查表（强制）：

• 当对象属于教程/新手引导，且争议触及回合主循环、一级行动、目标地区、支付对象、步骤横幅或主按钮时，至少再补一张 规则骨架 -> 一级行动 -> 二级目标 -> 真实承接物 -> 提示 UI 对照表，逐项写清：
  1. 规则书在这一段先要求玩家决定什么 1.1) 这一段规则书同层一级行动的完整全集有哪些
  2. 当前正式 UI 同时暴露了哪些一级行动
  3. 哪些对象只是后续目标/地区/支付选择，不是一级动作入口
  4. 哪个现实对象真正承接点击或确认
  5. 横幅、步骤卡、状态条里哪些只是提示，不是交互
  6. 哪些是默认预选/默认高亮，哪些才是玩家已确认过的对象
  7. 当前教程或 UI 是否把一级入口和后续目标入口教反
• 没做这张表前，不得把“交互现在能走通”直接判成“玩家已经学对了主流程”。

主要交互清单表（强制）：

• 当用户要求“所有交互都要审查”“整个基础流程都要过一遍”“别再漏一级动作/支付/战后收口”时，必须再补一张 交互类目 -> 进入条件 -> 第一眼入口 -> 真实承接物 -> 后续步骤 -> 当前问题 清单表。
• 这张表至少覆盖：
  1. 开局公共推进
  2. 一级行动入口
  3. 支付/弃牌
  4. 二级目标或来源选择
  5. 地图目标选择
  6. 待结算战斗
  7. 战后/围城/占领
  8. 年度或阶段结算
• 没做这张表前，不得把“教程和正式 UI 都审过了”直接判成已收口。
• 若本轮同时在调整教程结构或删除旧链路，必须再补“覆盖差异表”：
  1. 旧链路/旧章节原先覆盖了什么规则点
  2. 新链路的对应落点是什么
  3. 对应正式局入口当前是真实可用、低保真替代、教程注入专供，还是仍未实现 3.1) 若该入口依赖的可见对象仍是低保真预览、错 atlas、混入别类对象或没有规则级身份，必须单列写成对象真相缺口，不得并入“真实可用”
  4. 哪些覆盖被保留，哪些被降级为缺口
• 没做这张差异表前，不得把“这次只是合并章节/移除重复步骤”当成安全改动。
• 若本轮先完成的是“审查表 / 缺口表 / 规范落点 / skill 补丁”，下一步默认必须把命中的缺口继续翻译成运行态动作：
  1. 命中文案误导：回到正式局上屏文案与日志出口修正
  2. 命中真实交互承接错误：回到当前点击入口与 builder / reducer 修正
  3. 命中默认聚焦与已确认混用：回到视觉语义与状态字段修正
  4. 命中截图与现状不一致：回到真实 E2E / 截图链重跑核图
  5. 命中对象真相缺口：先回到素材合同、atlas 裁切合同或规则级对象映射，不得继续在错对象层上补正式入口结论
• 以上任一未做完，不得把“已经审查过了”包装成完成

首回合动作顺序表（强制）：

• 当用户要求“基础回合 / 完整回合 / 首回合 / 基本流程端到端 / 看出这个游戏怎么运作”时，必须再补一张 规则顺序 -> 当前正式局先暴露对象 -> 动作层级 -> 当前状态 对照表。
• 这张表至少写清：
  1. 规则书从正式主入口开始要求玩家依次决定什么
  2. 当前正式局在每一步先暴露给玩家的真实对象
  3. 这一步的对象属于一级动作、后续目标、支付还是确认
  4. 当前默认预选只是弱聚焦，还是已经进入正式确认
  5. 这一步若被教程写反，究竟是教程问题、正式 UI 问题，还是两者兼有
• 没做这张表前，不得把“基础回合已经讲明白”“端到端已经能看出怎么运作”直接判成通过。

当前屏幕可见可点对象盘点（强制）：

• 当争议涉及“第一步该点哪里”“默认高亮是不是已选”“横幅是不是交互”“按钮和地图谁是主入口”时，必须再补一张 当前对象 -> 玩家第一眼可见性 -> 真实语义 -> 是否当前该点 盘点表。
• 这张表至少写清：
  1. 这一屏玩家第一眼能看到哪些可见可点对象
  2. 每个对象属于 一级动作入口 / 二级目标 / 支付对象 / 确认控件 / 提示UI / 非当前步骤对象 哪一类
  3. 当前默认高亮是不是只属弱聚焦
  4. 玩家此刻真正该点的是谁
  5. 教程或正式 UI 是否把这些对象的层级讲反
• 没做这张表前，不得把任何默认高亮、默认聚焦或案例地区写成这一步的正式第一入口。

正式进行页一级入口核对表（强制）：

• 当用户目标已经升级为“所有交互都要审查 / 新游戏收工 / 端到端证明这个游戏怎么运作”时，必须再补一张 规则书一级动作 -> 当前正式局入口 -> 当前承接物 -> 当前状态 对照表。
• 这张表至少写清：
  1. 规则书同层一级动作完整全集
  2. 当前正式进行页里玩家第一眼能进入这些动作的现实入口
  3. 真正消费点击的对象
  4. 当前状态属于 真实可用 / 抽象替代 / 教程注入专供 / 尚未实现 哪一类
  5. 证据落点必须指向当前 Board.tsx、当前交互 builder、当前截图或当前 E2E
• 不得用 implementation-map / 教程脚本草案 / 覆盖矩阵 代替这张表的运行态证据。

教程教学闭环表（强制）：

• 当对象属于教程/新手引导时，至少再补一张 教学目标 -> 真实案例 -> 结果反馈 对照表，逐步写清：
  1. 这一段在教玩家什么现实目标（赢法 / 回合决策 / 组合收益 / 计分原因）
  2. 用的是哪一个真实局面或真实案例
  3. 玩家执行后看到了什么真实结果（分数变化 / 战力变化 / 控制权变化 / 资源收益）
  4. 若缺任一项，差异落在哪个文件（教程 manifest / 文案 / 棋盘锚点 / E2E）
• 没做这张表前，不得把“教程结束了”直接判成“玩家已经学会了游戏”。

代词/指代消歧（强制，D1/D5/D15/D18 高频漏审点）：

• 当权威描述包含“此/该/那/其/本次/这个/那个/this/that/it”等代词或省略主语时，必须输出一张指代消歧表，并写入审计文档：
  • 原文片段（不超过 25 字）
  • 指代对象裁决（例如：主攻击骰盘第几颗骰 / 奖励骰特写中的骰 / 目标玩家 / 原攻击者）
  • 在代码里的落点（字段/事件/handler）
• 禁止在审计文档里写“应该是…”但不落到“指代对象 + 代码落点 + 证据”。

时机正确性语义核对（强制，D1/D5/D18 高频漏审点）：

• 遇到“当…时 / 每当 / 在…之后 / 直到…为止 / 本回合内 / 结算后 / 关闭后 / 花费/消耗/支付” 等触发语义，必须完成 时机四问：
  1. 触发动作：究竟是哪一个“动作/状态变化”触发（例如：花费资源、结算完成、交互关闭、目标选择确认）。
  2. 触发时点：发生在“打出/宣告时”、还是“后续行为发生时”、还是“结算完成后”。
  3. 消耗发生点：若触发依赖消耗/支付，必须明确“消耗在何时发生”，并在代码里找到对应扣减点。
  4. 范围与持续：仅本次/本回合/持续直到条件满足？是否会“挂载等待”？
• 代码落点必须落在具体 handler / event / reducer，禁止只写“逻辑上应该如此”。
• 常见误审模式：把“依赖消耗/支付/结算后触发”的语义，误实现成“打出即触发/立即消耗/提前结算”。
• 重投/再投语义拆分（强制，D1/D3/D5/D23 高频漏审点）：
  • 遇到“可重掷其中 1 颗 / 可重掷至多 N 颗 / 可重投 1 次 / 可以同一颗掷 2 次 / 奖励骰可再掷”时，必须先拆成两层独立合同：
    1. 总共还能触发几轮重投
    2. 每一轮最多能重投几颗骰子
  • 审计文档必须分别写出真实消费者，不得只写一个抽象“重投上限”：
    • rollLimit：还能再投几轮
    • selectCount：本轮允许选择多少颗骰子
    • maxRerollCount：奖励骰总共还能重投几次
    • rerollDieLimit：像防御重投这类“下一轮至多可重投几颗”的共享校验
  • 禁止只看到 prompt/overlay 打开、rollLimit 提高、或 bonusDiceSettlement 存在，就把“可重掷至多 N 颗”判成已实现；必须继续追到真实 commandValidation / interaction consumption / UI 锁定态。
  • 阶段推进合同补充（强制）：
  • 若对象运行在 offensiveRoll / targetingRoll，并且玩家动作后还存在 pendingAttack、currentChoiceSourceAbilityId、bonus settlement 或其他 continuation，必须继续追到真实 ADVANCE_PHASE / Continue / 选择确认后的收口。
  • 若对象是在 CHOICE_RESOLVED / token 响应后才改写“不可防御 / 目标 / 伤害范围”，必须同时验证“选择前中间态正确”和“选择后共享合同已改写并成功收口”。
• 状态 family 对照补充（强制）：
  • 遇到“多张卡/多条技能都在写同一状态/token”时，必须继续画出一张最小状态矩阵：
    1. 写入 seam：是 direct grantStatus、customAction、choiceResolved、phase hook 还是其它特殊入口
    2. 共享消费者：是哪一层真正消费该状态（stack limit、accept/decline、upkeep、passiveTrigger、cleanup、transfer、damage gate）
    3. 已验证入口：当前哪几条真实入口或 L2/L3 证据已经打穿
    4. 不可外推差异：哪些兄弟入口只是共用写入 helper，哪些才共用完整生命周期
  • 禁止只因为“多个入口都能把状态写上去”就把整个状态 family 判成 L4 或“只差治理尾项”。
• 升级/替换 family 对照补充（强制）：
  • 遇到 replaceAbility、升级牌写槽、双面切换能力集或其它“先替换定义，再由新定义继续运行”的对象时，必须拆成两层：
    1. 替换壳：打牌/翻面/扣费/离手后，abilityLevel、upgradeCardByAbilityId 或能力集切换是否真实成立
    2. 被替换后的能力 seam：新的 trigger / variants / customAction / tags / postDamage continuation 是否真实成立
  • 禁止只因为“升级牌写进升级槽”或“角色翻面切到新能力集”就把整条 family 判成 L4；这只能证明壳层成立，不能替代 replacement ability 本体审计。
• 奖励骰/特写壳与消费者拆分（强制）：
  • 遇到多个对象都经过 rollDie、BONUS_DIE_ROLLED、奖励骰特写或 displayOnlySettlement 时，必须继续拆成三层：
    1. 触发/展示壳：overlay 是否真实打开、关闭、阶段是否可继续
    2. 分支消费者：不同骰面最终落到 drawCard / grantToken / damage / status / extraAttack / selectPlayer / damageShield 哪一类消费者
    3. 收口 continuation：是否还要经过 postDamage、额外进攻、选择确认或其它后续时序
  • 禁止只因为多个对象都能看到奖励骰特写，或都写了 BONUS_DIE_ROLLED / displayOnlySettlement，就把它们判成同一 L4 family；真正的判等边界必须落在后续消费者与 continuation。

Step 3：D 维度审计（必须）

• 先打开 docs/ai-rules/testing-audit-dimensions.md 入口索引。
• 先用摘要表和选择指南确定命中维度，再只打开命中维度所在的主题分卷；不要求无差别加载所有细则。
• 按 D 维度库逐项检查，命中维度必须在审计文档里标注（如 D1/D5/D8/D34/D49/D52）。
• 若发现“同类语义分叉/绕过共享抽象”，必须按 D3/D23/D33 记录为 finding。
• 维度落地门禁（强制）：
  1. 每个对象至少命中 1 个维度，不得只写“✅一致”而不标维度。
  2. 对出现“可选/至多/任意/必须/不可防御/不可响应/归属玩家”字样的描述，必须覆盖 D1 + D5 + D10 的检查。
  3. 自定义事件（custom action）必须执行 D10 元数据一致 检查（事件类型 ↔ categories 对齐）。
  4. 涉及 UI 展示归属/绑定的字段，必须覆盖 D15 UI 状态同步（如 playerId/targetId 归属）。
  5. 对“点击入口后仍需推进阶段/确认选择才结算”的对象，必须显式标注 D5 + D8 + D50，不得只拿入口截图当收口。
  6. 对“不可防御”或“选择后才改写攻击合同”的对象，必须显式标注 D1 + D5 + D22 + D55，并写出 声明值 -> 消费点 -> 证据。
  7. 若任一强制维度未覆盖，审计不得收口。

Step 4：证据与验证

测试策略必须与问题类型匹配：

• UI/交互：E2E 优先（Playwright）。
• 逻辑/规则：GameTestRunner / Vitest。

E2E 证据链门禁（强制）

• 涉及“改投/重掷/分步确认/阶段推进”的交互，必须提供至少 2 张连续截图（触发前/改投后），无证据链不得宣告完成。
• 涉及“奖励骰/骰子特写”的交互，必须包含特写出现截图 + 改投后特写更新截图；若规则要求主骰盘不变，截图中必须能看到主骰盘仍保持原值。

4.1 成功路径截图链（强制）

• 当你在审计里声称“某交互/某卡牌已验证”，则证据链必须包含成功路径：
  • 禁止只提供“失败提示/不可用提示”的截图就宣告完成。
  • 失败提示截图只能作为“否定路径”补充证据，不能替代成功链路证据。

4.2 奖励骰/特写交互：四段式闭环（强制）

凡出现“骰子特写/奖励骰特写/重掷入口/显示-only 结算（displayOnly）”，E2E 证据必须满足最小闭环：

1. 特写出现（Spotlight Open）：能看到骰面/提示文案/关键入口；若规则要求“不改主攻击骰盘”，截图必须包含主骰盘区域。
2. 重投/关键操作（Reroll / Action）：至少执行一次关键操作（点击重掷/确认/跳过），并截图证明 UI/状态发生变化。
3. 关闭特写（Close）：必须截图证明特写已关闭（或被确认按钮关闭）。
4. 收口证明（Settle）：必须证明“状态已收口且可继续推进”：
   • 临时/pending 状态已清空（例如 pendingSettlement/pendingInteraction/responseWindow 不残留）
   • 阶段可继续推进（下一阶段按钮出现/流程不阻塞）
   • 取消/消耗语义正确：必须明确并证明“本次关闭/确认”是否应消耗卡牌/资源/指示物：
     • 若规则/校验要求“条件不足则不可用”：应被门禁阻止，且不消耗卡牌/资源，并给出正确原因提示
     • 若规则要求“使用即消耗”：必须能在弃牌堆/日志/手牌变化中追溯到消耗结果

缺任一段，只能标“待补证据”，不得写“已收口/已一致”。

判定门槛补充（强制）：

• 失败提示不等于成功证据：如果出现“改投失败/不可重掷/条件不满足”等 toast/提示，这只能作为失败路径证据；不能替代上述 1-4 的成功闭环证据。
• 对外口径门禁：只要你在对用户的回复里写了“已验证成功/已跑 E2E 且通过/已修复”，你就必须在证据文档里给出上述 1-4 的截图绝对路径（至少覆盖关键截图），否则不得使用该口径收口。

生效时机判定（强制，避免把 Wild West 与 Righteousness/Zanshin 混为一谈）：

• “特写/奖励骰”只是 UI 展示形态，不等价于“数值一定延迟到关闭才生效”。
• 以“技能/卡牌/token 自己的描述”为准：
  • ✅ 若描述是“掷 1/5 颗骰子并获得该骰面的效果”（例如 Righteousness / Zanshin）：掷骰发生时效果即已确定，数值/状态允许在特写打开期间就写入权威状态（随后 UI 再展示、再关闭）。
  • ✅ 若描述是“当你花费 X 时…然后…”或明确写了“结算后/关闭后/花费后才追加”（例如 Wild West 挂载到 Loaded 的 postSettle）：必须证明数值不会在特写阶段提前写入，只能在实际触发点/收口点写入。

4.2.1 选择玩家目标（selectPlayer / 多目标）交互：三段式闭环（强制）

凡出现“选择 1/多名目标玩家”“至多 N 名目标玩家”“目标玩家/敌方玩家/任意玩家”等交互，E2E 证据必须满足最小闭环：

1. 目标列表出现（Target List Open）：截图中能同时看到全部候选目标玩家卡（用于验证目标集合语义：self/ally/enemy 是否正确）。
2. 选择态变化（Selection Changed）：至少选择 1 名目标玩家并截图证明“已选中/计数变化/确认按钮 enable”。
3. 结算落地（Resolved）：确认后截图证明交互已关闭且效果落到被选目标（同时不应误作用到未选目标）。

缺任一段，只能标“待补证据”，不得写“已完成/已验证”。

4.3 UI 归因一致性门禁（强制，D12/D15/D20）

审计必须明确区分“资源/指示物（token）”与“攻击修正汇总（attack modifier / bonus damage）”的 UI 归因，避免把 token 的变化误当作伤害修正已展示：

• Token 不等于攻击修正：token 的获得/消耗只能证明资源变化，不能替代“攻击修正区可见”的证据。
• 攻击修正徽章是“效果提示”，不是“结果证明”：徽章/提示出现只能证明“攻击修正已打出/已激活”，不能证明伤害数值已提前计入。
  • 若卡牌效果为“延迟结算/分段生效”（例如依赖奖励骰特写收口后再追加加伤），必须额外用状态断言证明“数值仅在实际生效时才进入 bonusDamage/attackModifierBonusDamage”。
• 卡牌加伤必须可见：凡通过事件/reducer 进入“攻击/伤害结算汇总”的加伤（例如 BONUS_DAMAGE_ADDED / attackModifierBonusDamage / pendingAttack.bonusDamage），必须在以下至少一个位置可见并被证据覆盖：
  1. 攻击修正区域（徽章/列表/tooltip）
  2. 战斗日志/结算日志（能区分来源）
  3. 结算数值展示（最终伤害拆解/来源标注）
• 若产品设计明确“不展示某类修正”，必须在审计文档写明：
  • 设计裁决（为什么不展示）
  • 替代证据（用何处证明玩家仍能理解/仍可复查）
  • 对应 D 维度（至少 D12 + D15 + D20）

4.4 分段生效/延迟结算（强制）

若同一张卡/同一交互包含“立即生效 + 延迟结算后再生效”的两段效果（如固定加伤 + 奖励骰结算加伤）：

• E2E 必须分别证明：
  1. 特写/交互打开阶段只体现“立即生效”部分
  2. 收口结算后才体现“延迟结算”部分
• 证据文档必须写清两段生效时机与 UI 展示位置，避免把“提前显示/提前计入”误审成正确。

4.5 截图与证据书写格式（强制）

• 截图路径必须为绝对路径。
• 每张关键截图必须写 1-3 条“肉眼观察结论”，直接回答本轮验收点（禁止只写“正常/通过”）。
• 最终回复门禁：如果最终回复中提到“已跑 E2E / E2E 通过 / 已验证成功”，则至少要给出 1 张你实际核对过的关键截图的完整绝对路径；否则不得使用该口径。
• 若本轮验收依赖视觉判断，除了给绝对路径，还必须先实际打开这些关键截图；没有开图，就不能写“我看图确认过”。
• 详见 docs/automated-testing.md 的截图规范。

Step 5：审计文档落地（强制）

• 审计文档必须落在 evidence/<gameId>/。
• 无文档 = 未审计。
• 推荐结构见 references/evidence-template.md。
• 若本轮对象存在图片可判定合同，审计文档必须显式引用录入阶段的“图片合同表”或等价分区表；没有这张表，不得说该对象的图面/槽位/atlas/区域合同已审完。

修订记录门禁（强制，防止“审计完了但旧结论还在误导”）

• 若发现旧结论失效：必须在“修订记录”写明以下四件事（缺一不可）：
  1. 旧结论是什么（建议引用原文句子或表格行的标题）
  2. 为何失效（指代消歧错误/证据链不闭环/否定路径遗漏/UI 归因不一致等）
  3. 新证据路径（至少 1 条绝对路径：E2E 截图/测试产物/对照裁图）
  4. 新结论（以及命中的 D 维度编号）
• 用语规范：避免“新增遗漏”这类模糊表述，统一写为“旧结论失效/先前未覆盖的维度/本轮补检结果”，并明确关联到具体维度。
• 正文同步回写（强制）：若旧文档内部仍保留会误导当前状态的对象矩阵行、残余范围、只到入口、仍待补 L3/L4、对象级未实现 等句子，必须把这些高风险正文行一并改掉，或在对应行内直接标成“历史轨迹/当前以某文档为准”。只在文首追加“以新文档为准”但正文旧结论不动，不算完成回写。
• 对象级缺口已收敛为批次治理尾项时必须改旧矩阵（强制）：如果最新证据已经证明对象级关键 L3/L4 已补齐，当前残余只在批次级判等矩阵、外围旧文档统一收口或治理口径，那么旧文档中仍把这些对象写成“未实现/只到入口/仍待补关键 L4”的矩阵行和总结段都必须同步改口；否则审计不得按“当前只剩治理尾巴”收口。

Step 6：输出与收口

• 输出：发现列表（Findings）+ 风险 + 证据路径 + 未覆盖项。
• 任何未覆盖风险必须显式保留，禁止“默认通过”。

何时需要额外规则文档

• 动画/特效：docs/ai-rules/animation-effects.md
• UI/布局：docs/ai-rules/ui-ux.md
• 引擎/系统：docs/ai-rules/engine-systems.md
• 数据录入：docs/ai-rules/data-entry.md

Resources

• references/dimensions.md：D 维度使用提示与索引
• references/evidence-template.md：审计文档模板