MoonBit 更新日志

当前版本 v0.1.54（0.1.16 是半代次：facade 缺位，见该页首两节） · mooncakes.io（mldong/jeeflow-core / jeeflow-persist / jeeflow-repository-mysql / jeeflow-facade 四模块，独立 0.x 版本线）· 仓库 mldong/jeeflow-moon · Releases 版本日期以本仓 git tag 为准；跨语言对齐脉络见 更新记录总览。

v0.1.54 — 2026-10-31

「退回修改、重提直返」首轮发版（0.1.53 未记本节，见下"注"；本轮 tag v0.1.54＝ 8bf98ec（实现）＋78ef4ef（守卫）＋633965a（出口契约）＋1e0e321（版本号与接力 pin）， 四模块同号）。条文见 规范 04 引擎操作「退回修改、重提直返」节。

• 新增：reapplyMode 节点属性与非法值解析期报错、submitType=6 直返建带 _reapplyContext 的申请待办、submitType=5 重提直接回来源节点、_branchCtx 分支归属 与汇合等齐判据、保留键入口剥离。实现落点：core/engine/reapply.mbt ＋ core/engine/engine_ops.mbt（全异步 SPI）。
• 变更（补齐带标记申请待办的入口守卫）：此前只在命名跳转那一档挡了，且文案与他栈不同； 现按 java 同形在 execute_and_jump_async 入口整体覆盖（命名跳转＋血缘回退两档）， execute_and_jump_to_end_async／execute_and_jump_to_first_async 各补守卫， 四档文案统一为"…不允许{动作}，只接受重新提交(submitType=5)"。
• 修复（ext 回退契约被新保留键打破）：facade/args.mbt 的 task_row_to_json 判据 补两枚保留键；回退语义从并入改为替换（旧写法把实例变量叠在控制键上，回退后 ext 仍带着 _branchCtx），现按其余七栈同形取实例变量副本再合回 _reapplyContext。 本栈实例变量写回只挑 f_*，结构上不带保留键。
• 注：v0.1.53（雪花号单实例＋bizData 键形）当时未在本页留节，此处一并补记。

v0.1.52 — 2026-10-17

audit8 R110＋R112＋R119＋R115 C3⑬（四模块 0.1.51）。

• 新增（删除定义守卫）：processDefine/remove 删除前校验任何实例存在即拒，批量先整批校验。
• 诊断（未知档的边）：决策＋4 个出边循环落穿时打印 from/to，行为不变。
• 修复（首任务节点尺子，R119）：按 nodes 序取首个 snaker:task，不再跟 start 首条出边（首边到 decision 时会导致 isFirstTaskNode 全假）。
• 修复（串行会签零参与者，R115 C3⑬）：零参与者照样建一行 DOING，不再静默 return 留下无可办行的僵尸实例。
• 修复（雪花号同毫秒重号，R111）：repository-mysql 默认发号器此前每次调用都 new 一个生成器 ⇒ 同毫秒连续取号返回同一枚 id，写 wf_process_task_actor 等表会撞主键；现改为进程内单实例。
• 修复（bizData 出口键形，R111）：动态读面行键是驼峰、引擎 reader 的 strict 匹配按列名取数，两形不一致导致业务字段被当“元数据外列”再小写平铺（companyname）；插件读侧先回转列名，出口恢复 companyName。

MoonBit 引擎（jeeflow-moon）为联邦第七个成员，独立版本线：mooncakes 早期阶段平台强制 0.x（决策 D-M5-1），平台放开 1.x 后首个版本即 1.0.0，不跳号。2026-09-05 首发日连发 0.1.0→0.1.2。发版通道与坑位见引擎仓 jeeflow-moon/MAINTAINING.md §3 与同文件 §4 的代决策日志（D-M5-／D-M6-）。

v0.1.49 — 2026-10-16

audit8 R91＋R78 甲/甲′＋R86＋R95（tag v0.1.49，四模块 core→persist→repository-mysql→facade 齐发； release 提交 39cf841，14 处 version＋relay pin 同笔）。

• R91：通用按名解析件＋节点级声明的优先序／回落／显性暴露，条文＝规范 02 §3。
• R78 甲/甲′：元数据腿五处调用钉 strict=true（禁分隔符归一），直通闸与字段消费改用同一把严格尺子； 幂等键仍由引擎按 java 同形注入 snake 键（既有件，未动夹具期望值）。条文＝规范 10 §5.1。
• R86：jump 目标节点不存在改显式报错＋空串档与"没带"同档。
• R95：补 规范 12 §12.4 空转档第一腿（T1-M10：事务内走真实读路径 find_instance_by_id 读回自己刚写的行／提交前独立连接读不到／回滚后不存在）。同轮现读更正：本栈三档落点名不是 T1-F120/121/122， 而是 repository-mysql/smoke 的 M4／M6／M7／M8。

v0.1.48 — 2026-10-16

audit8 R68①② 行为变更（tag v0.1.48，引擎 commit fa20d1e＋判据消警告 f794345； 四模块 core/persist/repository-mysql/facade 同代，模块间接力 pin 与版本同笔抬）。

• 行为变更（委托 update 缺键档）：processName／surrogate 缺键此前保留旧值（混合第三形）， 现改清空（时间窗与 enabled 本就已是清空派）⇒ 与 java 参考实现及多数派对齐，见 规范 06 §4.5 条款 4。
• 修复（enabled 的布尔档）：载荷 enabled 传 JSON 布尔 true 时旧形状落 0（启用被读成停用）， 现补 Json::True/False 两臂 ⇒ 1/0；字符串/数值档行为不变。
• 本栈代次纪律：新增判据曾带 2 枚 Show-弃用警告使 moon check 46→48，已改 unwrap_or 取真值消回 46 warnings/0 errors（与上代代基线全等），断言数值一字未动； moon test --target wasm 492/492，真机腿 T1 仓储级与 T1-F 门面级两腿发版前均 ALL PASS。

v0.1.47 — 2026-10-15

issues/212 收口：分页 action 缺省 pageSize 由 20 改为 10（tag v0.1.47，引擎 commit 0035ca8＋release c7b4401； core／persist／repository-mysql／facade 四模块同代，模块间接力 pin 与版本同笔抬）。

• 行为变更：六枚分页 action 缺省档 20L → 10L，对齐 规范 06 §2.2「pageNum 从 1 起；pageSize 默认 10」全局档。
• 升级影响：依赖"不传就返 20 条"的调用方现看到 10 条；显式传 pageSize 的不受影响。
• 判据：发版前 T0 488/488，T1 仓储级与 T1-F 门面级真库两腿 ALL PASS；moon check 46 warnings/0 errors 与上代基线全等。

v0.1.46 — 2026-10-14

issues/201 收口：SPI 求值抛错不再静默折 false（tag v0.1.46，引擎 commit 215fc79＋release 500269e）。 条文见 规范 06 · 门面 §4.6「求值失败留痕」（issues/201 立法，2026-10-14 owner 拍 C）。

• 现读更正：静默点在引擎 evaluate_expression 的 SPI catch——门面那条 catch 对「求值失败」结构性 不可达（它只罩 simple_eval，而后者零 raise）。
• 新增（可观测性，行为零变化）：引擎 SPI catch 臂补带原因输出（实例号／定义号／expr／err 四件，引擎层 拿不到 nodeId 未硬造）＋新增 eval_failure_warning 纯函数；遍历宽度维持折 false，合法判假不落这条日志。

v0.1.45 — 2026-10-14

issues/197 收口：PageQuery.order_by 全栈零消费者＋内存腿 page_defines 连 filters 都不滤 （tag v0.1.45，引擎 commit 439f867）。

• 修复（后果级）：内存腿三条 SQL／查询分支硬编码 ORDER BY id DESC、且完全不读过滤条件 ⇒ 带条件的内部调用点四处全打在内存腿上：processDesign/redeploy 会把新内容覆盖到另一条定义行、 deploy／saveDeployedDefine 的 version 基数取自别的流程、getLastByName 返回异名定义且 code=0。 order_by 参数则是"能传但没人消费"的死面。
• 跨栈现读：java／go／python／node 四家的内存腿都滤条件 ⇒ 本栈独家。
• 判据：新格＋变异对照＋moon check 警告数与基线全等（46 warnings／0 errors，零新增）。
• 发版链：publish 四步（core→persist→repository-mysql→facade）逐支 success＋pull_verify OK； 接力 pin 14 处同步（5 模块 version＋9 处内部 pin）。
• 传播面：本栈不走 13 壳矩阵——经 mldong-moon 插件跟版→第 14 栈一键包镜像， 通道门禁 51/0/3（3 SKIP＝结构性无 redis）→ 原样晋升（起栈实测装载器报 jeeflow v0.1.45）。

v0.1.44 — 2026-10-13

issues/194 收口：flow.auto／flow.admin 哨兵大小写两派（tag v0.1.44，引擎 commit dac457f＋51dd738）。

• 修复（本栈重一档）：两处敏感腿（聚合根与引擎判定）用精确串比对认哨兵 ⇒ 宿主传异写时代执行／ 管理员语义失效；且本栈栈内有两套口径（一处忽略、一处精确），同一份输入两个答案。 条文 规范 04 逐字带「忽略大小写」⇒ 改的是行为，非契约缺口。
• 同批：rust v1.0.41＋php v1.3.34；本栈腿经插件跟版到第 14 栈通道。
• 判据：两处腿各钉异写档；moon check 46 warnings／0 errors 与基线全等。

v0.1.43 — 2026-10-13

两案并批发版：issues/184（.impl. 类全名错串）＋ issues/185（监听器异常隔离但零日志） （tag v0.1.43，引擎 commit 7068eb1＋1c5ecab＋release fbfeb67）。

• issues/184：内置第 8 档 ActionPermissionProvider 的 className 多一段 .impl.、displayName 非同串——两字段同改，对齐 java／csharp 参照串。本栈头注写「移植 rust」，把 rust 的错串连带搬了过来， 故两栈同案同批（参照串源在 csharp）。
• issues/185：监听器隔离是做到了（catch { _ => () } 不吃异常流），但异常原因整条丢掉＝零日志， 缺裁定的「带原因 ERROR 日志」半句。本版补日志并把文案抽成纯函数便于判据断言。
• 判据：两处变异各咬合；全量 467/467；moon check 与基线全等。
• 传播面：rust→salvo＋本栈→插件，1 镜像＋通道 51/0/3 全晋升。

v0.1.42 — 2026-10-13

issues/182 收口：properties.ext 错键族——本栈读 ext 恒 {}（tag v0.1.42， 引擎 commit e0dee34＋release c2abb8f）。

• 修复（一行）：actions_main.mbt 那处改读 properties.field。基准就是 properties.field—— 全仓没有任何生产方往 ext 写 ⇒ persist 字段权限与 taskModel.ext 原料恒空。
• 同案两栈：rust v1.0.38 是同族另一形（读 ext 恒 null）；本栈的入口过滤缺失早由 issues/150 收口。
• 判据：3 枚＋变异＋还原后 md5 全等。
• 传播面：插件跟版→第 14 栈通道 51/0/3 → 晋升。

v0.1.41 — 2026-10-13

issues/180 收口：abandonTask 不再连带把整单置 99（tag v0.1.41，引擎 commit e907463＋f0f2503）。

• 变更：任务级废弃只废任务，删掉实例 state 的写点——对齐 spec 与 go／python／node； 五栈同批（java／php／rust／csharp／moon），五栈该方法全部零生产调用者（调用面 grep 仅定义处命中）⇒ 现生产零行为变化，收的是「一旦接上就会顺手废整单」的潜伏形状。
• 判据：3 枚＋夹具改为直接置态（避免夹具自身依赖废弃语义）；变异对照。
• 传播面：插件跟版；本轮 5 引擎→6 壳＋插件→6 镜像＋通道全晋升。

v0.1.40 — 2026-10-12

issues/178 收口：candidatePage 四派里的本栈形——只走第二级＋搜索腿丢入参＋分页默认值写死 （tag v0.1.40，引擎 commit 9f6d947）。条文见 规范 06 · 统一门面。

• 修复（三处同案）：① 候选映射只吃到第二级（getUser），没接 findById 优先档； ② 搜索腿入参（pageNum／pageSize／m_*）不透传——PageQuery::new(1L,10L) 写死， 前端翻页与条件搜索全部失效；本版让写死退役。
• 判据：七个用例族＋变异 MA/MB/MC；复跑全量 459 绿。
• 传播面：插件跟版→第 14 栈一键包，通道 50/0/3 → 晋升；同批 go／py／node／rust 共 9 张镜像＋moon 全晋升。

v0.1.39 — 2026-10-12

issues/177 收口：候选人两键改「顶层优先·properties.field 嵌套兜底」（tag v0.1.39，引擎 commit b6c5bb2）。 条文见 规范 08 场景 43「字段权限族」。

• 修复（用户可感知）：parser 只读顶层，设计器写在嵌套形里的候选人被读成空 ⇒ 待办没人能办。
• 判据：2 枚新格＋变异红样；复跑 453 绿。
• 传播面：插件跟版；同批六引擎，9 张镜像＋moon 一键包 10/10 晋升。

v0.1.38 — 2026-10-12

issues/176 收口：startAndExecute 自动办理腿 operator 改 flow.auto（tag v0.1.38，引擎 commit 3d3edfd）。

• 变更（用户可感知）：一键发起并办理的那条任务办理人记成系统哨兵，真实发起人不再同时出现在「我已办」； 三不变量不动（实例发起人／apply 参与者／u_* 仍记发起人）。八引擎同批。
• demo 期望随动：F118 的期望值随本次改动翻新——custom 记录行的执行主体随动 flow.auto （T1-F 真库腿复跑抓出，两档＋参与者锚全绿）。
• 判据：跨栈门禁 L2-43 同轮落格；修前通道预跑 48/1/3，唯一红即这一格（双锚红）。
• 传播面：本栈经插件→第 14 栈一键包；本轮总传播面 8 引擎→13 壳＋moon→14/14 全晋升。

v0.1.37 — 2026-10-11

issues/164 A＋166 A（种子）收口（tag v0.1.37，引擎 commit 1010188；五模块＋九处接力 pin 同批）。

• 变更（用户可感知）：决策节点零命中显式报错——遍历完全部出边仍无命中（带 expr 的边全判 false／ 判定变量缺失／零出边／自定义决策处理器未命中）时抛 decision节点无法确定下一步执行路线 （逐字＝java WfErrEnum.NOT_FOUND_NEXT_NODE，门面出口 99999999＋该 msg）。改前本栈该档 静默停住（令牌不前进也不报错）：办理人看到 code=0"成功"、实例挂在 state=10 且没有任何人的 待办。条文见 规范 06 §4.6「零命中档」。
• 种子：demo FINISHED 三行（F5/F8/F9）补 finalAmount=8000（issues/166——define 映射漂移， flows 目录加入 06-…-expire.json 后 define=12 已是 10-mixed-mode；补键走 e8→boss→end 与旧蒙臂 同形，demo 重置读数回 15/10）。
• 判据：core/engine/i164_decision_nomatch_test.mbt 3 格（内联夹具）＋变异对照； core/engine 151/151、全项目 449/449 绿；moon demo（内置 simple_eval 通用求值）重置 15/10 零种子报错。 消费方 mldong-moon 插件 pin 四处＋descriptor plugin_version 同批跟版（本地）。

v0.1.36 — 2026-10-10

issues/159 收口随 157/160 轮发版（此前 changelog 漏记，此处补一行）：决策边出口取边 id（旧形状取 label 优先）＋simple_eval 三缺陷收口（裸名不代入不蒙 0、排序运算非数字判 false、> Some(2) 死臂与 ${} 双查）。

v0.1.35 — 2026-10-10

issues/153 ②③ ＋ issues/154 ①④（mooncakes.io：仓内 5 个 moon.mod 同批抬号、发布物四件同号，引擎 commit ed42f1d／tag 2bb7d35）。

• 变更：core 的公开面变了——Engine::evaluate_expression 由包内 fn 抬成 pub， 让 facade 的 highLight 路径补全复用引擎那一支求值口，不在门面里另立第二套决策求值。 按「改过已发布模块就要前进代次」这条治理约束必须发新版本。
• 新增：approvalRecord 九键与 id ASC、highLight 的模型补全与决策边求值过滤，向 Java 基准并齐。
• 发版形状：5 个 moon.mod 的 version 与 9 枚接力 pin 同批抬（bump-version.sh 只改 version 不改 pin， 历史上的 0.1.7／0.1.9 半代次事故即源于此），自检＝发布物内部不留旧代次 pin。

v0.1.34 — 2026-10-08

issues/152 委托三件收口（mooncakes.io（四模块同号），引擎 commit 43325e0）。规范条文见 规范 06 §2.5 口径表 与 §4.5「processSurrogate/page 归属不变式」， 判据基线＝规范 08 用例 38–41。升级前两处用户可感知的行为变更必读（见下）。

• 新增：processSurrogate/page 的归属不变式落到引擎自己身上——门面按 §2.5 把归一后的 operator （缺键／空串／全空白 ⇒ demo 缺省 user1）作为 t.operator EQ 下发，形状与本栈 instancePage 一致； 仓储侧补第二层（SQL 侧 AND 1=0、内存侧判不命中），内存仓与 SQL 仓同答案。 此前这条语义全靠集成壳注入 operator（换宿主／直调 SPI 即退化成全库台账，vben5 前端本就不传）。
• 变更：归属条件的缺失档与空值档同判——绕过门面直调 pageSurrogates 时，t.operator 那条 EQ 值为空或整条没给都返回空页，不再"这条条件不加"放出全库；只收归属列， m_LIKE_* 那套"空值当没填"的可选过滤放行原样不动（与 §2.5 抄送侧同一条尺子）。
• 修复：写侧授权人三档归一。processSurrogate/save 收到空串／全空白 operator 时不再落进 operator （那种行是死行：getSurrogate 的 WHERE operator = ? 永不命中，台账看得见、待办永不并人）； save 缺省档落归一值，update 缺省档保留原授权人不变。
• 不变：委托查询的作用域优先级（精确优先）与择优顺序（先按 id 取最新一条再交判据裁决） 维持 v1.8.2x 起的既有立法（issues/123 收口形状），与内置 mldong-wf 版方向相反—— 差异与迁移动作已写进 §4.5「与内置版（mldong-wf）的三条方向差异」。
• ⚠️ 行为变更（用户可感知）：① 集成方若曾依赖"processSurrogate/page 不带 operator 返回全库"， 升级后该档只返回归一缺省 user1 名下的行；② 直调仓储的调用方若不给归属条件，将拿到空页。 jeeflow-ui 与 vben5 两条前端腿都经门面且各栈已实测零回归。
• 测试：仓内 T0 五档判据（作用域优先级／停用不自愈／自委托／写侧三档／分页归属两层）， 每档配真值档阳性对照；摘掉兜底判据必红。

v0.1.27 — 2026-10-06

四模块同号重发（core → persist → repository-mysql → facade；demo 不发布）。本版含破坏性 API 变化，见下"变更"首条。

• 修复（issues/144）：事务句柄从进程级全局槽改挂到仓储实例上。旧形状下 let tx_conn : Ref[MysqlConn?] 判的是"进程里有没有事务"，而本栈单线程事件循环且无 task-local ⇒ 并发请求在 await 点交错时会互相看见同一个槽：后进入的事务既不 BEGIN 也不 COMMIT、把写并进前一个事务， 前者回滚时把后者已经返回给调用方的确认写入一起抹掉（160 真库实测复现）。现行形状： MysqlRepository 持实例字段 tx，new_request() 派生请求级实例（同配置、独立槽）， execute_in_tx(op) 上提到仓储实例并把绑定后的实例交给回调，MysqlTxTemplate 改为持仓储实例委派。 SPI 的 42 个方法签名零改动。
• 变更（破坏面三处）：① MysqlTxTemplate::make 入参由连接配置改为仓储实例； ② 自由函数 current_tx_conn() / close_conn(conn) 改为仓储实例方法（后者转私有，仓外调用点改用 conn.close()）； ③ MysqlRepository 多一个字段 ⇒ 以记录字面量构造该类型的代码编译失败。
• 新增（issues/144 第二步）：Ctx::for_request(repository, ext_repository)——请求级派生入口。 本栈结构体是引用语义，既有 with_* 全是"原地改 self 再返回 self"，照那个样式换仓储会让请求 A 的替换全进程可见； for_request 因此新建注册表、六个容器字段逐个 copy()，而闭包字段（尤其 id 生成器）按引用共享 ——雪花 worker_id 固定、sequence 每毫秒归零，每请求新建生成器会在同一毫秒撞出同一个 id。 配套纪律：SPI 注册只允许启动期做。demo 的 MySQL 分支已改为按请求派生。
• 变更：事务模板回调的错误集由闭集 raise JeeflowError 放开成开放 raise。本栈 async fn 不写 raise 注解即被推成开放效应，闭集签名下宿主无法把一次门面动作包进事务（编译期直接拒）。模板对"抛什么错"本就不该挑： 任何错都回滚、原样外抛。
• 新增判据（事务这件事第一次有行为门禁；判据本体见 规范 12 · 事务契约 §12.4）：仓储级并发原子／ 嵌套不重复 BEGIN／归属边界两方向；门面级原子档（四张表逐个反查＋"不包事务就有残留"的阳性对照）／ 空转档（事务内写→同实例读得到、派生实例读不到、回滚后无残留）／反题桩。三枚变异对照在副本树跑， 各自把对应判据当场变红——其中把取连接逻辑改成"每句自取新连接"那枚，红在门面级原子档， 说明空转档抓得住别的栈的形状。
• 钉出来的现状缺陷：Facade::flow 把 raise 吞成 {code,msg,data} 信封 ⇒ 宿主外包事务时动作内部失败不会触发回滚， 半完成实例照旧提交。本版把它钉成读数（反题桩，不是认可）；契约侧对应 规范 12 · 事务契约 §12.2 「宿主外包事务的两条硬义务」。
• 门禁（2026-10-06 同窗现跑）：T0 moon test --target wasm 403/403；T1 仓储级真库冒烟 111→124 断言 ALL PASS； T1-F 门面级 130→141 断言 ALL PASS；T2 demo 冒烟 ALL PASS；action 清单双向无差集；跨语言一致性载荷逐字节等值； 警告数按两棵干净树同窗对比零新增。消费者侧 scripts/pull_verify.sh 0.1.27 ⇒ PULL-VERIFY OK （正向 code=0 含分页五键／负向 99999999），装到的依赖代次 async 0.22.4 / moondb 0.2.0 / moonmysql 0.7.3。 发布链终局（publish 四步逐步 success、Demo Deploy、sync-cn 三个 run 号）记在引擎仓 jeeflow-moon/docs/CHANGELOG.md。
• 未做：引擎与门面自身仍零事务接线（原子性依赖宿主外包并按契约检查出口 code）；SPI 的拦截器／监听器／ 动态表写出器都是同步形状，而同步函数调 async 判 4149 ⇒ 本栈业务规则落不了库，缺的是 SPI 的 async 形状立法。

v0.1.26 — 2026-10-02（补记）

摘掉 vendored——上游 moonbitstack/moonmysql@0.7.3 放开了 client 的 wasm 目标 ⇒ 引擎仓 vendored 那两个文件 的整目录删除，代码侧只 2 行改动，代次从 0.1.25 前进一格、四模块同号重发（5 version ＋ 7 pin）。 本轮零行为变化：改动本身是把一份"本仓拷贝"换回它对应的那份注册表原件。 发布链读数记在引擎仓 docs/CHANGELOG.md。

四模块同代发（core → persist → repository-mysql → facade；demo 不发布）。

• 新增（issues/115 §3-8）：门面第 47 个 action processTask/removeTaskActor。
• 修复（issues/137 §3-1）：门面出口固定文案「流程处理失败」＋判别式；坏 JSON 与内部异常原文 只走 detail() 落日志（issues/137-G／139 同批）。
• 修复（issues/137 §3-6）：删除腿收口为**「原值 ∪ trim 值」两形并集**（core 内存仓 ＋ repository-mysql）。
• 修复（issues/137 A §3-4）：实例级 expire_time 按定义级表达式求值（两处写点）， 并补 demo/cmd/i137a_mysql 真库腿——实例列真过 160 的 DATETIME(3) 读回，不只看内存对象。
• 修复（issues/137 D／E）：新增 parse_int_non_negative（一处裁四档）；相对档前缀 trim 裁在调用点， 判负单点不掺和。
• 文档（§3-11、批一 A6）：过期注释随批；README 补 native 目标说明（--target wasm 六处一处未删）。
• 发版机制：本版把接力 import pin 与 version 一并前进（五份 moon.mod 的 version ＋ 七枚 mldong/jeeflow-*@ pin 全指 0.1.25）。bump-version.sh --lang moon 只改 version 那一行、不改 pin， v0.1.22 就栽过一次（tag 指到修复前 commit）⇒ 本栈发版固定手工补这一步。
• 测试：T0 moon test（wasm 档——本栈 preferred_target = "wasm"，wasm-gc 会静默丢 async 用例还 exit 0） ⇒ Total tests: 402, passed 402, failed 0；T1 moon run --target wasm repository-mysql/smoke ⇒ T1 ALL PASS (wasm → 160)（专用库 jeeflow_moon_t1）；T1-F demo/cmd/t1_mysql ⇒ 130 PASS； 消费者侧 scripts/pull_verify.sh 0.1.25 ⇒ PULL-VERIFY OK（正向 code=0 含分页五键／负向 99999999）。

v0.1.24 — 2026-09-30（补记）

issues/141（G1/G2/G10 抄送腿）＋ issues/142（A 记录类／B 归属值归一）＋ issues/134/130 那一批的 moon 腿， 另含内存仓水合缺口全修（六条读路单点水合，8bb6a2d ＋ 5ab9dc0）。 本版门禁读数与发布链终局（四步 publish 逐步 success、registry 四件命中、Demo Deploy、sync-cn） 记在引擎仓 jeeflow-moon/docs/CHANGELOG.md， 此处不重复抄；上一节 v0.1.22 与本节之间无其他发布（0.1.23 那批是"只改文档未发版"）。

v0.1.22 — 2026-09-30

• 新增（issues/142 A 批）：记录类（snaker:custom）独立执行腿——parser 兜底臂 _ => Custom 拆成「显式 snaker:custom 档」＋新增 Unknown（未知档先 println 一条带 nodeId 与实得类型串 的 WARNING——文案抽成纯函数 unknown_node_warning，判据留纯函数、副作用留调用点）； Ctx 加 custom_handlers ＋ 注册/解析两成员；任务类零参与者照样建单（1bis 的 expire_time 留 NULL）。
• 变更（issues/142 B 批 · spec 06 §2.11）：@model.normalize_actors 升格通用入口（旧名 normalize_cc_actors 保留为转发）＋ normalize_actor 单值档；门面四条任务写点接同一枚 （surrogate/addCandidate 两形同判据、transfer 单值档、主键档响亮报错、f_/tf_nextNodeOperator 过漏斗）；两仓 remove_task_actor 删除位同 trim（' 8601 ' 删得掉 8601；归一后为空 ⇒ 一行不删， 空串不得批量误删历史 actor_id='' 脏行）；门面 updateCCStatus operator 补 trim （operator_arg 回落 user1 ＋ normalize）。
• 注意：本版四模块接力 import pin 全部同步到 0.1.22（0.1.22 首次发布时 pin 仍指 0.1.21， repository-mysql 的 publish 自检拉旧 core 编不过，属发版机制修正，使用方无感）。
• 测试：moon test --target wasm 316/316；T1-F 真机（160:3306/jeeflow）ALL PASS， 含 "custom1/custom2 expire_time 留 NULL" 两格复读。

v0.1.21 — 2026-09-29

• 修复（issues/138 · ccList 行形状三要件）：MySQL 腿把 cc.actor_id AS operator、 NULL AS variable、cc.create_* 换成共用实例行列清单（instance_select_columns()， 与 pageInstances 逐字同一份 ⇒ 两条查询出行同形）；pageInstances 改引用共用清单， 拼出的 SQL 逐字不变。内存腿 page_cc_instances 改走 instance_row_of（与 pageInstances 共用）。 归属谓词仍是 cc.actor_id（issues/129「空值即空页」不动）。
• 既有断言改判（本栈唯一一处，逐字交代）：已发布的 issues/108 格原写 assert_eq(pagec.rows()[0].operator, "leader")（查询者本人）——那正是 spec 06 §ccList 点名的错法（投 cc.actor_id ⇒ 在被抄送人自己的查询里恒等于他本人，「非空」类判据永远照不出来）。 现按基准改成「该行所属实例的发起人」，并把两格做成互相反向的夹具 （instA 发起人 user1 由 leader 查、instB 发起人 leader 由 user1 查）⇒ 只 echo 查询者的实现两格必红。
• 本栈三处差异（记账，不统一）：① 谓词经 PageQuery.operator 下传，不是门面 query.add("cc.actor_id",…) 条件列（同列同义）；② MySQL 腿保留 SELECT DISTINCT ＋ COUNT(DISTINCT pi.id)，而 java/PDO 是非去重 t.* ＋ COUNT(*) ⇒ 同实例多张 cc 时本栈出行 1 条，换纯实例列后 rows 与既有 count 口径首次自洽 （旧为 count=1/rows=2 打架）——去重口径本身归 issues/141 G2 待拍；③ 悬挂 cc 行 java/php 天然不出行， 内存腿为不动已发布计数语义保留出行（主键＝实例 id、operator 空串）。
• 测试：moon test（wasm 档）225/225（基线 218 ＋ 7）。两层变异：operator 退回 cc.actor_id ⇒ 红样点名「operator＝流程发起人 boss（实际 <ccuser>）」；投影换 cc 表原样 ⇒ 「id 的值＝实例 id 100001（实际 100004；旧写法出口的是 cc.id）」。 native 档与真库 MySQL 腿本机跑不了（同上一代口径记豁免）⇒ MySQL 腿只守 SQL 文本形状。

v0.1.20 — 2026-09-29

• 新增（issues/127 ＋ 132）：core/event 码表补齐 A 套 1..9，新建 notify_events.mbt 把九支的构造与广播集中一处便于逐键审计；直传载荷键按 §11.3 落齐——3/5/6/7 这几支 sourceId 是 taskId，载荷必须带 instanceId，否则集成层事件流水会被拆成多个 taskId 键、 顺序读不全（这是硬要求而非「方便字段」）。
• 形状记账：「state 落库后 fire」在本栈由「两处码 2 都排在 update_instance 之后」满足； 因 MoonBit 引擎不做完整子流程展开，java 的父实例待播上收结构性不适用（不造第二套语义）。
• 测试：moon test（wasm 档）218/218 通过；native 档本机跑不了（vendored 需 cc、 moonbitlang/async C 运行时只认 MSVC）⇒ 与上一代同口径记豁免。
• 立案未修：tf_ccActors / f_ccActors 在本栈只吃逗号串，数组形态静默丢值（java 两形态都收） ——同一份共用夹具在七栈建 cc、在本栈一支不建，见 issues/141 G6。

v0.1.19 — 2026-09-29

• 修复（issues/134 · 撤回不校验实例状态）：对已办结/非进行中的实例调撤回，改前会被静默改写—— 实例 state 被写成 30 且返回 code=0（症状现场：boot2 生产镜像 code=0 msg='成功'，state 20→30）。 聚合根 withdraw 入口加实例态守卫：state != 10(进行中) 一律拒，内部码 20010009，被拒时 实例与任务行零改写、不落库；出口按 issues/121 口径透出 code=99999999 + 逐字文案 「流程实例非进行中，无法撤回」（内部码不进 msg）。任务行层面的既有保护（spec 06 的"20/40 任务行 不改写"）原样保留，实例级守卫排在它之前。落点：core/model/aggregate.mbt::withdraw 签名改 raise @error.JeeflowError，守卫排在 任务行循环前。moon test 208/208（基线 199）＋ moon check 0 errors。moon 栈 130 侧无需改动。

v0.1.18 — 2026-09-28

• 修复（issues/126 案 A）：本栈无求值器 ⇒ 新增 core/model/expire_time.mbt（放 model 而非 util——本栈没有 core/util/，钟与时刻串在 model/clock.mbt）：process_time 三档逐字（变量档终局 NULL／类型不认识落穿／ s·m·h·d 相对档，d 走 add_days 日历加／绝对档严格 19 位），任何一档都不返回基准时刻。 五处写点：engine.mbt 普通建单 / 串行首位 / 并行全员，engine_ops.mbt 串行推进位与回退新建—— 回退那支原形状是「继承 history.expire_time」（抄上一行的值），改成置 None 后按被回退掉的当前节点表达式重算。
• 测试 moon check 0 errors（11 警告＝基线，新增文件零警告）、moon test 199/199（基线 179＋20）。 两向变异对照各自把测试跑红（红在「配 2h ⇒ 同行差值≈2h」与「§1.8 首成员∧推进第二成员都带到期」）。 行尾按本仓 惯例保住，未跑 moon fmt（它会洗行尾）。
• 发版核验（这一版是"接力式 pin"的正面案例）：bump-version.sh --lang moon 只改四模块自身版本， 本次手工把 facade/persist/repository-mysql/demo 的 import pin 一起对齐到 0.1.18 （persist 与 repository-mysql 当时还钉在 core@0.1.14，比 0.1.16 半代次更深一层）， publish CI 四步 core/persist/repository-mysql/facade 全 success，moon update 后索引四模块都读到 0.1.18。
• 跨栈一致性（同批八栈一起发，基准＝boot2 内置版 ProcessTaskServiceImpl:213/386/524 三处写）：普查发现写点其实是五处，第五处＝串行会签推进出的下一位成员（boot2 的推进回调 createCountersignTask（:485，内含 :524 到期写）），各栈这一支普遍绕过本栈建单 helper 直建行，只看建单/回退两支会漏。另一处分叉在落地中被抓出来：回退新建的表达式该取 boot2 的 current＝被回退掉的那个节点（:363 current = model.getNode(currentTask.getTaskName()) → :385 ((TaskModel)current).getExpireTime()），而不是落地行所属的 prev；java/php/csharp/rust/node/moon 取 current，go 与 python 头一轮取成了 prev，两栈当时的夹具只给一个节点配表达式 ⇒ 取错也全绿，是比对隔壁栈代码才发现。修完的判据改成双节点不同偏移（落地 1d ∧ 当前 3h ⇒ 断 ≈3h）＋反向钉一档「当前未配 ⇒ 必须空」。

v0.1.17 — 2026-09-28（facade 单独一代）

• 本版只为解开发版卡点：facade/moon.mod 的依赖 pin 从 jeeflow-core@0.1.14 提到 0.1.16 （persist 同批），并把 facade 自身版本提到 0.1.17 ⇒ publish CI 第四次全绿，四模块齐发。 功能内容与 0.1.16 那一代相同（131 的改动在 core 侧）。
• 为什么必须单独一代（接力式 pin，与本页 0.1.7/0.1.9 半代次同族但根因不同）： bump-version.sh --lang moon 只改各模块自身版本，不动 import 的依赖 pin； 而 publish 的包体自检从 registry 取依赖源码编译（不吃本仓源码）⇒ 新 facade 配旧 core， FlowData.get_string_array 必找不到。本地 moon test 179/179 全绿证不到这一层（workspace 用本仓 core）， 只有 publish 能证。
• 处置纪律：发布物不可变 ⇒ 没有动 v0.1.16 标签（重跑只会一直 409）。 下轮 moon 发版的起跳点＝四个模块的自身版本与依赖 pin一起对齐到 0.1.17。

v0.1.16 — 2026-09-28（半代次：core / persist / repository-mysql 出，facade 当时没出）

• 变更（issues/131 案 A，与 Rust 1.0.18 同题）：串行会签簿记从实例变量搬到任务变量。 core/json/flow_data.mbt 新增 insert_string_array / get_string_array（数组型簿记， 本栈原来只有逗号串的 insert_str/get_str）；建单侧 seed_countersign_bookkeeping 写进首个成员任务， 推进侧从 _task.variables 读回名单并把三键抄给下一成员任务；门面 actions_ext.mbt 按数组读。 复活行控制键过滤 is_control_var_key 未动——现读它本来就列着 csv_ / loopCounter / nrOfInstances / operatorList 四个前缀（外加 tf_ / f_），搬家后剔除腿天然覆盖新键名； 实施卡里"moon 只剔 csv_、不补就静默留残留"那条预警经 git show d995870~1 现读证伪，没据此改代码。
• 测试 moon check 0 errors；moon test（wasm，本机口径）179/179（.scratch/moon-131-test.log）。 surrogate_test.mbt 第 1.3 条断言按 A 案从"实例带簿记"改写到任务侧。
• 变异对照（.scratch/mutate-moon-131.py，两处独立）：名册值退回逗号串 ⇒ engine.blackbox_test 红； 读侧退回 exec.process_instance.variables ⇒ 同一格红。按 sha256 还原后全绿。
• 发版 tag v0.1.16（d32c244）触发的 publish 两次红在 "Publish facade" 步 ⇒ 本代只出三模块， facade 缺位；补全在 v0.1.17（见上一节）。

v0.1.15 — 2026-09-28

• 修复（issues/129 案 A，与 Java 1.8.32 同题）：新增 operator_arg(args)（判空用 trim、非空白返回原串＝java operatorArg 逐字同形），替换 actions_main.mbt 9 处 + actions_ext.mbt 3 处 arg_str_or(args, "operator", "user1")。没改通用取值函数 arg_str_or（别的 key 也在用）。
• 症状与 php 同档：本栈归属列空串不丢条件（Some("") 照绑 ⇒ 0 行），线上表现是"我的列表悄悄变空"而非那五栈的读全库（160 探针 moon 空串档=0）。第二层只在 repository-mysql/query/query.mbt 的 if is_empty_value(value) { continue }——那是 java JdbcProcessRepository:1095 的同形通用放行，而 m_EQ_operator / m_pi_EQ_operator / m_ta_EQ_actorId / m_cc_EQ_actorId 正好命中那四个归属列（本栈别名 ta）⇒ 归属列 EQ 空值不再丢条件，改写 AND 1=0 且不 bind；非归属列行为与改前逐字一致（哨兵格钉住）。内存通道的 m_ 解析本就没有空值跳过 ⇒ 不硬造一层，只加测试留判据。
• 既有语义保持：缺键（None）档仍是"不加条件"＝全库，与 java"没 add 这条条件"同形，不是漏收；门面归一化后四条归属出口经门面永远拿 Some(user1)。issues/114/115 硬必填与 8 处 "system" 审计缺省未动。
• 测试 T0（wasm，本机口径）：moon check 0 errors（警告数与改前同基线）、moon test 179/179（改前基线 168：facade +7、query +4）。既有断言一行未改（query_test.mbt numstat = 69 插入 / 0 删除）。native 档本机跑不了（vendored moon_mysql_client 要 cc，moonbitlang/async 的 C 源在 Windows 只认 MSVC）⇒ 由 CI 的 ubuntu Native Probe 裁决。
• 变异对照两层互不遮蔽：只回退 operator_arg ⇒ facade 包 31/36（5 红，四出口空串档 0≠2）；只回退第二层 ⇒ query 包 4/7（3 红：归属列空值 filter 被通用放行丢掉）；六文件按 sha256 还原后全量 179 绿。
• 发版核验：mooncakes 四模块齐发（CI publish job steps：core / persist / repository-mysql / facade 四步全 success；半代次号只出 core+persist 的先例见本页 0.1.7/0.1.9 注）。demo（/moon-api）部署绿后线上复验：四出口空串档 = 4 / 5 / 1 / 2。

v0.1.14 — 2026-09-26

• 变更（registry 依赖换代，无行为变化）：moonbitlang/async 0.20.3 → 0.22.4、 moonbitstack/moondb 0.1.8 → 0.2.0、moonbitstack/moonmysql 0.4.0 → 0.7.2。 单发一版的理由只有一个：依赖 pin 写在发布物的 moon.mod 元数据里——不发版， 用户 moon add mldong/jeeflow-* 拿到的仍是 0.20.3 那一代（本地编译走 workspace，证不到这一层）。
• 验证：三个 bump 逐个做、每步以全工程 moon check 为验收人，三次读数都是 0 error / 11 warning（那 11 条即 0.1.13 里逐条证伪过不可摘的结构性误报，一条没多）； T0 168/168、T1 仓储级 111 格、T1-F 门面级 104 格（真机 MySQL）、T2 全链路冒烟、 action manifest 46/46 全绿，八栈一致性快照 consistency/moon.json 载荷逐字节等值。
• 消费者侧回拉验证已固化为 scripts/pull_verify.sh：在临时工程里只从注册表装四包， 跑正向（processInstance/page ⇒ code=0 含分页五键）与负向（未知 action ⇒ 99999999）两支， 并打印实际解析到的第三方代次（本版为 async 0.22.4 / moondb 0.2.0 / moonmysql 0.7.2）。
• API 与出口形状零变化：46 个 action、SPI 签名、错误码、JSON 出口与 0.1.13 完全一致， 升级 = 改一行版本号。

v0.1.13 — 2026-09-26

• 变更（新工具链适配轮，无行为变化）：适配 moon 0.1.20260920 / moonc v0.10.14， 从"能编译"推到 0 error、诊断 629 → 11 条。采用的新形状：impl 方法不再被隐式提升为常规方法 ⇒ 补 48 条 pub extend T with Trait::{…}；try? 全量塌成 try { 块 } catch { 臂 }； 事务模板的收尾改 errdefer（工具链声明 try/catch 将来不再捕获异步取消）； substring(…) ⇒ 切片 s[a:b]（38 处）、StringView 尾巴 .to_string() ⇒ .to_owned()（42 处）； 弃办 fn meth(self : T) ⇒ fn T::meth(self : T)；SPI provider 改带类型标注的箭头值。
• 两处对外形状收敛（消费方需知）：ProcessInstance/Task::resume ⇒ resume_from_interrupt （resume 是工具链预留字；全仓 0 调用点，且不是跨栈契约名——契约只钉 action 串与 JSON 形状）； 若干从不抛错的函数摘掉 raise 声明（含门面出口 flow），效果收窄对调用方源码兼容。
• 判据未动：T0 168 例、T1 仓储级 111 格、T1-F 门面级 104 格、T2 全链路冒烟全绿； 八栈一致性快照 consistency/moon.json 逐字节不变。
• 残留 11 条警告已逐条证伪"可摘"（8 unused_trait_bound + 3 unused_error_type）： 它们是"只看函数体、不看调用链"的结构性误报——摘掉要么编译不过（本工具链效果不参与函数子类型）， 要么只是把告警搬到另一行；条目级静音在这版无可用机制。证据与四种试法见 MAINTAINING.md §1.3。
• 发版通道顺带修了一处：publish.yml 四模块改可重入（每步先 moon update 刷索引、 已在注册表则跳过）——0.1.13 首发就卡在"core 刚发完、索引没刷新，persist 解析不到 jeeflow-core@0.1.13"，重跑又撞重复发布。

v0.1.12 — 2026-09-26

• 变更（issues/120 附证：时钟基准）：SQL 侧摘掉第二把钟——repository-mysql 六条写路径的 NOW() 全部改绑引擎钟（新增 repo.now_v()），库里 update_time / create_time 与 finish_time 从此同基准（160 实测 @@session.time_zone=+08:00，旧形状同行两列差 8 小时）。
• facade/stats.mbt 的逾期判据由裸 @model.epoch_secs()（注入不了）改走 current_time_str()， 与 todayNew、写库列、委托生效窗同一把钟。
• demo 时钟基准由宿主注入：环境变量 JEEFLOW_TZ_OFFSET（东为正小时，支持 8/+8/-5/5.5/ +05:30，上限 UTC+14；未配或非法 ⇒ 保持 UTC 并打印所选基准，不静默猜区）。线上演示站已带 =8， 实例 createTime 与宿主墙钟同秒。
• 新增判据：facade/stats_clock_test.mbt 3 格（注入钟 = 真实 UTC − 12h 铺 ±1h 真窗， 带阳性对照）+ T1-I120 七格（六列 + 摘掉注入的对照组）；变异对照实测"换成 DB 钟必红"。
• 读码所得：moonbitlang/x/time 的 Zone::from_tzif2 吃真实 tzdata 不报错但静默给 Z； iceBear67/time 的 wasm 臂是桩；moondb 把 DATETIME(3) 投成 Blob（按文本读回得 <BLOB>）。

v0.1.11 — 2026-09-24

• 变更（issues/124 变量出口立法，对齐 Java v1.8.30 基准）：processInstance/detail 出口 variables 更名为 ext，variable 原串退出任务行出口（facade/actions_main.mbt + facade/args.mbt）；唯一出口 = ext（实例侧）+ instanceExt（任务行侧），空变量出 {}；持久层 variable 列不动。
• 测试 162 例全绿；mooncakes 四模块 moon add 全部可装——完整代次（四模块齐发，无半代次断档）。

v0.1.10 — 2026-09-23

• 变更（发布通道，零行为变更）四模块统一升 0.1.10，同仓依赖 pin 抬到已发布的 0.1.9 —— 解 0.1.9 只发出 core/persist 的接力问题（moon publish 的包体自检 vendored 的是注册表里的已发布 core，不吃本仓源码，机理见下节）。代码与 0.1.9 完全同源，无新增能力。
• 发版状态 ✅ tag v0.1.10 → publish CI completed / success；外部回拉核验用 moon add 走注册表解析器本身（api/v3/... 路径猜不中、mooncakes.io/docs/* 是 SPA 壳恒返 200，两条探针都不成立）：mldong/jeeflow-{core,persist,repository-mysql,facade}@0.1.10 四件解析全通。moon test 升 pin 前后同读数 162/162。
• ⚠️ 装配口径：MoonBit 侧请取 0.1.10 全套，不要把 0.1.9 当完整代次混装（0.1.9 只有 core/persist 在 mooncakes 上，按 0.1.9 拉 facade / repository-mysql 必失败）。demo 不发布，其 pin 不动。

v0.1.9 — 2026-09-23（⚠️ 仅 core / persist 两模块发布）

• 修复（委托判据取行顺序，对齐 Java 参考实现）：core/model/rows.mbt 新增单条裁决 ProcessSurrogate::is_effective（enabled 严格 1 / 被委托人非空且非本人 / 窗口覆盖判定时刻，起止空 = 该侧不限、time 传空串不比窗）+ surrogate_scope_hit 供两仓共用 ⇒ 双仓同答案由构造保证；内存仓拆掉扫描期过滤（pick_surrogate → newest_surrogate，只按 operator + 作用域取 id 最大）；SQL 仓撤掉 AND surrogate <> operator / AND enabled = 1 / 窗口谓词；精确作用域判否（含池空）后仍查全流程作用域的最新一条（不得判否即止）。新增 6 格内存仓用例 + smoke 双仓对拍 12 行 / 6 探针（含兜底格）。
• 变更 conn.mbt 的 NULL enabled 缺省由 1 改 0：撤掉 WHERE 谓词后 NULL 行会真被读到，缺省必须落在不生效侧（本栈 enabled : Int 非可空，表达不了 null）。
• 测试 moon test 162/162（基线 156，+6）、moon check 0 errors；变异对照：内存仓改回「先滤后取」逐格隔离跑 ⇒ 窗外 / enabled=0 / 脏值 2 / 自委托四格红，正向与兜底两格仍绿（red=4），cp 备份还原后 diff 无差异。未测：repository-mysql 的 smoke 与 demo 的 T1（本机真库凭据未设），SQL 侧形状与内存侧同构。
• 跨栈验证 MoonBit 仅引擎、无框架集成仓 ⇒ 不进 13 栈门禁对拍面，本栈判据由 T0 162 例 + 双仓对拍自证；同批跨栈实证见其余七语言页的 L2-17。
• 发版状态 ⚠️ 本版只发出一半：CI run 的 Publish repository-mysql 步退出 255，真错是 Error: [4021] Value surrogate_scope_hit not found in package model（repository/repository_ext.mbt）。机理：moon publish 会把产物解包后再 moon check 一遍，而包体校验阶段的依赖是从注册表 vendored 的已发布件取的——当时四模块的 pin 还停在 0.1.7，那份 core 里没有本轮新增的 surrogate_scope_hit ⇒ 本地 moon test 162 全绿而 CI publish 必红（同仓依赖「接力式 pin」：下一代发布前必须先把 pin 抬到已发布版本，否则自检永远看不到本仓新符号）。注册表实测 core@0.1.9 可解析、persist@0.1.9 可下载、facade@0.1.9 报 no version satisfies requirement ⇒ 同号重发必撞「版本已存在」，故四件统一升 0.1.10 收口（见上节）。
• 同批说明 退回上一步两格对外 msg 的删码前缀（本栈两格原为中文带 2001000x: 前缀）已随上一代次落地，测试断言同时由「前缀匹配」升级为逐字相等（更强：前后缀回归都抓）——本版无该项遗留。

v0.1.8 — 2026-09-23

tag v0.1.8（01:50），单 commit 793f833。这一代次才是 MoonBit 的完整可装配版本。

• 修复（issues/121 文案口径）：两格"退回上一步"的对外 msg 删掉 2001000x: 码前缀 （本栈原为中文带前缀），对齐 Java 逐字文案与规范 06 §4.3 统一表。
• 发版通道（关键一步）：同仓依赖 pin 由 0.1.0 抬到 0.1.7 —— publish 的包体校验吃的是 注册表已发布件而非本仓源码，旧 pin 拉到的 vendored 版本带旧泛型语法，直接把 publish 卡死 （本地 moon check 只有 warning，CI 却是 81 warnings, 2 errors，错位就在被 vendored 的依赖编译路径）。
• 发版状态 ✅ publish run 35763278556 completed/success，逐步核验： Publish core / Publish persist / Publish repository-mysql / Publish facade 四步全 success ⇒ 0.1.8 四模块齐发，可与 0.1.10 同代次混装（0.1.9 不行，见其节）。

v0.1.7 — 2026-09-22

tag v0.1.7（19:27），bump commit 2494efc。号已占死但只发出半代次 ⇒ 装配时不要指定 0.1.7。

• 新增（121 P1/P2 血缘回退 carry 口径）：persist_tasks 建单写 parent_task_id 与行级 isFirstTaskNode（830ea3e）； 退回上一步改血缘版并拆开 3/6 共用分支（11f4bc6）；门面 ext.isFirstTaskNode 改「行上值优先、存量行才现算」（a7f5e94）； 无血缘用例补到三种形状并各自证明绑的是自己那条支路（97cb829）。
• 修复（issues/116）：委托条款 1.1 补 trim——流程名带空白时委托曾静默失效（d6e96c7）； 委托自动生效内置 ＋「我已办」判据与窗口比较同一把尺子（c82e360）。
• 120 时基：MoonBit 豁免（不注入时钟、不造 FFI），跨栈对拍面也不含本栈（仅引擎、无框架集成仓）。
• 发版状态 ⚠️ 半代次：publish run 35721568129 completed/failure，逐步看是 Publish core ✅ → Publish persist ✅ → Publish repository-mysql failure → Publish facade skipped。 真错在被 vendored 的依赖编译路径（moon_mysql_client 一带的 2 errors）；mooncakes 版本号不可覆盖 ⇒ 0.1.7 这个号从此"有 core/persist、缺另两件"，修复只能走 0.1.8（即上一节那条 pin 抬升）。

v0.1.6 — 2026-09-19

• 变更（本版主体）MySQL 依赖坐标随上游迁移到 moonbitstack（纯改名，零行为变化）——repository-mysql 拉的 moonbit 官方 MySQL 驱动改了 org，代码与语义不动。
• 新增 PostgreSQL 建表 DDL schema/schema-postgres.sql（8 表与 mysql 版同构），此前只有 mysql 一份，按 postgres 起库无从下手。
• CI 补 sync-cn workflow，与六语言仓（java/go/python/node/rust/ui）同款模板：打 v* tag 或手动触发时把 master + 全部 tag 同步到 Gitee / GitCode 国内镜像。
• 文档（对外口径一次性收敛，占本版绝大多数提交）：门面 action 计数统一写 40+ 不写死精确数（历次 40/42/43/45 漂移的教训，历史版本节与 manifest 断言仍留精确值）；公开文档清洗私有台账引用（不再出现 issues/NNN、#NN）；docs/ 只留用户文档、维护者向内容收拢到仓根 MAINTAINING.md，其中内网主机字面值全换 <DB_HOST> 纯文本、from_env 内置默认改指 conn.mbt；import 示例改 moon add <pkg> 不钉版本；Quickstart clone 改 HTTPS（SSH 形式会卡死评审首步）；README 补 Live demo 小节（jeeflow-demo.mldong.com/?lang=moon）；修 mermaid 边标签反引号致 GitHub 渲染 Lexical error；发布通道三条错误归因更正留痕（403 归因、EXPECTED_MOON_VERSION 守卫职责、latest 与 yank 的关系）。
• 验证 本板未重跑引擎测试；该仓当前基线为 moon test 156/156 + demo/cmd/t1_mysql（wasm→真机 MySQL）ALL PASS（2026-09-22 复跑读数）。
• 发版状态 tag v0.1.6（2026-09-19 20:30 +0800）实证已打；mooncakes 四模块产物回拉验证本板未复核（站内 SPA，直接 curl 取不到版本列表），留作发版轮各 registry 统一核验的一条。

v0.1.5 — 2026-09-09

• 修复 五语言 SQL 仓聚合水合：MysqlRepository::find_instance_by_id 此前只查 wf_process_instance 单表，tasks 硬编码 []，门面 processInstance/detail 的 tasks/activeTaskList 恒空（gate26 L2-12 门禁真根因，非会签语义）。二次查 wf_process_task（复用 find_history_tasks：ORDER BY id + hydrate_tasks 批查 actor_ids，事务内经 open_or_tx 复用环境连接，autocommit 独立连接语义不变）水合任务副本，语义对齐 Java findTasksByInstanceId / PHP PdoProcessRepository / C# FindTasksInternalAsync（聚合水合口径）。update_instance 本就不级联任务（仅实例行 state/variable/update_time），withdraw 逐任务路径不变。memory 仓本就水合（基线正确，未动）；引擎核心会签语义未动。
• 测试 T0 新增 smoke.mbt::t1_i110_hydrate（T1 通道 moon run --target wasm，真实 160 MySQL，9903xx 独立 id 段 + clean_9x 自清理）：引擎 start_async 发起 doing 实例 → 断言 find_instance_by_id 水合任务非空 + 带 actor_ids，且门面 detail 消费（遍历 inst.tasks 组 tasks/activeTaskList）非空。
• 验证 moon test --target wasm 119/119 绿（单测套件未动）；moon run repository-mysql/smoke T1 ALL PASS（M1–M5 + 新增 I110 五断言全过）；moon check --target wasm 全 workspace 无硬错误。
• 发版状态 ✅ 已发布（2026-09-09，publish run 34331706389 四模块全绿，mooncakes 产物实下回拉验证）。过程留痕：首轮卡点经全量日志更正为 latest 漂移（官方 latest 前进到 0.1.20260904，被 EXPECTED_MOON_VERSION 守卫按设计拦截，非 CDN 403）；owner 定调去掉版本守卫（latest 为向前别名只前进、发布不强校验）后 re-run 通过，配套 0d23278 适配新编译器 3 处旧式泛型（双编译器 T0 119/119 全绿）。发布通道策略定调见 jeeflow-moon/docs/PUBLISH.md。

v0.1.4 — 2026-09-07

• 修复 instancePage/ccList 缺 operator 过滤（core/memory/memory.mbt）：page_instances 此前全量构建 rows 不读 query.operator()，任意用户「流程实例」页可见所有人实例 → 新增 operator_eq（String 列版），实例 operator 即发起人（与 java t.operator EQ / JeeflowFacade.java:254 同源，spec 06-facade §2.5）；page_cc_instances 补 cc.actor_id = operator 过滤（java :649 同口径）。过滤在构建 rows 时执行，recordCount 为过滤后计数（分页教训）。
• 核查 repository-mysql 路径无需改：page_instances/page_cc_instances 的 count/select 本就有 AND pi.operator=? / AND cc.actor_id=?，与 memory/java 三方口径一致（无 式「OR create_user」偏宽）。
• 测试 T0 119 用例全绿（新增 instancePage/ccList operator 正负向 + 无 operator 全量回归）；T1 wasm→160 mysql smoke ALL PASS（M1–M5，含 instancePage 分页五键 + operator 过滤回归）。
• 红线保持：processSurrogate/page（我的委托）无过滤是全语言现状（T003 矩阵不变量 7 依赖），未动；page_todo_tasks/page_done_tasks 行为不变（收口保持）。

v0.1.3 — 2026-09-06

• 修复 doneList 双缺陷：page_done_tasks 此前 define 传 None（行 processDefineDisplayName 恒 null，公网「我的已办」流程列整列「-」）且未应用 operator 过滤（混入他人任务）。照 page_todo_tasks 解析 instance→define + 新增 done_operator_match 按 t.actor_id=我 过滤（对齐 java t.operator EQ / spec 06-facade doneList），过滤在算 total 前执行保证 recordCount=命中数。
• 变更 repository-mysql doneList operator 收敛 t.operator=?（原 t.operator=? OR t.create_user=? 过宽，对齐 java；T1 wasm→160 smoke ALL PASS）。
• 契约对齐 stats 一致性 4 处偏差随本版带出：overview total 按 stateIn 门控 / stuckApprover 按 actor 关系逐人计数 / durationBucket 固定 4 桶全枚举 / 分组平级确定序；新增一致性驱动 demo/cmd/consistency（快照 consistency/moon.json 15/15 与 java/rust 逐字段全等）。
• 测试 T0 118 用例全绿（含 doneList 显示名非 null + operator 正负向 + 无过滤回归）；tag v0.1.3 → publish.yml CI 发 mooncakes 四模块（run 34046826425）+ demo-deploy 公网重建（run 34046826422）；公网复核「我的已办」流程列非「-」且仅本人任务（API + 浏览器双证据）。

v0.1.2 — 2026-09-05

• 变更（发布通道）publish.yml CI 通道恢复（D-M5-4）：装 latest 工具链 + EXPECTED_MOON_VERSION 守卫（漂移即 fail-fast）+ moon update 前置 + validate_only 自检通道；tag 实战发版成功（run 33951631628，四模块生效）。
• 修复 stats overview 均值口径（D-M5-5）：group/define 维 overview 改均值，本地 + 公网复核。
• 契约对齐 stats 计数/时长字段 JSON 类型与契约 §4.2 同口径（int），七语言类型断言 84 项 PASS；demo 公网 https://jeeflow-demo.mldong.com/moon-api，UI ?lang=moon 发起→待办→同意→state=20 全链路验证通过。

v0.1.1 — 2026-09-05

• 修复 0.1.0 的 parity 缺陷：Number→Int64/id 串转换 double 截断（雪花 id 超 2^53 后 T2 假绿，是否复现取决于 id 低位是否凑巧 double 可精确表示，health 门禁探不出）。5 处改 repr 优先：core/json as_i64、facade/args arg_actor_ids、core/engine parse_cc_actors、facade/outbound stringify_id_value（出口安全网同步加固）、repository-mysql value_to_string（SQL 字面量）。
• 测试 T0 增大整数精度回归至 117 用例；demo-deploy.yml 部署后加 T2 冒烟门禁（数字 id 全链路，防假绿复发）。checklist 全绿：T0 117 / T1 160 / T2 多轮 / manifest 45 / mooncakes 回拉验证 PASS。

v0.1.0 — 2026-09-05（首发）

• MoonBit 首发版本（第 7 语言）。全异步架构（仓储 SPI / 引擎 / 门面全 async fn），DDD 聚合根 + 状态机 spec/03 全集，45 action 契约基线（与 java JeeflowFacade 实查双向无差集，manifest 固化），LogicFlow 解析 / 会签门控 / 事件三型 / 7 内置 AssignmentHandler。
• mooncakes 四模块拓扑序：core → persist → repository-mysql → facade（demo 不发布，:8092 内存/MySQL 双存储 + jeeflow-ui ?lang=moon）。
• ⚠️ 本版含雪花 id double 截断缺陷，0.1.1 修复——外部装配请直接用 ≥0.1.1。