fix(workbench): remove synthetic check projections

docs/operational-task-workers.md

@@ -81,6 +81,8 @@ conda run -n server python scripts/sync_peripheral_work_orders.py
 
 使用相同工作身份，并配置 `OPERATIONAL_ACTION_PERIPHERAL_URL`。同步器读取分页工单，将外围版本投影到 `external_work_order` 任务。合成来源在摘要和证据中明确标注；工单完成只表示该外部任务完成，不代表其他调查自动完成。
 
+通用合成检查工单不属于预约任务。早期种子脚本创建的通信、压力和零流量检查工单已经退役，种子脚本不再恢复它们；同步器按不可编辑的专用 seed actor 跳过旧种子工单。投诉、爆管事件以及调查动作实际创建的现场工单继续同步。`018_remove_synthetic_check_task_projections.sql` 只清理专用 seed actor 创建的旧检查投影，不按用户可编辑的标题或状态删除任务，也不影响 `workbench.work_orders` 中保留的三条演示工单。
+
 水质投诉和爆管上报类型的外围工单同时创建关联调查，即使当时没有浏览器打开也会入队。两类事件从外围样板测试面板模拟上报；工况页负责展示调查。调查中创建的外围工单通过回执编号关联，后续反馈送回原调查，由 Agent 重新分析。
 
 ## 旧调查迁移

docs/operational-tasks.md

@@ -6,6 +6,8 @@
 
 - 定时任务：当前产品继续使用前端 mock。`scheduled_flow` 及后端计划接口为已有保留能力，不接当前前端、不由当前 worker 调度或执行。
 - `external_work_order`：外围预约、维修等工单的只读任务投影。`source.kind + source.external_id` 在项目内唯一，进度以外部版本反馈为准。
+
+预约任务采用单层结构：一张外围工单对应一条任务，工单快照直接提供状态、位置、负责人、预约时间、回执要求和按发生时间记录的 `activity`。活动仅由工单创建、修改或显式现场反馈产生；不能按当前状态补造派发、执行、复令三个阶段。旧快照中的 `subtasks` 仅在读取时兼容并丢弃，不回写外围工单或历史版本；后续外围修订同步为新结构。
 - `event_investigation`：投诉、爆管上报或人工发起的调查。Agent 查询受控数据，发布执行图、证据引用和报告；现场反馈会创建新的执行 generation，让 Agent 重新分析。
 
 创建请求使用 `request_id` 幂等。任务执行使用独立的 `run_id + execution_request_id`：Agent 必须领取当前 run，并通过 run 级心跳维持 60 秒租约。正常结束必须显式 complete；缺少同代最终计划或报告会以 `ARTIFACT_INCOMPLETE` 失败。`POST /operational-tasks/leases/recover` 会处理过期执行，连续三代超时后停止自动重试。
@@ -60,6 +62,7 @@ psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/011_workbench_work_o
 psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/014_operational_tasks.sql
 psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/015_workbench_events_and_task_runs.sql
 psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/017_workbench_schema_comments.sql
+psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/018_remove_synthetic_check_task_projections.sql
 ```
 
-`017_workbench_schema_comments.sql` 只增加数据库可见的表、列和 schema 注释，不改变数据、约束或索引。迁移不会创建或修改外围系统的业务表，也不授予 `PUBLIC` 权限。生产运行前需按部署身份显式授予新表权限。SQL 文件包含自己的事务边界，不能把外层 `ROLLBACK` 当作演练；具体要求见数据库变更门禁。
+`017_workbench_schema_comments.sql` 只增加数据库可见的表、列和 schema 注释，不改变数据、约束或索引。`018_remove_synthetic_check_task_projections.sql` 读取 `peripheral_sample.work_orders` 的不可编辑创建者标识，删除错误进入预约任务的旧种子检查投影，不修改外围表，也不删除演示工单、事件工单或调查动作创建的工单。迁移不授予 `PUBLIC` 权限。生产运行前需按部署身份显式授予新表权限。SQL 文件包含自己的事务边界，不能把外层 `ROLLBACK` 当作演练；具体要求见数据库变更门禁。

docs/peripheral-generated-data.md

@@ -44,7 +44,9 @@ CREATE TABLE peripheral_sample.demo_datasets (
 conda run -n server python scripts/seed_peripheral_sample.py --project-id <project-uuid>
 ```
 
-脚本使用固定 UUIDv5 请求号和专用 synthetic actor，重复执行会读取原幂等回执，不重复创建。它核验或补充 `water-demo-v1`，并创建 3 张测试工单和 12 条带 `DEMO-` 前缀的可编辑测试数据；不创建缺少合法 Action 来源的外围核查任务，不写正式工单、资产或监测表。
+脚本使用固定 UUIDv5 请求号和专用 synthetic actor，重复执行会读取原幂等回执，不重复创建。它核验或补充 `water-demo-v1`，并创建 12 条带 `DEMO-` 前缀的可编辑测试数据；不再创建早期用于检查通信、压力和零流量展示的三张测试工单，也不创建缺少合法 Action 来源的外围核查任务，不写正式工单、资产或监测表。
+
+通过工单接口新建的预约工单不再包含子任务和固定阶段。创建请求可直接填写 `feedback_requirements`；修改请求可填写 `progress_note`，它只追加一条有时间、操作者和正文的活动记录，不作为工单顶层字段保存。旧工单读取时去掉 `subtasks`，历史修订仍保留原样。
 
 ## 演示历史窗口配置
 

docs/workbench-database-rollout.md

@@ -8,6 +8,10 @@
 
 `017_workbench_schema_comments.sql` 只为 `workbench` schema 及其 17 张表和关键列增加数据库可见注释。它先在 `tjwater_v2` 应用；其他项目数据库保持原状，直到 `tjwater_v2` 验证通过并获得明确扩展确认。
 
+`018_remove_synthetic_check_task_projections.sql` 清理曾被错误同步为预约任务的通用合成检查投影。它按完整 `peripheral_sample:<work_order_id>` 标识关联外围源，只匹配 `general` 类型、没有调查动作回执关联且由专用 seed actor 创建的旧检查任务；不使用用户可编辑的标题或工单状态作为删除依据。`workbench.work_orders` 中三条演示工单、投诉与爆管事件以及调查产生的现场采样工单均不在清理范围。同步器使用同一专用 seed actor 阻止旧种子检查再次生成。
+
+预约工单结构调整无需 DDL。`seed_workbench_work_orders.py --project-id <已核对的项目 UUID>` 只重建该项目的三条演示预约投影，保留工单 ID 和标题，改为单层字段与显式活动记录。执行前必须核对脚本删除谓词实际命中的 ID；它不修改 `peripheral_sample.work_orders`、历史修订或调查任务。其他项目不得随 `tjwater_v2` 自动重建。
+
 后续数据库变更默认只写入 `tjwater_v2`。其他项目保持现状，必须等 `tjwater_v2` 验证通过并由维护者明确确认后，再逐库扩展。禁止把“所有活跃项目”作为写操作的默认范围。
 
 ## 变更顺序

docs/workbench-operations-storage.md

@@ -12,11 +12,12 @@ DDL 位于 `resources/sql/008_workbench_alert_events.sql`。任务通过 `POST /
 
 `resources/sql/017_workbench_schema_comments.sql` 在 `008`、`011`、`014` 和 `015` 之后执行，为工作台 schema、17 张表和关键列增加数据库可见的用途说明。
 
-- 一张主工单包含一个或多个 `subtasks`。
-- 每个子任务保存自己的位置、班组、时间窗和复令要求。
-- 每个子任务包含一个或多个有序 `stages`，`sequence` 从 1 连续递增，阶段编号在子任务内唯一，最多只有一个 `current` 阶段。
-- 阶段名称不写死为固定枚举。演示数据使用派发、执行、复令，正式工单适配器可以按业务定义其他阶段。
+- 一张预约工单对应一条单层投影，直接保存位置、负责人、预约时间和回执要求。
+- `activity` 只记录已经发生的创建、修改和现场反馈，按递增 `sequence` 排列；展示层不得根据工单总状态补造派发、执行或复令阶段。
+- 旧文档中的 `subtasks` 在兼容读取时被丢弃，不再进入新接口契约；历史修订保留原始审计内容。
 
-预约任务演示数据通过 `scripts/seed_workbench_work_orders.py` 直接写入。工作台会显示三张原有 mock 工单，分别处于派发、执行和复令阶段；每张工单都保留自己的子任务与有序阶段。脚本可重复执行，并会先清理旧的外围合成工单投影。外围种子脚本仍会恢复被软删除的固定演示资源。
+预约任务演示数据通过 `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`。