# Weave 实例受理与首批工作

状态：实例Start/Get/Steps、单步详情、固定版本、首批事务及后台推进已实现，并已接入[公共HTTP与独立SDK](api/workflows.md)。控制、信号、人工恢复见[恢复API](api/workflow-recovery.md)。当前视图与操作审计可读，完整历史、实例列表和生产验收继续交付。

## 1. 受理事务

内部入口为`weave/instance.Service`，存储由`WorkflowInstanceStore`实现。一个Start事务按以下顺序执行：

1. 验证凭据和`workflows:start`；取得应用额度排他锁，保留现有认证共享锁。
2. 以命名空间、`workflow.start`、幂等键冻结完整请求；同键不同定义、版本、输入或业务键冲突。
3. 读取并验证指定定义和不可变版本的原文摘要。所有被引用队列按ID排序，核对当前范围并直接取得排他锁；有业务任务时还需要`tasks:submit`。
4. 原回执在用量限制检查前返回。当前权限和固定版本归属仍需有效，重报不重算截止、输入、版本或首批工作。
5. 校验实例输入和未终结实例上限，解析最多32个初始变更；以数据库时间固定总截止。
6. 同事务创建门控、实例、全部静态步骤、内部根步骤，以及初始激活、任务/等待/轮次或待续记录，写入事件、审计及受理回执。

任何后续写入或额度预占失败都回滚整个图，包括首批中已经创建的任务。队列满额可用原身份重试；同一应用的多个队列共享原Pulse额度。队列暂停允许受理，由既有Worker门控阻止领取/开始。

流程推进不延长总截止。普通任务的实际deadline为自身任务时限与实例绝对截止的较早者；POLL任务还受查询节点绝对截止限制。冻结的单次尝试和重试策略不因剩余时限变短而重写，由Pulse在实际截止处终止授权。

## 2. 首批节点如何持久化

| 节点 | 受理时保存的内容 |
| --- | --- |
| TASK | 当前激活、精确输入、所属Pulse任务、流程门控及`workflow_activation`所有者 |
| BRANCH | 首次选择的case索引；未选中节点分批SKIPPED，不创建业务激活 |
| PARALLEL | 父激活、独立分支初始工作；后续结果消费运行器负责完成汇合 |
| SIGNAL | WAITING激活、信号名称/内容版本/精确业务关联、固定截止；不分配Worker |
| TIMER | WAITING激活和数据库时间计算的等待截止；不生成业务任务 |
| POLL | 固定输入、查询状态、首轮记录和唯一当前任务；used_rounds=1；可选最终信号等待与查询截止一致 |

所有关系由事务按namespace核验，不使用外键。TASK激活的task_id直接指向任务；POLL激活不占用该字段，查询任务通过轮次归属。真实Worker完成首批任务时，上一阶段的原子结果交付会写入该实例的Inbox。

空流程可在受理事务内完成并保存输出，完成门控关闭；纯等待流程进入WAITING。包含活动TASK/POLL或尚有待续变更的流程保持RUNNING。第一次持久化决策将实例版本从内部创建时的1推进到2，Start回执通常为revision="2"；调用者不得假设起始版本或自行递增版本。

## 3. 有限推进和查询

定义仍最多128个静态节点，每次Plan最多32个变更。存储额外建立不可由研发定义的`$root`/JOIN步骤，保存实例级根状态及当前激活。预算耗尽时，以根步骤ID、当前步骤版本和schema_version=1检查点写入`weave_pending_advances`，不能只依赖内存唤醒。

根步骤是内部记录，不出现在Steps查询中。Steps最多返回128项元数据及同一读取边界的实例revision，包含节点、状态、当前激活和直接任务引用；不把全部步骤输入/输出拼成大响应。读取核验固定定义和当前激活归属，缺失或错误关联不会降级为有效结果。

Get返回当前实例视图；Start重报返回受理时冻结的原始视图，两者语义不同。查询需要`workflows:read`以及固定版本涉及的全部队列范围。定义发布权限不会自动授予实例执行或读取权限；当前bootstrap的`--workflow-access`仍仅授予定义权限。

## 4. 运行边界和模型演进

| 项目 | 当前边界 |
| --- | --- |
| 请求输入 | 最多256 KiB；按固定定义严格类型校验，精确数字、显式null与缺失分别处理 |
| 业务键 | 最多191个Unicode字符，精确保留尾部空格；不提供执行幂等 |
| 活跃实例 | 每个namespace最多10000个RUNNING/WAITING/CANCELLING/NEEDS_REVIEW实例；终态不计入；满额仍可恢复原受理回执 |
| 信号关联 | 新受理最多512字节；数据库兼容旧191字符最长764字节，升级不截断历史 |
| 截止 | 数据库时间生成；任务、查询与等待均不超过实例总截止 |
| 自动运行 | Inbox消费、根待续、TIMER到期及后续POLL轮次已接入；SIGNAL与最终查询竞争已接入，内部控制与结清已接入，内部核查及TASK恢复已接入，等待恢复已接入内部服务，公共API/SDK仍待实现 |

迁移000018为Wait增加signal_name和payload_version两个带中文注释的可空字段；NULL仅表示TIMER或尚未核实的历史元数据，未来消费者不得把历史NULL自动解释为有效的新信号等待。correlation_key转为精确字节存储；实例business_key改为utf8mb4_0900_bin。该迁移时为35个实体、含公共Record的295个直接持久化字段声明，全部有中文注释，继续保持零外键。

## 5. 下一步接入

1. 结果消费与根待续运行器已按[运行器报告](reports/phase-4-runtime.md)验证；[定时和查询时钟](13-workflow-clock.md)已接入，继续补齐信号等待。
2. 已有扫描核验暂停、截止与所属应用停用；继续信号/查询回执竞争及失败分支结清，恢复保留原截止和次数。
3. 接通实例公共HTTP、独立SDK、来源查询和可运行端到端场景，同时实施真实节点退出与接管回归。

本阶段验证见[实例受理回归记录](reports/phase-4-admission.md)。纯受理测试不是流程运行验收，P4–P7仍按[完整计划](08-development-plan.md)推进。