feedback-closeout

反馈收口

单一真相

本 skill 是 BoardGame 反馈收口 workflow 的唯一规范真相源。references/feedback-open-api.md 只描述 HTTP 接口；服务器、SSH 和 Mongo 入口按根 AGENTS.md 指向的共享用户环境文档读取。

临时材料只作证据或镜像：

• temp/feedback-closeout/**
• evidence/feedback-closeout/**
• 截图、诊断包、导出文本
• temp/feedback-closeout/status-board.json

这些都不能冒充本地数据库当前状态，也不能冒充线上正式反馈记录。

默认口径

用户说“处理反馈 / 收口反馈 / 修复反馈”且没有明说线上、生产、远端、真实反馈或回写线上时，默认目标是本地数据库反馈记录。

口径	真相源	允许写哪里	禁止
本地数据库	本机反馈数据库或本地开发 API	本地数据库 + 本地状态镜像	自动拉线上或说成线上已回写
线上真实	线上真实反馈接口或经确认的线上真实写入口	线上真实记录 + 本地状态镜像	用本地导出替代线上记录
离线快照	用户明确指定的导出、诊断包或本地文件	指定文件 / 状态板	说成本地数据库或线上当前状态

找不到本地数据库入口时，停在“缺少本地数据库反馈来源”；不要自动改拉线上替代。

完成门槛

• 目标范围内仍有 open / in_progress / resolved 任一未收口项时，不得宣称完成。
• in_progress 只能表示当前执行中的暂态，绝不能作为最终结论、长期停车位或“待发布 / 待回查 / 待人工处理”队列；本轮结束前必须把每条目标反馈转成 resolved 或 closed，目标范围内 in_progress 必须为 0。代码 / 数据根因已经修复，且本地回归或等价的运行时消费证据已经通过时，直接写 resolved；生产发布、线上版本回查、生产行为观察和人工补操作都不是本地收口前置条件。
• 最终状态回查闸门： 所有状态写入完成后、最终汇报前，必须按本轮目标 ID 从真实源重新读取每条反馈，并逐条核对状态及 closedReason / resolvedMethod 与本地镜像。写入前的 summary.json、旧镜像和“写入成功”输出都不能代替这次回查；若关闭规则疑问，最终汇报必须复述真实源读回的解释。若仍有目标项为 in_progress，继续处理，不得结束本轮；若下一步确实依赖用户决策、补充信息或授权，先将尚未收口项从 in_progress 恢复为 open，重新核对真实源与镜像，并逐字列出待用户回答的具体问题、现实影响、直接证据、阻塞关系和最小补救动作。不得把内部排查、实现、常规验证、待发布或待线上回查伪装成用户决策，也不得为清零而伪造 resolved 或 closed。
• 数量多不是停止理由；继续批量处理直到清零，或报告真实阻塞。
• 每条反馈都必须建立“反馈原文 + 发现的问题 + 处理方式 / 修复结果”三项记录，缺一不可。 反馈原文必须来自本轮确认的真实来源，逐字保留；发现的问题必须说明实际核对后确认的故障、误报、非 bug、证据缺口或未复现结论；处理方式必须说明本轮实际做了什么、依据什么证据、当前结果是什么。只写“已修复”“已关闭”“验证通过”“不是 bug”均不算发现的问题或处理方式。
• 没有反馈原文、没有发现的问题或没有具体处理方式，禁止状态回写和最终汇报。 该限制同时适用于 resolved、closed 和仍在 in_progress 的代表项，不得用反馈 ID、摘要、分类、测试名、内部结论或诊断包路径代替。
• resolved / closed 是强门槛，不是文案可选项。 resolved 必须同时具备用户可读的 resolvedMethod；closed 必须同时具备用户可读的 closedReason。字段为空、泛化、只写内部术语或无法说明实际动作时，先补齐记录，再写最终状态；不得把字段缺失变成长期 in_progress。
• 真实规则 / 卡牌 / 技能 / 状态 / 卡图反馈必须完成源头到本地修复的全链路排查。 最低链路是：反馈原文 → 主真相源原图 / 规则原文 → 数据录入与锁定合同 → 运行时数据 / i18n / assetRef 映射 → 规则实现与消费点 → 本地同路径回归或可直接证明消费结果的自动化验证。根因确认、本地代码 / 数据修复和有效本地验证完成后，本轮直接写 resolved；生产部署和线上版本回查不再是 resolved 的前置门槛，只决定能否声称“线上已生效”。
• 凡是反馈命中卡牌、技能、Token、状态、基地、效果文字或玩家可见规则结果，都必须先核对主真相源原文和完整对象图面，再进入实现判断。 原文核对和卡面核对是每条符合条件反馈的固定首步，不得只挑用户质疑的那一条做；若对象确实没有卡面（纯状态 / 纯 UI / 纯流程），必须记录“卡面不适用”和替代真相源，不得默认为已核对。
• 反馈内容不是规则真相。 玩家说“应该不可转移”“操作不合法”“效果不能取消”等只能作为待核对断言；必须以规则书、完整卡面、提示板、已锁定录入合同和实现消费链对照判定。若原文 / 卡面证明当前行为合法，分类为 non_bug，直接 closed，closedReason 必须逐字附规则原文 / 卡面结论、当前行为和为什么符合规则；不得为了迎合反馈修改代码。
• 先定位游戏，再定位原始规则落点。 反馈没有直接给出来源时，必须先由 gameId / route / matchId / 对象名 定位对应游戏，再查该游戏 rule/ 下的规则原文、提示卡 / 玩家板 / 牌面原图和录入合同；不能拿通用 i18n、运行时字段或相邻游戏文本代替原始规则。
• 规则置信度分层固定执行。 项目 rule/ 中可回查的原始规则文本 / 规则表是高置信度；完整提示卡、玩家板或卡牌原图是次高置信度的直接证据；基于图片生成的录入表、i18n、静态数据、运行时定义、旧测试、旧 evidence 和玩家反馈都属于低置信度或派生证据。低置信度证据与 rule/ 冲突时，必须重新看原图并回修录入 / 消费链，不能用录入数据证明自己正确。
• 提示卡是规则核对对象。 状态 / Token 反馈如果规则写在提示卡而不是状态小图上，必须打开完整提示卡原图，定位对应状态的原文，再核对 rule/ 和录入字段；只看状态图标、图标文件名或 i18n 不算看过卡面。
• “看过代码、测试通过、当前树未复现、当前生产版本已恢复”都不能替代源头排查。 对卡牌图、效果文字、技能数值、Token、状态、基地或资源索引相关反馈，必须先核对主真相源，再判断是录入错、索引错、消费错、实现错、UI 展示错还是历史现场失效。
• 历史终态默认不可信，必须可复审。 读取到已有 resolved / closed 时，先按上述本地全链路逐项复核；缺少主真相源、录入合同、消费映射或本地修复证据时，标为 needs_review 并在当前处理轮次补齐证据，不能把它长期停在 in_progress。仅缺生产版本 / 线上行为证据，不得回退本地终态。
• 批量反馈必须逐条复审。 同一批、同一游戏或相似措辞不能共享“已核对原文 / 卡面”的结论；每条反馈都要留下自己的对象、原文位置、完整卡面 / 状态图路径、录入字段、实现消费点和判定理由。缺哪一项，就在当前处理轮次补齐；人工入口不是唯一证据来源，不得因为缺少人工截图而把反馈长期留在 in_progress。
• 高置信度结论必须逐链路列证据。 resolvedMethod / closedReason 必须分别写明源头结论、录入结论、实现结论和本地验证结果；若生产尚未部署，可如实写“本地已修复，生产待发布”，但不得因此把本地 resolved 延后或再次改写。线上未回查只能是事实边界，不能是阻塞结论。
• 每条人类玩家反馈在进入 resolved 或 closed 前，优先从最近真实入口尝试：恢复原房间 / 回放 / 诊断包，或按反馈文字重建最小可玩局面。若同一路径已有可靠自动化回归、运行时消费证明或服务层直接验证，人工进入页面不是必需门槛；不得因为无法做人工或线上回放而把修复长期停在 in_progress。
• 若实际执行了真实入口验收，继续遵守 e2e-verification 的三段式合同并记录截图 / PASS 清单；但截图、VIEWER_URL 和 npm run verify:e2e-evidence -- <PASS清单.json> 仅在本轮选择该证据路线时适用，不是所有反馈的统一收口前置条件。
• 真实入口按反馈步骤未复现且没有代码 / 数据修复时，记录入口、范围、版本 / 工作树和“本次未复现，不等于已修复”，用 closed 关闭；已经完成根因修复并有本地回归证据时，用 resolved 关闭，不得再等待线上行为观察。
• 每次阶段汇报和最终汇报必须写清口径和绝对时间。
• 对用户展示问题时，以“反馈内容 / 现实症状”为标题；反馈 ID 只放追溯证据，不作为主标题。
• 玩家反馈要写清游戏中文名、命中的对象 / 页面 / 效果、规则本应发生什么、实际坏在哪条玩家可见链路。
• 玩家反馈命中卡牌、技能、状态、基地、教程步骤或其它规则效果时，必须同时给出“效果描述原文”：从本轮确认的规则书、牌面图、录入合同、运行文案或其它真相源逐字摘出对应效果文本，并标明来源；不能只给实现摘要、测试名或自己的改写。
• 规则反馈若出现错误分类、条件语义误读或证据越权（不论最终判为真 bug、non_bug 或证据不足），必须复盘是已有规范未执行、规范缺口、测试缺口、审计留档缺口还是单游戏合同问题；若需更新规范，按系统 skill-governance 锁定并同轮更新唯一真相源；若现有规范已覆盖，只纠正执行并记录对应条款，不新增重复规则。真 bug 仍须完成修复后的漏审复盘。
• 系统自动反馈要写清自动检测场景、现实影响、监控触发条件、止血动作和根因证据是否存在。