| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
docs: 维护者向会话期文档出仓 + 活文档口径收敛（40+/版本引用/追认状态） - 删 docs/m1-progress.md：自称会话续接锚点，实际是 M1–M2 历史快照 （测试数 101/101 vs 现行 119、M3/M4/M5 未勾选 vs 已发 0.1.5、 Rust→Moon 映射表列错位、尾部未清理草稿「?不对——」）； 用途已被 decisions-log/CHANGELOG 取代。对齐其他语言仓 docs/ 只留 用户向文档的口径（java/go/python/node/rust/php 均无此类文件） - 删 docs/handoff-demo-deploy.md：0.1.0 时代「新会话直接粘贴」快照， 两个「当前卡点」均已 ✅ 解决，正文满布 G:\ 机器路径与过期数据 （116/117 用例、0cc0674）；内容属会话期交接，不入活文档 - P1-5 活文档 45 统一 40+（HEAD 9827217 只改了 engine-api/demo/ integration 三处）：README 5 处、docs/index 2 处、facade/README 2 处、 core/README 1 处、getting-started 1 处（已在 P0 提交）； engine-api/contract-notes 的「实查 45/45」改「双向无差集，精确计数 以 manifest 为准」——消 engine-api 自身 40+ 与 45 打架； 保留精确 45：action-manifest.json、check-action-manifest.mjs 断言、 CHANGELOG 历史条目、decisions-log 历史记录（manifest 45 在 D-M5-3 为历史事实留痕） - P1-6 docs/index 不再手写版本号：「当前版本 0.1.2」改指向各模块 moon.mod 与 CHANGELOG（同 45 漂移教训）；CHANGELOG 行描述去 0.1.0→0.1.2 写死区间 - P1-7 decisions-log 状态字段按事实更新：已追认条目（D-M0-1/2/3、 D-M3-1/2、D-M2-1/2、D-M5-1/2/3）「待追认」→「已追认（2026-09-05）」 （追认事实见 0.1.0 时代交接记录）；D-M5-5 保留待追认（不在已追认 清单内）；D-M5-4 补失效标注——版本守卫（EXPECTED_MOON_VERSION） 已被 2026-09-09 owner 定调移除，「遗留风险：守卫会拦下」随守卫 不存在，改由官方 yank 兜底（决策原文不改，仅追加状态） | 1 个月前 | |
| 1 天前 | ||
fix(wf): processDefine/remove 增加任何实例即拒守卫（audit8 R110） 整批先校验再删；内部码 20010005，文案沿用 boot2；mysql/内存双实现；check 46/0＋511/511 | 16 天前 | |
fix(facade): spec 04 两枚保留键算进 ext 控制键，82-3 回退复原 同 java 9cdbfaf 一处病：建单往每条任务变量写 _branchCtx（空分支也写 []），而 task_row_to_json 的「任务变量只剩控制键 ⇒ ext 回退实例变量」判据（issues/82-3 / 121 P1）只数 isFirstTaskNode 一枚 ⇒ 每条任务行不再回退、内部键从公开出口透出。 - 判据改为「除 isFirstTaskNode／_branchCtx／_reapplyContext 外没有别的键」 - 回退从**并入**改为**替换**：旧写法 for k, v in instance_ext { ext[k] = v } 把实例 变量叠在控制键上，回退后 ext 仍带着 _branchCtx；现按其余七栈同形，取 instance_ext 的副本，再把 _reapplyContext 原样合回（jeeflow-ui helpers.ts 读 ext._reapplyContext 取「重新提交后返回：X」）。合回只动任务侧那份，instanceExt 出口不被污染 - 新增 facade/task_row_ext_fallback_rts_test.mbt（两腿内容级判据） - 本栈实例变量写回只挑 f_*（engine_ops.mbt 那条循环），结构上不会把保留键带进实例 变量，故不需 go／python／node 那处挡键（三家现读各自确认过） 读数：moon check --target wasm 0 error；moon test --target wasm = 528/528（原 527）； T1 repository-mysql/smoke 连 160 ALL PASS；T1-F demo/cmd/t1_mysql ALL PASS。 坏样本（判据只认 isFirstTaskNode）⇒ 新用例 abort，moon 直接把 "Active test at executable exit" 点名到本用例；还原后 528/528。告警 49 条与 HEAD 同树现跑基线一致，改动文件零新增。 注：facade/args.mbt 行尾是 \r\r\n 与 \r\n 混排（本仓 .gitattributes 为 * -text）， 改动按字节级就地替换，未整文件重写（numstat 25/6）。 | 2 天前 | |
feat(m4): demo 全契约 + jeeflow-ui /moon-api 接入——demo :8092（POST /wf/{action} 45 action 全转发零业务 + /health + /api/stats + /api/reset + CORS 预检 + 8 具名用户 SPI（user/org/userSearch 关键词分页）+ flows 种子按文件名序 define id=1..15 + design/design_his listByType 契约完整 + JEEFLOW_DEMO_STORE=memory|mysql 双模式）；T2 冒烟脚本 scripts/smoke_t2.sh 全链路 ALL PASS（发起→待办→办理→state=20→高亮→未知 action 99999999→reset 重置）；修复：Int64::to_json 输出字符串致信封数字字符串化（number_of 改 parse 原文保 Number+repr）、未知 action 双重信封（dispatch 改 raise UnknownAction 顶层 99999999）、seed 排序错位（D-M3-2：core sort wasm 对 String 排序错误，自写插入排序全仓替换，issues/105-moon- 台账）；T0 116/116 | 1 个月前 | |
feat(146): 供数/回调族 SPI 全量 async 化 ＋ 动态表元数据端口 ＋ 事件监听器 async（站内信落点成立） 三件一并一轮（owner 定调：妥协不对，提引擎 issue 走引擎轮）。 缺口一：IUserProvider / IOrgUserProvider（三法）/ IUserSearchProvider（两法）/ biz_data_reader 由同步闭包改 async 闭包 ⇒ 宿主在闭包里现场查库；同批 async 化拦截器 pre/post、三类 handler、事件监听器。 判据＝"这一档回调的真实现要不要做宿主 I/O"，不是"java 签名同不同步"（moon 栈查库只有 async 一条路； 同步形状等于逼集成方启动期快照，mldong-moon 插件 v1 的 41 用户预载就是这么被迫的）。 纯计算四档（json/expression/id/permission）保持同步。另开 *_sync 便捷口 + @spi.async_of_sync 桥， 把"空转 async 必被判 unused_async"集中在三处，注册点零警告。 缺口二：persist 增 DynamicMetaProviderFns（async load_table_meta）+ InMemoryMetaProvider::as_provider + PersistPostInterceptor::make_from_provider；端口按 java 归属放 persist（IDynamicMetaProvider 就在 jeeflow-persist/meta，core 无消费者，挂 Ctx 即死端口）。T0 用例钉"运行期改列权限/新增列 ⇒ 下一轮生效"。 缺口三：监听器形状 async + 错误集折成闭集 ⇒ 监听器可 await 写库（站内信这类写型副作用第一次有落点）。 案文"无事件分发机制"不准确并已更正：9 支码/逐监听器兜底/落库后 fire 在 issues/132 那轮就有，真病灶是同步闭包。 破坏面：Ctx::with_user_provider 等一批签名、InterceptorFn.run、三类 handler、PersistPostInterceptor 字段名。 现读消费者只有 mldong-moon 插件与本仓 demo/夹具，均已随版改完。 门禁（本轮现跑）：moon check wasm 0 error（87 tasks）；moon test wasm 404/404； T1 repository-mysql/smoke（160 真库）ALL PASS；T1-F demo/cmd/t1_mysql 155 PASS ALL PASS， 新增 F146（运行期新用户免重启即解析 + 查无此人 None 不炸发起）与 F146E（async 监听器写库， 码 1/3/2 从真库读回）。警告 22→37 逐码归因写进 CHANGELOG 与 MAINTAINING §门禁基线。 | 26 天前 | |
fix(error,facade): issues/137 §3-1 门面出口固定文案「流程处理失败」＋判别式（moon） owner 2026-10-02 第 3/4 问拍 A（第 4 问明文点名要含本栈那 5 条驱动腿）；spec 先行已落 （doc 56f359e 新开 §2.12、908bbcb 补「集成方 handler/provider 的原文同属内部信息」先例）。 **第一步先追清了承重前提**（不是照抄批三 §1 的预测）：@error.Internal 的 message **确实会**流到对外 msg—— core/error/error.mbt:46 Internal(msg) => "内部错误: \{msg}" 把原文带前缀搬进 message()， facade/facade.mbt:48 顶层 catch err(e.message()) → outbound.mbt:29 直接落 {code:99999999, msg:<原文>} 信封 ⇒ 与 rust error.rs:84 **同形状**，那 5 条是真泄漏点。 **实证**：变异 M1（把出口还原成改前形状）下出口 msg 实测＝ 内部错误: mysql connect: Access denied for user 'root'@'10.0.0.8' (using password: YES) ——**带主机与账号的凭据串**（留痕 tmp/b3-31-mutation/m1-raw.txt）。 按主口径 ① 在**出口层**加判别式；驱动腿构造点 conn.mbt:36/65/79／tx.mbt:76/90 **不动**—— 出口已兜住，且原文经扩展后的 detail() 进门面日志；Internal 只有一个 String 字段， 要把原文挪出 message 只能另造变体 ⇒ 违反 §2.11「不抄第二份」。 - core/error/error.mbt（+28/0）：① pub const INTERNAL_FAILURE_MSG = "流程处理失败"（逐字，八栈同串）； ② 纯函数 JeeflowError::is_foreign_detail()（命名对应 java isForeignDetail）—— ⚠️ **moon 的变体本身就是档位**（批三 §1.5 的分档结论），判据收敛成"Internal ⇒ true"一条， **未移植** java 那套运行时类型族启发式（那是把简单问题复杂化）； ③ detail() 扩 Internal(d) => Some(d) 臂（复用批二 6384f27 的机制，不另起一套）。 - facade/facade.mbt（+10/−3）：出口 catch 改为 is_foreign_detail ? INTERNAL_FAILURE_MSG : e.message()； 既有 detail() 日志腿自动把驱动原文落日志（测试运行时可见 [jeeflow] action 执行失败: … detail=mysql query: …）。 - facade/actions_ext.mbt:556（bizData 腿，覆盖面②）**必须在构造点收口**：旧 Business("业务数据读取失败: \{e.message()}") 把第三方 reader 的原文拼进了**契约档** ⇒ 出口判别式挡不住这种形状（判据按"是不是 Internal"判，而它是 Business）。 改成 java 基准同文 Business("业务数据读取失败") ＋ println 日志带 cause/detail。 ⚠️ 这是本轮与"① 出口层为主"的一个**有意例外**：契约档里被拼进原文时，只有构造点能收。 新增两测试文件（照 java FacadeInternalErrorNoLeakTest 判据形状，**未动任何既有测试**）： core/error/i137_31_foreign_detail_test.mbt 纯函数腿（Internal 五形＋裸包装 ⇒ foreign／固定文案／ 原文可从 message() 与 detail() 两处取回；十个契约变体 ⇒ non-foreign ＋ 逐字抽查）； facade/i137_31_internal_no_leak_test.mbt 门面信封腿（test-only 扩展仓按 5 条驱动腿原文形状 raise ⇒ 出口 msg **逐字**＝流程处理失败；bizData reader 抛驱动原文／provider 原文 ⇒ 逐字＝业务数据读取失败 ＋正向对照；契约面透出题 operator 必填／任务不存在／任务非进行中，不可摘除参与人／ 至少需保留一名参与人／未知 action:／读取流程定义 JSON 失败 逐字）。 ⚠️ 真库腿本机不可跑（native 需 cc＋真库），按本仓"内存绿≠落库绿"的规矩用 test-only 扩展仓同文取证。 普查清单（全仓 \{e}／e.message() 插值进错误构造或对外字段，逐处判定）： · 5 条驱动腿 ⇒ 真泄漏点，出口层本轮兜住； · actions_ext.mbt:556 ⇒ 真泄漏点（拼进契约档），构造点本轮收口； · demo/app.mbt:300 Business("body 解析失败: \{e.message()}") ⇒ **不修**：e 只可能是 @json.parse_json 的 ParseErrorWithCause，其 message()＝固定文案「读取流程定义 JSON 失败」 （core/json/json.mbt:16），**无原文可漏**；且 demo 层不是引擎门面出口； · unknown_node_warning（core/parser/parser.mbt:185，两调用点 :390／engine.mbt:203） ⇒ **合规不修**：只进 println 日志、不进任何对外字段，内容为用户自有流程定义的 nodeId/type， 非内部细节（§2.12 明许"原文只进日志"）； · 解析族（批二 6384f27）复核**到位**：json.mbt:16 构造 ParseErrorWithCause(固定文案, 原文)、 error.mbt:45/55 message/detail 分档，既有 i137g_parse_msg_no_leak_test.mbt 3 格钉住 （本轮 402 中绿；**M2 下会红 ⇒ 钉子真实有效**）。未动 ParseError 通用档及其既有钉 error_test.mbt:21。 改前红样两组（tmp/b3-31-moon-mutation.py，报告 tmp/b3-31-moon-mutation-report.md； 字节级备份 → 逐行替换并保留每行自己的 terminator（本仓行尾混排 \r\r\n/\r\n 且 .gitattributes 是 * -text 零归一化）→ 跑 → copyback → sha 核对 3/3，未用 git checkout/stash）： · M1 还原泄漏（出口 err(e.message()) ＋ bizData 拼接）⇒ Total tests: 402, passed: 400, failed: 2， **恰为那两条泄漏格**（凭据串见上）； · M2 判据恒真（一律固定文案）⇒ 402/380/22：新契约面格＋core/error 契约档格＋**既有** i137g（批二）、i115×7、i141／i142b×4、withdraw×6 等**全部报警** ⇒ 本栈契约面有既有钉看着（这一片 java 一处都没钉，moon 比 java 强）。 读数（均我复跑非转述）：moon test --target wasm ⇒ **Total tests: 402, passed: 402, failed: 0** （改前基线 396 ＋ 6＝2 纯函数＋4 门面，**条数逐字相符**——wasm-gc 档会静默丢 async 用例且 exit 0， 故判据必须断言条数）；moon check --target wasm ⇒ **21 warnings / 0 errors**， 对照 HEAD 基线 21 为 **新增 +0**（HEAD 换回法：git show 取回改前内容＝21、copyback sha 3/3 一致， 留痕 tmp/b3-31-moon-warning-delta.md）。 numstat 只涨改动行（28/0、11/1、10/3），行尾保住（error.mbt 仍 0 CR；facade.mbt 仍全 \r\n； actions_ext.mbt \r\r\n 恒 750、新增 10 行沿用目标行自己的 \r\n）。 既有测试期望值改动 **0 处**——全仓 grep 确认无一处钉"msg 含原文" （无 解析错误: 前缀断言、无钉 内部错误: 出口的既有格）⇒ 红线"停下回报"未触发。 ⚠️ 两条如实留档： ① ParseError(msg) **通用档**若未来被第三方直接 raise 原文，会按契约档透出（解析错误: <原文>） ——这是批二立档时"调用方自己写的文案要能看见"的既定语义（error_test.mbt:21 钉住）， 本轮**未收窄**；引擎内部已零调用。 ② bizData 两条文案（业务数据读取失败／业务数据读取器未注册（…））都不在 spec 失败文案表内 （与批三 §1.6 记的"bizData 是两条腿两个文案"同一件事），本轮按 java 基准逐字对齐， **补录 spec 那一步留给主会话落账**。 | 1 个月前 | |
fix(wf): processDefine/remove 增加任何实例即拒守卫（audit8 R110） 整批先校验再删；内部码 20010005，文案沿用 boot2；mysql/内存双实现；check 46/0＋511/511 | 16 天前 | |
fix(wf): processDefine/remove 增加任何实例即拒守卫（audit8 R110） 整批先校验再删；内部码 20010005，文案沿用 boot2；mysql/内存双实现；check 46/0＋511/511 | 16 天前 | |
feat(146): 供数/回调族 SPI 全量 async 化 ＋ 动态表元数据端口 ＋ 事件监听器 async（站内信落点成立） 三件一并一轮（owner 定调：妥协不对，提引擎 issue 走引擎轮）。 缺口一：IUserProvider / IOrgUserProvider（三法）/ IUserSearchProvider（两法）/ biz_data_reader 由同步闭包改 async 闭包 ⇒ 宿主在闭包里现场查库；同批 async 化拦截器 pre/post、三类 handler、事件监听器。 判据＝"这一档回调的真实现要不要做宿主 I/O"，不是"java 签名同不同步"（moon 栈查库只有 async 一条路； 同步形状等于逼集成方启动期快照，mldong-moon 插件 v1 的 41 用户预载就是这么被迫的）。 纯计算四档（json/expression/id/permission）保持同步。另开 *_sync 便捷口 + @spi.async_of_sync 桥， 把"空转 async 必被判 unused_async"集中在三处，注册点零警告。 缺口二：persist 增 DynamicMetaProviderFns（async load_table_meta）+ InMemoryMetaProvider::as_provider + PersistPostInterceptor::make_from_provider；端口按 java 归属放 persist（IDynamicMetaProvider 就在 jeeflow-persist/meta，core 无消费者，挂 Ctx 即死端口）。T0 用例钉"运行期改列权限/新增列 ⇒ 下一轮生效"。 缺口三：监听器形状 async + 错误集折成闭集 ⇒ 监听器可 await 写库（站内信这类写型副作用第一次有落点）。 案文"无事件分发机制"不准确并已更正：9 支码/逐监听器兜底/落库后 fire 在 issues/132 那轮就有，真病灶是同步闭包。 破坏面：Ctx::with_user_provider 等一批签名、InterceptorFn.run、三类 handler、PersistPostInterceptor 字段名。 现读消费者只有 mldong-moon 插件与本仓 demo/夹具，均已随版改完。 门禁（本轮现跑）：moon check wasm 0 error（87 tasks）；moon test wasm 404/404； T1 repository-mysql/smoke（160 真库）ALL PASS；T1-F demo/cmd/t1_mysql 155 PASS ALL PASS， 新增 F146（运行期新用户免重启即解析 + 查无此人 None 不炸发起）与 F146E（async 监听器写库， 码 1/3/2 从真库读回）。警告 22→37 逐码归因写进 CHANGELOG 与 MAINTAINING §门禁基线。 | 26 天前 | |
fix(facade,core): issues/137-G/139 moon 腿——坏 JSON 出口只给 java 逐字基准文案，底层原文走 detail() 落日志 改前实测红样 2 条（还原 json.mbt 后 moon test --target wasm --package facade）： "解析错误: json: Invalid character '这' at line 1, column 15" != "读取流程定义 JSON 失败" ⇒ cjson 的行列号原文直接进用户面 msg；detail 档那格同时红（期望变体没拿到）。 正向对照格（合法 content 走同一条腿）改前改后都绿 ⇒ 判据不恒真。 形状照 rust ParseErrorWithCause 的同一条尺子： - error.mbt 新增变体 ParseErrorWithCause(对外固定文案, 底层原文)；message() 只给前者、 新增 detail() 给后者（只供门面 println，不进出口 msg）。 - **不动 ParseError 本身**：core/error/error_test.mbt:21 钉着 ParseError("bad json").message().contains("bad json")，那是"调用方自写文案要可见"的通用档， 改它＝动既有测试期望值。 - json.mbt 的 raise 点换成新变体，固定文案逐字取 java 基准「读取流程定义 JSON 失败」。 - facade.mbt 顶层 catch：先按 detail() 落一行 [jeeflow] 前缀日志，再 err(e.message())。 门票：moon test --target wasm ⇒ Total tests: 355, passed 355, failed 0（断言条数，防 wasm-gc 静默丢用例）。 新测试文件按本仓 facade 目录约定写 \r\r\n 行尾（.gitattributes 是 * -text，git 不归一，必须逐字保行尾）； facade.mbt 本身是 CRLF，改动走字节级替换（diff 只有 11 行，非整文件重写）。 本地 commit，未 push；随 §4 的 0.1.25 代一起发。 | 1 个月前 | |
fix(core): issues/138 ccList 行形状对齐 boot2 基准——cc 命中后输出实例行（id←pi.id／operator←流程发起人／variable、create_* 同实例行），退掉 cc.actor_id AS operator 与 NULL AS variable；内存腿共用 instance_row_of | 1 个月前 | |
feat(core,facade,repository-mysql): issues/141 G10 空抄送人不建 cc 行（对齐 java 5fbd5ac，spec 06 §2.10 四条逐条落） 普查把上一轮的预判证实了：本栈逗号串腿本来就 trim＋丢空，**数组腿只判 is_empty 不 trim、 且两处写侧毫无兜底** ⇒ [" "] 实测建一行 actor_id=' ' 并 fire 一个码 4； [" userB ","userB"] 实测两行两次 fire（同一人被判成两个 ⇒ 把上一轮 G2 的写侧判重打穿）； 直连仓储 create_cc_instance([""]) 落一行空值；create_cc_instance_if_absent([""," "]) 返回的子集就是 [""," "]（＝拿空人去发知会）；子流程发起腿同样中招。 判据单点新增 core/model/rows.mbt 的 pub fn normalize_cc_actors（trim→丢空→同次折叠→保序）， 四层各接一次：引擎 parse_cc_actors 两形态汇流处、门面手动腿（丢完为空 ⇒ 沿用既有 actorIds 缺失 档，不新造文案）、内存仓两个建行口、MySQL 仓新增纯函数 cc_actor_ids_to_insert（normalize ＋ cc_fresh_subset 两步组合，只做组合不另写规则； 抽 pub 是为了 T0 不连真库也能照到 MySQL 写侧）。 cc_fresh_subset 自身保持不 trim 不丢空——existing 侧读的是库里原值，与 java findCcActorIds 原值比对同口径；归一只发生在写入前。 core/spi/repository.mbt 的 trait 头注释把"抄送义务"从两条补成三条（G10 写侧这层必须 实现方自己挡），**未新增 SPI 成员、未改签名** ⇒ 不像上一轮 G2 那样构成编译期破坏。 既有格子只动一处、且是裁定要求的升级：cc_actors_shape_test.mbt 那条 G6"空串与空数组 两形态互相一致"原来是 assert_eq(cc_rows_of(a), cc_rows_of(b))——两态都空 ⇒ 恒真的假判据， 现改成绝对断言"零行＋零 fire"（互比两行保留作回归钉）。证据：在还原态下改后形态红在 :205（FAILED: 1 != 0，真落一条空行），把四行绝对断言临时摘掉换回旧的只比自等形态， 同一还原态下该格就绿 ⇒ 升级确实把假判据换成了会红的判据。 测试：新增 27 格（引擎 9／内存 6／MySQL 写侧 6／门面 6）。既有期望其余零改动。 逐处还原实测改前会红：只还原漏斗 3／只还原内存写侧 5／只还原 MySQL 写侧 5／ 只还原 trim（normalize 去 .trim()）23／只还原门面手动腿 1；漏斗＋内存同还原（本栈改前整体）11 红。 E1+E2+E5 三连读数未取（明确记未验）。 moon test 270→**297/297 全绿**（本机口径＝wasm；MySQL 真库 T1 与 native 档本机跑不了）。 未 bump moon.mod.json（仍 0.1.21）、未动 docs/ 与 import pin。 | 1 个月前 | |
feat(core,facade,repository-mysql): issues/141 G1/G2 抄送分页归属条件必填＋cc 写侧判重＝幂等空操作（对齐 java 3d1fc98） 判据单点落在 core/model/rows.mbt 两枚 pub 纯函数——cc_ownership_operator（G1：本栈 cc 归属 通道是 PageQuery.operator，缺键/空串/全空白 ⇒ None）与 cc_fresh_subset（G2：保序、已有跳过、 同调用内折叠）；内存仓与 MySQL 仓共用这两枚，不再各写一套（java 的 hasEffectiveCondition 在本栈收敛为一枚，因为本栈 conditions 通道只有 operator）。 G1：page_cc_instances 归属无有效值 ⇒ record_count=0/rows 空集；MySQL 侧把 count/data SQL 抽成 cc_page_count_sql/cc_page_data_sql 且归属谓词恒拼（删掉 None => "" 那条"这条不加"的退路）， 谓词形状可用纯 SQL 断言离线钉住。 G2：SPI 新增 find_cc_actors / create_cc_instance_if_absent（MoonBit trait 无 default ⇒ 这是 破坏性新增，24→26 方法，自实现仓储必须覆写；两内置仓均已实现，changelog 必须写）。 三条建行点（发起腿 f_ccActors、办理腿 tf_ccActors、子流程发起腿）＋门面手动 createCCInstance 一律走 IfAbsent 拿子集 fire，子集为空整支不发码 4；旧入口 create_cc_instance 同样幂等。 重复抄送：不新增行、不重置未读、不刷原行时间；查询侧不去重、历史重复行不清。 测试：新增 38 格（内存判据 6＋内存幂等 9＋引擎 fire 8＋门面 8＋MySQL SQL 形状 7）， moon test 232→270/270 全绿。逐处还原病灶实测改前会红：A 段（幂等＋子集 fire 还原）16 红、 B 段（摘内存 G1 短路）2 红、C 段（8 个实现文件整体还原）编译期就报缺函数（判据单点被两仓依赖）。 被 G1 顶到的 8 处既有格只改读法（换成仓储真相或补合法 cc.actor_id 条件），断言值一字未动， 其中两格（memory_test 的 issues/108 回归格、operator_blank_test 的 i129 边界留档格）原先 钉的正是"cc 零条件也返行"这一被 G1 关掉的形状——改读法＋注释写明改判依据，未回炉期望值。 MySQL 腿的"缺条件⇒空页"本轮只守到 T0（判据单点＋谓词恒拼两层）：行为档需要 async test， 而 repository-mysql/repo/moon.pkg 没有 test-scope 的 moonbitlang/async，加这行 import 属包配置 变更，未在本案顺手做。未 bump moon.mod.json（仍 0.1.21）、未动 docs/、未动 import pin。 | 1 个月前 | |
fix(core,memory): 六条任务读路收到单一参与者水合点——修列表读路同族缺口（待办漏人） 8bb6a2d 只补了两条守卫读路（find_task_by_id / find_history_tasks），本笔收掉它点名的同族 缺口：find_doing_tasks / find_done_tasks / page_todo_tasks / page_done_tasks 仍按聚合根 actor_ids 过滤与投影 ⇒ 发起腿门面 addTaskActor、processTask/surrogate 追加（java 同款只写 actor 表）的参与人，在待办列表里整行不可见。 改动（core/memory/memory.mbt）： - 新增模块级 hydrated_task(actors, tid, task)，把「actor 表即参与者唯一事实源」收成单点判据； 六条读路（含原两处内联块）全部走它，杜绝「补一条漏三条」。 - page_todo_tasks 的水合放在 query_match 过滤之前——那才是漏人的真位置。 - page_done_tasks 过滤判据是 actor_id（办理人，finish 写入），不受水合影响；水合只为投影一致。 - get_all_tasks 的「仅当 actor_ids 为空才回填」弱口径保持不动（只喂 stats、不在守卫/列表路径）， 改它会动 stats 读数，超出本缺口范围，留 owner 拍。 权威判据：java JdbcProcessRepository.mapTasks:571 对每行无条件 setActorIds(findTaskActors)； 本栈 mysql 仓 hydrate_tasks 同构（注释即「is_allowed 依赖 actor_ids」）。零既有断言被改。 测试（facade/i142_list_read_hydrate_test.mbt 新增 3 格；夹具刻意非对称——A 只写表 / B 表聚合 一至 / C 两处都空 / D 已办只写表，等值夹具会让 B、C 自等假绿）： - page_todo_tasks 水合后才不漏发起腿参与人（含 lisi 对照组、wangwu 负向、taskC 真空对照） - 四条任务读路对同一行给出同一参与者集合 - page_done_tasks 过滤口径不变、投影行归属与表一致 gate 三场景： - 正向：T0 352/352（349+3）全绿；demo 种子 in-progress 16/16、finished 9/9、surrogates 8/8 - 回归/负向：T2 冒烟 7/7 ALL PASS（含未知 action → 99999999），既有负向格零变红 - 变异对照（副本里把 hydrated_task 改成不水合，单点覆盖六条读路）：判红 5 格——本笔 3 格 （page_todo_tasks 报 0 != 1）+ 8bb6a2d 的 2 格（报 99999999 != 0），而对照组不红 ⇒ 新格确有判红能力，非恒绿。副本已删，共享树未动。 附带：把本文件遗留的 5 处纯 CRLF 归一回本仓约定的 CRCRLF（whitespace-only）。 | 1 个月前 | |
feat(core,facade,repository-mysql): issues/142 B 批 任务参与者归属值写侧归一（spec 06 §2.11）＋ §9.2 第二批删除位 trim＋门面 updateCCStatus 补 trim 判据单点＝@model.normalize_actors（G10 的 normalize_cc_actors 升格通用入口，旧名保留为 转发）＋ normalize_actor 单值档。门面四条任务写点接同一枚：surrogate/addCandidate 的 actorIds 两形同判据、transfer 的 operator/fromActor/toActor 走单值档（必填信封不动）、 主键档响亮报错、发起/办理两侧 f_/tf_nextNodeOperator 过漏斗单点。 两仓写侧兜底＋SPI 注释义务（add_task_actor 归一＋trim＋主键报错）；§9.2 第二批—— remove_task_actor 删除位两仓同 trim（「 8601 」删得掉 8601；归一后为空 ⇒ 一行不删/ 一条 DELETE 不发，空串不得批量误删历史 actor_id='' 脏行）；门面 updateCCStatus operator 补 trim（operator_arg 回落 user1 ＋ normalize_actor 取 trim 值，与 java normalizeActor(operatorArg(args)) 同构）。 测试：T0 新五件（判据/内存仓含删除位/消费腿/门面/MySQL 仓纯函数档），全量 347/347； T1 新增 F119 删除位真库读数（160 实测：trim 命中＋空档零删除脏行保留）， T1-F114..F119 ALL PASS。 | 1 个月前 | |
feat(facade,core): issues/159 moon 侧收口——simple_eval 蒙方向三处修正 + 边名出口取 id 159 归因反转：立案时"边模型没喂 properties.expr"的假设被现读证伪（EdgeModel::expr 一直读着 properties.expr，运行时 Decision 分支与门面 collect_path 同口），真根因是 simple_eval 三处违反 spec 06 §4.6 义务 2 第三条 ⚠（issues/158 立法）+ 157 轮 moon 腿打的是 0.1.33 代旧镜像 （160 镜像 10-09 01:45 构建，早于 0.1.35 发版与 pin 抬升，153②③/154①④ 从未上门禁）。 - 裸名代入：新增包级 resolve_bare_names——${}/# 之外的裸标识符从 args 查值代入（str/i64 双查， 同 #var 形）；查不到原样保留交给排序运算判 false（缺失变量不蒙 "0"——蒙 0 会让缺失变量的 <= 边判真，重演 159 落错支）。true/false/null 字面量与引号内内容不代入。 - 排序运算（> >= < <=）改走 compare_numeric：双侧必须数字，非数字操作数判 false（spec 明文）； 字符串字典序兜底只保留给 ==/!=（spec 不约束那两档）。 - 死臂修正：> 臂判 Some(2)、<= 臂"非 Some(2) 即 true"，而 compare_values 只产 Some(-1/0/1) ⇒ > 恒 false、<= 恒 true——正是 157 轮探针 amount=5000 走 task3 的根因；0.1.35 的 i153 夹具 只用 ==/!= 恰好绕开排序运算，故漏网。 - ${} 形连带：与 #var 同款 str/i64 双查（修前数字档变量被代成字面 "0"）。 - collect_path 边名出口取边 id、label（text.value）不再优先——参考实现 java AbstractNodeParser tm.setName(edge.getId())，画布文案从不进出口（159 读数 3）。 判据：core i159_decision_expr_test 六格 + facade i159_l2_39_test 三格（runner decision_flow 同形， 停在分支上档）——修前全红（含 active=[task3] 落错支仓内复现）、修后全绿；变异对照（副本还原 两源文件）core 6/6 红 + facade 落错支红。T0 moon test --target wasm 446/446；零警告与基线 逐字一致（clean check 类型计数 diff 为空）。无命中档（缺失变量 ⇒ 两边全 false ⇒ 现状停住） 自此在 moon 可达，行为未动待拍（issues/164）。 | 23 天前 | |
| 24 天前 | ||
feat(facade,core): issues/159 moon 侧收口——simple_eval 蒙方向三处修正 + 边名出口取 id 159 归因反转：立案时"边模型没喂 properties.expr"的假设被现读证伪（EdgeModel::expr 一直读着 properties.expr，运行时 Decision 分支与门面 collect_path 同口），真根因是 simple_eval 三处违反 spec 06 §4.6 义务 2 第三条 ⚠（issues/158 立法）+ 157 轮 moon 腿打的是 0.1.33 代旧镜像 （160 镜像 10-09 01:45 构建，早于 0.1.35 发版与 pin 抬升，153②③/154①④ 从未上门禁）。 - 裸名代入：新增包级 resolve_bare_names——${}/# 之外的裸标识符从 args 查值代入（str/i64 双查， 同 #var 形）；查不到原样保留交给排序运算判 false（缺失变量不蒙 "0"——蒙 0 会让缺失变量的 <= 边判真，重演 159 落错支）。true/false/null 字面量与引号内内容不代入。 - 排序运算（> >= < <=）改走 compare_numeric：双侧必须数字，非数字操作数判 false（spec 明文）； 字符串字典序兜底只保留给 ==/!=（spec 不约束那两档）。 - 死臂修正：> 臂判 Some(2)、<= 臂"非 Some(2) 即 true"，而 compare_values 只产 Some(-1/0/1) ⇒ > 恒 false、<= 恒 true——正是 157 轮探针 amount=5000 走 task3 的根因；0.1.35 的 i153 夹具 只用 ==/!= 恰好绕开排序运算，故漏网。 - ${} 形连带：与 #var 同款 str/i64 双查（修前数字档变量被代成字面 "0"）。 - collect_path 边名出口取边 id、label（text.value）不再优先——参考实现 java AbstractNodeParser tm.setName(edge.getId())，画布文案从不进出口（159 读数 3）。 判据：core i159_decision_expr_test 六格 + facade i159_l2_39_test 三格（runner decision_flow 同形， 停在分支上档）——修前全红（含 active=[task3] 落错支仓内复现）、修后全绿；变异对照（副本还原 两源文件）core 6/6 红 + facade 落错支红。T0 moon test --target wasm 446/446；零警告与基线 逐字一致（clean check 类型计数 diff 为空）。无命中档（缺失变量 ⇒ 两边全 false ⇒ 现状停住） 自此在 moon 可达，行为未动待拍（issues/164）。 | 23 天前 | |
fix(facade): highLight 块级降级面落可诊断日志（issues/162-R7 搭 176 轮） - 修点：actions_ext.mbt high_light 块级 catch { _ => () } → e => 失败支落 println("[jeeflow] WARN highLight 模型补全腿失败: instanceId=… defineId=… err=…")； 降级面保留（对外仍 code=0、边集/进度留空），形状照本仓 bizData 腿既有 [jeeflow] println 口径 - 判据：新件 i162 两枚（①坏定义 ⇒ code=0＋边集空＋nodeProgress {}＋任务行不受影响； ②好定义 ⇒ 边集正常填充不误伤）；「日志真拿到」＝测试 stdout grep 恰 1 行三件齐 （本栈 println 无注入 sink，以运行读数判，见案文记账） - 变异：失败支摘 println ⇒ 两枚判据仍绿、WARN 计数 1→0（日志腿由读数判别）；还原 cmp 全等 - 全量 451/451（449 基线＋2 新） | 21 天前 | |
fix(facade): candidatePage 三处收敛——映射链补 findById 第一级＋行键 id 三级回落＋搜索腿吃 pageNum/pageSize/m_*（issues/178 R12） 映射链形状照 java JeeflowFacade.java:945-1012；T0 七用例（档①命中压二级/档①b userId 回落/档②getUser/档③兜底/搜索腿捕获/缺省 1-10）。 全量 459/459 绿（facade 126 含新增 7）；三处逐处变异回旧形即红（id 回落缺/搜索腿写死/pageNum 不吃），字节级还原 cmp 清洁。 | 21 天前 | |
fix(facade): issues/182（R16）taskModel.ext 改读 properties.field＋i182 三枚判据 错键族与 rust 同源（移植连带）；判据 3 枚（正/负/回归；双锚 field＋诱饵 ext）。全量 465/465（基线 462＋3）、变异红、还原 md5 全等（c5f40214…）。 | 20 天前 | |
fix(core,repo): issues/197 R31——page_defines 两条腿都消费 order_by，内存腿补条件过滤 - core/model/order_by.mbt 新增 parse_order_by／order_column_bare：解析口径逐字照 java JdbcProcessRepository.buildOrder（逗号分子句、方向缺省升序、desc 大小写不敏感）， 方向词只产出布尔量 ⇒ order_by 原文永不进 SQL 串（java 那边方向词是直接拼串的） - core/memory page_defines：补 filters 过滤 + 消费 order_by + 缺省 id 倒序 （形照 java MemoryProcessRepository.pageDefines:571-597，那儿注释点名 deploy 版本查询依赖） - repository-mysql page_defines：ORDER BY 由 define_page_order_sql 组装，列名白名单＝java DEFINE_WHITELIST 八列，别名重写到 pd，白名单外/未给 ⇒ 回落 pd.id DESC - facade get_last_by_name：摘掉只在 LIMIT 1 单行上 max 的空转补偿（C7-L3 M-4② 点名的假账注释） - 判据 14 枚（内存腿 6／门面 4／SQL 文本 4）+ T1-M9 真库腿 8 条 - 门票：T0 483/483（基线 469）、T1 smoke ALL PASS、T1-F 192 PASS、consistency 载荷零漂移、 moon check 46 warnings（本轮新增文件零告警） | 19 天前 | |
fix(engine): SPI 求值抛错不再静默折 false，补带原因 WARN＋纯函数文案（issues/201·R79 拍 C） | 19 天前 | |
fix(facade): issues/212 audit8 R44——六枚分页 action 缺省 pageSize 20L→10L（spec 06 §2.2 全局档）＋i212 全族测试 define/instance/todo/done/design/surrogate 六枚旧默认 20L 与 ccList（154④）／candidatePage （R12 搜索腿）不一致；spec 06 §2.2「pageNum 从 1 起；pageSize 默认 10」。改后全族一个口径 （全仓分页缺省 20L 字样零命中）。新测试 i212_page_defaults_test.mbt：七枚缺省信封 1/10＋ 显式 2/7 原样回显对照。本地全仓 T0 488/0；变异（define 改回 20L）照红、还原 md5 全等。 | 18 天前 | |
test(facade): issues/236 i236 判据四处消息改 unwrap_or 取值——消 Show-of-Json/String? 的 deprecated 警告（moon check 48→46 回到 0.1.47 代基线，零新增警告这条本栈纪律兑现）；断言数值与判据形状一字未动 | 18 天前 | |
| 1 天前 | ||
chore: bump moon modules to 0.1.55 (relay pins synced) | 10 小时前 | |
| 24 天前 | ||
feat(core,facade,repository-mysql): issues/141 G1/G2 抄送分页归属条件必填＋cc 写侧判重＝幂等空操作（对齐 java 3d1fc98） 判据单点落在 core/model/rows.mbt 两枚 pub 纯函数——cc_ownership_operator（G1：本栈 cc 归属 通道是 PageQuery.operator，缺键/空串/全空白 ⇒ None）与 cc_fresh_subset（G2：保序、已有跳过、 同调用内折叠）；内存仓与 MySQL 仓共用这两枚，不再各写一套（java 的 hasEffectiveCondition 在本栈收敛为一枚，因为本栈 conditions 通道只有 operator）。 G1：page_cc_instances 归属无有效值 ⇒ record_count=0/rows 空集；MySQL 侧把 count/data SQL 抽成 cc_page_count_sql/cc_page_data_sql 且归属谓词恒拼（删掉 None => "" 那条"这条不加"的退路）， 谓词形状可用纯 SQL 断言离线钉住。 G2：SPI 新增 find_cc_actors / create_cc_instance_if_absent（MoonBit trait 无 default ⇒ 这是 破坏性新增，24→26 方法，自实现仓储必须覆写；两内置仓均已实现，changelog 必须写）。 三条建行点（发起腿 f_ccActors、办理腿 tf_ccActors、子流程发起腿）＋门面手动 createCCInstance 一律走 IfAbsent 拿子集 fire，子集为空整支不发码 4；旧入口 create_cc_instance 同样幂等。 重复抄送：不新增行、不重置未读、不刷原行时间；查询侧不去重、历史重复行不清。 测试：新增 38 格（内存判据 6＋内存幂等 9＋引擎 fire 8＋门面 8＋MySQL SQL 形状 7）， moon test 232→270/270 全绿。逐处还原病灶实测改前会红：A 段（幂等＋子集 fire 还原）16 红、 B 段（摘内存 G1 短路）2 红、C 段（8 个实现文件整体还原）编译期就报缺函数（判据单点被两仓依赖）。 被 G1 顶到的 8 处既有格只改读法（换成仓储真相或补合法 cc.actor_id 条件），断言值一字未动， 其中两格（memory_test 的 issues/108 回归格、operator_blank_test 的 i129 边界留档格）原先 钉的正是"cc 零条件也返行"这一被 G1 关掉的形状——改读法＋注释写明改判依据，未回炉期望值。 MySQL 腿的"缺条件⇒空页"本轮只守到 T0（判据单点＋谓词恒拼两层）：行为档需要 async test， 而 repository-mysql/repo/moon.pkg 没有 test-scope 的 moonbitlang/async，加这行 import 属包配置 变更，未在本案顺手做。未 bump moon.mod.json（仍 0.1.21）、未动 docs/、未动 import pin。 | 1 个月前 | |
wip(migrate): 警告批次 W8+W9——Json 弃办与 StringView 尾巴清完，deprecated 107→4（T0 168/168） - W8a：core/json 的 get/as_str 助手体先手改成编译器建议的判形，并补 as_array。 这一步必须在 jget 菜谱之前做：助手体自己就是 value.value(key)， 交给菜谱换成 @json.get(...) 会变成**自递归**（编译器不拦，运行期才炸）。 - jget：46 个 x.value(k) → @json.get(x, k)（deprecated 67→21）； - jasm：5 个 .as_string/.as_bool/.as_number() → 本仓助手 as_str/as_bool/as_f64（21→16）； - W9：12 个 StringView 尾巴 .to_string() → .to_owned()，**按列号锚定**配对 （编译器已判定接收者是 StringView，只剩"是哪一行"；行号在本仓不可信而列号可信。 一级判据用"报告行+列整对命中"——本轮实测被重写过的区段行尾已回 CRLF/LF， 那些文件报的行号就是真行号；二级才退回"该列唯一命中"，两处都不可判时**报歧义交人工**， 实跑 12/12 无歧义）。 总警告 128→65：deprecated 107→4、unused_package 39→8（W5 一条一验的成果）， 剩 unused_error_type 16 / unused_value 13 / deprecated_syntax 13 / unused_trait_bound 9 / unused_package 8 / ambiguous_block 2 / deprecated 4。 | 1 个月前 | |
| 1 个月前 | ||
wip(migrate): 警告批次 W11+W12——deprecated / deprecated_syntax 两类清零（54→35，T0 168、T1 111 绿） W11（确定性形状）： · fn meth(self : T) ⇒ fn T::meth(self : T) 4 处（实测**类型标注还得留着**： 写成 fn T::meth(self) 反报 "Missing type annotation for the parameter self"）； · demo/*/moon.pkg 里 @async 别名没人用 ⇒ 去别名保 import（异步运行时仍要）； · 删掉 conn.mbt 的死函数 sql_escape_text（LIMIT 内联改完就没人调了）。 W12（13 站点逐个精确改）： · 多行字符串直接当函数体 4 处 ⇒ 改 let 绑定形，中间的 $| 行**一个字节没动** （多行串的缩进参与内容，动它就是改测试数据）； · x.value(k)/x.as_string() 剩 4 处（接收者是 arr[0]、data_of(env)、带括号实参、 调用结果上切片——菜谱的正则只吃标识符接收者，这 4 处手写）⇒ 统一走本仓 @json 助手； · x |> _.to_int() 偏应用 1 处； · 闭包效应标注 4 处：fn(s){…} ⇒ 箭头形 (s) => …（2），fn(req,body,conn) ⇒ async fn； smoke 的事务体两头堵——不标 async 吃警告、标了 async fn() 效应又退化成开放 Error 与 execute_in_tx 的闭集 raise 不匹配 ⇒ **抽成具名 async fn t1_m4_boom_tx()**， 两头都躲开，T1 的回滚三格照旧绿。 | 1 个月前 | |
chore(migrate): W3——保留词改名 define→define_info / alias→table_alias（165 行/22 文件）+ derive(Eq, Show)→Debug（13）+ 测试限定名（20） 改名守住的三条边界（写在脚本注释里）：字符串字面量不动（stats 的 dimension 取值 "define" 是 契约字符串）、 #|/$| 原始多行串不动（流程 JSON）、注释行不动。\bdefine\b 天然不碰 define_id / save_define( / ProcessDefine。 derive(Show) 已废弃：换 derive(Debug)。对外 msg 不受影响——JeeflowError 的 msg 走手写的 impl Show ... message()，本轮没动它（已核实）。 踩坑一条（值得记）：照 moon check 的 unused_package 删 import 会**删过头**——那条诊断走的是 不含测试编译的通道，把 _test.mbt 与 for "test" 块要用的包（id_gen / @json / async）也判成 未用，一次引入 38 个 error。已回滚 moon.pkg，改用"check 与 test 双通道都报未用才删"的口径重做。 另记：moon 0.1.20260920 的 check/test 人类可读渲染都会 panic（ariadne: Label start is after its end），本机一律走 --output-json。 复验：moon check --target wasm → 431 warnings / 0 errors；moon test --target wasm → exit 0 全通过。 | 1 个月前 | |
feat(surrogate/152): processSurrogate/page 归属不变式两层 + 写侧授权人三档归一（未发版） - A 门面 surrogate_page 注入 query.set_operator(Some(operator_arg(args)))，与 instance_page 同形 （缺键/空串/全空白 ⇒ §2.5 归一缺省 user1），spec 06 §2.5 口径表 + §4.5「归属不变式」 - B apply_surrogate_fields 的 operator 臂改「只认非空白显式值」：空白档不得写进 operator （那种行是死行，get_surrogate 的 WHERE operator = ? 永不命中）；save 走归一缺省、update 保留原授权人 - C 判据单点 @model.surrogate_ownership_operator（rows.mbt 尾追加），内存仓与 MySQL 仓 page_surrogates 共用 ⇒ 双仓同答案由构造堵死（条款 6）；SQL 侧 WHERE operator = ?，空归属短路空页， m_ 可选过滤的"空值当没填"放行不在收口范围 - 用例：档1（精确接管 + 兜底腿）、档4（三档 operator + 本人待办命中）、档5（门面注入 + 直调仓储空归属⇒空页）； 档2/档3 由既有「批次123」三格覆盖，未重复造 - 改正一条既有断言（台账可查格）：实参补 operator=leader，期望 recordCount==1 一字未动，逐字交代写进案 §9 - T1-I152（smoke.mbt 48 行）只过编译，未连库——本轮禁连 160，真机读数归 T1 轮 - moon test --target wasm：Total tests 427 / passed 427 / failed 0（基线 424）； moon check --target wasm 警告 38 与基线逐码一致；阳性对照：摘掉内存仓兜底 ⇒ 档5 报 「带 operator 只见自己授出的行（实得 recordCount=4）」，按 md5 字节级还原后复绿 | 25 天前 | |
fix(facade/148): 委托 enabled 脏值按 spec 06 条款 4 落 0 建单，不再抛成 99999999 写侧归一本就是引擎门面职责（Java JeeflowFacade.java:1557-1560 缺省 1、脏值 0、不抛； 13 个集成壳对 enabled 零命中）。moon 原先走 arg_i64_or，不可解析即 raise，文案还是"非法id: abc" （连字段都说错），门禁 L2-18 写侧那腿因此恒红。 - 新增 surrogate_enabled_arg：键缺失=1；解析得出整数照实存；"abc"/""/"1x"/null/布尔/对象=0 且不抛。 save 新建臂与 apply_surrogate_fields（update 臂）共用，后者因此不再需要 raise 注解。 - 新增 surrogate_enabled_test.mbt 两支黑盒用例：脏值档「建单不抛＋代理人不并入」， 缺省/串化 '1' 档「都=1 且都并入」（反向哨兵，防把缺省一起改死成 0）。 - 改 surrogate_autoapply_test.mbt 一条既有断言：原要求"enabled=abc 必须被门面拒绝建单"， 与条款 4 选的机制（落 0）相反，且条款点名的反例正是"直接抛"；现改为要求建单成功， 下一行"脏值不得产生待办"原样保留，防护意图未削。逐字交代见 issues/148 §5。 moon check 0 errors；moon test --target wasm 406/406；facade 包摘新件 102 / 带新件 104（两支真跑）。 未推、未发版——mooncakes 0.1.29 与 mldong-moon 四路 pin 同步待 owner 点名。 | 25 天前 | |
fix(facade): spec 04 两枚保留键算进 ext 控制键，82-3 回退复原 同 java 9cdbfaf 一处病：建单往每条任务变量写 _branchCtx（空分支也写 []），而 task_row_to_json 的「任务变量只剩控制键 ⇒ ext 回退实例变量」判据（issues/82-3 / 121 P1）只数 isFirstTaskNode 一枚 ⇒ 每条任务行不再回退、内部键从公开出口透出。 - 判据改为「除 isFirstTaskNode／_branchCtx／_reapplyContext 外没有别的键」 - 回退从**并入**改为**替换**：旧写法 for k, v in instance_ext { ext[k] = v } 把实例 变量叠在控制键上，回退后 ext 仍带着 _branchCtx；现按其余七栈同形，取 instance_ext 的副本，再把 _reapplyContext 原样合回（jeeflow-ui helpers.ts 读 ext._reapplyContext 取「重新提交后返回：X」）。合回只动任务侧那份，instanceExt 出口不被污染 - 新增 facade/task_row_ext_fallback_rts_test.mbt（两腿内容级判据） - 本栈实例变量写回只挑 f_*（engine_ops.mbt 那条循环），结构上不会把保留键带进实例 变量，故不需 go／python／node 那处挡键（三家现读各自确认过） 读数：moon check --target wasm 0 error；moon test --target wasm = 528/528（原 527）； T1 repository-mysql/smoke 连 160 ALL PASS；T1-F demo/cmd/t1_mysql ALL PASS。 坏样本（判据只认 isFirstTaskNode）⇒ 新用例 abort，moon 直接把 "Active test at executable exit" 点名到本用例；还原后 528/528。告警 49 条与 HEAD 同树现跑基线一致，改动文件零新增。 注：facade/args.mbt 行尾是 \r\r\n 与 \r\n 混排（本仓 .gitattributes 为 * -text）， 改动按字节级就地替换，未整文件重写（numstat 25/6）。 | 2 天前 | |
feat(core): issues/134 案 A 撤回校验实例状态——非进行中(10) 一律拒，内部码 20010009 聚合根 withdraw 前加实例态守卫：state!=10 ⇒ 拒，被拒时实例与任务行零改写、不落库；任务行层面的既有保护原样保留，守卫排在它之前。出口按 121 轮口径透出 code=99999999 + 逐字文案「流程实例非进行中，无法撤回」（内部码不进 msg）。新增 T0 负向 20/40 与正向对照（10 照旧落 30），文案用精确等值断言。 变异对照：摘守卫 ⇒ 仅新负向格红、正向与既有格绿；守卫写反 ⇒ 正向格一并红（证明正向档不是恒绿）。既有断言期望值零修改。 | 1 个月前 | |
fix(facade): startAndExecute 自动办理腿操作人改 flow.auto（issues/176-R10） - actions_main：execute_task_async(task.task_id, operator → "flow.auto")，对齐 spec 04:60-62 与 boot2 ProcessInstanceServiceImpl:317 基准（apply 行 operator 列=flow.auto；发起人经 add_task_actor 留痕）。u_* 由发起腿留下、引擎对 flow.auto 跳过注入 ⇒ u_realName 仍=发起人 - doneList 连带：apply 行 operator=flow.auto ⇒ 不再进发起人已办（对齐 boot2 :350 排除式观察面） - 判据翻新 2 枚（withdraw_transfer_test）： ① withdraw 正向：apply.update_user 期望 applicant → flow.auto（撤回不得覆写办结时主体） ② 回归红线（转办后撤单）：被摘走的人 doneList 断言由"不凭空多单"改为发起人档不含该单 （!page_has_instance）＋改锚 flow.auto 档证留痕仍在（防 0==0 自等假绿） - 变异对照：修点回 operator ⇒ 两枚断言全红（449/447/2）；还原后 449/449 绿 | 21 天前 |
The unified 40+ action facade of jeeflow-moon: one
entry point, one federation envelope (code=0 success / 99999999 failure), one outbound
contract layer that every response passes through.
Quickstart
let facade = @facade.Facade::make(ctx) // ctx wires engine + repositories + SPI closures
let resp = facade.flow("processDefine/startAndExecute", args) // start + auto-apply
let _ = facade.flow("processTask/execute", args) // submitType dispatch: 0/1/2/3/4/6/20
let page = facade.flow("processTask/todoList", args) // five-key pagination
The 40+ actions
| group | actions |
|---|---|
processDefine (8) |
page · detail · startAndExecute · deploy · redeploy · remove · upAndDown · getLastByName |
processInstance (14) |
page · detail · startAndExecute · withdraw · highLight · approvalRecord · getAssigneeTextData · bizData · createCCInstance · updateCCStatus · ccList · stats/overview · stats/trend · stats/group |
processTask (9) |
todoList · doneList · execute · detail · jumpAbleTaskNameList · candidatePage · surrogate · addCandidate · latest |
processDesign (9, ext repo) |
page · detail · save · update · updateDefine · remove · deploy · redeploy · listByType |
processSurrogate (5, ext repo) |
page · save · update · detail · remove |
Outbound contract layer (enforced, not optional)
- recursive id stringification —
id/*Id/*_id, and pluralids/*Idsarrays element-wise (snowflakes exceed float64); - five-key pagination —
pageNum/pageSize/recordCount/totalPage/rows; - time normalization —
yyyy-MM-dd HH:mm:ss, ISOTfolded to space; - stats as pure columns — overview (13 keys), trend (hour/day/ISO-week/month buckets), group (9 dimensions incl. stuck-node/approver and 4 duration buckets), explicit errors on missing/invalid params.
License
Apache-2.0 — part of jeeflow-moon.