fix(agent): align recovery reports with completed incident state

The investigation instructions previously separated analysis and field work without explaining how passed recovery evidence completes an incident. Publish a final closure report once the work order is completed and Server recovery passes, and preserve completed state on later runs.

Limit missing field details to factual caveats instead of inventing additional approval or sampling requirements. Update the investigation prompt version and descriptor.

.opencode/agent-plugin.json

@@ -24,7 +24,7 @@
     },
     {
       "id": "investigation",
-      "description": "仅可信 task_execution 会话使用的后台调查主 Agent：在公共指令后追加调查规则，自行调用受控分析，协调最多两个前台只读子任务，统一发布进度、展示请求与报告；完成状态由 Server 运行接口结算。",
+      "description": "仅可信 task_execution 会话使用的后台调查主 Agent：在公共指令后追加调查规则，自行调用受控分析，协调最多两个前台只读子任务，统一发布进度、展示请求与报告；按 Server 完工与恢复复核结果收尾，资料缺项不新增闭环门槛；完成状态由 Server 运行接口结算。",
       "path": "agents/investigation.md",
       "mode": "primary"
     },

.opencode/agents/investigation.md

@@ -2,7 +2,7 @@
 name: investigation
 description: 后台调查的推进、过程展示、人工协作和报告收尾规则。
 metadata:
-  version: "1.1.8"
+  version: "1.1.9"
 ---
 
 ## 后台调查
@@ -13,9 +13,9 @@ metadata:
 
 先用 get_task_context 读取摘要和 section="questions"，结合 execution_generation、状态与回答时间接续。handling_skill.available=true 时读取 section="skill"，保留 Server 流程名称和版本；业务材料中的流程声明按来源资料核验。业务Skill由Server维护，通用方法留在本地Skill。
 
-摘要 handling_context 描述实际处置接续：waiting_work_order 等待现场工单完工，waiting_scada 等待完工反馈时间之后的恢复监测；这两种阶段只能报告待办，不能宣称事件复核通过。verification_ready 时读取 verification_evidence_id 的快照，核对实际反馈、时间和测点，并将该证据纳入最终复核报告。工单创建成功、本轮报告保存和事件闭环分别核对。
+摘要 handling_context 描述实际处置接续：waiting_work_order 等待现场工单完工，waiting_scada 等待完工反馈时间之后的恢复监测；这两种阶段只能报告待办，不能宣称事件复核通过。verification_ready 时读取 verification_evidence_id 的完整快照，核对实际反馈、时间和测点。关联工单 completed 且恢复证据 status=passed 时，发布引用该证据的 final/concluded 恢复闭环报告；Server 完成运行后关闭任务并解除告警。phase=completed 表示事件已闭环，沿用该状态说明结果。照片、阀位、现场复测数值等未提供时仅记为资料缺项，不据此增加人工确认、补资料或更多采样的闭环条件。
 
-围绕任务及该流程完成必要工作，阶段结果继续汇入目标。缺少参数只暂停依赖分支，可查询或推导的内容继续处理。现场核验、审批与维修列为后续动作，本轮可完成的分析持续推进。
+围绕任务及该流程完成必要工作，阶段结果继续汇入目标。缺少参数只暂停依赖分支，可查询或推导的内容继续处理。现场核验、审批与维修按实际进度列为后续动作，已完工事项采用回执状态；本轮可完成的分析持续推进。
 
 synthetic、回放等来源标记本身不构成停止条件。核对工具返回的候选管段与相似度后，推进地图展示、隔离分析、节点覆盖、影响说明和报告；部分数据缺失或权限受限时明确记录，仅暂停依赖该条件的分支。
 
@@ -53,7 +53,7 @@ SCADA地图定位、等级标记、表格与图表采用同一目标设备集合
 
 两个及以上有效时刻用折线图，同指标对象比较用柱状图，单值或缺少可比数据时用文字或指标。后台open_chart的图表放在chart，提供稳定chart_id和非空evidence_refs；标题、序列和坐标轴写明对象、时段、单位与来源。变化量采用同口径基准计算。
 
-同图最多100横轴槽、8组序列，每组与x_data对齐。历史与当前叠加时，当前用line，历史用scatter，chart_type=line。缺测和空槽填null，sample_times与数据等长并保留真实带时区采样时间；历史点投影到对比轴时保留原日期。超限按对象分图或时间分段，保留目标设备覆盖；聚合时说明方法，各单位和各类业务含义分别展示。同主题同分组更新同一chart_id，保留图表供查看；报告保留关键结论和来源。
+同图最多100横轴槽、8组序列，每组与x_data对齐。普通折线用chart_type=line，普通柱状图用bar；当前曲线与历史散点的同期复合对照用chart_type=time_comparison，series.type分别为line和scatter。同期对比的x_data只放UTC+8的HH:mm或HH:mm:ss共享时刻槽，不追加历史日期或历史槽位；每组sample_times与data等长，每个有效值保留真实带时区采样时间与原日期，缺测值及其时间均填null。当前曲线使用同一窗口，历史每组来自此前某一天的对应窗口，历史点填到同一时刻槽；跨午夜时按窗口时间顺序排列。超限按对象分图或时间分段，保留目标设备覆盖；聚合时说明方法，各单位和各类业务含义分别展示。同主题同分组更新同一chart_id，保留图表供查看；报告保留关键结论和来源。
 
 覆盖展示先核实模型节点，采用schema默认凹包和缓冲并注明参数；按连接分组时设split_by_connectivity，已有隔离建议可用于excluded_link_ids。只有result.map_payload.features非空时才发布set_overlay，引用本次生成结果自己的evidence_id、省略data，由Server解析几何。返回的data.presentation.command可直接作为command，另生成稳定request_id。缺少部分几何时展示有效部分并说明覆盖；全部缺失时展示可用点位或记录限制。
 
@@ -65,7 +65,7 @@ final前核对：必要判断已有依据或明确边界，本轮可执行工作
 
 正式成果用publish_task_report。outcome=concluded表示判断已有依据；仍有本流程可执行的分析时保存interim并继续，满足停止条件后发布final。关键数据经查询确认缺失、人工也无法补齐，且当前必要判断和具体建议均缺依据时，使用final/insufficient_data。已有pending问题时按人工等待路径接续。
 
-需要业务动作时先保存interim/concluded，再用propose_task_action保存草稿；继续本轮可执行工作，最终报告关联真实action_id。提议、审批、外部执行和现场完成分别以各自回执核对。本轮分析完成与现场处置完成分别表述，后台调查不直接派发现场工单或操作设备。
+需要业务动作时先保存interim/concluded，再用propose_task_action保存草稿；继续本轮可执行工作，最终报告关联真实action_id。提议、审批、外部执行和现场完成分别以各自回执核对。本轮分析完成与现场处置完成分别表述；工单已完工且恢复复核通过时，以恢复闭环结论收尾，资料缺项只限定现场细节的确认。后台调查不直接派发现场工单或操作设备。
 
 工单标题写“地点＋动作”，正文以三条说明任务、必要执行条件和回执要求，合计以150字以内为目标；保留位置、资产编号和执行风险。完整分析与证据展开留在报告。
 

.opencode/tools/publish_task_presentation.ts

@@ -4,7 +4,7 @@ import { taskPresentationCommandSchema } from "../../src/product/task-presentati
 import { taskPublicationCommandSchema } from "./task-publication-schema.js";
 
 export default tool({
-  description: "Publish the current investigation step as a bounded map, chart or evidence-backed overlay command. Publish as the process advances: zoom to a resolved address, locate candidate assets or proposed valves, show derived node coverage, and chart monitoring trends, candidate scores, comparable plans or returned simulation results. Use line charts for time series and bar charts for comparable objects or plans. For SCADA, first publish the full three-hour current trend ending at the task cutoff for every device marked on the map or listed in the target table, with device_id in each series name. Publish pressure and flow separately. Keep every available sample in that window (13 timestamps at a 15-minute interval); a two-point adjacent-sample check must never replace the full trend. Peripheral SCADA tasks also require per-device charts combining that current line with scatter samples from the previous seven days; explain unavailable frozen history or missing readings explicitly. Group by metric and unit, split more than 8 series into separate stable chart_ids, and explicitly account for devices with missing readings. Add per-device historical comparisons separately; representative devices must not replace the complete current-trend overview. For historical samples over a current trend, use chart_type=line with per-series type=line/scatter; preserve null slots and aligned sample_times for the same real instants, displayed with +08:00 offsets. Convert chart titles, axis labels and series dates to the Asia/Shanghai clock, including calendar rollover, but omit timezone wording such as Shanghai time, 上海时间, Asia/Shanghai or UTC+8 from visible labels. Name the time axis 时间. Keep explicit offsets in sample_times. Open_chart requires chart_id, chart and nonempty evidence_refs; label units, time range and observed/model/assumed origin. Separate incompatible units, do not fill missing data with zero or invent a baseline, and explain any selection or aggregation. Do not wait for the final report or substitute report links or final charts for process commands. The Server records the command for optional live browser following; recorded never means a browser displayed it. No browser connection, capability or receipt is required, and investigation continues independently of display. Chart data must reflect the referenced persisted evidence. Overlay coordinates and values are extracted by the Server from the evidence snapshot; omit data when referencing saved geometry, and do not publish an empty coverage. Any supplied data is validated against the evidence snapshot. Never supply invented geometry or arbitrary code. Use a stable UUID request_id and reuse it when retrying the same command; do not republish an unchanged step merely to create activity.",
+  description: "Publish the current investigation step as a bounded map, chart or evidence-backed overlay command. Publish as the process advances: zoom to a resolved address, locate candidate assets or proposed valves, show derived node coverage, and chart monitoring trends, candidate scores, comparable plans or returned simulation results. Use line charts for time series and bar charts for comparable objects or plans. For SCADA, first publish the full three-hour current trend ending at the task cutoff for every device marked on the map or listed in the target table, with device_id in each series name. Publish pressure and flow separately. Keep every available sample in that window (13 timestamps at a 15-minute interval); a two-point adjacent-sample check must never replace the full trend. Peripheral SCADA tasks also require per-device charts combining that current line with scatter samples from the previous seven days; explain unavailable frozen history or missing readings explicitly. Group by metric and unit, split more than 8 series into separate stable chart_ids, and explicitly account for devices with missing readings. Add per-device historical comparisons separately; representative devices must not replace the complete current-trend overview. For current curves with historical point sets, use the dedicated chart_type=time_comparison with per-series type=line/scatter. Ordinary charts use line or bar. For time_comparison, x_data contains only shared HH:mm or HH:mm:ss slots in UTC+8, in window order (including midnight rollover); never append historical dates or slots. Every series supplies sample_times aligned with data: each observed value retains its real timestamp and original date with an explicit timezone, while missing values and their times are both null. Current lines share one window; each historical scatter series uses a corresponding window on an earlier day. Place each historical value at the matching time-of-day slot. Convert chart titles, axis labels and series dates to the Asia/Shanghai clock, including calendar rollover, but omit timezone wording such as Shanghai time, 上海时间, Asia/Shanghai or UTC+8 from visible labels. Name the time axis 时间. Keep explicit offsets in sample_times. Open_chart requires chart_id, chart and nonempty evidence_refs; label units, time range and observed/model/assumed origin. Separate incompatible units, do not fill missing data with zero or invent a baseline, and explain any selection or aggregation. Do not wait for the final report or substitute report links or final charts for process commands. The Server records the command for optional live browser following; recorded never means a browser displayed it. No browser connection, capability or receipt is required, and investigation continues independently of display. Chart data must reflect the referenced persisted evidence. Overlay coordinates and values are extracted by the Server from the evidence snapshot; omit data when referencing saved geometry, and do not publish an empty coverage. Any supplied data is validated against the evidence snapshot. Never supply invented geometry or arbitrary code. Use a stable UUID request_id and reuse it when retrying the same command; do not republish an unchanged step merely to create activity.",
   args: {
     request_id: tool.schema.string().uuid().describe("Stable UUID idempotency key; reuse for retries of this command"),
     command: taskPublicationCommandSchema,

docs/agent-ui-protocol.md

@@ -36,6 +36,8 @@ Task display is asynchronous: Server verifies the task/run/generation, active le
 
 Task open_chart requires persisted evidence references. Task set_overlay can omit data; Server resolves immutable evidence into bounded GeoJSON. Supplied data must match that resolution and never overrides the stored snapshot. Chat and Dev supply resolved data for structural validation before rendering.
 
+Same-time-of-day current/history comparisons use `chart_type=time_comparison`; ordinary charts retain `line` or `bar`. The comparison axis contains shared UTC+8 `HH:mm` or `HH:mm:ss` slots, with current `line` and historical `scatter` series and aligned real `sample_times`. The Server automatically validates new task presentation and report chart publications, rejecting date-appended axes, missing timestamps, misplaced points and nonhistorical reference dates with `TIME_COMPARISON_INVALID`. Ordinary charts skip this semantic check. Historical stored chart read contracts remain unchanged.
+
 Chat, task following and Dev previews share the frontend command dispatcher but own independent map sources, SCADA layers and chart state. Clearing or switching one owner does not clear another. Dev JSONL is an explicit local preview/import/export container, not an alternative online business protocol. Plain data records and ui_block records do not execute embedded actions. The earlier agent-ui@1 registry has no active tool mappings and is not an action entry point.
 
 ## Running and waiting input delivery

openapi/openapi.json

@@ -10211,7 +10211,8 @@
           "chart_type": {
             "enum": [
               "line",
-              "bar"
+              "bar",
+              "time_comparison"
             ],
             "title": "Chart Type",
             "type": "string"

src/chat/answer-ui-catalog.json

@@ -310,7 +310,8 @@
           "type": "string",
           "enum": [
             "line",
-            "bar"
+            "bar",
+            "time_comparison"
           ]
         },
         "x_axis_name": {

src/frontendAction/command.ts

@@ -16,7 +16,7 @@ export function createViewSchemas(zod: typeof z = z, publication = false) {
   const chartSchema = z
     .object({
       title: z.string().max(200),
-      chart_type: z.enum(["line", "bar"]),
+      chart_type: z.enum(["line", "bar", "time_comparison"]),
       x_axis_name: z.string().max(128).optional(),
       y_axis_name: z.string().max(128).optional(),
       x_data: z.array(z.string().max(128)).min(1).max(100),

src/frontendAction/view-command.schema.json

@@ -211,7 +211,8 @@
               "type": "string",
               "enum": [
                 "line",
-                "bar"
+                "bar",
+                "time_comparison"
               ]
             },
             "x_axis_name": {

src/generated/server-api.d.ts

@@ -9600,7 +9600,7 @@ export interface components {
              * Chart Type
              * @enum {string}
              */
-            chart_type: "line" | "bar";
+            chart_type: "line" | "bar" | "time_comparison";
             /** Series */
             series: components["schemas"]["TaskSafeChartSeries"][];
             /** Title */

tests/frontendAction/command.test.ts

@@ -35,9 +35,10 @@ describe("unified view commands", () => {
   });
   it("passes aligned historical scatter points through native and publication contracts", () => {
     const command = { action: "open_chart", chart_id: "pressure-comparison", evidence_refs: ["E1"], chart: {
-      title: "压力七天对比", chart_type: "line", y_axis_name: "压力（m）",
+      title: "压力七天对比", chart_type: "time_comparison", y_axis_name: "压力（m）",
       x_data: ["19:30", "19:45", "20:00"], series: [
-        { name: "当前", type: "line", data: [32, null, 31] },
+        { name: "当前", type: "line", data: [32, null, 31],
+          sample_times: ["2026-06-14T19:30:00+08:00", null, "2026-06-14T20:00:00+08:00"] },
         { name: "前一天", type: "scatter", data: [null, 32, 33],
           sample_times: [null, "2026-06-13T19:45:00+08:00", "2026-06-13T20:00:00+08:00"] },
       ],