ai-exchange/docs/AI_ICT_自动化执行层_P15-PXX闭环任务清单_v1.md

AI_ICT 自动化执行层 P15-PXX 闭环任务清单 v1

1. 目标

本文件用于把 P14 之后的自动化执行层工作收敛成一条有限、可验证、可连续推进的任务队列。

目标不是无限追加阶段，而是把当前已知的 unattended operations、视觉证据、多通道分发、质量复盘和远端闭环缺口一次性列清楚。后续执行默认按本文件从 P15 顺序推进；每个 P 完成后自动进入下一个 P，除非遇到真实外部 blocker 或必须由 operator 决策的产品边界。

---

2. 连续执行规则

1. P15-PXX 是自动化执行层，不是 Research Council 新阶段。
2. P0-P6 Research Council 继续冻结，P7 继续作为成熟度路由层。
3. 每个 P 都必须形成独立闭环：代码、测试、脚本/API/前端 smoke、状态回写、必要文档回写、git commit。
4. 如果本地 PostgreSQL、远端环境或外部通道不可用，只要不影响本地实现与单测闭环，就先完成本地闭环并记录环境 blocker。
5. 不允许任何 P 修改 execution_allowed、real_live_ready、risk governor、trust bucket 或 operator confirmation protocol。
6. 不把 fills=0 当作当前 analysis/decision-only 阶段 blocker。
7. 不宣称真实成交闭环可上线，除非未来明确进入 real-trading validation phase。

---

3. 当前基线

• P8: visual watch review/capture/feedback loop 已闭环。
• P9: alert quality rollup 已闭环。
• P10: visual capture retention cleanup 已闭环。
• P11: runtime stuck task watchdog 已闭环。
• P12: alert silent-window noise control 已闭环。
• P13: failed-delivery retry recovery 已闭环。
• P14: webhook transport retry 已闭环。

当前剩余缺口集中在：

• 降噪策略从静默窗口扩展到更细粒度的 channel/type/severity policy。
• 浏览器级真实截图采集仍未落地，当前主要是 advisory HTML capture。
• 视觉证据已具备策略触发/跳过与 ROI 统计基础；后续缺口集中在媒体证据分发和多通道路由。
• 外部媒体和多通道分发仍未完全编排。
• unattended runtime 的事件日志、恢复建议、长期复盘和端到端演练仍可加强。
• 远端 deploy/smoke 需要在环境可用时完成最终闭环。

---

4. P15-PXX 总览

Phase	名称	主目标	完成后默认进入
P15	Alert Noise Policy Matrix	细化 alert type / severity / channel / duty mode 的降噪策略	P16
P16	Browser Screenshot Capture Adapter	落地浏览器级截图采集，替代仅 HTML capture 的缺口	P17
P17	Visual Trigger ROI Router	用策略和统计控制何时触发视觉层	P18
P18	Visual Evidence Media Dispatch	让外发与 workbench 都能消费图片/截图证据	P19
P19	Multi-Channel Alert Routing	扩展多通道路由与通道健康可观测性	P20
P20	Operator Digest And Review Queue	把零散告警汇总成班次/周期复盘队列	P21
P21	Runtime Incident Journal	持久化 runtime incident 与恢复建议	P22
P22	Maintenance And Retention Rollup	汇总存储、delivery、feedback、runtime 维护状态	P23
P23	End-To-End Unattended Harness	构造端到端无人值守演练与回归脚本	P24
P24	Remote Smoke And Ops Closure	在远端可用时完成 deploy/smoke 与执行层冻结评审	PXX
PXX	Automation Execution Closure Gate	判断 P15-P24 是否全部闭环，冻结已知执行层扩展	Long-running monitor

---

5. P15 Alert Noise Policy Matrix

目标

把 P12 的静默窗口扩展为明确的降噪策略矩阵，避免所有 alert 只有一个全局 quiet-hour 判断。

范围

• 增强 DeliveryPolicyService 或新增轻量 policy helper。
• 支持按 alert type、severity、channel、operator mode、silent window 判断发送策略。
• 区分 workbench_only、external_allowed、suppressed_noise_policy、suppressed_silent_window。
• 在 dispatcher result、alert quality summary、runtime alert_dispatch details、workbench Alert Quality 中暴露策略命中计数。

验收

• 同一 alert 在 workbench channel 可见，但在外部 channel 可被 noise policy 抑制。
• 质量摘要能显示 noise-policy suppression。
• runtime task details 能显示 policy suppression 计数。
• focused tests 与 tests/unit 通过。

当前进展

• 2026-05-12 P15 已完成 Alert Noise Policy Matrix 本地闭环：新增 alert noise policy settings 与 evaluate_alert_delivery_policy()，按 alert type、severity、channel、duty mode、operator mode、silent window、cooldown 输出结构化策略结果。
• 2026-05-12 P15 已将 delivery_policy 写入 dispatcher payload，并在 dispatcher result、alert quality summary、runtime alert_dispatch details、run_alert_dispatcher.py 与 workbench Alert Quality 面板中暴露 suppressed_noise_policy、workbench_only、policy_external_allowed 等计数。
• 2026-05-12 P15 本地闭环已验证：focused P15 tests 通过，tests/unit 全量 667 个测试通过，script static checks 与 node --check src/web/app.js 通过；dispatcher smoke 与 quality-summary API smoke 可见 policy counters。runtime smoke 的 alert_dispatch 任务成功，但整体 runtime 受本机 market stream / OKX read connection refused 外部环境阻塞影响。

---

6. P16 Browser Screenshot Capture Adapter

目标

补齐真实浏览器截图采集能力，让 visual snapshot 不再只依赖 HTML advisory capture。

范围

• 增强 VisualSnapshotCaptureService 或新增 browser capture adapter。
• 优先支持 local workbench/chart URL 的截图；外部 TradingView/OKX Web 可作为后续适配源。
• 产物包括 image_path、html_path、metadata_path、viewport、source、capture status。
• 新增或扩展脚本/API，允许手动触发 screenshot capture。
• workbench Visual Reviews 区块能展示截图路径和 capture status。

验收

• 本地可对一个稳定 URL 生成 PNG/JPEG 截图文件。
• 失败时返回 unavailable 结构，不中断 runtime。
• focused tests、脚本 smoke、API smoke 通过。

当前进展

• 2026-05-12 P16 已完成 Browser Screenshot Capture Adapter 本地闭环：VisualSnapshotCaptureService 会继续生成 review-packet HTML/JSON artifact，并在本机 Edge/Chrome headless 可用时额外生成 PNG screenshot。
• 2026-05-12 P16 已将 capture payload 扩展为 html_path、screenshot_path、metadata_path、capture_url、browser_capture_status 与结构化 browser_capture，并把这些字段接入 scripts/run_visual_snapshot_capture.py、POST /trading/visual-watch/capture 和 workbench Visual Reviews 面板。
• 2026-05-12 P16 本地闭环已验证：focused browser capture/script/API tests 通过，tests/unit 全量 668 个测试通过，script static checks 与 node --check src/web/app.js 通过；真实本机 browser screenshot smoke 已生成 PNG，脚本在无 watch run 时仍安全 no-op。

---

7. P17 Visual Trigger ROI Router

目标

让视觉层只在高价值事件触发，并能统计触发原因与后续反馈价值。

范围

• 新增或补齐 VisualTriggerPolicyService。
• 支持触发类型：candidate_actionable_watch、candidate_block_reason_review、market_anomaly_review、session_focus_watch、news_window_review、reconciliation_review。
• runtime visual_watch task 只按策略触发，并记录 skip reason。
• alert quality summary 或 visual review summary 中统计 trigger type、review result、feedback label。

验收

• 普通 observe 状态不会触发截图/视觉复核。
• actionable 或 degraded 状态能触发视觉复核。
• 触发与跳过都有可审计 reason。

当前进展

• 2026-05-12 P17 已完成 Visual Trigger ROI Router 本地闭环：新增结构化 evaluate_visual_trigger_policy()，普通 observe/monitoring 状态返回 observe_monitoring_not_high_value，actionable、blocked、market degraded、broker/reconciliation degraded、council watch item 会输出明确 trigger type 与 reason codes。
• 2026-05-12 P17 已将 visual_trigger_policy、visual_trigger_skip_reason、visual_trigger_roi 写入 decision alert payload，并把同一 policy metadata 传入 reserved visual watch request 与 visual review payload。
• 2026-05-12 P17 已在 runtime decision_packet / visual_watch task details、alert quality visual review summary、scripts/run_visual_review.py、workbench Alert Quality 与 Visual Reviews 面板中暴露 trigger/skip/ROI 计数。
• 2026-05-12 P17 本地闭环已验证：focused P17 tests 通过，tests/unit 全量 672 个测试通过，script static checks 与 node --check src/web/app.js 通过；visual review smoke 在无 pending watch run 时返回 skip_reason=no_pending_visual_watch_runs，quality-summary API 可见 trigger counters，runtime smoke blockers=none。

---

8. P18 Visual Evidence Media Dispatch

目标

让视觉证据从“路径/摘要可见”升级为“消息与 UI 均可消费的媒体证据”。

范围

• alert payload 中增加 stable media evidence block。
• webhook/workbench 继续兼容文本摘要，同时携带 screenshot path、mime type、capture metadata。
• 若外部 channel 不支持文件发送，必须降级为链接/路径/摘要，不标记为失败。
• Alert Quality 与 Visual Reviews 面板能看到最近媒体证据状态。

验收

• actionable alert 能带 visual summary 和 screenshot metadata。
• channel 不支持媒体时不会中断 dispatch。
• delivery record 能区分 media_attached、media_linked、media_unavailable。

当前进展

• 2026-05-12 P18 已完成 Visual Evidence Media Dispatch 本地闭环：新增 build_visual_media_evidence() 与 summarize_visual_media_evidence()，将 visual review 转为稳定 media_evidence block，包含 primary media path、mime type、browser capture status、fallback reason 与 channel support。
• 2026-05-12 P18 已将 media_evidence 写入 alert dispatcher delivery payload，并在 dispatcher result、message template、delivery summary、runtime alert_dispatch details、run_alert_dispatcher.py、visual review API 与 workbench 中暴露 media_attached、media_linked、media_unavailable 状态。
• 2026-05-12 P18 本地闭环已验证：focused P18 tests 通过，tests/unit 全量 675 个测试通过，script static checks 与 node --check src/web/app.js 通过；dispatcher smoke 在无 pending alert 时安全 no-op 且 media counters 可见，quality-summary API 与 runtime smoke 均可见 media counters 且 runtime blockers=none。

---

9. P19 Multi-Channel Alert Routing

目标

从 workbench/webhook 扩展到可编排的多通道策略，先保证结构和可观测性，再逐步接入真实外部通道。

范围

• 扩展 ChannelRouterService 的 channel capability 描述。
• 支持 channel health summary。
• 预留 WeCom / Email adapter，若凭据不可用则实现 disabled adapter 与明确 skip reason。
• dispatcher result、quality summary、runtime details 暴露 per-channel sent/failed/skipped。

验收

• 不同 alert type 可路由到不同 channel。
• 凭据缺失时显示 channel_disabled 或 credential_missing，不伪装成功。
• 现有 webhook/workbench 行为不回归。

当前进展

• 2026-05-12 P19 已完成 Multi-Channel Alert Routing 本地闭环：ChannelRouterService 现在输出结构化 channel_route、channel capability 与 channel health summary，覆盖 workbench、webhook、WeCom、Email。
• 2026-05-12 P19 已将 WeCom/Email 预留为 disabled adapter：凭据缺失时显示 credential_missing，即使未来填入凭据但 adapter 未实现也会保持 adapter_not_implemented，不会伪装成成功发送。
• 2026-05-12 P19 已在 dispatcher result、delivery payload、delivery summary、runtime alert_dispatch details、run_alert_dispatcher.py 与 workbench Alert Quality 中暴露 per-channel status、channel disabled count 与 channel health。
• 2026-05-12 P19 本地闭环已验证：focused P19 tests 通过，tests/unit 全量 679 个测试通过，script static checks 与 node --check src/web/app.js 通过；dispatcher smoke 在无 pending alert 时安全 no-op 且 channel health 可见，quality-summary API 与 runtime smoke 均可见 channel counts/health 且 runtime blockers=none。

---

10. P20 Operator Digest And Review Queue

目标

把零散告警、视觉复核和反馈聚合成 operator 可复盘的周期摘要，减少长期 unattended 噪音。

范围

• 新增 digest service 或扩展 alert quality summary。
• 生成 recent window 摘要：高价值告警、被抑制告警、失败重试、视觉 mismatch、待反馈项。
• 新增脚本/API 获取 digest。
• workbench 增加 compact digest panel 或复用 Alert Quality 面板。

验收

• digest 能在无数据时安全 no-op。

• digest 能列出需要 operator 复核的 top items。

• 不改变交易权限或自动下单边界。

• 2026-05-12 P20 已完成 Operator Digest And Review Queue 本地闭环：新增 OperatorDigestService 聚合 recent alerts、delivery history、visual reviews、quality flags 与 feedback gaps，输出 high_value_alerts、suppressed_alerts、failed_retry_items、visual_mismatch_items、pending_feedback_items 与 bounded review_queue。

• 2026-05-12 P20 已新增 scripts/run_operator_digest.py 与 GET /trading/alerts/operator-digest，并将 digest status/counts/top queue items 接入 workbench Alert Quality 面板。

• 2026-05-12 P20 本地闭环已验证：focused P20 tests 通过，tests/unit 全量 685 个测试通过，script static checks 68 个脚本通过，node --check src/web/app.js 通过；digest 在无数据时返回 safe idle/no-op，有数据时可列出 operator top review items，脚本/API/runtime smoke 均可见 review queue/counts 且 runtime blockers=none；该层只读聚合，不改变交易权限或自动下单边界。

---

11. P21 Runtime Incident Journal

目标

把 runtime/watchdog/dispatcher/snapshot 的异常沉淀为可查询事件日志和恢复建议。

范围

• 新增 incident journal repository/service，或使用现有存储模式落地。
• 捕获 stalled task、dispatch retry exhausted、capture unavailable、channel disabled、DB unavailable 等事件。
• 新增脚本/API 查询 recent incidents。
• runtime status 增加 incident summary。

验收

• 重复事件可去重或聚合。

• 每条 incident 有 severity、source、reason、first_seen、last_seen、recommended_action。

• 环境问题被记录为环境 blocker，不被伪装成代码完成。

• 2026-05-12 P21 已完成 Runtime Incident Journal 本地闭环：新增 runtime_incidents 表与 RuntimeIncidentJournalService，按 incident_key 聚合 runtime/watchdog/blocker/noisy incident，并保留 severity、source、reason、subject、first_seen、last_seen、occurrence_count 与 recommended_action。

• 2026-05-12 P21 已新增 scripts/run_runtime_incident_journal.py 与 GET /trading/runtime-incidents，并将 incident_summary 接入 runtime status、run_trading_runtime.py 和 workbench runtime panel。

• 2026-05-12 P21 本地闭环已验证：已应用 043_create_runtime_incidents.sql，focused P21 tests 通过，tests/unit 全量 691 个测试通过，script static checks 69 个脚本通过，node --check src/web/app.js 通过；脚本/API smoke 返回 idle persisted state，runtime smoke blockers=none 且显示 Incident journal: idle / 0。

---

12. P22 Maintenance And Retention Rollup

目标

把清理、重试、反馈、delivery、visual captures、incident journal 汇成维护健康摘要。

范围

• 新增 maintenance summary service。
• 聚合 capture retention、alert delivery retention、feedback counts、incident counts、watchdog state。
• 可通过脚本/API/workbench 查看。
• 明确哪些维护动作是自动执行，哪些只给 operator 建议。

验收

• 能看到 storage/delivery/feedback/runtime 的维护状态。

• 维护摘要能作为 P23 harness 的断言输入。

• 不自动删除未纳入 retention policy 的业务数据。

• 2026-05-12 P22 已完成 Maintenance And Retention Rollup 本地闭环：新增 MaintenanceSummaryService，聚合 visual capture retention dry-run、alert delivery health、feedback sample health、runtime watchdog 与 incident journal summary，并输出 checks、blockers、warnings、maintenance_actions 与 p23_assertions。

• 2026-05-12 P22 已新增 scripts/run_maintenance_summary.py 与 GET /trading/maintenance-summary，并将 maintenance rollup 接入 workbench runtime panel。

• 2026-05-12 P22 本地闭环已验证：focused P22 tests 通过，tests/unit 全量 696 个测试通过，script static checks 70 个脚本通过，node --check src/web/app.js 通过；脚本/API smoke 返回 warning-only feedback.sample_health，blockers 为空，且 p23_assertions.no_unscoped_deletion=true / retention_policy_dry_run_only=true。

---

13. P23 End-To-End Unattended Harness

目标

构造一条可重复的端到端无人值守演练链，验证 P15-P22 的关键路径。

范围

• 新增或扩展 smoke harness，覆盖 seeded alert、policy suppression、dispatch retry、visual capture fallback、feedback rollup、runtime watchdog、maintenance summary。
• 支持无真实外部通道、无真实成交样本的 analysis/decision-only 模式。
• 输出单一 JSON 报告，包含 blockers、warnings、passed checks。

验收

• 本地可一条命令跑完 harness。
• 环境依赖不可用时输出明确 blocker，不误报为业务失败。
• 可作为 P24 远端 smoke 的主要入口。

本地闭环记录

• 2026-05-12 P23 已新增 UnattendedHarnessService，以 analysis/decision-only 模式验证 policy suppression、dispatch retry contract、runtime watchdog、visual capture fallback、feedback rollup、visual media/channel rollup、operator digest、maintenance summary 与 runtime environment。
• 2026-05-12 P23 已新增 scripts/run_unattended_harness.py 与 GET /trading/unattended-harness，输出单一 JSON 报告，包含 checks、passed_checks、warnings、blockers、external_channels_used=false 与 real_trade_required=false。
• 2026-05-12 P23 本地闭环已验证：focused P23 tests 通过，tests/unit 全量 701 个测试通过，script static checks 71 个脚本通过，node --check src/web/app.js 通过；脚本/API smoke 均返回 status=passed、passed_checks=9、warnings=[]、blockers=[]。

---

14. P24 Remote Smoke And Ops Closure

目标

在远端环境可用时，把 P15-P23 的本地闭环部署并完成远端 smoke。

范围

• 部署当前 HEAD。
• 执行必要 migration。
• 验证 /health、/trading/runtime-status、/trading/review-packet、alert quality、visual watch、maintenance summary、P23 harness。
• 回写远端 smoke 结果到 SESSION.md / TASKS.md / docs。

验收

• 远端 API 与 workbench 能看到 P15-P23 关键能力。
• 若远端 PostgreSQL、proxy、channel credential 不可用，记录为环境 blocker，并明确本地闭环状态。
• 不把远端 smoke 未完成的能力宣称为完全发布完成。

---

15. PXX Automation Execution Closure Gate

目标

判断当前已知自动化执行层扩展是否全部闭环，并停止继续自动生成新 P。

关闭条件

1. P15-P24 均处于 closed 或 environment-blocked-with-local-closure 状态。
2. tests/unit 通过。
3. 相关 scripts static checks 通过。
4. P23 harness 本地通过或只剩明确外部环境 blocker。
5. P24 远端 smoke 通过，或明确记录远端环境 blocker。
6. SESSION.md / TASKS.md / 相关 docs 均已回写。
7. 当前执行层没有新的已知 code/doc mismatch。

PXX 后默认状态

state: automation_execution_layer_pxx_known_scope_closed
current_phase: Long-running Analysis Decision Monitor With Ops Rollup
next_action: continue_periodic_analysis_decision_monitoring_with_maturity_rollup
new_phase_policy: require_explicit_user_product_decision

PXX 之后，系统默认进入长期 monitor + ops rollup，不再自动发明 P25/P26。若未来需要真实成交闭环、真实外部媒体发送、或新的产品能力，必须作为新的用户明确产品阶段打开。

---

16. 推荐连续执行入口

默认下一步：

P15 Alert Noise Policy Matrix

执行方式：

1. 打开 P15 最小闭环。
2. 完成代码、验证、状态回写、commit。
3. 自动进入 P16。
4. 重复直到 PXX closure gate 或真实 blocker。