feat(workbench): add dynamic task approval lifecycle

docs/workbench-operations-storage.md

@@ -1,6 +1,6 @@
 # 工作台工单与告警存储契约
 
-工作台只聚合预约工单与任务主动推送的告警。浏览器不推导告警，也不写正式工单。
+工作台聚合外围来源工况任务与任务主动推送的告警。浏览器不推导告警，也不直接写工况任务。
 
 ## 任务告警
 
@@ -8,16 +8,8 @@ DDL 位于 `resources/sql/008_workbench_alert_events.sql`。任务通过 `POST /
 
 ## 预约工单
 
-`workbench.work_orders` 的 DDL 位于 `resources/sql/011_workbench_work_orders.sql`。每行保存一个只读工单投影，文档必须满足 `WorkbenchRuntimeWorkOrder`：
+外围样板的 `peripheral_sample.work_orders` 是演示工单的管理来源；`activity` 只记录实际发生的创建、修改和现场反馈，不由总状态补造阶段。同步器将有效工单写入 `workbench.operational_tasks` 的 `external_work_order` 投影。原有三张独立演示工单也已迁入外围样板，并由同一面板管理。
 
-`resources/sql/017_workbench_schema_comments.sql` 在 `008`、`011`、`014` 和 `015` 之后执行，为工作台 schema、17 张表和关键列增加数据库可见的用途说明。
+`resources/sql/011_workbench_work_orders.sql` 和 `017_workbench_schema_comments.sql` 属于历史基线；`021_retire_workbench_work_orders.sql` 在验证三个迁入目标及其任务投影后，仅在 `tjwater_v2` 删除旧表。不要重放 `011` 重建它。`GET /api/v1/workbench/runtime` 暂保留空的 `work_orders` 字段作为接口兼容。其他项目数据库没有旧表，不需要应用 `021`。
 
-- 一张预约工单对应一条单层投影，直接保存位置、负责人、预约时间和回执要求。
-- `activity` 只记录已经发生的创建、修改和现场反馈，按递增 `sequence` 排列；展示层不得根据工单总状态补造派发、执行或复令阶段。
-- 旧文档中的 `subtasks` 在兼容读取时被丢弃，不再进入新接口契约；历史修订保留原始审计内容。
-
-预约任务演示数据通过 `scripts/seed_workbench_work_orders.py` 直接写入。工作台继续显示三张原有演示工单，保留既有 ID、标题和状态，并改用回执要求与真实活动记录表达过程。脚本可重复执行，并会先清理旧的外围合成工单投影。`scripts/seed_peripheral_sample.py` 不再创建通信、压力和零流量检查工单。
-
-截至 2026-09-24，本次数据清理和三张演示工单结构重建仅应用于物理数据库 `tjwater_v2`，项目为 `324ff7ee-c2d4-5184-a84b-48fb14a2933e`。核验结果为三张演示工单均使用单层结构，旧种子检查投影为 0；其他项目数据库未执行本次变更。扩大范围必须遵循 [`workbench-database-rollout.md`](workbench-database-rollout.md) 的逐库门禁。
-
-工作台运行账号对工单表只需 `SELECT`，同步账号使用独立受控写权限；对告警事件表需要 `SELECT, INSERT`，对告警状态表需要 `SELECT, INSERT, UPDATE`。
+告警事件表需要 `SELECT, INSERT`，告警状态表需要 `SELECT, INSERT, UPDATE`。迁移及扩展门禁见 [`workbench-database-rollout.md`](workbench-database-rollout.md)。