generic-issue-log-analysis

name	generic-issue-log-analysis
description	分析 IndustrialPlanner 仓库的公开 GitHub issue。优先读取 issue 正文和评论，结合截图、复现步骤、浏览器环境信息与仓库代码判断根因，并给出修复建议。

IndustrialPlanner Issue Analysis

项目概况

IndustrialPlanner 是一个运行在浏览器中的工厂规划工具（纯前端 Web App，React + TypeScript + Vite）。

关键目录结构：

• src/app/ — 应用层 UI（面板、工具栏、状态管理）
• src/editor/ — 编辑器核心（放置、验证、文档存储、视口）
• src/domain/ — 领域模型（设备、配方、蓝图等）
• src/registry/ — 静态数据定义（配方、设备变体、物品等注册表）
• src/shared/i18n/ — 多语言翻译文件（以中文为主）
• src/renderer/ — 渲染层（设备精灵、画布绘制）
• src/simulation/ — 仿真引擎
• .temp/json-export.json — 游戏解包数据（端口坐标、设备变体、渲染模板等，用于校验数据准确性）
• blueprints/ — 示例蓝图文件
• help/ — 帮助文档

Scope

• 默认把 #1234 视为当前仓库 issue。
• 如果用户给了完整 issue URL，则以该 URL 为准。
• 只分析可以直接访问的公开 issue、评论、截图和附件。
• 本项目是纯前端应用，没有后端日志或崩溃转储。主要证据来源是：截图、浏览器控制台输出（如果用户提供）、复现步骤、issue 正文描述。
• 如果证据不足（缺少截图、复现步骤或控制台错误），要先明确说明，再基于现有材料给出初步判断。

Workflow

1. 规范化输入。

   • #1234 视为当前仓库 issue。
   • 完整 issue URL 以 URL 为准。

2. 获取 issue 内容。

   • 读取正文和评论。
   • 提取：版本、浏览器、设备类型（桌面/平板/手机）、预期行为、实际行为、复现步骤、截图附件。
   • 如果维护者或其他评论已经给出结论，不要直接照抄；仍要用代码和文档自行验证。

3. 提取附件和现场证据。

   • 优先关注截图（最直接的证据来源）。
   • 留意用户是否提供了浏览器控制台错误信息、导出的蓝图 JSON、配置信息。
   • 截图重点观察：UI 是否正常渲染、是否有异常遮罩或弹窗、数据是否正确显示。

4. 建立复现路径。

   • 从 issue 文本确定用户操作路径和"出问题的时刻"。
   • 对照项目代码中的组件、状态流转、事件处理链路。

5. 回溯到代码和文档。

   • 先看 src/registry/ 确认数据定义是否正确（如配方数据、设备端口坐标）。
   • 再看 src/domain/ 和 src/editor/ 确认业务逻辑。
   • 最后看 src/app/ 确认 UI 渲染逻辑。
   • 如果涉及解包数据准确性，对照 .temp/json-export.json 校验。
   • 如果涉及设备/物品名称，先在 src/shared/i18n/ 查找中文名和对应 id。

5.5. 判断是否为仿真与游戏行为不一致问题。

• 确认用户表达的根因是否是"仿真的实现与游戏内行为不一致"。
• 典型信号：用户说"游戏里是这样的，但工具里是那样的"、配方产物/耗时/端口与游戏不符、设备行为逻辑与游戏不同。
• 若属于此类问题，必须要求补充游戏内截图作为对照证据。没有游戏内截图则标记为证据不足，不给出最终结论。
• 对照游戏截图与仿真数据/逻辑，逐项列出差异点。

6. 区分 issue 当时环境与当前分支。

   • 从 issue 文本还原用户当时的版本/环境。
   • 对照当前代码判断问题是仍然存在还是已修复。
   • 如果 issue 较旧，必要时按对应 tag 复核旧逻辑。

7. 输出结论。

   • 明确区分"已证实的根因""高概率怀疑点""证据不足的待确认项"。
   • 给出可执行的下一步。

证据类型与优先级

截图（最高优先级）

• 项目是可视化工厂规划工具，截图是最直接的证据。
• 最适合看：
  • UI 渲染是否正确（设备图标、连接线、端口位置）
  • 数据面板显示的数值是否正确
  • 是否有异常弹窗、遮罩、加载态
  • 布局/缩放/分辨率是否导致显示问题

issue 正文描述

• 适合看：
  • 用户操作路径和预期行为
  • 复现步骤
  • 使用的设备/配方名称

浏览器控制台输出

• 适合看：
  • JavaScript 错误堆栈
  • React 渲染警告
  • 数据解析异常

导出的蓝图 JSON / 配置文件

• 适合看：
  • 蓝图数据是否正确
  • 导入/导出是否损坏

解包数据对照

• 当 issue 涉及设备数据、端口坐标、配方数值的准确性时，对照 .temp/json-export.json 校验。

How To Filter Evidence

1. 从 issue 文本提取锚点：

   • 版本、浏览器、设备类型（桌面/平板/手机）
   • 操作路径（如"从工具箱拖入设备→连接端口→保存蓝图"）
   • 用户声称"出问题"的具体界面/阶段

2. 从截图中找高价值信号：

   • UI 元素是否错位、缺失、重叠
   • 数据数值是否异常
   • 是否有异常状态提示

3. 先锁定关键组件再下钻。

   • 从 issue 描述定位涉及的 UI 组件或业务模块。
   • 在该模块代码中搜索相关逻辑。

4. 区分表象和根因。

   • 用户看到的 UI 异常可能只是表象。
   • 根因可能在数据定义（src/registry/）、业务逻辑（src/domain/）或状态管理（src/app/state/）。

5. 回答时只保留关键片段，不要倾倒整段代码。

Common Patterns

• 问题在截图和描述不一致：以截图为准，指出描述与截图不符之处。

• 问题涉及数据值不对：优先检查 src/registry/ 中的定义数据，必要时对照 .temp/json-export.json。

• 问题只在特定设备/分辨率出现：检查 src/shared/browser/ 的响应式判断逻辑。

• 问题涉及中文名称：在 src/shared/i18n/ 中查找对应 id。

• 仿真与游戏行为不一致：先确认用户是否声称仿真实现与游戏内行为有差异。若是，则必须要求补充游戏内截图作为对照。无游戏截图则不给出最终结论，标记为证据不足。对照游戏截图与仿真数据逐项列出差异。

• 证据更接近"场景不支持"：给出代码中的限制逻辑依据，不要只给主观判断。

Correlating With Code

对本项目的代码回溯优先级：

1. src/registry/ — 静态数据定义（配方、设备、物品）
2. src/domain/ — 领域模型和业务规则
3. src/editor/ — 编辑器核心逻辑
4. src/simulation/ — 仿真引擎
5. src/app/ — UI 层
6. src/shared/i18n/ — 翻译文案
7. help/ — 帮助文档
8. .temp/json-export.json — 解包数据校验

中文文案查找

本项目使用 src/shared/i18n/ 管理多语言文案。输出结论时：

• 设备名称、物品名称、按钮文案等，先在 src/shared/i18n/ 中查找中文名和对应 id。
• 如果找不到中文文案，给出 key/id 并说明"未在 i18n 文件中找到对应中文"。
• 用户自定义名称优先保留，必要时括号补原始 key。

Linking Code Evidence

• 统一给出远端 GitHub blob 行号链接：https://github.com/<owner>/<repo>/blob/<commit>/<path>#L14-L20
• <commit> 默认使用当前 HEAD。
• 引用文档或配置也尽量给远端链接。

Output Format

## Issue 概要

- issue：`#1234`
- 版本 / 浏览器 / 设备：
- 涉及功能 / 设备 / 配方：
- 用户现象：

## 附件概览

- 实际可读文件 / 截图：
- 缺失或未上传的证据：

## 关键证据

<details><summary>点击此处展开</summary>

- issue 正文 / 评论：
- 截图分析：
- 控制台输出：
- 代码依据：

</details>

## 根因判断

- 直接结论：
- 证据链：
- 当前主线是否可能已修复：

## 修复方案

1. 代码 / 数据层修复
2. 需要补充的测试或验证
3. 如属于不支持场景，如何限制入口或改进提示

## 给用户的建议

- 临时绕过方案：
- 是否建议升级/刷新：

## 置信度

- 高 / 中 / 低
- 还缺什么证据

Reminders

• 不要仅凭 issue 文本下结论，必须回溯代码。
• 不要把当前分支代码直接当成 issue 当时的真实环境。
• 截图和分析冲突时，优先解释冲突，再决定更可信的证据链。
• 涉及数据准确性时，对照 src/registry/ 和 .temp/json-export.json。
• 设备/物品名称使用 i18n 中文文案，不要直接输出内部 id。
• 代码引用用远端 GitHub blob 链接，不要给本地路径。