流程包去掉发布机制 —— 严格检查 + 保存即生效,生效由运行时决定

用户要的是运行时机制:新建 + 编辑,存下去就生效,旧任务走完旧版本,
新任务调用时才加载新编排。所以「草稿 → 发布」两态整套去掉。

## 闸从「发布」挪到「保存」

`savePackage` 现在先跑闭合校验,不闭合抛 `NotClosedError`(路由 412 带报告)——
**一个字节都不落库**。存进来的每一版都能起单,所以不需要「已发布」这个标记。
`publish` 用例、路由、`publishPackage` 存储方法一并删掉。

实测:把进 A6 的边映射清空后保存 → 412,逐条点名「边 e-g3-a6 未完成载荷映射;
节点「报价议价」的必填字段未映射:rows」。

## 保存恒新增版本号,服务端说了算

这不是可选项,是「旧任务走完旧版本」的前提:工作流按 (包id, 版本) 去读定义,
就地覆盖 v1 就等于改掉所有在途 v1 任务正在读的编排 —— 它们会中途换了规则却毫不知情。

版本号由用例层算(当前最大 + 1),**不采信入参**。实测:入参故意填 version: 999,
落的是 v2。store 层因此改成**只插不改**:撞键宁可让唯一约束报错,也不静默覆盖。

起单取版从「最新已发布」改为「最新一版」(retired 除外);触发器的 requiredInputs 同口径。
实测:改完描述存成 v2 后,新起的单用 v2,早先那单仍挂 v1。

## 迁移:旧状态值不归一就是一读就炸

状态枚举从 draft/published/retired 收成 active/retired。列上和 definition 这个 jsonb 里
各存着一份 state,两处都要改 —— 不改,`processPackageSchema.parse` 读一行就抛。
这不是开发期小麻烦,任何已部署实例都会中招。加了迁移 0012。

## 界面:恒为 0 的假指标撤掉,不换个说法留着

- 编排面板:「已发布/草稿」芯片 → 「生效中/历史版本」(真正的区别是哪一版会被新起单取到);
  发布按钮撤掉,保存按钮改成「保存并生效(存为 vN)」并在确认卡里说清影响面
- 历史版本只读,但就地指路:「去 v(N-1) 改(生效中)」,不让人自己找
- 蓝图面:「草稿 N · 未闭合 M」两个计数在新机制下**结构上恒为 0**(不闭合存不进来),
  换成「共 N 个版本,保存即生效」
- 驾驶舱:「未闭合草稿」卡整张撤掉 —— 同理恒为 0。天然的第三张是「死路」
  (route-dead-end 事件),但那需要一条按事件类型聚合的路由,没有之前不摆(同死信卡的规矩)

## 顺手修:种子的幂等判断本来是坏的

比对用 `JSON.stringify` 认键序,而 jsonb 从 PG 读回来键是重排过的 —— 永远判不等,
每播一次种就多存一版一模一样的定义(实测一口气堆到 v3)。改成递归按键名排序后比对。
连播三次,只第一次存。

## 契约变更(破坏性,一步到位)

`publish` 删除、`NotPublishableError` → `NotClosedError`、`publishable` → `closed`、
状态枚举收窄。按规矩破坏性变更该走三步弃用 —— 这里一步改完,因为:
① depcruise 反查下游全在仓内(374 模块无违规),同批改完;
② 要弃用的是一个**产品决定不再存在**的机制,留弃用窗口没有意义。
CONTRACT.md 已同步,快照单独说明。

typecheck ✓ lint ✓ depcruise 374 模块 ✓ 495 测试 ✓

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KeDBx2PHLavbURXB8LJJ7m
This commit is contained in:
2026-07-28 12:49:24 +08:00
co-authored by Claude Opus 5
parent 78622b8799
commit b2f5f69d6a
26 changed files with 307 additions and 355 deletions
+34 -7
View File
@@ -83,7 +83,7 @@ export const MVP_PACKAGE: ProcessPackage = processPackageSchema.parse({
id: 'unified-quote',
name: '统一报价',
version: 1,
state: 'draft',
state: 'active',
callInterface: {
input: {
type: 'object',
@@ -426,13 +426,40 @@ const TRIGGER_REGISTRATION = triggerConfigSchema.parse({
export async function seedMvpFlow(container: Container): Promise<void> {
const log = (line: string) => process.stdout.write(line + '\n');
await container.process.savePackage(MVP_PACKAGE);
const report = await container.process.validate(MVP_PACKAGE);
if (!report.publishable) {
log(' 闭合校验未过,不得发布:' + report.violations.map((v) => v.message).join('; '));
/*
* 保存即生效,且**内容没变就不再存新版**。
*
* 保存恒新增版本(这是「旧任务走完旧版本」的前提),所以种子不能无条件存 ——
* 那样每跑一次播种就多一个版本,库里堆一串一模一样的定义。
* 比对的是语义与呈现,不含 version/state(它们由保存本身决定)。
*/
/*
* 比对要**认内容不认键序**。jsonb 从 PG 读回来时键是重排过的
* (Postgres 对 jsonb 的对象键排序),直接 `JSON.stringify` 永远判不等 ——
* 于是每播一次种就多存一版一模一样的定义(实测:一口气堆到 v3)。
* 所以递归按键名排序后再序列化;version / state 由保存本身决定,不参与比对。
*/
const canonical = (value: unknown): unknown =>
Array.isArray(value)
? value.map(canonical)
: value !== null && typeof value === 'object'
? Object.fromEntries(
Object.entries(value as Record<string, unknown>)
.filter(([k]) => k !== 'version' && k !== 'state')
.sort(([a], [b]) => (a < b ? -1 : a > b ? 1 : 0))
.map(([k, v]) => [k, canonical(v)]),
)
: value;
const stripped = (pkg: unknown) => JSON.stringify(canonical(pkg));
const current = await container.process.getPackage(MVP_PACKAGE.id);
if (current !== undefined && stripped(current) === stripped(MVP_PACKAGE)) {
log(`④ 流程包「统一报价」v${current.version} 已在库,内容未变 —— 不存新版`);
} else {
await container.process.publish(MVP_PACKAGE.id, MVP_PACKAGE.version);
log(`④ 流程包「统一报价」v${MVP_PACKAGE.version} 已发布 —— ${MVP_PACKAGE.nodes.length} 节点,边映射闭合校验通过`);
const saved = await container.process.savePackage(MVP_PACKAGE);
log(
`④ 流程包「统一报价」v${saved.version} 已保存生效 —— ${saved.nodes.length} 节点,` +
`闭合校验通过(不闭合会拒存)${current === undefined ? '' : `;旧版 v${current.version} 原样留着,在途任务照它跑完`}`,
);
}
await container.trigger.upsert(TRIGGER_EVENT);