// 仅分析 `AutoStockStapleMain` 的 MaaEnd 日志。用于还原该任务实际购买了什么、购买所对应的证据、逐步剩余账单（券/账单）数值时间线，以及在 pipeline 或 go-service 中应当加日志/埋点的位置。适用于用户询问 `AutoStockStapleMain`、`AutoStockStaple`、武陵/四号谷地的稳定需求物资购买，或该任务内账单数值变化原因等场景。
| name | autostockstaple-log-analysis |
| description | 仅分析 `AutoStockStapleMain` 的 MaaEnd 日志。用于还原该任务实际购买了什么、购买所对应的证据、逐步剩余账单（券/账单）数值时间线，以及在 pipeline 或 go-service 中应当加日志/埋点的位置。适用于用户询问 `AutoStockStapleMain`、`AutoStockStaple`、武陵/四号谷地的稳定需求物资购买，或该任务内账单数值变化原因等场景。 |
该 skill 仅用于 AutoStockStapleMain。
不要复用该流程到其他任务，例如 AutoStockpileMain、信用购物（credit shopping）、出售（selling），或通用 issue 故障排查。
只要你要分析 AutoStockStapleMain 的日志，就使用本 skill（不需要用户先提出特定问题）。
并且：只要运行本 skill，就必须执行“账单重建/剩余账单时间线”的还原，而不是只在用户问到“还剩多少券/账单”时才做。
重要澄清：
AutoStockpileMain；后者是另一套任务流，应使用独立的分析流程/skill。本 skill 重点包括：
AutoStockStapleMain 实际买了什么ValleyIV 与 Wuling 之间切换时如何解释账单数值AutoStockStaple 的 pipeline 节点优先从目标日志目录读取：
go-service.logmaafw.logmaafw.bak.*.logmxu-tauri.logmxu-web-YYYY-MM-DD.log代码上下文（用于理解任务语义与节点含义）：
assets/resource/pipeline/AutoStockStaple/ValleyIV.jsonassets/resource/pipeline/AutoStockStaple/Wuling.jsonassets/resource/pipeline/AutoStockStaple/General/Item.jsondocs/en_us/developers/custom.md无论用户具体问什么，运行本 skill 的输出里都必须包含：
CurrentStockBillText 的逐步重建）先定位精确的 AutoStockStapleMain 任务实例。
搜索：
AutoStockStapleMaintask_idTasker.Task.StartingTasker.Task.Succeededtask end: [cb_detail={"entry":"AutoStockStapleMain"...注意：
maafw.log 可能发生了轮转（rotated）。maafw.log 中缺失，改去检查 maafw.bak.*.log。task_id 混入本次分析。购买真相不能只看商品 OCR 候选，也不能只看进入买入任务。
AutoStockBuyItemValleyIVTask / AutoStockBuyItemWulingTask 只表示“识别到候选商品并进入是否需要购买的判定流程”，不直接等价于“实际已购买”。
先做强制检查：
task_id 缩小范围，只跟踪本次 AutoStockStapleMain 的事件。maafw*.log 文件内继续向后追踪，不要只看命中的第一小段上下文。maafw*.log 文件重搜。在 maafw*.log 中搜索：
Node.Action.Succeeded.*AutoStockBuyItemValleyIVTaskNode.Action.Succeeded.*AutoStockBuyItemWulingTaskAutoStockStapleQuantityControlAutoStockStapleQuantityControl.*BuyAutoStockStapleQuantityControl.*ExcludeAutoStockStapleQuantityControlConfirmBuyAutoStockStapleQuantityControlAction每次成功点击里都会包含 box=[x,y,w,h]。
随后在附近查找 AutoStockInStapleItemName 的 OCR 结果，并把“点击框（box）”与“OCR 的商品框（box）”做一一对应匹配。
这样才能得到“候选商品名称”。
不要把所有 OCR 候选都当成“已购买”。
AutoStockBuyItem(ValleyIV|Wuling)Task 动作成功，只能说明“进入候选商品的数量控制流程”。task_id 下向后追踪命中的具体物品子节点，例如 AutoStockStapleQuantityControlEchoingRemedy。AutoStockStapleQuantityControl<Item>Buy 分支识别成功，并继续走到其后的 AutoStockStapleQuantityControlAction / AutoStockStapleQuantityControlConfirmBuy 成功路径时，才把该商品标记为“实际已购买”。AutoStockStapleQuantityControl<Item>Buy 未命中，而 AutoStockStapleQuantityControl<Item>Exclude 成功，则应标记为“识别到该商品，但判定为当前不需要购买”，不能记入购买列表。AutoStockStapleQuantityControl<Item> 命中，但后续 Buy / Exclude 分支未查全，结论必须保持为“证据不足，需继续向后追踪”。只有满足以下全部条件，才能得出“本次没有购买”的结论：
task_id 所在的全部相关 maafw*.log 完成检索。AutoStockStapleQuantityControl<Item>Buy 并完成后续购买确认的证据。如果已经发现 AutoStockBuyItem...Task 的 Node.Recognition.Starting，
则必须继续检查同文件后续日志，直到确认以下至少一种结果：
Node.Action.SucceededNode.Action.Failed如果已经发现 AutoStockStapleQuantityControl<Item> 或其 Buy / Exclude 分支的 Node.Recognition.Starting，
则同样必须继续向后检查，直到确认以下至少一种结果：
AutoStockStapleQuantityControl<Item>Buy 成功并继续进入购买确认路径AutoStockStapleQuantityControl<Item>Exclude 成功Node.Action.Failed禁止仅依据以下局部证据直接下结论“没有购买”：
Node.Recognition.StartingNode.Recognition.Failed逐步的剩余账单使用：
AutoStockCurrentStockBillCurrentStockBillText典型信号：
OCRer.cpp ... CurrentStockBillText ... "text":"4153万"解读规则：
CurrentStockBillText OCR，把下一次数值视作“上一次购买后的最新可见剩余账单”。AutoStockStapleMain 可能在 ValleyIV 和 Wuling 之间切换。
当任务发生场景切换时，不要假设“账单数值口径与上一场景完全可直接比较、可当作同一账本连续相减”。
默认解释：
ValleyIV 与 Wuling 可能使用不同的账单类型/券种口径。当出现这类情况时，需要在结论中明确写出：
优先使用时间线表：
| 时间 | 场景 | 已购买商品 | 购买前可见剩余账单 | 下一次可见剩余账单（购买后） |
|---|
如果最后一次购买之后没有更晚的 OCR 识别结果，需明确说明“最终购买后账单不可用/无法从当前证据得到”。
同时提供事件时间线：
| 时间 | 事件 | 证据 |
|---|---|---|
| ... | 进入四号谷地 / 买了某商品 / 切换到武陵 / 任务结束 | ... |
AutoStockpileMain 是另一套任务。
不要把 AutoStockpileMain 的内容合并进 AutoStockStapleMain 的最终购买结果。
快速区分：
AutoStockpileMain：go-service 中 autostockpile 的货物礼包/套装选择流程AutoStockStapleMain：由 pipeline 节点（如 AutoStockBuyItemValleyIVTask、AutoStockBuyItemWulingTask）驱动的稳定需求物资购买流程如果用户询问的是 AutoStockStapleMain 前后某段时间范围，你可以提到相邻出现的 AutoStockpileMain 活动，但必须把它与 staple 购买列表分开。
用这些节点来解释行为：
AutoStockInStapleValleyIVAutoStockInStapleWuling它们决定本地搜索循环走向：
AutoStockBuyItemValleyIVTaskAutoStockBuyItemWulingTask它们是“识别到候选商品并进入后续购买判定”时的最佳 pipeline 节点。
原因：
它们同时满足：
AutoStockInStapleItemAutoStockInStapleItemDiscountsAutoStockInStapleItemNamebox_index 指向商品名 OCR 的结果
识别成功之后立刻发生点击
它们的 next 会进入 AutoStockStapleQuantityControl，因此这里只能确定“候选商品是谁”，不能单独作为“已购买”的最终证据
AutoStockStapleQuantityControlAutoStockStapleQuantityControl<Item>AutoStockStapleQuantityControl<Item>BuyAutoStockStapleQuantityControl<Item>ExcludeAutoStockStapleQuantityControlConfirmBuy它们决定“是否真的需要买”以及“后续走买入还是排除”。
解读规则：
AutoStockStapleQuantityControl<Item> 命中：说明当前候选商品已被映射到具体物品规则。AutoStockStapleQuantityControl<Item>Buy 命中：说明该商品通过数量阈值判定，允许继续购买。AutoStockStapleQuantityControl<Item>Exclude 命中：说明该商品被判定为无需购买，应从候选集中排除。Buy 分支继续走到其后的购买动作/确认路径，才算实际购买。AutoStockTargetCanNotBuyValleyIVAutoStockTargetCanNotBuyWuling它们是“账单低于阈值因此无法继续购买”的最佳节点。
AutoStockCurrentStockBillCurrentStockBillText它们是“实际剩余账单数值”的最佳证据来源。
当用户询问“该在哪里加日志/埋点”时，建议：
最佳位置：
AutoStockBuyItemValleyIVTask / AutoStockBuyItemWulingTask 附近为什么：
建议 payload：
task_id最佳位置：
AutoStockTargetCanNotBuyValleyIVAutoStockTargetCanNotBuyWuling建议 payload：
最佳位置：
AutoStockStapleQuantityControl<Item>BuyAutoStockStapleQuantityControl<Item>Exclude建议 payload：
buy / exclude如果要记录“实际完成购买”的最终证据，优先放在 AutoStockStapleQuantityControl<Item>Buy 后续的确认节点上。
最佳位置：
AutoStockCurrentStockBill 识别如果只能选用其中一个节点：
不要声称“仅通过停止买入节点就能直接得出实际购买了哪个商品”。
go-service.log 仍然能提供上下文：
AttachToExpectedRegexAction 展示当时把哪些商品白名单挂载到了 AutoStockInStapleItemName但“购买真相”仍应以 maafw*.log 的点击结果 + OCR box 对应匹配为准。
症状：
AutoStockInStapleItemName 展示了多个允许的商品AutoStockBuyItem...Task 的成功点击结论：
AutoStockBuyItem...Task 但最终没有购买症状：
AutoStockBuyItemValleyIVTask 或 AutoStockBuyItemWulingTask 的点击成功AutoStockStapleQuantityControl<Item>AutoStockStapleQuantityControl<Item>Buy 未命中AutoStockStapleQuantityControl<Item>Exclude 成功结论：
症状：
CurrentStockBillText结论：
症状：
ValleyIV 账单”和“首次可见 Wuling 账单”之间，或反过来结论：
AutoStockInStapleValleyIV 切换到 AutoStockInStapleWuling（或反向）结论：
症状：
maafw.bak.*.logmaafw.log 或后续某个 backup 只包含解析/初始化内容结论：
Recognition.Starting 就误判未购买症状：
AutoStockBuyItemValleyIVTask 或 AutoStockBuyItemWulingTask 的 Node.Recognition.StartingNode.Action.Succeeded / Node.Action.Failed结论：
Node.Recognition.Starting 只说明进入了买入判定，不代表最终没有购买Node.Action.Succeeded / Node.Action.Failed 为准maafw*.log 文件，再继续向后核对使用下面结构进行回答：
## AutoStockStapleMain 概要
- task_id: `...`
- 起止时间: `...`
- 结果: 成功 / 失败
## 实际购买顺序
1. `时间` - `区域` - `商品名`
2. `时间` - `区域` - `商品名`
## 识别到但未购买（如有）
- `时间` - `区域` - `商品名` - `原因：数量控制走了 Exclude / Buy 分支未通过`
## 事件时间线
| 时间 | 事件 | 说明 |
| ---- | ------------------------------------------------- | ---- |
| ... | 进入四号谷地 / 购买某商品 / 切换到武陵 / 任务结束 | ... |
## 账单（券/账单）时间线
| 时间 | 场景 | 商品 | 购买前可见剩余账单（券/账单） | 购买后下一次可见剩余账单（券/账单） |
| ---- | ---- | ---- | ----------------------------- | ----------------------------------- |
| ... | ... | ... | ... |
说明:
- 同场景内可近似按连续账本理解
- 跨 `ValleyIV` / `Wuling` 场景时，若出现大幅变化，优先解释为券种切换而不是单次异常大额消耗
## 关键依据
- `maafw*.log`: `AutoStockBuyItem...Task` 点击成功 + `AutoStockInStapleItemName` OCR box 对应（用于锁定候选商品）
- `maafw*.log`: `AutoStockStapleQuantityControl<Item>Buy` / `Exclude` / `ConfirmBuy`（用于判断是否真的购买）
- `maafw*.log`: `CurrentStockBillText` OCR
- `go-service.log`: 运行时 override / 任务上下文
## 适合加日志的节点
- 记录购买项: `AutoStockBuyItemValleyIVTask` / `AutoStockBuyItemWulingTask`
- 记录停止原因: `AutoStockTargetCanNotBuyValleyIV` / `AutoStockTargetCanNotBuyWuling`
- 记录剩余账单（券/账单）: `AutoStockCurrentStockBill`
AutoStockStapleMain。AutoStockpileMain 合并进最终购买列表。AutoStockBuyItem...Task 的成功点击直接当作“购买结果”；它只代表进入了是否需要购买的后续判定。task_id 范围内不存在任何真正走通的购买确认路径；不能只看 AutoStockBuyItem...Task 有没有命中。AutoStockBuyItem...Task 的 Node.Recognition.Starting，必须继续向后核对到 Node.Action.Succeeded、Node.Action.Failed、任务结束或明确切分支，不能中途停止。AutoStockStapleQuantityControl<Item> 或其 Buy / Exclude 分支开始，也必须继续向后核对到购买确认、排除成功、失败、任务结束或明确切分支，不能中途停止。maafw*.log 文件重查。MaaEnd MapTracker 相关组件编写指南。为 agent/go-service/maptracker 下的 Go 代码提供说明，并提供 MapTracker 的开发文档指引。在参与开发 MapTracker 的 Go 代码实现时，或需要了解 MapTracker 详细工作原理时使用。
向 routes.json 添加环境监测（EnvironmentMonitoring）新观察点条目。使用时：新增 zmdmap / kite_station_i18n 观察点路线配置、适配新版本的环境监测任务、补全缺失的 EnterMap、MapPath 或 MapTarget 数据。会自动检测缺失任务，逐字段询问路线数据后写入 routes.json。
分析 Windows 崩溃转储文件（.dmp），诊断 MaaEnd 及其依赖项（MaaFramework、MXU）的崩溃。自动从 GitHub Releases 下载对应版本 PDB 符号，使用 minidump-stackwalk 解析堆栈轨迹并定位崩溃根因。当 issue 日志包或附件中发现 .dmp 文件，或用户要求分析 DMP/崩溃转储时使用。
分析 MaaEnd 上游仓库公开 Issue（`https://github.com/MaaEnd/MaaEnd/issues/...` 或 `#1234`）。自动抓取 issue 正文和评论中的 `MaaEnd-logs-*.zip` 附件，下载解压后从 `maafw.log`、`maafw.bak.*.log`、`go-service.log`、`mxu-tauri.log`、`mxu-web-*.log`、`mxu-agent*.log`、`config/*`、`on_error/` 中筛选关键证据，并结合 MaaEnd、MaaFramework、MXU 的代码和文档判断根因、给出修复方案，供用户在让你分析 MaaEnd issue、日志包、识别失败、任务卡死、控制器差异、Pipeline/Agent/MXU 问题时使用。
分析 MaaEnd `CreditShoppingMain` 的日志。用于还原信用购物任务中实际购买了什么商品、每件商品的折扣力度、是否触发过刷新（或刷新次数已用尽）、稳健刷新是否触发、以及信用点的消耗状况。货架槽位必须以日志中的 `CreditIcon`（TemplateMatcher）为锚，有无 `BuyFirstOCR`/`Priority2OCR` 不影响槽位级货架的还原与呈现。适用于用户询问信用点交易、信用购物买了什么、折扣情况、刷新配置、`CreditShoppingMain` 任务行为等场景。
MaaEnd Pipeline JSON 编写指南。基于 MaaFramework Pipeline 协议，提供节点命名、识别算法、动作类型、流程控制、可复用节点等编码规范与模式参考。在编写、修改或审查 Pipeline JSON、设计节点流程、使用 TemplateMatch/OCR/Custom 识别或 Click/Swipe 动作时使用。