feat(workbench): add dynamic task approval lifecycle

docs/operational-tasks.md

@@ -10,6 +10,12 @@
 预约任务采用单层结构：一张外围工单对应一条任务，工单快照直接提供状态、位置、负责人、预约时间、回执要求和按发生时间记录的 `activity`。活动仅由工单创建、修改或显式现场反馈产生；不能按当前状态补造派发、执行、复令三个阶段。旧快照中的 `subtasks` 仅在读取时兼容并丢弃，不回写外围工单或历史版本；后续外围修订同步为新结构。
 - `event_investigation`：投诉、爆管上报或人工发起的调查。Agent 查询受控数据，发布执行图、证据引用和报告；现场反馈会创建新的执行 generation，让 Agent 重新分析。
 
+调查计划由 Agent 按本次工单或人工请求动态生成。新计划使用 `execution-plan@2`，节点声明执行步骤、条件判断、并行分叉/汇合和审核点；判断节点记录所选路线，审核点引用持久化申请或动作。重新分析追加计划修订和新节点，不使用环形连线。旧 `execution-plan@1` 快照保留原样读取。字段、约束与示例见 [`dynamic-investigation-plan.md`](dynamic-investigation-plan.md)。
+
+数据读取申请通过 `POST /operational-tasks/{task_id}/access-requests` 创建，`POST .../access-requests/{access_request_id}/decision` 由具备项目审核权限及对应数据源读取权限的用户决定。申请、批准范围和审核身份保存在任务库中，批准或拒绝后重新排队分析。调查接口不会将服务身份继承的项目数据读取权限直接授予 Agent；批准的范围也只在该任务的有效执行期可查询。需配置 `OPERATIONAL_DATA_DELEGATION_BEARER` 为具备对应来源读取权限及该项目成员身份的专用产品凭证。未配置时返回 503，不以普通 Agent 会话的工具许可代替任务授权。
+
+工单草稿可通过 `PATCH .../actions/{action_id}/draft` 修改并增加审计版本；`POST .../actions/{action_id}/confirm-dispatch` 使用一次人工操作批准当前版本并幂等提交，结果不明时继续使用回执核对。其他动作类型维持既有审批接口，不在调查页伪装为已支持的工单编辑动作。
+
 创建请求使用 `request_id` 幂等。任务执行使用独立的 `run_id + execution_request_id`：Agent 必须领取当前 run，并通过 run 级心跳维持 60 秒租约。正常结束必须显式 complete；缺少同代最终计划或报告会以 `ARTIFACT_INCOMPLETE` 失败。`POST /operational-tasks/leases/recover` 会处理过期执行，连续三代超时后停止自动重试。
 
 ## 主要接口
@@ -25,11 +31,15 @@
 | `POST /operational-tasks/{task_id}/runs/{run_id}/complete` | 校验同代最终产物并显式结束 run |
 | `POST /operational-tasks/{task_id}/runs/{run_id}/fail` | 使用稳定失败码显式终止 run |
 | `POST /operational-tasks/{task_id}/data-query` | 查询固定白名单数据源，同时保存有界原始快照并返回证据 ID |
+| `POST /operational-tasks/{task_id}/access-requests` | Agent 创建任务级数据访问申请 |
+| `POST .../access-requests/{access_request_id}/decision` | 人工批准部分或全部申请范围，或拒绝申请 |
 | `POST /operational-tasks/{task_id}/agent-artifacts` | 追加证据、计划快照和报告修订 |
 | `POST /operational-tasks/{task_id}/human-evidence` | 保存用户补充信息并重新排队分析 |
 | `POST /operational-tasks/{task_id}/external-feedback` | 幂等同步稳定外部事件流的单调版本 |
 | `POST /operational-tasks/{task_id}/actions` | 提议需要人工确认的动作 |
 | `POST .../actions/{action_id}/decision` | 有对应审批权限的用户确认或拒绝 |
+| `PATCH .../actions/{action_id}/draft` | 人工修改工单草稿并产生新审核版本 |
+| `POST .../actions/{action_id}/confirm-dispatch` | 一次确认当前草稿并幂等下发工单 |
 | `POST .../actions/{action_id}/execute` | 重新校验执行权限后通过类型化适配器提交 |
 | `POST .../actions/{action_id}/reconcile` | 仅使用固定执行请求号查询不确定或已提交动作的回执 |
 | `GET /operational-task-notifications` | 返回当前用户可见、按用户区分已读状态的通知 |
@@ -54,15 +64,12 @@
 test "$(psql "$PROJECT_BIZ_DSN" -XAtc 'select current_database()')" = "tjwater_v2"
 ```
 
-完成备份和回滚演练后，再按依赖顺序应用。`017` 是工作台范围的注释迁移，要求告警、工单、任务和 Run 表均已存在：
+`008`、`011`、`014`、`015` 和 `017` 属于历史基线；不要在旧工单表退役后重新运行 `011`，否则会重建它。`019` 和 `022` 都带有 `tjwater_v2` 物理数据库名硬门禁，其他 BizDB 尚未应用。完成备份和回滚演练后，仅在已核对的 `tjwater_v2` 执行迁移：
 
 ```bash
-psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/008_workbench_alert_events.sql
-psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/011_workbench_work_orders.sql
-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
+psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/019_operational_task_access_requests.sql
+psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/021_retire_workbench_work_orders.sql
+psql "$PROJECT_BIZ_DSN" -v ON_ERROR_STOP=1 -f resources/sql/022_operational_notification_lifecycle.sql
 ```
 
-`017_workbench_schema_comments.sql` 只增加数据库可见的表、列和 schema 注释，不改变数据、约束或索引。`018_remove_synthetic_check_task_projections.sql` 读取 `peripheral_sample.work_orders` 的不可编辑创建者标识，删除错误进入预约任务的旧种子检查投影，不修改外围表，也不删除演示工单、事件工单或调查动作创建的工单。迁移不授予 `PUBLIC` 权限。生产运行前需按部署身份显式授予新表权限。SQL 文件包含自己的事务边界，不能把外层 `ROLLBACK` 当作演练；具体要求见数据库变更门禁。
+`017_workbench_schema_comments.sql` 只增加历史基线的数据库可见注释。`018_remove_synthetic_check_task_projections.sql` 只清理错误进入预约任务的旧种子检查投影。`020_prune_non_actionable_notifications.sql` 删除历史任务创建、报告更新和正常完成通知，保留审批与异常通知。`021` 只有在三条演示工单均已迁入外围样板并形成有效工况任务时才删除旧表，不修改外围源及历史修订。`022_operational_notification_lifecycle.sql` 仅限 `tjwater_v2`，为保留通知回填 `active|resolved` 生命周期和业务对象引用，不新增表。通知路由和状态流见 [`operational-notification-routing.md`](operational-notification-routing.md)。SQL 文件包含自己的事务边界，不能把外层 `ROLLBACK` 当作演练；具体要求见数据库变更门禁。