状态：
DESIGN_AND_SNAPSHOT_CONTRACT_ONLY本文把
QuantRuntimeSettings的现有 Cloudflare Worker 网站确定为个人部署的唯一人类控制面入口。它不新增券商连接、凭证读取、订单、资金动作或 P4–P6 运行资格。
人只需要访问一个网站，便能看见整个 Quant 组织的：P0–P6 状态、日更数据/回放健康、单策略/组合/插件候选、AI 的机器建议，以及仅在需要时出现的 P6 决策项。
这不代表把所有系统塞进一个网页，也不代表网页成为券商。各仓库仍拥有自己的代码、数据、P1 输入、P2 配置和 P3 证据；控制台只是汇总经过验证的最小状态快照，并在未来记录人类的明确决策。
各仓 driver / 日更任务 ──来源快照（按 source_id）──► QuantRuntimeSettings Worker + KV ──聚合──► 网页
│
▼
一个网页登录后的全局决策平台
│
AI 只读建议 ◄── 审计收据 / 决策意图 ───┴──► P6 所有者明确决定
券商凭证、订单与资金 ──仅未来独立确定性执行网关持有── 不经过网页或 AI
现有 web/strategy-switch-console 已具备 GitHub OAuth、allowlist、管理员配置、KV 审计，以及受专用 token 保护的 strategy_health_dashboard.v1 只读健康快照。首页现在采用“人工决策台”：默认展示待处理决策，研究、证据和运行资料作为按需展开的下钻内容；历史策略切换则收敛到“策略设置”。
它仍不能被误解为券商终端：跨仓目录、完整 P0–P6 生命周期、P6 决策收据和确定性执行网关仍须以独立快照/适配器逐步接线。因此，现有设置页的按钮不是新的全局执行授权。
新增两层快照契约：各仓只发布自己的 qsl_control_plane_source_snapshot.v1；Worker 汇总为给网页读取的 qsl_control_plane_dashboard.v1。它汇总候选身份、当前阶段、数据新鲜度、P1/P2/P3 摘要、机器建议和 P6 是否等待所有者决定；不携带原始行情、账户、完整订单、文件路径或密钥。
data_status=ready 只说明来源快照已同步，不表示策略已验证、可执行或有订单授权。Worker 另行给出只读 attention：任一策略、组合或插件候选处于 DEFERRED / PARKED、来源产生脱敏错误，或没有候选时为 attention_required；缺快照为 unavailable；其余为 research_only。该字段只帮助监控和界面避免“工作流绿灯即策略绿灯”的误读，绝不提升 P4–P6 权限。
Worker 以独立于 dispatch token 的同步身份接收来源快照、按 source_id 分开保存在 KV，并只向已登录 allowlist 用户读取聚合结果。这样一个仓库不能覆盖另一个仓库的候选；同名候选会 fail-closed 并记录冲突。快照缺失、过期、未来时间戳或 schema 不符时，页面显示 unavailable / stale，不伪造全局健康结论。当前日更来源默认 36 小时后变为 stale，适配交易日节奏而不把周末误报为实时故障。
执行状态另用独立的 qsl_execution_evidence_source_snapshot.v1 与 qsl_execution_evidence_dashboard.v1 投影。每一条记录的身份是“固定策略 revision × 目标平台 × 当前执行通道”，显示策略、目标数据和目标执行证据，以及该平台的 shadow / paper 能力。它有独立 KV 前缀和同步 token，不能覆盖 P1–P3 候选快照，也不能创建订单、资金变更或 P6 授权。没有来源时页面保持空状态；在某个平台已有 live 或 paper 记录，也只是一项该目标的证据，不自动推广到别的平台。
首页是一个安静的操作台，不是绩效宣传页。它在一屏内按优先级回答三个问题：系统是否有可信的新鲜证据、今天机器做了什么、是否有仅能由所有者决定的事项。
- 全局状态：快照新鲜度、候选总数、本次
DEFERRED、PARKED和等待所有者决定的计数。没有值时明确显示未知，不用绿色填充空白。 - 所有者队列：仅显示 P6 的明确决定；正常情况下应为空。P1–P5 的延期或停车属于自动化处理项，不要求人反复点击确认。
- 候选生命周期：每条单策略、组合或插件候选显示类型、域、P 阶段、机器建议和证据新鲜度；首页只显示摘要，不复制 raw data 或大段日志。
- 策略 × 平台执行证据：展示每个平台的 shadow / paper 能力和匹配证据。
PAPER_BROKER只在该平台与适配器都可用时自动运行；没有 paper 能力时，系统继续自动 shadow，满足精确策略、数据和执行证据后才显示“需要所有者决定是否进行受限实盘试运行”。这仍不是实盘授权或按钮。 - 策略健康与审计：保留为下钻页面。健康项默认安静，只将异常、过期或需要决定的条目用有意义的状态色突出。
- 历史部署配置：现有切换页继续存在以保证兼容，但不放在默认入口，也不和 P0–P6 的真实状态混为一谈。
研究任务属于候选列表的下钻队列，而不是新的交易面。每条任务只显示不可变任务 ID、候选/版本、两次已验证观察的脱敏比较、P1/P2/P3 摘要、实验上限、固定的 no-order authority 与审计时间线。任务生产者与候选生产者分开保存，避免 Watcher 的任务记录覆盖流水线的 P3 状态。qsl_control_plane_source_snapshot.v1 不含任务字段；已接线的独立 qsl_research_task_source_snapshot.v1 索引负责投影任务。首份合格真实来源快照出现前，页面显示空队列，不能把 Issue 或 GitHub 配置猜成研究任务。
前端采用低干扰的运维工作台：浅色画布、单一强调色、紧凑列表和清晰留白；不使用“所有指标都是卡片”的马赛克，也不在日更数据只产生一个点时伪造收益曲线。刷新按快照更新频率进行，避免每几秒无意义轮询。
这遵循“仪表盘应直接回答问题、减少认知负担、异常优先”的运维原则；参考 Grafana dashboard best practices 与 Google SRE monitoring guidance。
成熟的量化和运维控制台并不是把所有数据都放在首页，而是让每个异常都能被负责的人快速、可审计地处理。基于 QuantConnect、Grafana、Datadog、PagerDuty 与 Backstage 的公开设计，本站遵循以下约束：
- 首页只放可行动事项。 每项应逐步具备“策略 × 平台/账户目标、严重度、影响、证据新鲜度、当前安全状态、建议动作、责任人/运行手册”的最小字段。缺字段时显示“证据不足”，不能用绿灯代替。
- 告警按影响合并和分流。 同一根因的运行告警应归为一个事项；高风险即时通知，需复核的事项批量通知，纯信息留在系统状态页。告警必须说明触发原因、如何判断与下一步，而不是只复制日志。Grafana 告警实践 与其 通知策略 都强调可行动性、分组与路由。
- 变更先证明，再执行。 策略设置页只显示当前值、拟议差异、适用范围和就绪检查；执行证据、持仓、现金与运行状态保持只读。QuantConnect 的实盘模型同样将算法状态、持仓、现金、订单事件与停止/清仓操作分离，避免把“看见状态”误解为“可直接改券商”。QuantConnect 实盘入门
- 事故有时间线，日常没有噪音。 系统状态页仅突出 critical/review、最后可信样本与关联证据；后续补充的审计视图应记录状态、影响、负责人、检测与根因时间线，符合 Datadog 事故管理 的可追溯原则。
- 策略、插件与平台是同一套目录对象。 它们应从代码/快照衍生身份、版本、责任、生命周期、运行手册和部署目标，而不是由网页手填。这个“目录先于大屏”的思路与 Backstage Software Catalog 一致。
- 不在控制台新增直连券商的紧急按钮。 需要停止或降风险时，只创建绑定证据的受限意图，并由独立、幂等且可对账的执行网关消费；浏览器、AI、网页配置和 GitHub workflow 都不能绕开该边界。
当前三项主导航正好对应这套低频人工流程：决策（今天要判断什么）、策略设置（准备提交什么差异）、系统状态（为什么需要判断）。目录、通知策略与审计会在各自已有真实快照/权限接口后作为下钻加入，不能先用静态假数据占据首页。
网页将“策略健康”扩展为“全局概览 + 决策队列”：
- P1–P3 的异常显示为机器可处理的
DEFERRED/PARKED，下一有效交易日可重试；一次数据源中断不应作废整年研究。 - P4/P5 只显示预先写入策略的自动评估状态，不显示“AI 立即改参”按钮。
- 只有阶段为 P6、状态为
owner_decision_required且建议为owner_live_decision的候选才进入所有者队列。人可选择确认受限试运行意图、保持暂停或退役候选；页面创建并校验qsl_owner_decision_intent.v1，绑定当前候选证据指纹，不直接调用券商。证据、候选或阶段变化后，旧意图不会匹配，必须重新决定。
当 P0 独立策略根、确定性执行网关和 P4/P5 收据都已实际接线后，才为“确认 P6”增加一个窄适配器。它只接受：当前候选 revision、当前风险摘要、当前证据摘要和一次性所有者决定。任一变化都要求新决定；网页、AI 或 GitHub Actions 都不能扩大风险或重置熔断。
现有手工切换页在此之前保留，以免破坏已有部署，但应在 UI 中标为历史部署配置工具，不能当作 P0–P6 控制台的运行授权。
| 信息 | 唯一生产者 | 控制台职责 | 不做什么 |
|---|---|---|---|
| P0 控制根/策略状态 | QuantRuntimeSettings |
显示经验证摘要 | 不签发或续期策略 |
| P1/P3 日更状态 | UsEquitySnapshotPipelines |
显示最近证据和新鲜度 | 不读取原始 bars 或凭证 |
| P2 策略/候选 | 各策略仓及候选注册表 | 显示固定 revision 与建议 | 不改参数或替换候选 |
| P4/P5 收据 | 未来独立生命周期服务 | 显示状态与原因码 | 不提交 paper / shadow 请求 |
| 策略 × 平台执行证据 | 未来平台审计/调度来源 | 显示目标平台与通道的最小能力、证据和下一步 | 不把其他平台的 paper/live 结果当作授权，也不创建 P6 试运行 |
| P6 所有者决定 | 决策适配器 | 显示、创建可审计意图 | 不直接下单 |
组合和插件与单策略一视同仁：每个 candidate_id 都有独立生命周期，不从成分策略继承 P3/P4/P5/P6 资格。
- 把所有仓库、原始数据和密钥复制进 Settings：会让单一网站成为高权限故障点，也无法提高数据可靠性。
- 让网页直接用 broker token 下单：绕开未来执行网关、幂等、对账和熔断边界。
- 让 AI 点击“优化并替换当前策略”：会把研究、候选和运行状态混在一起，无法解释一次结果来自哪版数据/代码。
- 重新建设重量级仪表盘平台：当前 Worker + KV + JSON snapshot 足够支撑个人部署的第一阶段；数据量和用户规模都不需要另引入数据库、队列或前端框架。
QuantRuntimeSettings新增快照 schema、Worker 安全读写端点和只读“全局概览”页；没有快照时 fail-closed 空状态。UsEquitySnapshotPipelines仅在 P1/P3 已完成时发出脱敏摘要；旧历史派生回测只能标为 exploratory，不能进入 P3 成功队列。- 候选注册表开始发布单策略、组合和插件的固定身份；控制台按候选而不是按模糊策略名显示。
- 实现 P4/P5 的独立自动化策略和收据后，再把它们显示为自动阶段。
- 最后才实现 P6 所有者决策意图与执行网关适配器。
第一阶段的验收标准很简单：一个登录用户在一个页面能准确看见“什么在跑、什么延期、什么需要我决定”，而页面永远不能因为缺少数据就编造状态，也不能触碰券商密钥或订单。
strategy_health_dashboard.v1 继续存在，现有监控不需要立即迁移。qsl_control_plane_dashboard.v1 是并列的新契约，等生产者逐步接入后再成为全局概览的数据源。Worker 的同步 token 必须与 OAuth、workflow dispatch token、策略 root 和未来 broker 凭证全部分离；KV 仅保存清洗后的快照和最小审计索引。