[Feature] 完善现有定时任务的执行历史、成果归因与统计查询

This is a multi-part design proposal, so start by reading internal/httpapi/assistant_tasks.go (readScheduledTurn, deleteScheduledSessionsExcept), internal/httpapi/assistant_session_cleanup.go, and internal/domain/analytics.go (AnalyticsFilter) to see how scheduled sessions and filters work today. Done is not a single patch: a maintainer would first need to split the issue into smaller, separately verifiable tasks, such as durable execution records for scheduled runs, then usage deduplication. Treat this as a discussion to clarify scope before writing code.

Problem

定时 AI 任务和定时触发 SOP 已经可以持续运行，但用户目前主要能看到最近一轮状态、会话结果和已上报 Token，难以准确回答：某个 Loop 历史执行了多少次、创建/处理了哪些 Issue 和 PR、最终交付了什么、累计消耗多少，以及数据是否完整。

本 Issue 聚焦完善现有定时任务、运行记录和统计页面。不新增独立看板、一级菜单或另一套统计中心，不把项目总量当作某个 Loop 的成绩。旧提案 #455 已关闭，本 Issue 按上述边界重新整理。

已确认的现状

• 定时任务执行已经给会话写入 scheduled 来源和 taskId，可复用现有身份关系。
• 同文件的 readScheduledTurn 在成功后删除上一轮会话，并调用 deleteScheduledSessionsExcept；另外还有定时会话清理策略。因此，不只是展示问题：仅靠会话无法保证历史累计完整。
• AnalyticsFilter已有项目、工作流、用户、时间等筛选，但缺少完整的定时任务和单次执行维度。
• 会话与工作区 Run 可能包含同一份用量，直接相加会重复；costUsd=0 也可能代表未知，不能当作免费。
• GitHub 上的 Issue、PR、review 和合入状态可以查询，但尚未形成跨会话、下游 SOP 和外部动作的完整任务归因。

Proposed behavior

1. 在现有入口补齐展示

现有定时任务列表/详情：保留当前配置和最近结果，补充历史执行列表。每轮可查看触发方式、时间、状态、结果摘要、关联工作项/Issue/PR、已知 Token 和采集情况，并跳到现有会话、运行详情及外部成果。可以复用现有详情、弹窗或抽屉组件，不另建独立看板。

现有统计页面：在当前项目、时间等筛选基础上增加“定时来源/任务”维度，复用已有图表、表格和下钻交互。选中单个任务后，所有卡片、趋势、明细、导出及 API/MCP 查询保持同一范围与口径。

默认先回答“做成了什么”，Token 和费用作为投入展示。任务类型不相关或未支持的指标不强行填零；原始工具调用量、扫描轮数和产物数量作为诊断信息，不充当交付效果。

用户要查看的信息	在现有入口中的展示
某个 Loop 执行情况	历史执行、成功/失败/取消/等待/跳过、无产出轮次、失败原因
Issue 成果	平台新建工作项、外部新建 Issue、实际处理/解决的独立 Issue，并可看明细
PR 成果	创建、审查、修改和合入的独立 PR，动作类型、状态及原始链接
投入	已知总 Token、输入/输出、缓存读写、估算/已上报费用、缺失来源
证据	对应执行、会话/Run/Trace、Issue、PR、review、验证记录；清理后说明可用范围

2. 优先保住历史：独立执行记录

复用现有任务 ID，每次触发建立持久化执行记录，不以聊天记录作为统计账本；已有可复用的运行/执行实体应优先扩展，避免重复存储和重复记账。

• 两类入口均覆盖：AI 提示词任务、扫描并派发 SOP 的触发任务。即使扫描后没有派发，也保留本轮结果；“空扫描执行成功”不等于完成了需求。
• 区分定时触发、立即运行、排队、实际开始、等待、成功、失败、取消和跳过；同轮节点重试不增加定时触发次数，手动重跑有独立执行及来源关系。
• 稳定 taskId → executionId → session/workspace/run/子 SOP/attempt。传播到下游，异步 SOP 结束和外部合入不因主会话结束而失去归属。
• 保存执行时的任务名称、配置版本/摘要、模型、起止时间、结果摘要和必要证据引用。任务改名/修改配置不覆盖历史，停用或删除任务配置不自动删除统计事实。
• 执行事实、成果和用量与会话/Trace 分开留存；详细内容仍可按现有策略清理，页面明确哪些内容已过期。留存策略须明确、可配置；用户显式删除业务数据时遵守平台规则。
• 执行开始尽早落库，缺凭据、启动失败、服务重启/中断等也留下可辨识记录，不能只保存成功轮次。采集异常可重试/补采，不重新执行已完成的外部写操作。

3. 明确 Issue / PR 归因与去重

从平台工具成功结果、现有交付关联、SOP 事件和外部系统确认中采集结构化成果，至少保留来源任务/执行、资源唯一键、动作、发生时间、执行者、结果与证据。

• 平台建单与外部建 Issue 分开。导入已有 GitHub Issue 不算新建外部问题，同一个问题的多份平台关联不重复计算独立外部问题。
• 扫描/读取与实际处理分开。分诊、回复、状态变更、修复等作为不同动作；新建、处理、解决分别统计，不把它们相加为交付总数。
• 完成状态与修复效果分开。平台工作项 done、外部 Issue 关闭、验证通过各自保留口径；重复/不计划处理的关闭不算修复。已解决后重开保留变化历史。
• 创建 PR、提交 review、审查评论、推送修复、合入分开。仅查看 diff 不算审查；独立 PR 数与 review/评论/更新次数分别统计。普通聊天评论不能无条件视为有效审查。
• 合入以代码托管平台为准，保留真实 merged 时间、分支和合入者。Loop 创建或审查、由人合入的 PR 标记为协作成果，不表述为全自动合入；合入也不等同上线/验收。
• 同一 PR 多轮处理、多个 Loop 参与时，分别保留创建/审查/修复等贡献；任务行可以都关联该 PR，平台独立资源总数取并集，不直接相加。主任务与子 SOP 的同一成果不重复累计。
• 动作时间、合入时间、当前状态分开。默认按成果事件发生时间统计；查看某轮执行的最终成果时可看到后续异步变化，并注明观察截止时间。
• 稳定资源键应包含托管平台/实例、仓库、资源类型及 ID；不能仅凭标题或机器人账号猜任务归属。无法确认的关联展示为未归因/待核实，不计入已核实成果。

外部状态采用已有 webhook 能力或增量轮询核实；重复通知和重试幂等处理，有最后同步时间、失败原因与补采状态。不要求为此先实现一整套新的 webhook 平台。

4. Token 和费用按任务累计，保留完整度

• 包含主会话、下游 SOP、重试、失败/取消已产生的用量；同一模型用量来源只记一次，会话与工作区副本、父级汇总与子级明细不能重复相加。
• 正确处理增量事件、累计快照、恢复执行及不同模型的缓存口径；缓存读写单列，不能不加区分地再加进总 Token。
• 支持 taskId/executionId 和时间范围汇总，并下钻到来源。执行次数与模型调用/用量来源数分开，覆盖率明确分母。
• 区分零用量、未知、不支持和部分已知。未知价格/缺失用量不能显示为完整的零成本；上报费用与估算费用标明来源、币种和价格版本，不混称实际账单。
• 单位成果投入只在成果范围、时间范围和成本覆盖明确时显示；失败、返工和无产出轮次的投入不得隐藏，多成果共享消耗不能重复全额分摊。

5. 通用上报，不绑定某个 Loop 或项目

内置 Issue/PR/用量采集覆盖常用工具路径；同时提供有文档的成果上报 API/MCP/脚本契约，复用统一执行上下文、鉴权、幂等与证据字段。可上报文档发布、巡检发现等其他业务资源/动作，不为每个任务新增专属数据库列或写死标题前缀。

任意 shell/外部 MCP 中的动作不能保证自动识别：支持的适配器自动采集，其余通过显式上报补齐并说明覆盖边界。AI 自报“修复了十个问题”只作为待核实摘要，不能直接变成已核实成果。第一版不做自定义 BI/公式编辑器。

6. 接口、权限与历史数据

• 扩展现有查询能力支持任务、执行、时间、来源和成果类型；后端聚合、分页明细、趋势和 CSV/JSON 导出同口径，MCP 能读取相同数据。不得静默忽略 taskId 导致返回项目总量。
• 服务端校验当前项目权限与执行归属；跨项目汇总只包含授权数据，不能通过伪造 taskId/executionId 写入其他任务。避免在指标中存储凭据或完整敏感工具参数。
• 历史回填仅使用仍存在且可验证的会话、Run 和外部关联，不猜测恢复已经删除的历史；标明采集起点、回填范围、缺失与统计更新时间。
• 持久化按现有领域仓库和手工 SQL 迁移约定实现。优先增量采集、可重算聚合和分页，前端不靠拉取全部会话解析文本计数。

建议实现顺序

1. 先上线独立执行记录和用量持久化，防止后续历史继续丢失；保留现有会话清理能力。
2. 串联下游 SOP，补齐 Issue/PR 结构化成果、外部核实与去重，以及通用上报契约。
3. 将上述数据接入现有任务历史/运行详情和统计筛选、明细及导出，完成浏览器验收。最终交付需覆盖以上完整路径，不以“只有埋点没有可见数据”结束。

本次不要求实现人工工时节省、意见自动采纳判定或 RSI 效果归因等缺乏可靠证据的高级指标。后续若接入 Verification/评测，沿用成果和证据关联，不另建统计体系。

Acceptance criteria

• 无新增独立看板、一级导航或并行统计中心；用户从现有定时任务入口看历史，从现有统计入口按任务筛选并下钻，同一筛选下卡片、趋势、明细、导出和 API/MCP 一致。
• 同一任务连续成功执行三轮后，即使旧会话被清理，三轮状态、结果摘要、成果、已知用量仍在；修改名称、停用和删除配置不覆盖统计。历史页面能区分证据已清理与执行不存在。
• AI 提示词、扫描派发两种任务均有记录，覆盖空扫描、启动失败、等待、取消、立即运行、节点重试和重启中断；次数口径明确，失败不从分母和投入中消失。
• A 在外部创建 I1 并关联平台、导入已有外部 I2、创建 P1、对 P2 提交两次真实审查：外部新建 Issue=1、创建 PR=1、审查独立 PR=1、审查次数=2，I2 不计外部新建。
• B 也审查 P1：A 的处理 PR 并集=2、B=1，平台独立处理 PR=2；每条贡献可查动作和原始证据，重复上报/回调不变更计数。
• P1 次日由人合入：按真实合入时间计数，仍可追到 A 的创建和 B 的审查贡献，标明人工合入；关闭未合入、Issue 重开及无法核实均不伪装成已交付。
• 主会话100 Token、独立下游 SOP200 Token、另一失败执行300 Token：任务已知累计600；重复会话/工作区记录和父级累计快照不双计。另有缺失用量时标明部分已知，而非完整零成本。
• 文档发布任务可通过同一上报契约记录资源、动作与证据，出现在现有任务历史/成果明细；不新增专属统计页面或专属数据库列，自报与已核实信息有区分。
• API 测试覆盖幂等、并发、累计/增量用量、任务归因、异步成果、补采、版本兼容和越权；浏览器测试覆盖历史→执行→成果/会话/运行详情的路径及零/缺失/不支持/空状态。
• 提供数据采集范围、留存/迁移、旧数据回填及统计口径说明；外部动作成功但采集失败可补采，不为了补采重做外部业务写入。

Scope

Platform — workflows / collaboration; UI / integrations.

Alternatives considered

• 新建独立看板：增加重复入口和维护成本，不采用。
• 无限制保留聊天，再解析自然语言：存储成本高且口径不可靠，不采用；保留结构化事实，详细记录按策略留存。
• 只按项目总量、标题前缀或统一机器人账号统计：缺少可靠任务归因，可辅助历史核对但不能作为唯一依据。

Checks

• 不依赖组织专属基础设施、内部数据或凭据。
• 已检索相关 Issue；#455 保持关闭，本 Issue 明确改为完善现有入口及数据能力。