feat: expose workflow runtime through HTTP and Go SDK

2026-09-18 06:51:08 +08:00
parent af1ae4cb21
commit b9e4191c6b
50 changed files with 2221 additions and 143 deletions
--- a/docs/03-http-websocket-protocol.md
+++ b/docs/03-http-websocket-protocol.md
@@ -33,21 +33,21 @@

 应用、凭据、队列、配额和审计管理接口沿用同一鉴权、版本与错误规范，其完整路径清单在接口评审时补齐。就绪检查必须反映关键依赖，数据库不可用时不能继续宣称可安全接单。

-Weave 的补充接口建议如下，功能范围已确认，具体技术细则以 [流程设计](06-workflow-spec.md) 为准：
+Weave以下接口已接入公共HTTP与SDK，具体字段和权限以[实例接口](api/workflows.md)、[恢复接口](api/workflow-recovery.md)为准：

 | 方法与路径 | 行为 |
 | --- | --- |
 | `POST /v1/workflow-definitions/{definition_id}/versions` | 研发通过 SDK 发布不可变定义；同版本同内容幂等，不同内容冲突 |
 | `POST /v1/workflows` | 幂等启动流程，固定定义版本 |
 | `GET /v1/workflows/{workflow_id}` | 查询实例、定义版本、执行状态、暂停标记与等待摘要 |
-| `GET /v1/workflows/{workflow_id}/steps` | 分页查询步骤、输入/结果引用、激活、查询轮次、已用预算与关联任务 |
+| `GET /v1/workflows/{workflow_id}/steps` | 按键返回最多128项步骤元数据；单个步骤详情另用`/steps/{key}`读取输入/输出、等待和查询预算 |
 | `POST /v1/workflows/{workflow_id}/signals` | 幂等受理信号，不等于信号已经被消费 |
 | `GET /v1/workflows/{workflow_id}/signals/{signal_id}` | 查询信号受理、匹配与消费结果 |
-| `POST /v1/workflows/{workflow_id}:pause` | 持久化暂停门控与审计；不代表在途业务已停止 |
-| `POST /v1/workflows/{workflow_id}:resume` | 解除暂停并安排受控推进；不重置预算、核查状态或原版本 |
-| `POST /v1/workflows/{workflow_id}:cancel` | 记录取消意图，结清关联工作 |
+| `POST /v1/workflows/{workflow_id}/control` | PAUSE/RESUME/CANCEL；按control_revision保存门控与意图 |
+| `POST /v1/workflows/{workflow_id}/recovery/*` | 六类有证据恢复，按当前实例/步骤/任务版本核对 |
+| `GET /v1/workflows/{workflow_id}/operations` | 有界分页读取流程操作审计摘要，正文另用单条查询 |

-流程列表、事件查询与人工核查/恢复接口待细化；恢复必须带预期状态版本、稳定操作身份、原因与证据，不提供任意修改状态的通用入口。
+流程列表和完整历史查询仍待交付；恢复必须带预期状态版本、稳定操作身份、原因与证据，不提供任意修改状态的通用入口。

 暂停和继续使用独立管理权限、预期控制版本、幂等操作身份与原因；同一操作重报返回原确认，过期控制版本不能覆盖后来的操作。建议 `200` 确认门控已提交，后续执行进度通过查询观察；门控失效条件和终态操作错误在协议评审时固定。

--- a/docs/06-workflow-spec.md
+++ b/docs/06-workflow-spec.md
@@ -1,6 +1,6 @@
 # Weave 流程编排功能与设计

-> 版本 0.9 · 2026-09-18。首版功能范围已确认。定义结构、发布校验与不可变版本已实现，见[定义格式](api/workflow-definition-format.md)和[发布API](api/workflow-definitions.md)；[实例受理](11-workflow-admission.md)、[结果消费与根推进](12-workflow-runtime.md)、[TIMER与POLL时钟](13-workflow-clock.md)已接入。[信号等待及最终查询竞争](14-workflow-signals.md)已接入内部运行器；[暂停/继续/取消与停止结清](15-workflow-controls.md)已实现内部链路；[人工核查与TASK恢复](16-workflow-recovery.md)已接入内部服务；[POLL跨激活恢复](17-workflow-poll-recovery.md)和[等待恢复](18-workflow-wait-recovery.md)已接入；实例公共API/SDK仍待P4–P5实现验收。
+> 版本 0.10 · 2026-09-18。首版功能范围已确认。定义结构、发布校验与不可变版本已实现，见[定义格式](api/workflow-definition-format.md)和[发布API](api/workflow-definitions.md)；[实例受理](11-workflow-admission.md)、[结果消费与根推进](12-workflow-runtime.md)、[TIMER与POLL时钟](13-workflow-clock.md)已接入。[信号等待及最终查询竞争](14-workflow-signals.md)已接入内部运行器；[暂停/继续/取消与停止结清](15-workflow-controls.md)已实现内部链路；[人工核查与TASK恢复](16-workflow-recovery.md)已接入内部服务；[POLL跨激活恢复](17-workflow-poll-recovery.md)和[等待恢复](18-workflow-wait-recovery.md)已接入；[实例公共API/SDK](api/workflows.md)已接入；完整历史、来源及生产验收仍需交付。

 ## 1. 职责与边界

@@ -174,7 +174,7 @@ Weave 不执行特定业务逻辑，也不把整段业务代码放入平台进
 3. 在一个事务内记录管理操作，创建新的步骤激活及关联 Pulse 任务，并固定关联关系。
 4. 保留旧激活与旧任务结果，沿用恰当的业务幂等身份。

-执行核查、步骤结论、解除核查及TASK新激活已按[人工恢复约定](16-workflow-recovery.md)实现内部服务，原预算和绝对截止不重置；[POLL跨激活恢复](17-workflow-poll-recovery.md)已接入，等待恢复已接入内部服务，公共API另行交付。普通任务人工重试入口应拒绝绕过流程管理的关联任务请求。已经确认成功的步骤不能通过“重试流程”随意再执行一次。
+执行核查、步骤结论、解除核查及TASK新激活已按[人工恢复约定](16-workflow-recovery.md)实现内部服务，原预算和绝对截止不重置；[POLL跨激活恢复](17-workflow-poll-recovery.md)已接入，等待恢复已接入内部服务，公共API已接入，见[恢复接口](api/workflow-recovery.md)。普通任务人工重试入口应拒绝绕过流程管理的关联任务请求。已经确认成功的步骤不能通过“重试流程”随意再执行一次。

 取消和补偿是不同业务操作。若未来增加补偿，补偿本身也必须是有权限、可审计、可重试或可核查的业务步骤；不能宣称撤销流程就能撤回已经生效的外部业务操作。

--- a/docs/08-development-plan.md
+++ b/docs/08-development-plan.md
@@ -28,24 +28,24 @@
 | P1 任务受理闭环 | 应用凭据与作用域权限、队列、幂等提交、查询、待执行取消、受理事件；SDK 客户端 | API/SDK 创建查询闭环；重复键与内容冲突、响应未确认重报、跨命名空间拒绝、参数边界 | 已完成并通过阶段回归（见 P1 报告；真实断路/提交 ACK 丢失注入留后续故障阶段） |
 | P2 Worker 执行闭环 | WSS 接入、能力/容量、领取与开始、租约、续租、结果确认、排空与恢复；Worker SDK | 真 Worker 执行；失联/重连/重复确认/旧尝试拒绝；业务效果未知转核查；节点故障接管 | 已完成并通过阶段回归：服务端、自动 SDK、历史查询、完整 Schema 与真实进程强杀恢复；测试拓扑和剩余生产故障矩阵见 P2 验收报告 |
 | P3 Pulse 完整能力 | 安全重试、延时、Cron/固定间隔、漏跑策略、计划版本、运行中取消、并发许可、配额/背压、可靠结果订阅、批量受理、独立任务核查/人工重试、查询筛选与事务Outbox接入 | 多实例领取/触发竞争、重试上限、取消竞争、队列隔离、积压恢复、事件重复交付 | 已完成平台功能阶段验收：[原范围逐项核对](reports/phase-3.md)、[本轮完整回归](reports/phase-3-delay-recovery.md)。补齐相对延迟、改参数关联示例和四种重试全停恢复场景；20个可运行示例全部通过。全平台生产门槛及SDK首版交付剩余项仍按P6–P7推进 |
-| P4 Weave 主流程 | SDK 定义构建与发布校验、实例、顺序/分支/结构化并行汇合、信号/定时等待、版本绑定 | 重启接续、早到/重复信号、并行竞争、内部事件重放、发布版本兼容；端到端通用流程 | 定义格式/词法类型校验、不可变发布、独立SDK及六类节点定义例子已实现，已通过[子项验收](reports/phase-4-definitions.md)；已补[有限决策器及内部结果交付](reports/phase-4-engine-core.md)；[实例受理及首批事务](reports/phase-4-admission.md)已实现；[结果消费和根接续](reports/phase-4-runtime.md)已接入后台，顺序/分支/并行及真实进程恢复已验证；[TIMER与后续POLL轮次](13-workflow-clock.md)已接入；[信号消费和最终查询竞争](14-workflow-signals.md)已接入内部运行器；[内部控制与停止结清](15-workflow-controls.md)已接入；[内部核查与TASK新激活](16-workflow-recovery.md)已接入；等待恢复已接入内部服务；实例公共API/SDK继续开发 |
-| P5 Weave 恢复与查询 | 有界查询、暂停继续、取消、人工核查恢复、控制门控与审计 | 轮次与尝试独立预算；暂停/开始/回执/超时竞争；恢复保留预算；未知结果不盲目重复 | 有界查询轮次/尝试独立预算及原截止恢复已接入内部运行器；最终信号竞争及在途查询结清已接入；内部暂停/继续/取消与失败结清已接入；执行核查、步骤结论、解除核查及TASK新激活已接入；[POLL跨激活恢复](17-workflow-poll-recovery.md)已接入；等待恢复已接入内部服务；公共API/SDK继续开发 |
+| P4 Weave 主流程 | SDK 定义构建与发布校验、实例、顺序/分支/结构化并行汇合、信号/定时等待、版本绑定 | 重启接续、早到/重复信号、并行竞争、内部事件重放、发布版本兼容；端到端通用流程 | 定义格式/词法类型校验、不可变发布、独立SDK及六类节点定义例子已实现，已通过[子项验收](reports/phase-4-definitions.md)；已补[有限决策器及内部结果交付](reports/phase-4-engine-core.md)；[实例受理及首批事务](reports/phase-4-admission.md)已实现；[结果消费和根接续](reports/phase-4-runtime.md)已接入后台，顺序/分支/并行及真实进程恢复已验证；[TIMER与后续POLL轮次](13-workflow-clock.md)已接入；[信号消费和最终查询竞争](14-workflow-signals.md)已接入内部运行器；[内部控制与停止结清](15-workflow-controls.md)已接入；[内部核查与TASK新激活](16-workflow-recovery.md)已接入；等待恢复已接入内部服务；实例公共API/SDK与基础可运行场景已接入；完整历史、来源与更多场景继续开发 |
+| P5 Weave 恢复与查询 | 有界查询、暂停继续、取消、人工核查恢复、控制门控与审计 | 轮次与尝试独立预算；暂停/开始/回执/超时竞争；恢复保留预算；未知结果不盲目重复 | 有界查询轮次/尝试独立预算及原截止恢复已接入内部运行器；最终信号竞争及在途查询结清已接入；内部暂停/继续/取消与失败结清已接入；执行核查、步骤结论、解除核查及TASK新激活已接入；[POLL跨激活恢复](17-workflow-poll-recovery.md)已接入；等待恢复已接入内部服务；公共API/SDK已接入；完整历史、来源与更多场景继续开发 |
 | P6 生产验证与运维 | 完整监控、凭据轮换、备份恢复、滚动升级、运行手册、可复现负载和故障工具 | 对照生产验收清单执行，报告环境/指标/遗留项；容量、RPO/RTO 按真实拓扑验证 | 待开发 |
 | P7 首版交付核对 | SDK 兼容与发布准备、完整 API 手册、场景示例、全量回归及交付清单 | 新接入者按文档跑通全部示例；所有首版能力可追溯到实现与测试；报告实际生产边界 | 待开发 |

 SDK、文档与示例随 P1–P5 同步开发，P7 是全量核对，不是最后才开始补文档。

-P4/P5定时等待与后续查询轮次的实现及回归记录见[时钟报告](reports/phase-4-clock.md)。外部信号与最终查询竞争见[信号报告](reports/phase-4-signals.md)。实例公共入口继续与控制能力同步交付，不能将内部存储链路作为完整SDK验收。
+P4/P5定时等待与后续查询轮次的实现及回归记录见[时钟报告](reports/phase-4-clock.md)。外部信号与最终查询竞争见[信号报告](reports/phase-4-signals.md)。公共实例、控制、信号、六类恢复和操作审计已接入HTTP与独立SDK，见[公共接入报告](reports/phase-5-public-api.md)。完整历史和来源仍须完成。

 ### P4/P5 下一步实施顺序

 1. 已实现FAIL_AFTER_SETTLED与显式取消的内部分支结清，见[控制报告](reports/phase-5-controls.md)：持久取消意图、复用Pulse取消、收集已发出查询/任务结果、等待全部已激活工作结清后才进入失败或取消终态。效果未知仍保留核查。
 2. 已实现实例暂停/继续/取消内部操作，以control_revision、操作幂等身份、明确原因及审计保护控制决定；暂停不延长原截止，继续不覆盖核查或取消状态。
 3. 已实现内部执行核查、步骤结论、解除核查及TASK新激活和旧激活隔离，见[核查报告](reports/phase-5-recovery.md)。POLL跨激活恢复已实现（见[查询恢复](17-workflow-poll-recovery.md)）；[核查后PENDING接续和独立等待重建](18-workflow-wait-recovery.md)也已接入内部服务，保留原预算、轮次、结果和证据。
-4. 同步开放实例/步骤/信号/来源/审计HTTP、独立SDK和端到端场景，覆盖原键恢复、权限、版本冲突、竞争与进程全停；公共步骤/激活查询须返回目标激活代次，调用方据此发送恢复后的信号，不能要求调用方自行猜测sequence。公共能力逐项记录实际验收结果。
+4. 实例/当前步骤/信号/控制/六类恢复及流程操作审计HTTP和独立SDK已接入，步骤查询返回实际激活代次；并行执行与信号回执场景已有可运行示例。继续补齐实例筛选分页、完整激活/轮次/信号历史、信号资源审计与Pulse任务流程来源，并提供独立轮询及恢复示例。逐项验证原键恢复、权限、版本冲突、竞争与进程全停。
 5. 转入P6/P7的生产故障、容量、运维、发布与全部文档核对。内部存储阶段通过不会提前勾选公共接口或生产验收。

-公共接入下一批按以下调用链交付，逐项补齐服务端、独立SDK、Markdown手册和真实HTTP回归：
+公共接入按以下调用链推进；本批已接入启动/当前详情、控制、信号、六类恢复和流程操作审计，并提供独立SDK及基础示例。以下历史、来源、分页和更多独立场景继续交付：

 | 调用链 | 需要补齐的内容 | 验收重点 |
 | --- | --- | --- |
@@ -105,10 +105,10 @@ P4/P5定时等待与后续查询轮次的实现及回归记录见[时钟报告](
 | 业务操作定位 | 精确业务键 → 创建区间 → 游标分页 → 查询详情 | P3，已实现完整示例 |
 | 独立任务人工恢复 | 未知结果 → 证据核查 → 保留原任务 → 关联新任务 → 审计查询 | P3，已实现完整示例 |
 | 研发定义发布 | 六类节点描述 → 校验/发布 → 原键确认 → 新版本 → 读取旧版本 | P4定义子项，[已实现示例](examples/workflow-definition.md) |
-| 并行生成结果 | 发布流程 → 并行执行 → 汇合 → 完成 | P4 |
-| 审核与外部回执 | 提交流程 → 等待信号 → 授权信号注入 → 继续 | P4 |
-| 外部作业轮询 | 提交一次 → 有界查询处理中状态 → 回执或最终结果 → 超限核查 | P5 |
-| 暂停与人工恢复 | 暂停 → 保存结果 → 核查/恢复 → 查看审计 | P5 |
+| 并行生成结果 | 发布流程 → 并行执行 → 汇合 → 完成 | P4，[已实现示例](examples/workflow.md) |
+| 审核与外部回执 | 提交流程 → 等待信号 → 授权信号注入 → 继续 | P4，[已实现模拟外部回执示例](examples/workflow.md)；实际外部系统由接入方对接 |
+| 外部作业轮询 | 提交一次 → 有界查询处理中状态 → 回执或最终结果 → 超限核查 | P5，HTTP/SDK恢复场景已回归，独立可运行示例待补 |
+| 暂停与人工恢复 | 暂停 → 保存结果 → 核查/恢复 → 查看审计 | P5，HTTP/SDK及审计场景已回归，独立可运行示例待补 |
 | 故障恢复 | 节点/连接中断 → 相同身份核对 → 恢复或人工核查 | P2–P6 |
 | 执行历史核对 | 读取尝试 → 查看冲突/迟到证据 → 对照权威结果 | P2，已实现完整示例 |

@@ -130,6 +130,11 @@ P4/P5定时等待与后续查询轮次的实现及回归记录见[时钟报告](

 ## 7. 文档入口

+- [流程实例公共API](api/workflows.md)
+- [流程恢复API及SDK](api/workflow-recovery.md)
+- [并行作业与回执示例](examples/workflow.md)
+- [公共接入验证记录](reports/phase-5-public-api.md)
+
 - [等待恢复](18-workflow-wait-recovery.md)
 - [等待恢复验证记录](reports/phase-5-wait-recovery.md)
 - [有界查询恢复](17-workflow-poll-recovery.md)
--- a/docs/10-workflow-engine-core.md
+++ b/docs/10-workflow-engine-core.md
@@ -74,7 +74,7 @@ v16及以前的未处理记录缺少冻结来源，升级后统一标为QUARANTI

 ## 4. 后续存储适配必须满足的条件

-以下保留存储运行器的完整要求。第1项已按[受理报告](reports/phase-4-admission.md)验证；第2–4项结果消费和根接续已接入[实际运行器](12-workflow-runtime.md)，第5项的TIMER/POLL已接入[时钟运行器](13-workflow-clock.md)，第5项的信号等待已接入[信号运行器](14-workflow-signals.md)，内部控制与结清已接入[控制运行器](15-workflow-controls.md)，[核查与TASK新激活](16-workflow-recovery.md)已接入；接口和SDK仍继续实现：
+以下保留存储运行器的完整要求。第1项已按[受理报告](reports/phase-4-admission.md)验证；第2–4项结果消费和根接续已接入[实际运行器](12-workflow-runtime.md)，第5项的TIMER/POLL已接入[时钟运行器](13-workflow-clock.md)，第5项的信号等待已接入[信号运行器](14-workflow-signals.md)，内部控制与结清已接入[控制运行器](15-workflow-controls.md)，[核查与TASK新激活](16-workflow-recovery.md)已接入；公共接口和SDK已接入，完整历史及来源继续实现：

 1. 启动时认证、固定不可变版本/输入和策略、校验全部队列、计算实例截止，并在同事务创建实例、门控、首批激活/任务及审计回执。相同身份返回原实例。
 2. 消费者领取内部事件后核对命名空间、来源任务版本、激活/轮次及当前步骤版本；消费确认、步骤变化、后续任务或持久化待续记录同事务提交。
--- a/docs/11-workflow-admission.md
+++ b/docs/11-workflow-admission.md
@@ -1,6 +1,6 @@
 # Weave 实例受理与首批工作

-状态：内部Go服务与MySQL存储适配已实现实例Start/Get/Steps、固定版本、首批决策落库和可靠结果交付。[后台Inbox消费和根待续扫描](12-workflow-runtime.md)已接通。**尚未开放实例HTTP路由、启动SDK或命令行入口；[内部控制和结清](15-workflow-controls.md)已接入，[内部核查及TASK恢复](16-workflow-recovery.md)已接入，等待恢复已接入内部服务，公共API/SDK继续开发；[信号运行器](14-workflow-signals.md)已接入。** Weave相关公开SDK目前仅支持定义发布。[TIMER和后续POLL轮次](13-workflow-clock.md)已接入，TASK及组合节点已可自动推进，不能将此解释成全部等待/控制能力已实现。
+状态：实例Start/Get/Steps、单步详情、固定版本、首批事务及后台推进已实现，并已接入[公共HTTP与独立SDK](api/workflows.md)。控制、信号、人工恢复见[恢复API](api/workflow-recovery.md)。当前视图与操作审计可读，完整历史、实例列表和生产验收继续交付。

 ## 1. 受理事务

--- a/docs/12-workflow-runtime.md
+++ b/docs/12-workflow-runtime.md
@@ -1,6 +1,6 @@
 # Weave 结果消费与自动推进

-状态：内部实例的TASK结果消费、顺序、分支、有限并行汇合和根检查点接续已接入Orbit后台运行器。[定时等待和后续查询轮次](13-workflow-clock.md)也已接入。[信号等待与最终查询竞争](14-workflow-signals.md)已接入。实例公共HTTP/SDK仍未开放，[失败后的分支取消结清与内部控制](15-workflow-controls.md)已接入，[内部核查及TASK恢复](16-workflow-recovery.md)已接入，等待恢复已接入内部服务，公共API/SDK继续开发，不能将本阶段等同于完整Weave交付。
+状态：TASK结果消费、顺序、分支、有限并行汇合、根检查点、TIMER/POLL及信号等待已接入Orbit后台。实例、控制、信号与恢复已经提供[公共API及独立SDK](api/workflows.md)。完整历史查询和生产验收继续按计划推进。

 ## 1. 后台运行和事务边界

@@ -64,4 +64,4 @@ flowchart LR

 进程回归由`make integration`构建二进制后显式执行。缺少一次性数据库或`ORBIT_TEST_SERVER_BINARY`时测试会跳过；跳过不构成进程恢复证据。验证记录见[本阶段报告](reports/phase-4-runtime.md)。

-持久化信号等待及查询最终信号竞争已按[信号运行约定](14-workflow-signals.md)实现。内部控制及停止结清也已接入。下一步仍包括实例/来源公共API、独立SDK和通用端到端场景。P4整体及P5–P7继续按[完整计划](08-development-plan.md)执行。
+持久化信号等待及查询最终信号竞争已按[信号运行约定](14-workflow-signals.md)实现。内部控制及停止结清也已接入。实例公共API与独立SDK已接入，下一步包括完整历史、来源公共API及更多通用场景。P4整体及P5–P7继续按[完整计划](08-development-plan.md)执行。
--- a/docs/13-workflow-clock.md
+++ b/docs/13-workflow-clock.md
@@ -50,7 +50,7 @@ TIMER由待续表直接唤醒，不创建Pulse业务任务，也不占Worker执

 当前任务仍在途且查询总截止已到时，实例转NEEDS_REVIEW并关闭新执行门控；步骤保持ACTIVE、轮次保持当前任务引用，继续收集Pulse结果。时钟不释放执行许可，也不假定外部请求已经停止。Pulse恢复将失联执行记录为UNKNOWN后，内部消费再结清当前查询记录，保留核查状态。

-最终信号与在途查询的竞争已按[信号运行约定](14-workflow-signals.md)接入：保存赢家后等待Pulse查询结清，不能提前释放许可或覆盖未知效果。实例及信号公共HTTP/SDK尚未开放。
+最终信号与在途查询的竞争已按[信号运行约定](14-workflow-signals.md)接入：保存赢家后等待Pulse查询结清，不能提前释放许可或覆盖未知效果。实例及信号公共HTTP/SDK已接入，见[实例接口](api/workflows.md)。

 ## 5. 升级和验证

--- a/docs/14-workflow-signals.md
+++ b/docs/14-workflow-signals.md
@@ -1,6 +1,6 @@
 # Weave 外部信号与最终查询结果

-状态：内部 Go 信号受理/查询、SIGNAL 等待、早到保存、截止处理及 POLL 最终信号竞争已接入 MySQL 和后台运行器。**实例与信号的公共 HTTP/独立 SDK 尚未开放**；内部控制和失败分支结清已按[控制约定](15-workflow-controls.md)接入；人工恢复继续按[持续计划](08-development-plan.md)实现。定义发布 SDK 不等于实例运行 SDK。
+状态：信号受理/查询、SIGNAL等待、早到保存、截止处理及POLL最终信号竞争已接入MySQL和后台运行器，并已提供[公共HTTP与独立SDK](api/workflows.md#5-有身份的外部信号)。控制和人工恢复也已接入；完整历史与更多场景继续按[计划](08-development-plan.md)推进。

 ## 1. 受理身份与权限

@@ -65,4 +65,4 @@

 [受理回归](../internal/storage/mysql/workflow_signals_integration_test.go)、[消费回归](../internal/storage/mysql/workflow_signal_runtime_integration_test.go)、[真实v19升级](../internal/storage/mysql/workflow_signal_upgrade_integration_test.go)和[实际进程恢复](../internal/storage/mysql/workflow_runtime_process_integration_test.go)对应受理/并发/故障/升级边界，实际运行结果记录在[阶段报告](reports/phase-4-signals.md)。

-内部失败分支取消结清、实例暂停/继续/取消已接入。人工核查及[POLL新激活的最终信号换代](17-workflow-poll-recovery.md)已接入；[PENDING接续与独立等待重建](18-workflow-wait-recovery.md)已接入内部服务，下一步交付实例与信号HTTP、独立SDK及完整场景。当前内部存储测试不替代尚未开放的公共接口验收，也不替代生产MySQL切换与容量测试。
+内部失败分支取消结清、实例暂停/继续/取消已接入。人工核查及[POLL新激活的最终信号换代](17-workflow-poll-recovery.md)已接入；[PENDING接续与独立等待重建](18-workflow-wait-recovery.md)已接入内部服务，实例与信号HTTP、独立SDK和基础场景已接入，完整历史及更多场景继续交付。公共接入验收另见[报告](reports/phase-5-public-api.md)，也不替代生产MySQL切换与容量测试。
--- a/docs/15-workflow-controls.md
+++ b/docs/15-workflow-controls.md
@@ -1,6 +1,6 @@
 # Weave 控制与停止结清

-状态：内部Go暂停、继续、取消服务及后台失败/取消结清运行器已接入。**公共实例/控制HTTP与独立SDK尚未开放，[内部核查及TASK新激活](16-workflow-recovery.md)已接入，等待恢复已接入内部服务，公共入口仍在后续交付范围**。本文说明已实现的持久化规则，不把内部存储回归当作全部Weave或生产验收。
+状态：暂停、继续、取消与后台失败/取消结清已实现，并通过[公共控制API及SDK](api/workflows.md#4-暂停继续与取消)调用。人工恢复另见[恢复API](api/workflow-recovery.md)。当前功能回归不等同于生产验收。

 ## 1. 控制操作

@@ -60,4 +60,4 @@ CANCELLED仅表示本次流程停止已结清，不撤销先前成功的业务

 [控制及结清回归](../internal/storage/mysql/workflow_controls_integration_test.go)覆盖控制版本、权限重报、开始竞争、失败/未知、审计回滚、信号与查询及超过32步骤接续；[真实v20升级](../internal/storage/mysql/workflow_stop_upgrade_integration_test.go)验证兼容回填；[实际Orbit进程回归](../internal/storage/mysql/workflow_runtime_process_integration_test.go)覆盖停止意图和结果在全停期间保存后由两个新进程接续。实际结果见[阶段报告](reports/phase-5-controls.md)。

-下一步仍需完成公共实例/控制/信号/审计接口、独立SDK及可运行场景，再完成P6–P7生产故障、性能、运维和发布验收。当前测试不替代生产MySQL复制、故障切换、备份恢复或RPO/RTO验证。
+公共实例/控制/信号/审计接口、独立SDK及基础可运行场景已接入，下一步补齐完整历史、来源与更多场景，再完成P6–P7生产故障、性能、运维和发布验收。当前测试不替代生产MySQL复制、故障切换、备份恢复或RPO/RTO验证。
--- a/docs/16-workflow-recovery.md
+++ b/docs/16-workflow-recovery.md
@@ -1,6 +1,6 @@
 # Weave 人工核查与接续

-状态：内部Go服务已提供执行核查、步骤结论确认、解除核查，以及TASK/POLL新激活重试。POLL跨激活预算与附属信号换代见[查询恢复](17-workflow-poll-recovery.md)。公共HTTP、独立SDK和通用接入示例尚未交付；[PENDING接续及独立等待重建](18-workflow-wait-recovery.md)已接入内部服务。完整交付继续按[开发计划](08-development-plan.md)推进。
+状态：执行核查、步骤结论、解除核查、TASK/POLL新激活、PENDING等待接续和SIGNAL/TIMER换代已实现，并接入[六类公共恢复API及SDK](api/workflow-recovery.md)。当前详情与管理审计可读，完整历史和生产验收继续按[计划](08-development-plan.md)推进。

 ## 1. 六类操作

@@ -74,6 +74,6 @@ POLL跨激活恢复已实现，保留原业务轮、同轮剩余尝试、查询
 | POLL次数耗尽，人工取得最终结果 | 核实历史请求均已结束 → ResolveStep(符合固定成功映射的结果) → Continue；原used_rounds不改变 |
 | 取消后出现UNKNOWN | ReviewTask → 等待消费 → ResolveStep → Continue → 原取消结清；不创建后继工作 |

-这些是内部服务流程说明，公共接入方目前不能调用未开放的HTTP路由或SDK。后续接口文档和可运行场景须覆盖相同证据与版本要求。
+以上内部操作已通过[公共恢复API及SDK](api/workflow-recovery.md)提供，六类真实服务场景保留相同证据与版本要求。

 [存储专项](../internal/storage/mysql/workflow_recovery_integration_test.go)、[实际进程测试](../internal/storage/mysql/workflow_runtime_process_integration_test.go)和[阶段报告](reports/phase-5-recovery.md)记录验证范围。本阶段不替代生产数据库高可用、灾难恢复和容量验收。
--- a/docs/17-workflow-poll-recovery.md
+++ b/docs/17-workflow-poll-recovery.md
@@ -1,6 +1,6 @@
 # Weave 有界查询的人工恢复

-状态：内部 `RetryStep` 已支持 POLL 新激活，保留跨激活的业务轮次、同轮剩余尝试和绝对截止；附属最终信号等待随新激活换代。[核查后PENDING接续和独立等待重建](18-workflow-wait-recovery.md)已接入内部服务，公共实例/恢复 HTTP、独立 SDK 和可运行接入示例继续按[开发计划](08-development-plan.md)交付。验证范围见[阶段报告](reports/phase-5-poll-recovery.md)。
+状态：POLL新激活保留跨激活的轮次、同轮尝试和原绝对截止，附属信号随新激活换代；已通过[公共恢复API](api/workflow-recovery.md)提供独立SDK。PENDING等待接续见[等待恢复](18-workflow-wait-recovery.md)，历史实现验证见[报告](reports/phase-5-poll-recovery.md)。完整历史、通用接入场景及生产验证继续交付。

 ## 1. 业务轮次与请求尝试

@@ -50,7 +50,7 @@ POLL 带最终信号时，恢复创建同契约、同精确关联键、同原截

 当前代次仍有 PENDING 信号时，先消费这些事实，恢复拒绝直接丢弃。已有赢家时核对其受理证明与关联后保留历史。最终信号原截止已过时不重新开始等待。

-这些规则覆盖 POLL 附属等待；独立 SIGNAL/TIMER 使用[RearmWait](18-workflow-wait-recovery.md)，公共接口仍待交付。
+这些规则覆盖 POLL 附属等待；独立 SIGNAL/TIMER 使用[RearmWait](18-workflow-wait-recovery.md)，公共接口已接入。

 ## 5. 内部调用场景

--- a/docs/18-workflow-wait-recovery.md
+++ b/docs/18-workflow-wait-recovery.md
@@ -1,6 +1,6 @@
 # Weave 等待核查与恢复

-状态：内部服务已实现 `ContinuePoll` 和 `RearmWait`，均使用[人工恢复的权限、版本、证据及原键回执规则](16-workflow-recovery.md)。公共流程 HTTP、独立 SDK、通用可运行场景与生产验收继续按[开发计划](08-development-plan.md)交付；本页不是公共 SDK 调用示例。
+状态：ContinuePoll和RearmWait已实现，并已接入[公共恢复HTTP及独立SDK](api/workflow-recovery.md)。均遵守[人工恢复权限、版本、证据及原键规则](16-workflow-recovery.md)。本页说明内部持久化语义，完整历史和生产验收继续按[计划](08-development-plan.md)推进。

 ## 1. 两类操作

--- a/docs/api/README.md
+++ b/docs/api/README.md
@@ -26,8 +26,9 @@
 | `/v1/schedules`、不可变版本、暂停/恢复及触发查询 | P3 已实现 | [计划接口与 SDK 场景](schedules.md) |
 | `/v1/subscriptions` 及管理、交付查询与重试 | 已实现 HTTP、管理 SDK 和完整管理示例 | [订阅手册](subscriptions.md) |
 | `/v1/events/connect` | 已实现 WSS、消息 Schema、连接 SDK 和自动消费器 | [消息协议](subscriptions.md#5-websocket-建连与边界) / [消费 SDK](../sdk/event-consumer.md) |
-| `/v1/workflow-definitions` 创建、发布与固定版本读取 | P4定义子项已实现，实例执行尚未实现 | [定义接口](workflow-definitions.md)、[格式规范](workflow-definition-format.md) |
-| `/v1/workflows` 与流程管理 | 计划 P4–P5，尚未实现 | [流程接口规划](workflows.md) |
+| `/v1/workflow-definitions` 创建、发布与固定版本读取 | P4定义子项已实现，实例另用启动接口 | [定义接口](workflow-definitions.md)、[格式规范](workflow-definition-format.md) |
+| `/v1/workflows`、步骤详情、控制、信号及操作审计 | 已接入HTTP与独立SDK | [实例接口](workflows.md) |
+| `/v1/workflows/{id}/recovery/*` 六类人工恢复 | 已接入有证据恢复及独立SDK | [恢复接口](workflow-recovery.md) |

 未实现路由返回 404。健康检查就绪不表示任务执行、定时调度或流程引擎已经可用。

--- a/docs/api/authentication.md
+++ b/docs/api/authentication.md
@@ -63,3 +63,5 @@ P3 独立任务核查、人工重试和操作审计分别增加 `tasks:review`
 P3 结果订阅核心新增 `events:read`、`events:manage` 和 `events:consume`，bootstrap 仅显式 `--event-access` 时授予。订阅绑定创建凭据与单个队列，不能用同命名空间的另一张凭据消费或管理。当前 HTTP/WSS、管理及消费 SDK 已接入；凭据重绑继续开发，详见 [订阅接口](subscriptions.md)。

 P4定义发布新增`workflows:definitions:read`与`workflows:definitions:publish`，仅显式`--workflow-access`授予。创建/读取元数据作用于命名空间，发布及读取完整版本额外校验全部引用队列；默认提交/Worker凭据不获此权限。发布不创建任务，不要求tasks:submit，详见[定义API](workflow-definitions.md)。
+
+P4/P5实例公共接入增加`workflows:start/read/control/signal/recover`及`workflows:audit:read`。五个独立CLI开关`--workflow-run-access`、`--workflow-control-access`、`--workflow-signal-access`、`--workflow-recovery-access`、`--workflow-audit-access`分别明确授予。前四个同时包含实例读取；audit只授予流程操作审计读取。原`--workflow-access`仍仅授予定义读/发布，任务`--recovery-access`不授予流程恢复。全部固定队列仍按当前凭据校验，详见[实例权限表](workflows.md#1-路由权限与-sdk)。初始化权限集合在交付凭据前校验。
--- a/docs/api/workflow-definitions.md
+++ b/docs/api/workflow-definitions.md
@@ -1,6 +1,6 @@
 # 流程定义与不可变版本

-状态：P4 定义校验、持久化发布及独立 Go SDK 已实现；实例启动、推进、等待和恢复尚未实现。规则格式见[结构版本1](workflow-definition-format.md)，可运行源码及命令见[研发发布场景](../examples/workflow-definition.md)。
+状态：P4 定义校验、持久化发布及独立 Go SDK 已实现；实例启动、控制、等待和恢复已接入[实例API](workflows.md)及[恢复API](workflow-recovery.md)。规则格式见[结构版本1](workflow-definition-format.md)，可运行源码及命令见[研发发布场景](../examples/workflow-definition.md)。

 ## 1. 权限、传输与范围

--- a/docs/api/workflow-recovery.md
+++ b/docs/api/workflow-recovery.md
@@ -0,0 +1,146 @@
+# 流程人工核查与恢复 API / SDK
+
+状态：六类内部恢复已接入公共HTTP和独立SDK。所有路径以 `/v1/workflows/{id}/recovery/` 开头，均为POST，要求 `workflows:recover`、全部固定队列范围、Bearer凭据、稳定Idempotency-Key及application/json。成功首次与重复响应均为200。身份、读查询、错误码见[实例接口](workflows.md)。
+
+恢复只针对NEEDS_REVIEW实例。SDK不会自动重试、补齐声明、刷新版本或生成新键。核查前应读取当前实例、当前步骤、相关任务及外部证据；每次新决定使用当前版本，响应未知则用原决定原键核对。输入和结果最多256 KiB，请求体总计最多512 KiB。
+
+## 1. 公共字段
+
+所有请求包含WorkflowRecoveryDecision的**扁平字段**：
+
+| 字段 | 必填与语义 |
+| --- | --- |
+| expected_revision | 必填，当前实例的非零revision十进制字符串，不能用control_revision替代 |
+| reason | 必填，1–1024个Unicode字符；不允许全空白或NUL |
+| evidence_ref | 必填，1–512个Unicode字符，不含空白或控制字符；平台不访问引用、不存放秘密 |
+
+步骤类请求还包含WorkflowStepDecision的扁平字段：step_key（固定定义步骤名，最多64个ASCII字符）、activation_id（当前32位激活ID）、expected_step_revision（当前非零步骤版本字符串）。实例版本、步骤版本及激活身份一起检查，旧激活不能操作新工作。
+
+服务端检查待消费/隔离Inbox、历史任务归属、仍在执行的尝试及未释放许可。声明为true是操作者确认，不替代服务端验证。恢复不会重置原绝对截止、次数或业务关联；已有停止目标不会被撤销。
+
+## 2. 六类命令
+
+| 路径后缀 | SDK方法 / 请求类型 | 额外必填字段与结果 |
+| --- | --- | --- |
+| task-review | ReviewWorkflowTask / ReviewWorkflowTaskRequest | task_id、expected_task_revision字符串、execution_settled=true、outcome=SUCCEEDED或FAILED、非null result；核实本实例任一历史激活的待核查执行 |
+| step-resolve | ResolveWorkflowStep / ResolveWorkflowStepRequest | 步骤公共字段、execution_settled=true、outcome=SUCCEEDED或FAILED、result；确认当前叶子步骤的逻辑结论 |
+| continue | ContinueWorkflow / ContinueWorkflowRequest | review_resolved=true；确认全部核查事项已处理后解除核查 |
+| step-retry | RetryWorkflowStep / RetryWorkflowStepRequest | 步骤公共字段、safe_to_retry=true；为TASK/POLL创建新激活，保留原预算和截止 |
+| poll-continue | ContinueWorkflowPoll / ContinueWorkflowPollRequest | 步骤公共字段、pending_confirmed=true；权威结果已确认为PENDING时按原间隔恢复等待，不重查同轮 |
+| wait-rearm | RearmWorkflowWait / RearmWorkflowWaitRequest | 步骤公共字段、wait_verified=true；独立SIGNAL/TIMER在原截止内更换等待代次，含首次最多32代 |
+
+所有确认布尔值必须在HTTP中显式提供且为true。拒绝嵌套`Decision`、伪造actor_id、大小写别名和未声明字段。
+
+执行核查请求示例：
+
+```json
+{
+  "expected_revision":"8",
+  "reason":"已核实请求完成且外部作业仍在处理",
+  "evidence_ref":"evidence:query-001",
+  "task_id":"88888888888888888888888888888888",
+  "expected_task_revision":"4",
+  "execution_settled":true,
+  "outcome":"SUCCEEDED",
+  "result":"PENDING"
+}
+```
+
+ReviewTask只改变执行结论，旧UNKNOWN尝试和证据保持原样。它产生新的内部结果，必须等待后台消费，当前步骤及实例不会自动解除核查。POLL请求成功不等于流程业务成功；ResolveStep对POLL的成功结果必须映射到固定的业务成功值，不能把PENDING写成步骤成功。TIMER成功只能在首次等待时长满足后确认，result必须为显式null。
+
+PENDING接续请求示例：
+
+```json
+{
+  "expected_revision":"11",
+  "reason":"沿原间隔继续查询外部作业",
+  "evidence_ref":"evidence:query-001",
+  "step_key":"query",
+  "activation_id":"66666666666666666666666666666666",
+  "expected_step_revision":"3",
+  "pending_confirmed":true
+}
+```
+
+相同字段布局适用于step-resolve、step-retry和wait-rearm，额外字段按上表替换。Continue只有实例公共字段及review_resolved，不要求步骤字段。
+
+## 3. 回执与当前视图
+
+六个方法统一返回WorkflowRecoveryResult；HTTP的data字段为该对象：
+
+| 字段 | 含义 |
+| --- | --- |
+| instance | 首次管理事务完成时的完整实例快照，字段同[启动回执](workflows.md#2-固定版本启动) |
+| audit_id | 本次流程管理审计ID，可用GetWorkflowOperation读取原因、证据及前后摘要 |
+| step | 步骤类操作返回当前步骤快照，包含激活代次；不是后续实时状态 |
+| task | task-review或step-retry返回执行任务快照；字段同GetTask |
+| task_audit_id | task-review对应的独立任务审计ID，与流程审计同事务保存 |
+| deduplicated | 是否恢复原回执；恢复原键仍检查当前权限 |
+
+步骤恢复回执示意，省略字段按协议确实不存在，并非JSON占位：
+
+```json
+{
+  "request_id":"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
+  "data":{
+    "instance":{
+      "id":"22222222222222222222222222222222",
+      "namespace_id":"33333333333333333333333333333333",
+      "definition_id":"11111111111111111111111111111111",
+      "definition_version_id":"44444444444444444444444444444444",
+      "version":"v1","state":"NEEDS_REVIEW","revision":"13",
+      "paused":false,"control_revision":"3",
+      "input":{"n":9007199254740993},"business_key":"operation-001 ",
+      "deadline_at":"2026-09-18T08:01:00Z",
+      "created_at":"2026-09-18T08:00:00Z","updated_at":"2026-09-18T08:00:10Z"
+    },
+    "audit_id":"99999999999999999999999999999999",
+    "step":{
+      "id":"55555555555555555555555555555555","key":"query","kind":"POLL",
+      "state":"WAITING","revision":"4",
+      "activation_id":"66666666666666666666666666666666","activation_sequence":1
+    },
+    "deduplicated":false
+  }
+}
+```
+
+ContinuePoll保留当前激活与信号代次；RetryStep及RearmWait创建新激活。恢复等待或创建新任务后仍须显式Continue解除核查；paused仍为true时还需ControlWorkflow(RESUME)。任何恢复操作都不盲目撤回已发生的外部业务效果。
+
+## 4. SDK接入顺序
+
+以下为嵌入接入方函数的调用片段，api是已认证Client，workflowID为目标实例，operationKey与本次完整命令需要由调用方持久保存：
+
+```go
+current, err := api.GetWorkflowStep(ctx, workflowID, "query")
+if err != nil { return err }
+if current.Step.ActivationID == nil { return errors.New("query is not activated") }
+command := orbit.ContinueWorkflowPollRequest{
+    WorkflowStepDecision: orbit.WorkflowStepDecision{
+        WorkflowRecoveryDecision: orbit.WorkflowRecoveryDecision{
+            ExpectedRevision: current.Revision,
+            Reason: "已核实权威PENDING结果，沿原预算接续",
+            EvidenceRef: "evidence:query-001",
+        },
+        StepKey: current.Step.Key,
+        ActivationID: *current.Step.ActivationID,
+        ExpectedStepRevision: current.Step.Revision,
+    },
+    PendingConfirmed: true,
+}
+receipt, err := api.ContinueWorkflowPoll(ctx, workflowID, operationKey, command)
+if err != nil { return err } // 不生成新键绕过冲突；结果不明时原命令原键核对。
+audit, err := api.GetWorkflowOperation(ctx, workflowID, receipt.AuditID)
+if err != nil { return err }
+fmt.Println(audit.Action, receipt.Instance.State)
+```
+
+完整、可执行的六类SDK场景位于[真实服务集成测试](../../sdk/go/workflow_instances_integration_test.go)：UNKNOWN→执行核查→逻辑结论→解除核查；已知失败→剩余预算重试，同时重建信号等待；UNKNOWN查询→核查为PENDING→原间隔接续。运行方式为仓库根目录`make integration`，由脚本创建隔离MySQL、实际服务及凭据。
+
+一般步骤是：查询当前事实 → 提交一个有证据的决定 → 等待该决定产生的内部结果消费 → 重新读取当前版本 → 再提交下一决定。不要自动将任意STATE_CONFLICT重试为“最新版本”；冲突可能意味着新的在途结果、权限变化、原截止已到或预算耗尽，应重新核查。相同命令的响应未知则仍使用原版本和原键。
+
+## 5. 兼容与剩余范围
+
+新路由仅在本开发版本及之后可用；旧服务返回404时不能降级为普通任务重试来绕过Weave所有权。SDK类型独立、版本字段保留uint64精度。规则及数据模型未增加表、字段、外键或级联。
+
+本批尚不提供完整历史激活/轮次遍历、实例筛选列表或信号资源审计列表；当前输入结果、当前查询预算、单条信号和流程管理审计可读。生产数据库切换、容量及恢复目标继续按P6验证，见[阶段报告](../reports/phase-5-public-api.md)。
--- a/docs/api/workflows.md
+++ b/docs/api/workflows.md
@@ -1,15 +1,171 @@
-# 流程接口状态
+# 流程实例、控制、信号与操作审计

-状态：定义格式校验、创建与不可变版本发布已实现，详见[定义接口](workflow-definitions.md)、[格式规范](workflow-definition-format.md)和[可运行SDK例子](../examples/workflow-definition.md)。实例执行与管理仍按P4–P5开发。下表仅列后续实例接口。
+状态：下表公共 HTTP 与独立 Go SDK 已接入。定义发布见[定义接口](workflow-definitions.md)，人工恢复见[恢复接口](workflow-recovery.md)，完整运行例子见[并行作业与回执](../examples/workflow.md)。SDK 尚未发布正式版本，服务端与 SDK 应使用同一开发版本。

-| 操作 | 候选接口 | 完成要求 |
+实例筛选分页、历史激活/轮次/信号列表及 Pulse 任务的流程来源查询继续开发。旧冻结回执可能不含新增的activation_sequence，应另读当前步骤详情；当前步骤详情只反映当前激活；旧记录保留在数据库，不能把本页的当前视图当作全部历史。
+
+## 1. 路由、权限与 SDK
+
+下文 `{id}` 为32位小写十六进制流程实例ID，不是定义ID；身份和命名空间来自凭据。所有读取均检查固定定义引用的全部队列。变更还需要 `Content-Type: application/json`、`Authorization: Bearer <token>` 和一个稳定的 `Idempotency-Key`；键最长128字节，字符规则沿用[任务协议](tasks.md)。请求体最大512 KiB，拒绝重复字段、大小写别名、未声明字段和多余查询参数。
+
+| 方法与路径 | 权限 | Go SDK 方法 |
 | --- | --- | --- |
-| 启动实例 | `POST /v1/workflows` | 固定版本并幂等启动，首批任务与实例原子创建 |
-| 查询实例 | `GET /v1/workflows/{workflow_id}` | 状态、暂停标记、版本、等待原因、预算摘要 |
-| 查询步骤 | `GET /v1/workflows/{workflow_id}/steps` | 步骤、激活、查询轮次、输入/结果引用与任务关联 |
-| 提交信号 | `POST /v1/workflows/{workflow_id}/signals` | 幂等、授权、业务操作匹配；受理与消费分别可查 |
-| 暂停/继续 | `POST /v1/workflows/{workflow_id}:pause`、`:resume` | 控制版本与门控原子变化，保留进度、预算与审计 |
-| 取消 | `POST /v1/workflows/{workflow_id}:cancel` | 停止后续工作，收集在途结果，不伪装业务撤销 |
-| 核查恢复 | 具体接口待实现阶段冻结 | 权限、证据、预期版本与稳定操作身份；保留旧激活历史 |
+| `POST /v1/workflows` | `workflows:start`；有任务队列时还需 `tasks:submit` | StartWorkflow |
+| `GET /v1/workflows/{id}` | `workflows:read` | GetWorkflow |
+| `GET /v1/workflows/{id}/steps` | `workflows:read` | GetWorkflowSteps |
+| `GET /v1/workflows/{id}/steps/{key}` | `workflows:read` | GetWorkflowStep |
+| `POST /v1/workflows/{id}/control` | `workflows:control` | ControlWorkflow |
+| `POST /v1/workflows/{id}/signals` | `workflows:signal` | SendWorkflowSignal |
+| `GET /v1/workflows/{id}/signals/{signal}` | `workflows:read` | GetWorkflowSignal |
+| `GET /v1/workflows/{id}/operations` | `workflows:audit:read` | ListWorkflowOperations |
+| `GET /v1/workflows/{id}/operations/{operation}` | `workflows:audit:read` | GetWorkflowOperation |

-配套场景：并行生成结果、等待审核信号、外部作业有界查询、暂停与核查恢复。正式示例将在对应 API 和 SDK 通过端到端验证后提供。节点与状态设计见 [Weave 功能与设计](../06-workflow-spec.md)。
+GET成功为200；启动及信号首次受理为201，原键回执为200；控制成功为200。控制响应表示意图已保存，取消结清由后台完成。SDK签名、独立类型及各字段中文说明见[调用方法](../../sdk/go/workflow_instances.go)和[协议类型](../../sdk/go/workflow_instance_types.go)。
+
+CLI显式开关分别为：`--workflow-access`（定义读/发布）、`--workflow-run-access`（实例读/启动）、`--workflow-control-access`（实例读/控制）、`--workflow-signal-access`（实例读/信号）、`--workflow-recovery-access`（实例读/恢复）、`--workflow-audit-access`（流程操作审计读）。普通 Worker、定义发布及任务核查权限均不会自动获得流程管理权限。初始化会先验证权限集合再交付凭据，具体命令见[示例](../examples/workflow.md)。
+
+## 2. 固定版本启动
+
+`StartWorkflow(ctx, key, StartWorkflowRequest)` 的请求：
+
+```json
+{
+  "definition_id": "11111111111111111111111111111111",
+  "version": "v1",
+  "input": {"n": 9007199254740993},
+  "business_key": "operation-001 "
+}
+```
+
+| 字段 | 类型与约束 |
+| --- | --- |
+| definition_id | 必填，当前命名空间的定义ID |
+| version | 必填，1–64个ASCII版本字符，首字符字母或数字，之后还可用 `_ . -`；不解析latest |
+| input | 必填，最多256 KiB JSON，必须符合固定版本输入契约；显式null与缺失不同，数字不经过float64 |
+| business_key | 可选，默认空字符串，最多191个Unicode字符；尾部空格保留，不能替代幂等键 |
+
+示意完整回执：
+
+```json
+{
+  "request_id": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
+  "data": {
+    "instance": {
+      "id": "22222222222222222222222222222222",
+      "namespace_id": "33333333333333333333333333333333",
+      "definition_id": "11111111111111111111111111111111",
+      "definition_version_id": "44444444444444444444444444444444",
+      "version": "v1",
+      "state": "RUNNING",
+      "revision": "2",
+      "paused": false,
+      "control_revision": "1",
+      "input": {"n": 9007199254740993},
+      "business_key": "operation-001 ",
+      "deadline_at": "2026-09-18T08:01:00Z",
+      "created_at": "2026-09-18T08:00:00Z",
+      "updated_at": "2026-09-18T08:00:00Z"
+    },
+    "deduplicated": false
+  }
+}
+```
+
+`GetWorkflow`的data直接是instance对象。可能状态为RUNNING、WAITING、CANCELLING、NEEDS_REVIEW、SUCCEEDED、FAILED、CANCELLED；paused是独立标记。`output`在存在结果时返回，成功输出可以为显式null。`cancel_requested_at`、`stop_kind`（CANCEL/FAILURE）、`stop_requested_at`、`completed_at`仅有值时返回。所有时间为UTC RFC3339，revision及control_revision为十进制字符串，SDK使用uint64。
+
+启动固定定义版本和总截止，并在同事务创建门控、步骤和首批任务。原键同内容返回**首次受理快照**，不重算时间，不代表当前状态；同键不同内容返回IDEMPOTENCY_CONFLICT。网络响应丢失时保持原键和原请求核对，再用GetWorkflow读取当前状态。每命名空间最多10000个未终结实例，已保存的原回执在满额时仍可恢复。
+
+## 3. 步骤及当前激活
+
+GetWorkflowSteps返回 `{instance_id, revision, steps}`，steps按key排序、最多128项，不含内部根步骤。每项含 `id/key/kind/state/revision`；已激活时还含 `activation_id/activation_sequence`，TASK还含直接 `task_id`。未激活步骤没有激活ID和代次。步骤状态包括BLOCKED、ACTIVE、WAITING、SUCCEEDED、FAILED、CANCELLED、NEEDS_REVIEW、SKIPPED。
+
+GetWorkflowStep返回单个步骤详情，实例revision与当前步骤同事务读取：
+
+```json
+{
+  "request_id": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
+  "data": {
+    "instance_id": "22222222222222222222222222222222",
+    "revision": "8",
+    "step": {
+      "id": "55555555555555555555555555555555",
+      "key": "receipt",
+      "kind": "SIGNAL",
+      "state": "WAITING",
+      "revision": "2",
+      "activation_id": "66666666666666666666666666666666",
+      "activation_sequence": 1
+    },
+    "input": {"name": "done", "payload_version": "v1", "correlation": "operation-001 "},
+    "activated_at": "2026-09-18T08:00:05Z",
+    "wait": {
+      "id": "77777777777777777777777777777777",
+      "kind": "SIGNAL",
+      "state": "WAITING",
+      "name": "done",
+      "payload_version": "v1",
+      "correlation_key": "operation-001 ",
+      "deadline_at": "2026-09-18T08:00:35Z"
+    }
+  }
+}
+```
+
+- `input/output`属于当前激活，每次只读取一份；未激活或尚无输出时省略，显式null保留。`activated_at/completed_at`属于当前激活，不能据新激活时间重算原预算。
+- POLL的 `poll` 包含 used_rounds、first_round、first_round_attempts_used、max_rounds、max_attempts_per_round、interval_ms、deadline_at、last_task_id；current_task_id、next_poll_at、resolved_at在有值时返回。last_task_id指当前激活最后业务轮任务，可再通过GetTask读取其状态/版本。
+- SIGNAL、TIMER和有最终信号的POLL返回 `wait`，包含当前等待身份、类型、状态、原截止和关联；name/payload_version不适用于TIMER，旧未核验等待也可能缺失。winner_signal_id和resolved_at在有值时返回。已选中赢家不代表在途任务已结清。
+- 时间预算不会随人工换代增加。信号发送者应读取activation_sequence，不能把激活ID、步骤revision或任务尝试epoch当作等待代次。
+
+## 4. 暂停、继续与取消
+
+`ControlWorkflow(ctx, id, key, WorkflowControlRequest)`：
+
+```json
+{"operation":"PAUSE","expected_control_revision":"1","reason":"维护期间停止推进新工作"}
+```
+
+operation必填，为PAUSE/RESUME/CANCEL；expected_control_revision为读取到的非零control_revision字符串，reason为1–1024个Unicode字符，不允许全空白或NUL。成功data为 `{instance, deduplicated}`，instance字段同启动回执。新决定使用旧控制版本返回STATE_CONFLICT；原键恢复仍返回第一次的冻结决定。
+
+PAUSE关闭新执行授权，在途结果继续收集；RESUME不清除NEEDS_REVIEW，不撤销首次停止目标，不延长原截止。CANCEL保存取消意图并停止后继，保留在途许可直到真实执行结束；未知效果仍进入核查。后台任务结果改变通用revision，不要求操作者追逐每个结果去更新control_revision。详细结清规则见[控制设计](../15-workflow-controls.md)。
+
+## 5. 有身份的外部信号
+
+`SendWorkflowSignal(ctx, id, key, SendWorkflowSignalRequest)`：
+
+```json
+{
+  "name":"done",
+  "payload_version":"v1",
+  "target_step_key":"receipt",
+  "target_activation_sequence":1,
+  "correlation_key":"operation-001 ",
+  "payload":{"n":9007199254740993},
+  "reason":"已核验外部回执",
+  "evidence_ref":"evidence:receipt-001"
+}
+```
+
+name/payload_version/target_step_key必填，分别最多128/32/64个ASCII名称字符；代次为非零uint32数字。correlation_key为1–512字节UTF8、精确匹配并保留尾部空格。payload必填、最多256 KiB，符合固定契约时可显式null。reason规则同控制原因；evidence_ref可选、最多512个Unicode字符，不含空白或控制字符，平台不会访问这个引用。
+
+成功data为 `{signal, deduplicated}`。signal字段：id、namespace_id、workflow_id、revision字符串、name、payload_version、target_step_key、target_activation_sequence、correlation_key、payload、actor_id、state、accepted_at、expires_at；evidence_ref、disposition、consumed_wait_id在有值时返回。actor_id从认证获得。GetWorkflowSignal直接返回当前signal对象。
+
+受理与消费分离：PENDING可以稍后变为CONSUMED、REJECTED或EXPIRED。每实例全部历史受理记录最多1024条，原键回执先于上限检查。早到信号可以指定首次代次1；当前旧代次信号保存为REJECTED/STALE_ACTIVATION，未来代次冲突。恢复为新代次后，原信号原键仍返回旧回执，不能用重报改变目标。最终查询与信号按原事件时间竞争，PENDING查询不争夺业务完成权，见[信号设计](../14-workflow-signals.md)。
+
+## 6. 操作审计与错误处理
+
+ListWorkflowOperations接受HistoryPageRequest：limit默认20、范围1–100；cursor最大1024字节，绑定命名空间、流程ID和查询种类，不可跨资源复用。data为 `{items, next_cursor?}`；每项含 id、workflow_id、operation_id、actor_id、action、created_at，按时间及ID倒序。GetWorkflowOperation除这些字段外还返回reason、evidence_ref（可空省略）、before、after JSON摘要。单独读取正文，避免列表聚合大结果。
+
+该接口当前查询resource_kind=workflow的启动、推进、控制和恢复审计；独立任务核查审计通过恢复回执的task_audit_id关联。信号自身的受理状态通过GetWorkflowSignal读取，信号资源审计列表及完整激活历史继续开发。
+
+| HTTP/错误码 | 处理方式 |
+| --- | --- |
+| 400 INVALID_ARGUMENT | 修正字段、固定契约或查询游标；不要把遗漏声明默认成true |
+| 401 UNAUTHENTICATED / 403 PERMISSION_DENIED | 核对凭据和显式动作权限，重报不会绕过撤权 |
+| 404 NOT_FOUND | 资源不存在、跨命名空间或队列不在授权范围 |
+| 409 STATE_CONFLICT / IDEMPOTENCY_CONFLICT | 当前状态/版本不符或原键请求改变；先读取权威状态 |
+| 409 WORKFLOW_INSTANCE_LIMIT / WORKFLOW_SIGNAL_LIMIT | 固定资源数量上限，不能通过新键盲目补发 |
+| 429 QUEUE_FULL / APPLICATION_FULL | 新工作配额不足；保持原请求身份核对，服务端给Retry-After |
+| 413 BODY_TOO_LARGE / 415 UNSUPPORTED_MEDIA_TYPE | 缩小请求或使用application/json |
+| 503 UNAVAILABLE / 网络异常 | 提交结果可能不明，保持原键和原命令核对；SDK不自动换键 |
+
+已实现路由之外的路径为404。回归证据和剩余交付范围见[公共接入报告](../reports/phase-5-public-api.md)。
--- a/docs/examples/README.md
+++ b/docs/examples/README.md
@@ -6,7 +6,13 @@

 - [完整命令和结果](workflow-definition.md)、[SDK源码](../../sdk/go/examples/workflow-definition/main.go)。
 - 六类节点的有限结构定义、原键及同版本确认、新版本发布、旧版本读取保持不变。
- 当前只发布定义，实例执行仍在P4–P5开发。
+- 本例只发布定义；实际运行见下方流程示例。
+
+## 已可运行：并行作业、定时等待与外部回执
+
+- [完整命令、输入输出与失败处理](workflow.md)、[独立SDK源码](../../sdk/go/examples/workflow/main.go)。
+- 两个任务并行处理并汇合，计时等待后接收显式目标代次的信号，再执行后续任务；最终三个任务完成并有界排空。
+- 启动及信号原键重复不会建立新的实例或信号。

 ## 已可运行：业务事务与任务提交Outbox

--- a/docs/examples/workflow-definition.md
+++ b/docs/examples/workflow-definition.md
@@ -1,6 +1,6 @@
 # 研发定义与发布流程

-本例运行真实HTTP发布与读取，验证六种节点的格式以及不可变版本。当前不创建流程实例、不执行外部业务。实例运行示例随P4–P5交付。
+本例运行真实HTTP发布与读取，验证六种节点的格式以及不可变版本。当前不创建流程实例、不执行外部业务。实际运行另见[并行作业与回执示例](workflow.md)。

 源码：[workflow-definition/main.go](../../sdk/go/examples/workflow-definition/main.go)。接口：[定义发布](../api/workflow-definitions.md)；字段规范：[结构版本1](../api/workflow-definition-format.md)。

--- a/docs/examples/workflow.md
+++ b/docs/examples/workflow.md
@@ -0,0 +1,57 @@
+# 并行生成结果 → 等待外部回执 → 后续任务
+
+[完整源码](../../sdk/go/examples/workflow/main.go)通过独立Go SDK发布固定版本、启动实例，并使用真实自动Worker处理任务。流程是两个文本规范化任务并行完成并汇合，等待500毫秒，等待模拟外部确认信号，最后用左侧输出执行发布步骤。输入为 `{"text":"  hello orbit  "}`，输出为 `{"text":"HELLO ORBIT"}`。
+
+## 1. 启动
+
+环境：Go 1.27.1、MySQL 8.4+，已设置专用ORBIT_MYSQL_DSN。仓库根目录执行：
+
+```sh
+go run ./cmd/orbit-migrate up
+mkdir -p .local
+chmod 700 .local
+go run ./cmd/orbit-admin bootstrap \
+  --application workflow-example --namespace default --environment development \
+  --queue workflows --workflow-access --workflow-run-access \
+  --workflow-signal-access --worker-access \
+  --output .local/workflow.credentials.json
+go run ./cmd/orbit
+```
+
+初始化仅执行一次，文件存在时不会覆盖。重用该凭据运行例子无需重复bootstrap。另开终端，从仓库根目录执行：
+
+```sh
+cd sdk/go
+ORBIT_URL=http://127.0.0.1:8080 \
+ORBIT_CREDENTIALS_FILE=../../.local/workflow.credentials.json \
+go run ./examples/workflow
+```
+
+生产使用HTTPS/WSS，并为定义发布者、启动者、信号发送者及Worker分别签发所需权限。本示例使用一个专用开发凭据，未申请人工恢复或控制权限。
+
+## 2. 调用链与输出
+
+CreateWorkflowDefinition → PublishWorkflowVersion(v1) → StartWorkflow → 原键再次StartWorkflow → 自动Worker并行执行 → GetWorkflowStep读取当前信号契约与代次 → SendWorkflowSignal → 原键再次发送 → 后继任务完成 → GetWorkflow → Worker有界排空。
+
+预期输出中的ID每次运行不同：
+
+```text
+workflow=<32位实例ID> state=SUCCEEDED result={"text":"HELLO ORBIT"} start_deduplicated=true signal_deduplicated=true
+worker_drained=true started=3 confirmed=3
+```
+
+示例会确认三个任务实际开始、三个结果确认且没有运行中的处理器。信号的target_activation_sequence读取自当前步骤，correlation_key使用等待原关联，不猜测恢复代次；重复键不改变目标。示例模拟已核验外部回执，不调用真实第三方业务系统。实际使用中由独立外部调用者保存证据后发送。
+
+## 3. 失败与恢复
+
+示例最长运行45秒，Worker排空最长5秒。NEEDS_REVIEW、FAILED、CANCELLED或Worker提前退出都会报错，不把受理回执当成业务成功。命令重新运行会生成新的独立示例流程，不属于故障时的原身份核对；生产接入方应在自身事务中保存operationKey及完整命令。
+
+出现网络结果不明时，使用原definition/version/input/business_key和原幂等键重报。暂停不延长原截止；信号受理不表示消费。人工恢复使用[六类恢复命令](../api/workflow-recovery.md)，不能用普通任务RetryTask绕过流程门控和预算。
+
+示例成功后保留定义、实例、任务、信号和审计，不硬删除历史。每次运行使用唯一处理器名，避免其他Worker误消费该例子。完整命令、HTTP字段和权限见[实例API](../api/workflows.md)。
+
+## 4. 其他可执行恢复场景
+
+[公共SDK集成测试](../../sdk/go/workflow_instances_integration_test.go)还实际运行：启动响应丢失的原键恢复；暂停/继续、定时等待、信号消费和取消；UNKNOWN执行核查、步骤结论及解除核查；剩余尝试内TASK重试与SIGNAL换代；确认PENDING后沿原查询预算继续。使用`make integration`在一次性环境复现。
+
+历史激活列表、流程来源查询、更多独立业务示例及生产验收仍按[计划](../08-development-plan.md)推进。
--- a/docs/reports/phase-5-public-api.md
+++ b/docs/reports/phase-5-public-api.md
@@ -0,0 +1,42 @@
+# P4/P5 流程公共 HTTP 与独立 SDK 接入回归
+
+日期：2026-09-18。范围为15条实例/控制/信号/恢复/操作审计路由、当前步骤详情、独立Go SDK和一个实际并行执行场景。本报告不表示P4/P5全部范围或生产平台已完成。
+
+## 实现
+
+- StartWorkflow固定版本和输入；GetWorkflow读取当前实例，GetWorkflowSteps返回最多128项元数据，GetWorkflowStep只读取单个当前激活的输入/输出、查询预算及等待。当前代次进入新步骤视图和恢复回执；旧冻结回执不改写。
+- ControlWorkflow使用control_revision；信号固定步骤和激活代次。六类人工恢复复用现有事务服务，版本、证据、明确声明、原预算和停止意图全部保留。
+- 流程资源操作审计支持独立权限、摘要分页和单条正文，游标绑定命名空间、实例及查询种类。信号资源审计及完整激活历史尚待补齐。
+- 严格JSON支持匿名公共字段的扁平组合，仍拒绝大小写别名、未知/重复字段和缺少必填确认，保留显式null和精确整数。
+- 初始化分别授予执行、控制、信号、恢复和审计权限，原workflow-access仍只定义读/发布。联调发现新审计动作漏登记导致凭据被拒绝，已补齐认证白名单，并在凭据交付前验证权限集合。
+- SDK保持独立module，协议类型有中文注释，不导入服务端模型或存储。新增运行例子为并行处理→汇合→定时等待→模拟外部回执→后继任务，验证恰好三个任务和有界排空。
+
+本批不新增迁移、数据表或持久化字段；仍为35个实体、305个直接持久化字段声明，无数据库外键和级联。
+
+## 回归证据
+
+环境为本机darwin/arm64、Go 1.27.1、Docker MySQL 8.4.10；专项及完整脚本使用一次性隔离数据库和真实Orbit二进制。
+
+| 检查 | 结果 |
+| --- | --- |
+| 既有执行/恢复与元数据读专项 | `-race`通过，39.627秒，覆盖实例受理、TASK/POLL/等待恢复与新增当前详情读取 |
+| 初始化权限与详情专项 | `-race`通过，5.892秒；六种独立流程授权及无外键归属拒绝 |
+| 独立SDK专项 | 定义SDK与四组实例场景通过，包21.154秒；实例场景19.76秒 |
+| 可运行示例 | 原定义发布例子与新workflow例子通过；新例子SUCCEEDED、start_deduplicated=true、signal_deduplicated=true、started=3、confirmed=3 |
+| 基础回归 | 最终make fmt/test/vet/build全部通过，包含主模块、独立SDK和两个业务示例模块的竞态检查、静态检查及构建 |
+| 完整隔离回归 | `scripts/test-mysql.sh`退出0；存储219.229秒、实际流程进程恢复48.336秒、流程SDK21.342秒（四组实例20.01秒）、最终Worker/订阅进程故障组95.200秒；20个SDK示例及2个独立业务模块全部通过，一次性环境由脚本清理 |
+| 无外键升级 | 历史v7至当前版本回归通过，4.58秒；70个外键全部移除，已有数据、未替换索引及唯一约束保留，运行时拒绝意外新增外键 |
+| 模型、SQL及文档 | Go AST核对305个直接持久化字段，缺中文注释0；实际MySQL已应用至v22，外键0、业务表字段缺COMMENT为0；991个本地文档链接及61个JSON示例检查通过 |
+
+四组真实HTTP/SDK场景：
+
+1. 服务端实际提交启动事务后代理丢弃响应，原键找回同一实例和原截止；暂停/原键恢复/旧控制版本拒绝/继续，Worker完成首任务后经过TIMER与SIGNAL，再执行后继；信号旧回执与当前消费结果分别查询。审计分页及跨实例游标拒绝、取消等待实例也一并覆盖。
+2. Worker报告UNKNOWN → ReviewWorkflowTask确认成功 → 后台消费新结果 → ResolveWorkflowStep确认逻辑成功 → ContinueWorkflow；旧UNKNOWN尝试保留，管理原因和证据可读取。
+3. 已知失败步骤与并行信号等待 → RearmWorkflowWait第二代，原截止不变 → 旧代次信号被拒绝 → RetryWorkflowStep只保留一次剩余尝试 → 解除核查 → 新任务和新代次信号完成流程。
+4. 查询UNKNOWN → 核查为SUCCEEDED/PENDING → 原结果消费 → ContinueWorkflowPoll → ContinueWorkflow → 只创建第二业务轮并最终DONE；查询总截止不变。
+
+实现和证据：[公共路由](../../internal/transport/httpserver/workflows.go)、[严格JSON测试](../../internal/transport/httpserver/workflows_test.go)、[初始化范围测试](../../internal/storage/mysql/workflow_bootstrap_integration_test.go)、[当前详情及审计范围测试](../../internal/storage/mysql/workflow_details_integration_test.go)、[独立SDK场景](../../sdk/go/workflow_instances_integration_test.go)、[示例源码](../../sdk/go/examples/workflow/main.go)。完整复现入口是[隔离MySQL脚本](../../scripts/test-mysql.sh)，跳过的环境依赖测试不算通过。
+
+## 剩余交付
+
+继续提供实例筛选分页、完整激活/轮次/信号历史、信号资源审计、Pulse任务流程来源和更多独立恢复示例，再逐项核对P4/P5原功能范围。P6/P7仍包括生产监控、凭据轮换、故障及容量工具、备份恢复/切换与发布验收。本机多进程和单数据库回归不能替代生产复制、跨故障域部署或RPO/RTO验证。
--- a/docs/sdk/README.md
+++ b/docs/sdk/README.md
@@ -1,6 +1,6 @@
 # Go SDK 接入说明

-已实现健康查询、任务单项与[批量提交](../api/batch-tasks.md)/查询/分页/待执行取消、队列创建/查询、[自动 Worker](worker-runtime.md)、[Worker 底层协议 SDK](worker.md) 和 [执行历史查询](../api/execution-history.md)。[人工核查与重试](../api/task-recovery.md) 已提供 ReviewTask、RetryTask 与任务操作审计查询。[安全重试](../api/retries.md) 已提供有限策略、WorkerFailure.Retryable、历史查询及完整例子。[计划调度](../api/schedules.md) 已支持创建、查询、版本发布、暂停/恢复、触发历史与完整示例。[订阅管理](../api/subscriptions.md) 已支持创建、查询、暂停恢复、交付历史与人工重试；[事件消费 SDK](event-consumer.md) 已支持连接、自动心跳、重连与确认。流程构建等后续接口按 [开发计划](../08-development-plan.md) 继续实现。
+已实现健康查询、任务单项与[批量提交](../api/batch-tasks.md)/查询/分页/待执行取消、队列创建/查询、[自动 Worker](worker-runtime.md)、[Worker 底层协议 SDK](worker.md) 和 [执行历史查询](../api/execution-history.md)。[人工核查与重试](../api/task-recovery.md) 已提供 ReviewTask、RetryTask 与任务操作审计查询。[安全重试](../api/retries.md) 已提供有限策略、WorkerFailure.Retryable、历史查询及完整例子。[计划调度](../api/schedules.md) 已支持创建、查询、版本发布、暂停/恢复、触发历史与完整示例。[订阅管理](../api/subscriptions.md) 已支持创建、查询、暂停恢复、交付历史与人工重试；[事件消费 SDK](event-consumer.md) 已支持连接、自动心跳、重连与确认。[流程定义发布](../api/workflow-definitions.md)、[实例/控制/信号/操作审计](../api/workflows.md)及[六类人工恢复](../api/workflow-recovery.md)已提供独立SDK；完整历史与更多场景按[开发计划](../08-development-plan.md)继续实现。

 module：`git.yuntuo.hk/k2safe/orbit/sdk/go`。SDK 使用独立 go.mod，依赖 Go 标准库与 `github.com/coder/websocket v1.8.15`，不引用服务端模型或数据库实现。

@@ -201,4 +201,4 @@ P2 已提供底层协议、[自动 Worker 运行器及示例](worker-runtime.md)

 ## 流程定义发布

-已提供独立WorkflowSpecification类型及CreateWorkflowDefinition、GetWorkflowDefinition、PublishWorkflowVersion、GetWorkflowVersion四个HTTP方法。业务侧研发显式发布，服务端冻结版本；当前不包含实例执行方法。见[接口与字段](../api/workflow-definitions.md)、[结构版本1](../api/workflow-definition-format.md)、[完整可运行场景](../examples/workflow-definition.md)。
+已提供独立WorkflowSpecification类型及CreateWorkflowDefinition、GetWorkflowDefinition、PublishWorkflowVersion、GetWorkflowVersion四个HTTP方法。业务侧研发显式发布，服务端冻结版本；实例执行使用[StartWorkflow等方法](../api/workflows.md)，完整运行见[示例](../examples/workflow.md)。见[接口与字段](../api/workflow-definitions.md)、[结构版本1](../api/workflow-definition-format.md)、[完整可运行场景](../examples/workflow-definition.md)。