|
29927
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/shijie-scene-assets
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"68b55da164790dc837961154a1caf9d26d6edd78","Message":"test(shijie): record four-category scene asset release acceptance\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-10T20:15:39-07:00"},"CompareURL":"luoanwu/image-generation/compare/main...68b55da164790dc837961154a1caf9d26d6edd78","Len":0}...
|
1789445272
|
Edit
Delete
|
|
29928
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/shijie-shot-workbench
|
0
|
|
1789445277
|
Edit
Delete
|
|
29929
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/shijie-shot-workbench
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"b1b2939fecf4e70ee4688e9f6feb83e4b1604fdf","Message":"test(shijie): record fixed-source shot workbench release acceptance\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-10T17:25:24-07:00"},"CompareURL":"luoanwu/image-generation/compare/main...b1b2939fecf4e70ee4688e9f6feb83e4b1604fdf","Len":0}...
|
1789445277
|
Edit
Delete
|
|
20282
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
|
1785590611
|
Edit
Delete
|
|
20283
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"815f9b634 {"Commits":[{"Sha1":"815f9b634be98eeea1ead07bc5daaf37dec909e0","Message":"feat(solution): 三档方案支持每档多商品，数量默认取项目包房总数\n\n## 多商品\n契约 `solutionOptionInputSchema.products` 一直是 `.min(1).max(500)`，后端逐条落\nSolutionOptionProduct、转报价桥接逐条转成报价明细、客户页也已在显示「配置 N 项」——\n整条链路早就支持多商品，**只有设计器表单把它写死成单元素数组**，能力在用户唯一\n够得着的那一层被锁掉（同 C25/C26 族：能力挂在哪一层决定它存不存在）。\n\n改法复用仓内既有 AccessoryEditor 模式：选择 + 数量 → 添加成可删除的清单行。\n刻意不用 `\u003cselect multiple\u003e`：每个商品要带自己的数量，多选框表达不了；且 Select\n原语的注释明确禁止把它改造成多选（E2E 按 locator(\"select\") 定位、Capacitor 依赖\n原生选择器）。同档重复添加同一商品累加数量，不并排出现两行肉眼一样的配置。\n\n## 数量默认值\n默认 = 本项目包房总数（kind===\"ROOM\" 的空间数量求和），只预填不锁定。\n回落 1 而非 0：契约 quantity 是 int().positive()，预填 0 会让按钮看着能点、\n提交却被 Zod 挡下（C24 同款：默认值不合法 = 表单永远提交不了）。\nUI 显式写明「数量默认按本项目包房总数 N 间预填，可逐项调整」，不做魔法数字。\n\n## 顺带修掉一个跨项目状态串味\nSolutionDesigner 的已选商品与包房数预填都是挂载时求值的本地状态，\n渲染处此前无 key——切换项目不重挂，会把上一个项目的选择带过去。已加 key={project.id}。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check exit 0；check:runtime 279/0；check:ui 9/0\n- 端到端读回：推荐档配 2 个商品 → 客户页断言「配置 2 项」→ 成功转成正式报价\n- 负向测试两条均实跑判红后恢复：\n ① addProduct 改为 `products: [line]`（回潮到单商品）→ 恰好 solution-product-row\n 期望 2 实得 1 判红；\n ② roomTotal 改为常量 1 → 恰好 待添加数量 期望 \"8\" 实得 \"1\" 判红\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:23:24-07:00"}],"HeadCommit":{"Sha1":"815f9b634be98eeea1ead07bc5daaf37dec909e0","Message":"feat(solution): 三档方案支持每档多商品，数量默认取项目包房总数\n\n## 多商品\n契约 `solutionOptionInputSchema.products` 一直是 `.min(1).max(500)`，后端逐条落\nSolutionOptionProduct、转报价桥接逐条转成报价明细、客户页也已在显示「配置 N 项」——\n整条链路早就支持多商品，**只有设计器表单把它写死成单元素数组**，能力在用户唯一\n够得着的那一层被锁掉（同 C25/C26 族：能力挂在哪一层决定它存不存在）。\n\n改法复用仓内既有 AccessoryEditor 模式：选择 + 数量 → 添加成可删除的清单行。\n刻意不用 `\u003cselect multiple\u003e`：每个商品要带自己的数量，多选框表达不了；且 Select\n原语的注释明确禁止把它改造成多选（E2E 按 locator(\"select\") 定位、Capacitor 依赖\n原生选择器）。同档重复添加同一商品累加数量，不并排出现两行肉眼一样的配置。\n\n## 数量默认值\n默认 = 本项目包房总数（kind===\"ROOM\" 的空间数量求和），只预填不锁定。\n回落 1 而非 0：契约 quantity 是 int().positive()，预填 0 会让按钮看着能点、\n提交却被 Zod 挡下（C24 同款：默认值不合法 = 表单永远提交不了）。\nUI 显式写明「数量默认按本项目包房总数 N 间预填，可逐项调整」，不做魔法数字。\n\n## 顺带修掉一个跨项目状态串味\nSolutionDesigner 的已选商品与包房数预填都是挂载时求值的本地状态，\n渲染处此前无 key——切换项目不重挂，会把上一个项目的选择带过去。已加 key={project.id}。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check exit 0；check:runtime 279/0；check:ui 9/0\n- 端到端读回：推荐档配 2 个商品 → 客户页断言「配置 2 项」→ 成功转成正式报价\n- 负向测试两条均实跑判红后恢复：\n ① addProduct 改为 `products: [line]`（回潮到单商品）→ 恰好 solution-product-row\n 期望 2 实得 1 判红；\n ② roomTotal 改为常量 1 → 恰好 待添加数量 期望 \"8\" 实得 \"1\" 判红\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:23:24-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/ccbb031fdb47bc913ed2b4ba270c0a49889eb88d...815f9b634be98eeea1ead07bc5daaf37dec909e0","Len":1}...
|
1785590611
|
Edit
Delete
|
|
20284
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"b0ed5cba7 {"Commits":[{"Sha1":"b0ed5cba764d5df24360ea70486bad9b6885431d","Message":"feat(solution): 数量来源可选空间分类或手动输入，选品增加商品分类筛选\n\n## 数量来源可选\n此前默认值写死「包房总数」。但走廊音响、前台设备、设备间机柜这类根本不按包房走，\n把包房硬编码成唯一口径等于只服务一种配置习惯。\n\n改为下拉可选：**按任一空间分类的数量合计**（包房/前台/走廊/水吧/办公室/设备间/其他，\n选项上直接标出该类当前数量）或**手动输入**。默认仍落在包房——点歌设备按包房逐间\n配是这门生意的常识配比。\n\n- 按空间分类走时数量输入框只读：避免出现「显示按包房、值却被手改过」这种谁也说不清\n 依据的数字；要自己填就显式切到「手动输入」。\n- 取值一律 Math.max(1, …)：契约 quantity 是 int().positive()，项目里没录前台时\n 合计为 0，预填 0 会让「添加」看着能点、提交却被 Zod 挡下（C24 同款教训）。\n- 空间分类总数用枚举 reduce 统一算，不给某一类空间写死分支。\n\n## 选品增加商品分类\n选品下拉前置「全部分类 / 设备 / 服务 / 配件」筛选（沿用商品库同名口径，不另造说法）。\n切换分类时清空已选商品——否则下拉显示的是新分类、value 仍指向旧分类那件商品，\n提交的是用户此刻根本看不见的东西。\n\n添加一件后**保留分类与来源**、只清商品：连着配同一类设备是常态，每加一件就把筛选\n重置回默认等于逼人重选一遍。\n\n来源与分类只是挑选时的辅助，不进已选行——存进去会让配置多出两个读模型不消费、\n契约也不收的字段。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check exit 0；check:runtime 279/0；check:ui 9/0\n- E2E 新增断言：切「配件」后候选从 4 项收窄到 2 项（证明筛选真的干活）；\n 切「手动输入」填 3 后该行数量为 3，而主设备那行仍是按包房总数的 8\n （证明两种来源可在同一档并存）\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:40:01-07:00"},{"Sha1":"18359985bc7144f7c67c3f17d80e7f848770d956","Message":"fix(ci): 让 UI 验收红盘可判责——失败时打印捕获输出并上传证据产物\n\nPR #6 的 Runtime and UI acceptance 在远端判红，但日志里只有一行\n「✗ playwright-test failed (exit 1)」，看不出是哪条断言、为什么失败。\n\n根因：check-ui-acceptance.mjs 的 runSync 把子进程 stdout/stderr 收进 report JSON\n的 stdoutTail/stderrTail 后**从不打印**，而 workflow 又不上传 report——\n证据在当场就被丢掉了。G23 ④ 记的「2026-07-31 红盘 tests-floor got 0 根因至今\n未定位」是同一个病根。\n\n- runSync 失败时把两条尾巴打到 stderr\n- workflow 失败时上传 reports/*.latest.json + e2e-results.json + playwright traces\n\n本机以全新库复跑 check:ui 为 9/9 全绿，无法复现远端红盘；按治理纪律\n「根因未定位不得归因」，先补证据链再判是偶发还是回归。\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:33:17-07:00"}],"HeadCommit":{"Sha1":"b0ed5cba764d5df24360ea70486bad9b6885431d","Message":"feat(solution): 数量来源可选空间分类或手动输入，选品增加商品分类筛选\n\n## 数量来源可选\n此前默认值写死「包房总数」。但走廊音响、前台设备、设备间机柜这类根本不按包房走，\n把包房硬编码成唯一口径等于只服务一种配置习惯。\n\n改为下拉可选：**按任一空间分类的数量合计**（包房/前台/走廊/水吧/办公室/设备间/其他，\n选项上直接标出该类当前数量）或**手动输入**。默认仍落在包房——点歌设备按包房逐间\n配是这门生意的常识配比。\n\n- 按空间分类走时数量输入框只读：避免出现「显示按包房、值却被手改过」这种谁也说不清\n 依据的数字；要自己填就显式切到「手动输入」。\n- 取值一律 Math.max(1, …)：契约 quantity 是 int().positive()，项目里没录前台时\n 合计为 0，预填 0 会让「添加」看着能点、提交却被 Zod 挡下（C24 同款教训）。\n- 空间分类总数用枚举 reduce 统一算，不给某一类空间写死分支。\n\n## 选品增加商品分类\n选品下拉前置「全部分类 / 设备 / 服务 / 配件」筛选（沿用商品库同名口径，不另造说法）。\n切换分类时清空已选商品——否则下拉显示的是新分类、value 仍指向旧分类那件商品，\n提交的是用户此刻根本看不见的东西。\n\n添加一件后**保留分类与来源**、只清商品：连着配同一类设备是常态，每加一件就把筛选\n重置回默认等于逼人重选一遍。\n\n来源与分类只是挑选时的辅助，不进已选行——存进去会让配置多出两个读模型不消费、\n契约也不收的字段。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check exit 0；check:runtime 279/0；check:ui 9/0\n- E2E 新增断言：切「配件」后候选从 4 项收窄到 2 项（证明筛选真的干活）；\n 切「手动输入」填 3 后该行数量为 3，而主设备那行仍是按包房总数的 8\n （证明两种来源可在同一档并存）\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T06:40:01-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/815f9b634be98eeea1ead07bc5daaf37dec909e0...b0ed5cba764d5df24360ea70486bad9b6885431d","Len":2}...
|
1785591608
|
Edit
Delete
|
|
20285
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"47ce4c614 {"Commits":[{"Sha1":"47ce4c6146a13c443db38c5816749d0591339e46","Message":"fix(quotations): 视图筛选下沉服务端 + 公开方案页不再泄漏后端英文报错\n\n## 1. 三个筛选视图的分页回归（G24 引入，本次修复）\n审核中心 / 客户报价页 / 报价版本 原先在浏览器里对列表结果 filter。列表全量返回时\n那样是对的，但 G24 加分页后客户端筛选只作用于**当前页**：待审报价不在最新一页\n就会被静默漏掉，而分页条的 total 仍是全量数，出现「共 N 条却一行不显示」的错位。\n与 C27「聚合范围由前端恰好拿到多少行决定」同族——筛选范围必须由拥有数据的一层决定。\n\n- contracts 新增 QUOTATION_VIEW_FILTERS 单源（inbox/review/customer/versions），\n 两后端各自翻译成 Prisma where；total 随之变成「该视图下的全量」；\n- quotationListViewSchema 刻意不 extend paginationQuerySchema——那会让\n quotation.ts 反向 import pagination.ts 的值，与既有 type import 形成循环；\n- 非法 view 是 400 而不是静默退回全部（静默兜底会让筛选看着生效实则没有）；\n- 前端只保留一条**权限谓词**（无 customer_link.read 读不到 accessToken）：\n 它对同一角色恒为全真或全假，不会像数据谓词那样把行留在分页窗口外。\n\n⚠️ 期间发现 QuoteOption.accessToken 是 @default(uuid()) **非空**，\n原「客户报价页」的 options.some(accessToken) 实际是权限谓词而非数据谓词。\n\n## 2. 公开方案页把后端英文报错渲染给客户\nPublicCustomerSolutionView 直接渲染 query.error.message，客户看到的是\n「Solution project not found」——看不懂、像坏了，还把内部对象名暴露出去。\n改为统一中文文案，且**不区分**链接无效/未发布/返工中：区分开等于告诉持链接的人\n「方案确实存在，只是没轮到你看」，而服务端刻意用 404 而非 403 正是为了不泄露存在性\n（方案蓝图 S1 审计裁决）。前端说破，那道防线就白立了。\n\n## 门禁断言随执行点搬家（不是放宽）\nquotation-review-server-state / quotation-version-snapshot 钉的是被移走的客户端谓词。\n不变量没变、执行点变了，故改为钉：前端必须把 mode 作为 view 传下去、\n两后端必须从 contracts 单源翻译 where，并加 reject 断言禁止客户端重新实现视图谓词。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check 0 / check:runtime 294 / check:ui 9\n- 两后端各 +3 条断言（view=review 只回待审、total 随筛选收窄、非法 view 400）\n- 负向两条实跑判红后恢复：\n ① 服务端忽略 view → view=review 期望 1 实得 2 判红\n ② 视图谓词写回客户端 → quotation-view-client-side-filter 判红\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T08:35:11-07:00"},{"Sha1":"b0ba9576541405a0613ae827ad3c80873437ef53","Message":"docs(flow): 重新梳理业务模块与主干流程，补齐审批中心并画 mermaid 流程图\n\nbusiness-flow-overview.md 写于同一天更早的提交，正文里一次都没提 approval-inbox\n（468a6cd 才落地的 9 类聚合）。本次按 contracts 与前端导航逐条核对后重梳理：\n\n- 新增 §6 待办审批中心：明确它是**横切在主干之上的视图，不是主干的一个节点**\n （无写端点、不重定义「什么算待审」、入口不设独立 capability 而挂 event.read），\n 并给出 9 类条目各自落在主干哪一步；第 8/9 类是待办不是审批闸门。\n- 新增 §1.1 业务模块分层，并标注 owner-matrix 里的 inventory/procurement/logistics\n **不是物理模块**：三个域的写链全部实现在 fulfillment.service.ts（~2100 行，\n 两后端各一份），按目录名去搜会扑空。\n- §3 补两条被 happy path 掩盖的主干分支：报价审批是**条件审批**\n （quotationMachine 的 DRAFT 同时接 send，服务端仅在存在 requiresApproval 的\n 方案档时抛 409 拦截）；销售订单可先转 PROCUREMENT_REQUIRED，纯服务订单反向跳过发运。\n- §1 主干图 ASCII 换 mermaid（GitHub 可渲染），信息等价。\n\n仍不复制状态机全图——那是 P1 禁止的第二真源，图里只点 contracts 导出符号名。\n未新建流程图文档：本文件已是该事项的登记位置，另开一份即第二真源。\n\n证据：本地工作区 check:docs-truth / check:naming / check:governance-docs /\ncheck:gate-selftest 均绿（静态级，工作区 dirty，不外推远端与运行态）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T08:08:20-07:00"},{"Sha1":"f315e642beda9d7ccc527955b2397f4702d33a9c","Message":"chore(gate): docs-truth 负向测试固化 + 幽灵资产清单扩面\n\n会话里手工跑一次的红盘不留证据，下轮重构会静默失效（G13）。把 docs-truth 的\n负向测试固化为 scripts/lib/docs-truth.test.mjs，由 check:gate-selftest 重跑，\ngateSelftests 地板 2 → 3。\n\n幽灵资产两条断言扩面：\n- no-phantom-config-prisma 清单补入 docs/README.md 与 naming-standard.md\n- 新增 contracts-package-name，递归扫描 docs/ 全域，真值取自\n packages/contracts/package.json 的 name（非黑名单）\n\n扩清单判据：该文件是在**主张**这条幽灵引用，还是在**否定**它？只有前者进清单——\nADR 澄清段与治理经验库引用它正是为宣告作废，扫进来即咬住纠错本身（C1 同类陷阱）。\n\nCLAUDE.md 会话收尾清单同步回灌两个已实锤两次的坑：注入点是否真落在目标断言上\n（replace 只换第一处），以及红是否红在点子上（崩溃/环境不满足同样非 0 退出）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T08:08:01-07:00"},{"Sha1":"468a6cd2ab36d76237ae9c4d849eda17204d722c","Message":"feat(approval-inbox): 跨域待办审批中心（切片一）——9 类聚合 + 中心内直接审批\n\n经 business-module-intake 接待流程落地，蓝图见 docs/domain/approval-inbox-blueprint.md。\n\n## 解决的问题\n全系统有 7 道审批闸门，只有报价那一道有「审核中心」入口；技术复核、经理批准、\n采购、盘点、红冲、退款全部藏在各自工作台深处，待办不可发现。\n\n## 设计要害：聚合层不得成为第二真源\n- **不新建聚合写入口**：中心里的审批动作一律打各域原有端点，写入唯一点不变；\n- **不重新定义「什么算待审」**：判据只引用各域自己的状态枚举；\n- **入参 schema 直接引用各域已有 Zod schema**（APPROVAL_PAYLOAD_SCHEMAS），\n 某域改入参→改自己的 schema→中心类型立刻变→编译期红，而不是运行时静默 400/409；\n- 描述表 `satisfies Record\u003cApprovalTaskKind, …\u003e` 锁全集，漏一类即编译不过；\n- capability 裁剪、自批过滤、排序计数统一交给 contracts 纯函数 buildApprovalInbox，\n 两后端共用——行为对等由结构保证（G17）。\n\n## 覆盖 9 类\n7 道审批 + 2 类客户决定后的待办（客户已接受待申请合同、客户已选档待转报价）。\n后两类**不是审批闸门**：客户决定仍立即生效，只是把「决定之后必须有人做的那一步」\n从各自工作台捞出来，零状态机改动、零迁移、零对客语义变更。\n\n## 实测暴露并绕开的坑\n- 盘点列表 capability(inventory.stocktake) ≠ 审批 capability(.approve)，\n SALES_MANAGER 只持后者——中心按**审批** capability 判定，否则审批人看不到自己该审的单；\n- 采购员不持 procurement.approve（三责分离），中心里必须继续不可见；\n- 方案两类需回传 versionNo 做 STALE_VERSION 校验，中心从聚合结果带出。\n\n## 诚实边界（蓝图 §7，切片二再补）\n发起人字段只有 2/7 个域存在，自批过滤只在红冲/退款生效，UI 如实标注可判定范围。\n**本模块不得宣称「已保证不可自批」**——只有这两类成立。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check 0 / check:runtime 294（地板 279→294）/ check:ui 9\n- contracts 13 条单测；两后端各 1 条聚合 HTTP 验收（capability 裁剪/跨租户/自批计数/待办类）\n- check:module-integration 新增 5 条断言，三条负向实跑判红后恢复：\n ① 聚合层加写端点 ② capability 裁剪改全放行 ③ 去掉实时失效\n 其中 ② 首轮未判红——断言只查标识符、留着未使用 import 就能骗过，\n 已收紧到锚定调用点（断言剧场自查）\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T07:45:16-07:00"}],"HeadCommit":{"Sha1":"47ce4c6146a13c443db38c5816749d0591339e46","Message":"fix(quotations): 视图筛选下沉服务端 + 公开方案页不再泄漏后端英文报错\n\n## 1. 三个筛选视图的分页回归（G24 引入，本次修复）\n审核中心 / 客户报价页 / 报价版本 原先在浏览器里对列表结果 filter。列表全量返回时\n那样是对的，但 G24 加分页后客户端筛选只作用于**当前页**：待审报价不在最新一页\n就会被静默漏掉，而分页条的 total 仍是全量数，出现「共 N 条却一行不显示」的错位。\n与 C27「聚合范围由前端恰好拿到多少行决定」同族——筛选范围必须由拥有数据的一层决定。\n\n- contracts 新增 QUOTATION_VIEW_FILTERS 单源（inbox/review/customer/versions），\n 两后端各自翻译成 Prisma where；total 随之变成「该视图下的全量」；\n- quotationListViewSchema 刻意不 extend paginationQuerySchema——那会让\n quotation.ts 反向 import pagination.ts 的值，与既有 type import 形成循环；\n- 非法 view 是 400 而不是静默退回全部（静默兜底会让筛选看着生效实则没有）；\n- 前端只保留一条**权限谓词**（无 customer_link.read 读不到 accessToken）：\n 它对同一角色恒为全真或全假，不会像数据谓词那样把行留在分页窗口外。\n\n⚠️ 期间发现 QuoteOption.accessToken 是 @default(uuid()) **非空**，\n原「客户报价页」的 options.some(accessToken) 实际是权限谓词而非数据谓词。\n\n## 2. 公开方案页把后端英文报错渲染给客户\nPublicCustomerSolutionView 直接渲染 query.error.message，客户看到的是\n「Solution project not found」——看不懂、像坏了，还把内部对象名暴露出去。\n改为统一中文文案，且**不区分**链接无效/未发布/返工中：区分开等于告诉持链接的人\n「方案确实存在，只是没轮到你看」，而服务端刻意用 404 而非 403 正是为了不泄露存在性\n（方案蓝图 S1 审计裁决）。前端说破，那道防线就白立了。\n\n## 门禁断言随执行点搬家（不是放宽）\nquotation-review-server-state / quotation-version-snapshot 钉的是被移走的客户端谓词。\n不变量没变、执行点变了，故改为钉：前端必须把 mode 作为 view 传下去、\n两后端必须从 contracts 单源翻译 where，并加 reject 断言禁止客户端重新实现视图谓词。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check 0 / check:runtime 294 / check:ui 9\n- 两后端各 +3 条断言（view=review 只回待审、total 随筛选收窄、非法 view 400）\n- 负向两条实跑判红后恢复：\n ① 服务端忽略 view → view=review 期望 1 实得 2 判红\n ② 视图谓词写回客户端 → quotation-view-client-side-filter 判红\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T08:35:11-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/b0ed5cba764d5df24360ea70486bad9b6885431d...47ce4c6146a13c443db38c5816749d0591339e46","Len":4}...
|
1785598520
|
Edit
Delete
|
|
20286
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"fb6c5ad39 {"Commits":[{"Sha1":"fb6c5ad390153c534787dc66d90284ff257d28d1","Message":"docs(governance): 治理入口新增业务主干导航行\n\nCLAUDE.md「使用入口」表加一行，把「搞清业务从头到尾怎么跑 / 新人上手」\n路由到 docs/domain/business-flow-overview.md。\n\n为什么要有这一行：跨域主干导航文档已经落在 docs/domain/ 下，但治理入口表\n不指向它——一份没有入口的资产下轮就没人读、也没人维护，随后静默漂移\n（C25 同族：文档指向的东西运行时到不了，反过来也一样成立）。\n\n该行同时写明它是**派生非真源**、据它下判断前必须回到 contracts / blueprint\n复核，避免入口表把导航文档抬成第二份状态机口径（P1）。\n\nAGENTS.md 为符号链接自动跟随；pnpm check exit 0（含 check:governance-docs）。\n作用域：本地工作区 dirty（并发会话有 approval-inbox 切片二在途），本提交\n只含 CLAUDE.md 一个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T19:58:50-07:00"},{"Sha1":"9e6f5674f9279f43dd8bd6b4acbcfbe5d7af29b6","Message":"test(e2e): 待办审批中心转报价的浏览器级用例——堵住两个 bug 的共同逃逸路径\n\n## 为什么补这一条\n\n审批中心 9 类待办里，「客户已选档·待转报价」是**唯一没被 E2E 打过**的一类。\n两个 bug 正是从这个缺口同时逃逸，且叠在一起：\n1. 前端把端点拼成 /api/solutions/:id/quotation，真实路由是 /create-quotation → 404；\n2. 动作必填 optionId，而 ApprovalTask 投影里没有这个字段 → 400。\n路径修对了也只是把 404 换成 400，这个按钮**从落地起就没成功执行过**。\n\n同轮已补两道静态门禁（check:api-routes / check:approval-payload），但它们各自\n只覆盖一半：前者只校验路径不看请求体，后者只校验入参不看路由。本用例是第三层，\n一次性覆盖两者，且打的是真实浏览器链路。\n\n## 用例设计\n\n前置数据用 API 铺（方案要走完设计→双审核→发布→客户选档才会进待办）——本用例的\n验证目标是**中心内的执行动作**，那条设计链路早已被第 4 条用例覆盖。铺数据序列先在\n真实后端上逐步试通，撞到四个真实约束，均已写进用例：\n- 无 body 的动作要传 {}，否则 Fastify 回 FST_ERR_CTP_EMPTY_JSON_BODY；\n- design 必须三档齐全（经济/推荐/旗舰）；\n- targetSegment 必须**建时就给**：APPROVED 后禁改输入，而对客发布闸门要求它非空；\n- 客户联系人字段是 primaryContact；档案无联系人时选档一律拒绝（审计 S3 fail-closed）。\n\n断言锚到 [data-testid=\"approval-task-row\"][data-approval-kind=\"...\"]，不用全页\ngetByText——页面含实时事件流面板会污染宽断言（C16）。成功判据不看 toast，看\n**服务端读回** QUOTATION_CREATED + quotationId：路径 404 或 optionId 缺失都会\n让这里读不到，且条目不会消失。\n\n自带客户与联系人常量（INBOX_*），不复用 CUSTOMER_NAME/CONTACT_NAME，避免这条链路\n把早期用例的客户档案推进到 QUOTATION_CREATED 而影响它们的断言。\n\n## 证据\n\n- 正向：pnpm check:ui 10 用例 0 失败（PG:55432/juhai_quotation_ui_final_20260801 +\n Redis:6382，UI_WEB_PORT=3132/UI_API_PORT=3232）。\n- 负向：移除 NestJS 聚合的 optionId 后重跑，**恰好第 10 条判红、其余 9 条全绿**，\n 失败点正是 approval-blocked-reason 出现（UI 如设计般禁用按钮而非发必然 400 的请求）；\n 现场已恢复。\n- ⚠️ 负向那次会把 ui-acceptance.latest.json 覆盖成 status=failed/9 passed——那是负向\n 测试的产物不能当证据，故重跑正向后才提交（本提交内报告为 passed/10）。\n- baseline uiTestsPassed 9→10；CLAUDE.md 证据新鲜度行与 ui-acceptance 基线行同步回灌。\n- pnpm check 全绿 exit=0（18 项，自检 5 组）。本轮未跑 check:runtime（没动写链逻辑）。\n\n工作区 dirty：并发会话在途的报价域改动未包含在本提交内。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T09:52:10-07:00"},{"Sha1":"80fbe00d13bcdf8c4bf8ed64dca1c18cccbab449","Message":"feat(gate): 审批中心入参完整性门禁——从 Zod schema 反推必填字段，契约层与实现层各查一遍\n\n## 背景：一个从落地起就没成功执行过的按钮\n\n待办审批第 9 类「客户已选档·待转报价」的动作接口必填 optionId，而 ApprovalTask\n投影里根本没有这个字段，前端 buildPayload 返回 {}。同轮还有一个路径拼错的 bug\n盖在前面，路径修对了也只是把 404 换成 400 optionId Required。\n\n四道防线同时失效：\n- check:api-routes（同轮新建）只校验路径存在，不看请求体；\n- typecheck 抓不到——`optionId?: string` 是**可选**字段，后端不返回照样编译通过；\n- 9 类待办里恰好只有这一类没被 E2E 打过；\n- descriptor 里的 requiresVersionNo 是**手写布尔标记**，作者当初意识到「有些类\n 需要额外字段」却把它硬编码成单个布尔，新增 optionId 时没有对应标记。\n\n## 判据\n\n对每个 kind 从 Zod schema **反推**必填集合（不依赖任何手写标记），逐字段两层校验：\n1. 契约层：不在中心表单可输入白名单（comment/note/internalComment）的必填字段，\n 必须出现在 ApprovalTask 投影里；\n2. 实现层：**两个后端的聚合都真的产出了它**。第二层是关键——可选字段漏返回\n 不会被 typecheck 抓到，本次 bug 正是这么活下来的。\n\n某域给自己的 schema 加一个必填字段，中心立刻红，而不是等用户点按钮才发现。\n\n## 过程中修正了自己的一次误报\n\n初版用「kind 字面量 ±600 字符」文本窗口，一跑报 4 条红。先判责再改代码：方案两类\n共用 solutionReviews() 一个方法，两个 kind 字面量在方法开头推查询条件，而 versionNo\n在 25 行后的统一 map() 里，超窗即被判「没产出」。**字段产出点与 kind 声明点不在\n同一处是正常写法，门禁不该逼代码迁就它**——改按方法体切块。该坑已写成专门的自检\n用例钉死，防止以后被「优化」回窗口法而静默回潮。\n\n## 已知边界（不得外推）\n\n只校验必填不校验可选；不校验字段类型；USER_INPUT_FIELDS 白名单人工维护，\n往里加字段等于宣称中心表单能收集它，加之前必须确认 UI 真渲染了对应控件。\n\n## 证据\n\n- 真实源码两层负向测试：删 ApprovalTask.optionId → 契约层红；删 NestJS 聚合的\n optionId → 实现层红并点名 NestJS；现场均已恢复。\n- 自检 14 项（scripts/lib/approval-payload-contract.test.mjs），含 1 条基线绿 +\n 3 条端到端红，断言 exit **恰好为 1**（崩溃同样非 0，会让「期望红」以错误理由通过）。\n- 接线：pnpm check / governance-report 棘轮 / baseline（新增 0 地板，\n gateSelftests 4→5）/ CLAUDE.md 基线表。\n- 本地工作区 pnpm check 全绿 exit=0（18 项，自检 5 组）；工作区 dirty\n （含并发会话在途的报价域改动，未包含在本提交内）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T09:14:36-07:00"}],"HeadCommit":{"Sha1":"fb6c5ad390153c534787dc66d90284ff257d28d1","Message":"docs(governance): 治理入口新增业务主干导航行\n\nCLAUDE.md「使用入口」表加一行，把「搞清业务从头到尾怎么跑 / 新人上手」\n路由到 docs/domain/business-flow-overview.md。\n\n为什么要有这一行：跨域主干导航文档已经落在 docs/domain/ 下，但治理入口表\n不指向它——一份没有入口的资产下轮就没人读、也没人维护，随后静默漂移\n（C25 同族：文档指向的东西运行时到不了，反过来也一样成立）。\n\n该行同时写明它是**派生非真源**、据它下判断前必须回到 contracts / blueprint\n复核，避免入口表把导航文档抬成第二份状态机口径（P1）。\n\nAGENTS.md 为符号链接自动跟随；pnpm check exit 0（含 check:governance-docs）。\n作用域：本地工作区 dirty（并发会话有 approval-inbox 切片二在途），本提交\n只含 CLAUDE.md 一个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T19:58:50-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/47ce4c6146a13c443db38c5816749d0591339e46...fb6c5ad390153c534787dc66d90284ff257d28d1","Len":3}...
|
1785639545
|
Edit
Delete
|
|
20287
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"bc5d9cc90 {"Commits":[{"Sha1":"bc5d9cc90007b3602ccd809110887ba581f0e4b0","Message":"docs(truth): 清除 docs/README.md 三处幽灵资产 + 两条断言机器化\n\nREADME「配套的工程工具」表长期把 commitlint 与 Husky 列成已有工具\n（\"本地 commit 时自动触发 lint + commitlint\"），实测两者从未存在：\n无 commitlint.config.js、无 .husky/、package.json 也无相关依赖。\n实锤旁证——本轮真实提交 fb6c5ad 未触发任何 hook。\n\n**\"以为有门禁\"比\"知道没有\"更危险**：读者据此跳过手工检查，等于文档\n凭空注销了一道本就不存在的卡口。故两行改为 🟡 规划未落地并写明\n\"提交前请手工跑 pnpm check\"，落地模板指回 git-standard。\n\n同表第三处：`scripts/check-naming` 缺扩展名，真身是 check-naming.mjs。\n另把该表补一列「状态」，让已落地/未落地在结构上就分得开。\n\n机器化（C14 纪律：只为已实锤的漂移加断言）：\n- commitlint-husky-honesty 从只扫 git-standard 扩到同时扫 README，\n 触发条件同时看 commitlint.config.js 与 .husky 两者是否存在\n- 新增 no-phantom-script-path：README 反引号里的 scripts/xxx 必须真实存在；\n 只扫反引号内且路径后至少一个字符，正文\"scripts/ + CI\"这类泛指不参与判定\n\n负向证据（scripts/lib/docs-truth.test.mjs，由 check:gate-selftest 重跑）：\n- 抹掉 README / git-standard 的未落地标注 → 各自判红并命中对应断言 id\n （用 replaceAll，避免只替换第一处而静默拔牙）\n- README 写入不存在的脚本路径 → 判红命中 no-phantom-script-path\n- 泛指目录 \"scripts/ 目录\" → 保持绿，确认新断言够窄不误杀\n\npnpm check exit 0；check:gate-selftest 5 组全绿。作用域：本地工作区\ndirty（并发会话 approval-inbox 切片二在途），本提交只含这 3 个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:09:57-07:00"}],"HeadCommit":{"Sha1":"bc5d9cc90007b3602ccd809110887ba581f0e4b0","Message":"docs(truth): 清除 docs/README.md 三处幽灵资产 + 两条断言机器化\n\nREADME「配套的工程工具」表长期把 commitlint 与 Husky 列成已有工具\n（\"本地 commit 时自动触发 lint + commitlint\"），实测两者从未存在：\n无 commitlint.config.js、无 .husky/、package.json 也无相关依赖。\n实锤旁证——本轮真实提交 fb6c5ad 未触发任何 hook。\n\n**\"以为有门禁\"比\"知道没有\"更危险**：读者据此跳过手工检查，等于文档\n凭空注销了一道本就不存在的卡口。故两行改为 🟡 规划未落地并写明\n\"提交前请手工跑 pnpm check\"，落地模板指回 git-standard。\n\n同表第三处：`scripts/check-naming` 缺扩展名，真身是 check-naming.mjs。\n另把该表补一列「状态」，让已落地/未落地在结构上就分得开。\n\n机器化（C14 纪律：只为已实锤的漂移加断言）：\n- commitlint-husky-honesty 从只扫 git-standard 扩到同时扫 README，\n 触发条件同时看 commitlint.config.js 与 .husky 两者是否存在\n- 新增 no-phantom-script-path：README 反引号里的 scripts/xxx 必须真实存在；\n 只扫反引号内且路径后至少一个字符，正文\"scripts/ + CI\"这类泛指不参与判定\n\n负向证据（scripts/lib/docs-truth.test.mjs，由 check:gate-selftest 重跑）：\n- 抹掉 README / git-standard 的未落地标注 → 各自判红并命中对应断言 id\n （用 replaceAll，避免只替换第一处而静默拔牙）\n- README 写入不存在的脚本路径 → 判红命中 no-phantom-script-path\n- 泛指目录 \"scripts/ 目录\" → 保持绿，确认新断言够窄不误杀\n\npnpm check exit 0；check:gate-selftest 5 组全绿。作用域：本地工作区\ndirty（并发会话 approval-inbox 切片二在途），本提交只含这 3 个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:09:57-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/fb6c5ad390153c534787dc66d90284ff257d28d1...bc5d9cc90007b3602ccd809110887ba581f0e4b0","Len":1}...
|
1785640209
|
Edit
Delete
|
|
20288
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"b15cb5471 {"Commits":[{"Sha1":"b15cb54710ee5d1849b806adc01fcdddcaff5484","Message":"Merge remote-tracking branch 'github/feat/solution-tier-multi-product' into feat/solution-tier-multi-product\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:10:47-07:00"},{"Sha1":"7b9d30ff91324ab64ec0c115a0f05c0c503f81b6","Message":"Merge branch 'main' into feat/solution-tier-multi-product","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-01T20:02:59-07:00"},{"Sha1":"ab8275d49416872ad2c720a1274d8d59068d2495","Message":"Merge pull request #5 from laoluojuhai/feat/g24-list-pagination-and-options\n\nfeat(g24): 列表分页 + 选择器 options 双读路径（关闭 G24）","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-01T20:01:54-07:00"},{"Sha1":"ad018e731c9be66721d9bae55dde85574d03e6c2","Message":"Merge pull request #4 from laoluojuhai/chore/governance-c25-c26-c27\n\n治理修复：关闭 C25/C26/C27 —— 幽灵 UI 资产、partial schema 丢失的不变量、浏览器端 KPI","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-01T20:01:33-07:00"},{"Sha1":"c1777844395fa1863bec92d95284c2f74250136b","Message":"Merge pull request #3 from laoluojuhai/chore/close-g14-remote-gate\n\ndocs: 关闭 G14——远端门禁从「能绿」推进到「会拦」","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-01T20:00:23-07:00"}],"HeadCommit":{"Sha1":"b15cb54710ee5d1849b806adc01fcdddcaff5484","Message":"Merge remote-tracking branch 'github/feat/solution-tier-multi-product' into feat/solution-tier-multi-product\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:10:47-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/bc5d9cc90007b3602ccd809110887ba581f0e4b0...b15cb54710ee5d1849b806adc01fcdddcaff5484","Len":5}...
|
1785640342
|
Edit
Delete
|
|
20289
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"3a22776ed {"Commits":[{"Sha1":"3a22776ed81118bba6b93bfb50d5b36a70b2ee35","Message":"feat(approval-inbox): 切片二（4/5 域）——补发起人字段与不可自批硬校验\n\n蓝图 §7 裁决的方案 B：中心先落地、内控另立一片。本片补齐 5 个缺发起人的域中的 4 个。\n\n## 新增字段（两后端 schema 对等 + 迁移）\n- SolutionProject.reviewRequestedBy —— **把方案推进到当前待审状态的人**。\n 单列足够：同一时刻只有一个待审阶段。技术复核阶段=提交人、经理批准阶段=技术复核人，\n 正好都是各自阶段该被禁止自批的那一个。\n- PurchaseOrder.acceptedBy —— 接单人\n- Stocktake.submittedBy —— 提交盘点的人\n\n三列一律 nullable：迁移前的存量行无从追溯发起人，**判不了就不判**。\n给个假默认值会让不可自批看起来生效、实际保护不了任何一行。\n\n## 不可自批硬校验（两后端对等）\n方案技术复核 / 方案经理批准 / 采购审批 / 盘点审批各加 approver ≠ requester 校验，\n403 + code=SELF_APPROVAL_FORBIDDEN，与红冲/退款既有口径一致。\n角色分离挡不住 ADMIN（持全部 capability），所以必须按 actor 再判一次——两层缺一不可。\n\nactor 串进 5 条写链（两后端各自的 controller/route 补 RequestActor/requestActor）。\n\n## 契约与聚合\nselfRequestedKnown 对这 4 类转 true；聚合把 requestedBy 带出来，\n自批过滤随之在这 4 类上真正生效。UI 文案改为点名「报价审批暂未记录发起人」。\n\n## E2E 随内控调整（这些红盘是闸门在正确工作，不是回归）\n原用例里同一个 ADMIN 既提交又审批——正是不可自批要禁的。浏览器会话取不到身份时\nactor 兜底为 `role:\u003cROLE\u003e`（同角色视为同一人，刻意 fail-closed，不得为测试放宽）。\n故改为：先在浏览器断言「点了没推进」（这是该闸门唯一的浏览器级证据），\n再换一个审批人身份走 API 放行。覆盖方案双审核、采购审批、盘点审批三处。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check 0 / check:runtime 296（地板 294→296）/ check:ui 10（地板 9→10）\n- 两后端各 +1 条自批 403 断言；contracts 单测覆盖 selfRequestedKnown 全集\n- 负向实跑判红后恢复：拔掉采购不可自批校验 → 期望 403 实得 200 判红\n\n## 仍未闭环\n报价审批（ApprovalRequest 无 requestedBy）**本片未做**——并发会话正在改报价域，\n避让以免卡住对方。中心因此仍**不得**笼统宣称「已保证不可自批」。\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:15:14-07:00"}],"HeadCommit":{"Sha1":"3a22776ed81118bba6b93bfb50d5b36a70b2ee35","Message":"feat(approval-inbox): 切片二（4/5 域）——补发起人字段与不可自批硬校验\n\n蓝图 §7 裁决的方案 B：中心先落地、内控另立一片。本片补齐 5 个缺发起人的域中的 4 个。\n\n## 新增字段（两后端 schema 对等 + 迁移）\n- SolutionProject.reviewRequestedBy —— **把方案推进到当前待审状态的人**。\n 单列足够：同一时刻只有一个待审阶段。技术复核阶段=提交人、经理批准阶段=技术复核人，\n 正好都是各自阶段该被禁止自批的那一个。\n- PurchaseOrder.acceptedBy —— 接单人\n- Stocktake.submittedBy —— 提交盘点的人\n\n三列一律 nullable：迁移前的存量行无从追溯发起人，**判不了就不判**。\n给个假默认值会让不可自批看起来生效、实际保护不了任何一行。\n\n## 不可自批硬校验（两后端对等）\n方案技术复核 / 方案经理批准 / 采购审批 / 盘点审批各加 approver ≠ requester 校验，\n403 + code=SELF_APPROVAL_FORBIDDEN，与红冲/退款既有口径一致。\n角色分离挡不住 ADMIN（持全部 capability），所以必须按 actor 再判一次——两层缺一不可。\n\nactor 串进 5 条写链（两后端各自的 controller/route 补 RequestActor/requestActor）。\n\n## 契约与聚合\nselfRequestedKnown 对这 4 类转 true；聚合把 requestedBy 带出来，\n自批过滤随之在这 4 类上真正生效。UI 文案改为点名「报价审批暂未记录发起人」。\n\n## E2E 随内控调整（这些红盘是闸门在正确工作，不是回归）\n原用例里同一个 ADMIN 既提交又审批——正是不可自批要禁的。浏览器会话取不到身份时\nactor 兜底为 `role:\u003cROLE\u003e`（同角色视为同一人，刻意 fail-closed，不得为测试放宽）。\n故改为：先在浏览器断言「点了没推进」（这是该闸门唯一的浏览器级证据），\n再换一个审批人身份走 API 放行。覆盖方案双审核、采购审批、盘点审批三处。\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check 0 / check:runtime 296（地板 294→296）/ check:ui 10（地板 9→10）\n- 两后端各 +1 条自批 403 断言；contracts 单测覆盖 selfRequestedKnown 全集\n- 负向实跑判红后恢复：拔掉采购不可自批校验 → 期望 403 实得 200 判红\n\n## 仍未闭环\n报价审批（ApprovalRequest 无 requestedBy）**本片未做**——并发会话正在改报价域，\n避让以免卡住对方。中心因此仍**不得**笼统宣称「已保证不可自批」。\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:15:14-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/b15cb54710ee5d1849b806adc01fcdddcaff5484...3a22776ed81118bba6b93bfb50d5b36a70b2ee35","Len":1}...
|
1785640521
|
Edit
Delete
|
|
20290
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"fbdc3680f {"Commits":[{"Sha1":"fbdc3680f4ef53e824738ca8cbf8f0e6deefce55","Message":"fix(gate): 文档诚实注收窄到行——文件级标注不该赦免同文件里的另一句谎话\n\ngit-standard 导语长期写「Conventional Commits 规范 + commitlint 自动校验」，\n而同文件 §三 已标注「🟡 规划未落地」。上一轮加的 commitlint-husky-honesty\n是**文件级**判定（文件里出现「规划未落地」即算诚实），因此绿着放行了这句\n自相矛盾的导语——而读者读的正是导语，不会翻到第三节。\n\n粒度选得比缺陷粗一级，门禁就会用\"文件里有免责声明\"赦免\"文件里另一句谎话\"。\n读者是按句子受骗的，断言就得按句子判。\n\n改动：\n- git-standard 导语改为如实描述：校验靠人、无 hook、提交前手工跑 pnpm check\n- 新增 commitlint-husky-no-auto-claim：同一行既点名 commitlint/husky\n 又宣称\"自动\"、且该行无未落地字样 → 判红。收窄到行是为了不误咬 CI 侧\n 合法的\"自动\"表述（C14：宁可窄，不造模糊规则）\n\n负向证据（scripts/lib/docs-truth.test.mjs，由 check:gate-selftest 重跑）：\n- 向两份文件各写回**那句历史原文** → 各自 exit 恰为 1 且命中\n [commitlint-husky-no-auto-claim:\u003cfile\u003e]，确认红在点子上而非撞上别的断言\n- 同行带未落地标注的「自动」表述 → 仍绿，锁住新断言的窄边界。\n 只有红测试的门禁会朝越咬越宽漂移，直到有人为了让它闭嘴而删掉它\n\npnpm check exit 0；check:gate-selftest 5 组全绿。作用域：本地工作区 dirty\n（并发会话 approval-inbox 切片二在途），本提交只含这 3 个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:18:46-07:00"}],"HeadCommit":{"Sha1":"fbdc3680f4ef53e824738ca8cbf8f0e6deefce55","Message":"fix(gate): 文档诚实注收窄到行——文件级标注不该赦免同文件里的另一句谎话\n\ngit-standard 导语长期写「Conventional Commits 规范 + commitlint 自动校验」，\n而同文件 §三 已标注「🟡 规划未落地」。上一轮加的 commitlint-husky-honesty\n是**文件级**判定（文件里出现「规划未落地」即算诚实），因此绿着放行了这句\n自相矛盾的导语——而读者读的正是导语，不会翻到第三节。\n\n粒度选得比缺陷粗一级，门禁就会用\"文件里有免责声明\"赦免\"文件里另一句谎话\"。\n读者是按句子受骗的，断言就得按句子判。\n\n改动：\n- git-standard 导语改为如实描述：校验靠人、无 hook、提交前手工跑 pnpm check\n- 新增 commitlint-husky-no-auto-claim：同一行既点名 commitlint/husky\n 又宣称\"自动\"、且该行无未落地字样 → 判红。收窄到行是为了不误咬 CI 侧\n 合法的\"自动\"表述（C14：宁可窄，不造模糊规则）\n\n负向证据（scripts/lib/docs-truth.test.mjs，由 check:gate-selftest 重跑）：\n- 向两份文件各写回**那句历史原文** → 各自 exit 恰为 1 且命中\n [commitlint-husky-no-auto-claim:\u003cfile\u003e]，确认红在点子上而非撞上别的断言\n- 同行带未落地标注的「自动」表述 → 仍绿，锁住新断言的窄边界。\n 只有红测试的门禁会朝越咬越宽漂移，直到有人为了让它闭嘴而删掉它\n\npnpm check exit 0；check:gate-selftest 5 组全绿。作用域：本地工作区 dirty\n（并发会话 approval-inbox 切片二在途），本提交只含这 3 个文件。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:18:46-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/3a22776ed81118bba6b93bfb50d5b36a70b2ee35...fbdc3680f4ef53e824738ca8cbf8f0e6deefce55","Len":1}...
|
1785640746
|
Edit
Delete
|
|
20291
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"479c74220 {"Commits":[{"Sha1":"479c742208b50c7e788cb4eea1b6b878fcfe615e","Message":"feat(approval-inbox): 切片二收口——报价审批补发起人，不可自批 6/6 道闭环\n\n上一轮避让并发会话对报价域的改动，留下 ApprovalRequest 这最后一道。\n现该域已干净（其工作已合入 b15cb54），补齐收口。\n\n## 改动\n- ApprovalRequest.requestedBy（两后端 schema 对等 + 迁移，nullable）\n- requestApproval 落发起人；decideApproval 校验 approver ≠ requester\n → 403 + code=SELF_APPROVAL_FORBIDDEN，与其余五道口径一致\n- actor 串进两后端的 request-approval / approve / reject-approval\n （Fastify 的 request-approval 因此脱离无 actor 的 noBodyAction）\n- contracts 描述表 QUOTATION_APPROVAL.selfRequestedKnown → true；\n 聚合把 PENDING 子行的 requestedBy 带出来，自批过滤在报价审批上真正生效\n- UI 文案去掉「报价审批暂未记录发起人」的例外说明\n\n## 至此不可自批覆盖 6/6 道真审批\n报价 / 方案技术复核 / 方案经理批准 / 采购 / 盘点 / 红冲 / 退款\n（仅剩的两类 selfRequestedKnown=false 是「客户决定后的待办」，本就无发起人概念）\n\n## 诚实边界（未因本片改变）\n- 列均 nullable：建列前的存量行判不了就不判，**不假装判过**\n- 仍受 G8 制约：Bearer 未验签、actor 取不到时兜底 `role:\u003cROLE\u003e`，\n 所以这是「防误操作」不是「防抵赖」，**不得宣称为审计级职责分离**\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check 0 / check:runtime 296 / check:ui 10\n- 两后端各 +1 条报价自批 403 断言，并各配一条「换个审批人即通过」的反证\n ——只断言 403 无法区分「拦对了」与「谁都批不了」的误杀\n- 负向实跑判红后恢复：拔掉报价不可自批校验 → 期望 403 实得 200\n- 回灌：CLAUDE.md 真源地图新增「跨域待办审批与不可自批」条目 +\n 证据新鲜度/棘轮行更新；蓝图 §4 缺口 1、2 标记闭环\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:28:00-07:00"}],"HeadCommit":{"Sha1":"479c742208b50c7e788cb4eea1b6b878fcfe615e","Message":"feat(approval-inbox): 切片二收口——报价审批补发起人，不可自批 6/6 道闭环\n\n上一轮避让并发会话对报价域的改动，留下 ApprovalRequest 这最后一道。\n现该域已干净（其工作已合入 b15cb54），补齐收口。\n\n## 改动\n- ApprovalRequest.requestedBy（两后端 schema 对等 + 迁移，nullable）\n- requestApproval 落发起人；decideApproval 校验 approver ≠ requester\n → 403 + code=SELF_APPROVAL_FORBIDDEN，与其余五道口径一致\n- actor 串进两后端的 request-approval / approve / reject-approval\n （Fastify 的 request-approval 因此脱离无 actor 的 noBodyAction）\n- contracts 描述表 QUOTATION_APPROVAL.selfRequestedKnown → true；\n 聚合把 PENDING 子行的 requestedBy 带出来，自批过滤在报价审批上真正生效\n- UI 文案去掉「报价审批暂未记录发起人」的例外说明\n\n## 至此不可自批覆盖 6/6 道真审批\n报价 / 方案技术复核 / 方案经理批准 / 采购 / 盘点 / 红冲 / 退款\n（仅剩的两类 selfRequestedKnown=false 是「客户决定后的待办」，本就无发起人概念）\n\n## 诚实边界（未因本片改变）\n- 列均 nullable：建列前的存量行判不了就不判，**不假装判过**\n- 仍受 G8 制约：Bearer 未验签、actor 取不到时兜底 `role:\u003cROLE\u003e`，\n 所以这是「防误操作」不是「防抵赖」，**不得宣称为审计级职责分离**\n\n## 证据（本地工作区 2026-08-01）\n- pnpm check 0 / check:runtime 296 / check:ui 10\n- 两后端各 +1 条报价自批 403 断言，并各配一条「换个审批人即通过」的反证\n ——只断言 403 无法区分「拦对了」与「谁都批不了」的误杀\n- 负向实跑判红后恢复：拔掉报价不可自批校验 → 期望 403 实得 200\n- 回灌：CLAUDE.md 真源地图新增「跨域待办审批与不可自批」条目 +\n 证据新鲜度/棘轮行更新；蓝图 §4 缺口 1、2 标记闭环\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:28:00-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/fbdc3680f4ef53e824738ca8cbf8f0e6deefce55...479c742208b50c7e788cb4eea1b6b878fcfe615e","Len":1}...
|
1785641286
|
Edit
Delete
|
|
20292
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
{"Commits":[{"Sha1":"06495232f {"Commits":[{"Sha1":"06495232f1936d9e221f7745216962379994b261","Message":"chore: 合并 main 后刷新治理报告\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:45:47-07:00"},{"Sha1":"ae1046edf9b030e1a67c30235ddd345590e61fdf","Message":"Merge remote-tracking branch 'github/main' into feat/solution-tier-multi-product\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:42:40-07:00"},{"Sha1":"8ab2314d69f1885d49bbbf1fc3c5b3c6cccb6711","Message":"Merge pull request #6 from laoluojuhai/feat/solution-tier-multi-product\n\nfeat(solution): 三档方案每档多商品 + 数量默认取包房总数","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-01T20:09:43-07:00"}],"HeadCommit":{"Sha1":"06495232f1936d9e221f7745216962379994b261","Message":"chore: 合并 main 后刷新治理报告\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-01T20:45:47-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/479c742208b50c7e788cb4eea1b6b878fcfe615e...06495232f1936d9e221f7745216962379994b261","Len":3}...
|
1785642353
|
Edit
Delete
|
|
29930
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/template-making-uiux
|
0
|
|
1789445282
|
Edit
Delete
|
|
29931
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/template-making-uiux
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"fcbee15d07deb0a3212286790442541c9a86de8b","Message":"docs: record verified template master display release\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-09T07:54:32-07:00"},"CompareURL":"luoanwu/image-generation/compare/main...fcbee15d07deb0a3212286790442541c9a86de8b","Len":0}...
|
1789445282
|
Edit
Delete
|
|
29932
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/template-slot-gestures
|
0
|
|
1789445288
|
Edit
Delete
|
|
29933
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/template-slot-gestures
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"0ae508df9ca6f194a57d2b65b554cf4a210a4577","Message":"docs(governance): mark heavy baseline rows pending for template slot gestures\n\nSource changed in apps/web, so the six source-bound heavy reports and the\ndependency audit no longer prove this tree. The 11 baseline rows now point\nat docs/governance/log/2026-09-10-template-slot-gestures.md and wait for\na rerun; static reports regenerated by pnpm check (23/23 tasks green).\n\nCo-Authored-By: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-09T19:59:31-07:00"},"CompareURL":"luoanwu/image-generation/compare/main...0ae508df9ca6f194a57d2b65b554cf4a210a4577","Len":0}...
|
1789445288
|
Edit
Delete
|
|
29568
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/feat/u31-u33-u34-consumer-feedback
|
0
|
|
1789393970
|
Edit
Delete
|
|
29569
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/feat/u31-u33-u34-consumer-feedback
|
0
|
{"Commits":[{"Sha1":"a76562a9c {"Commits":[{"Sha1":"a76562a9c4710a6763243f4f1e1b87f12461b429","Message":"chore(reports): rebind gate reports to 66d02e6\n\n本轮 pnpm check（exit 0，30 项）与治理回归 183/183 的报告产物，按仓纪律 §5 落在实现提交之后。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T06:52:39-07:00"},{"Sha1":"66d02e665eba56a132e0c68a0916fdbb54f535e1","Message":"feat(governance,client-fact): land U-31 / U-33 / U-34 consumer feedback\n\n真实上层接入（digital-employee-os 的 os-employment-projection）暴露的三条缺口，\n按回灌纪律「机器门禁 \u003e 手册条目 \u003e 口头经验」落到本仓。\n\nU-33（机器门禁）：check:pins 只读 package.json 的版本字符串，\n`\"@juhai/client-fact\": \"1.0.0-rc.2\"` 在它眼里是完美 exact pin，而 pnpm-lock.yaml 可以把同一个\n包解析到临时目录的 tarball（实测：会话 scratchpad 下的 file:/private/tmp/...tgz）。这比明着写\nfile: 依赖更危险——所有既有门禁全绿，只有别人 clone 后 pnpm install 失败才暴露。现把判据下沉到\nlockfile 的解析结果：@juhai/* 的 resolution tarball 必须落在 .npmrc 声明的 scope registry 下；\n非 registry 来源须在 platform-dependency-deviations.json 完整登记（五字段全填且未过期）；\n临时目录来源不可登记豁免。\n\n不误伤既有上层仓的三条：无 lockfile 不判定；lockfile 里没有 @juhai 外部条目（纯 workspace 消费）\n不判定、也不要求 .npmrc；只有真的存在外部解析才要求声明 registry。本仓自测 checked=0 通过，\n对 OS 仓实测 4 个解析来源全部合规。\n\nU-34 / U-31（包契约）：client-fact 此前没有 README，而 clients/README 却说\"实现与验收见包 README\"。\n新建并加进 files：\n- baseUrl 必须含 /api 前缀——本包用相对 URL 解析端点，少写 /api 不报错而是让所有回查 404，\n 消费者若把 404 当\"事实不存在\"就会判 UNTRUSTED_FACT、三次进死信；一个配置漏字母把整条摄入\n 变成全量死信。同时写明 404 / 不可达 / 未配置三种情况的不同处置。\n- 迁移模板只给表：策略无 TO 子句（对 PUBLIC 生效，system 角色同样被挡）且全文无 GRANT，\n 消费者若用低权限运行角色，照抄后对五张表没有任何权限。契约改为\"表 DDL 逐字照用，\n GRANT 与策略角色绑定由消费者按自身角色模型补齐\"。\n- 附 rc.3 的 STALE 行为变更与\"升级后应删除边界翻译\"。\n\n验证：新增 governance/test/check-pins.test.mjs 10 例（1 正向 + 6 负向判据 + 3 条不误伤）；\n治理回归 183/183；根 pnpm check exit 0（30 项）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T06:52:14-07:00"},{"Sha1":"036a308f27acf35a46f068c96fea7723ef74d05e","Message":"feat(client-fact): U-29 判落后版本为 STALE，不再当毒消息\n\n真实消费者接入（digital-employee-os 的 os-employment-projection）暴露：applyOne 在\nversion \u003c= watermark 时抛 FactRejected(\"UNPROCESSED_VERSION_BEHIND_WATERMARK\")，\n而 handle 把任何 FactRejected 计入 attempts——至少一次投递下的**正常迟到重投**三次即\n被打进死信，与\"内容有毒\"共用一套判据；类型里写着的 \"STALE\" 返回值反而不可达。\n平台自己的主线 e2e 用合成宿主表，从不重放已过水位的事实，因此一直照不出这条。\n\n改为返回 \"STALE\"，并顺手删掉该 fact 可能留在 gap 缓冲里的副本：落后事实永远等不到\nprevious_version = 水位，留着只会把缓冲占满到 GAP_BUFFER_FULL，drain 循环也会空转。\n\n证据：runtime/test/e2e/mainline.test.ts 新增断言——清掉 processed 行后重放旧事实，\n连判三次 STALE、platform_client_fact_failure 无行、投影仍停在 11；该文件 6/6 通过\n（真实 M3/M5/M6 库 + Redpanda，MAINLINE_ENV=ms23）。治理负向回归 173/173、\ncheck:pins 34 个 package.json 全 exact pin、根 pnpm check 全链通过。\n\n发布列车三件套同步升到 1.0.0-rc.3，**尚未发布**：rc.2 已在 Registry 且不可覆盖，\n上层在 rc.3 发布前继续 pin rc.2 并在边界做错误码翻译。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-13T22:10:52-07:00"}],"HeadCommit":{"Sha1":"a76562a9c4710a6763243f4f1e1b87f12461b429","Message":"chore(reports): rebind gate reports to 66d02e6\n\n本轮 pnpm check（exit 0，30 项）与治理回归 183/183 的报告产物，按仓纪律 §5 落在实现提交之后。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T06:52:39-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/d1ef5414093aa67ff4b8e2b7af8d13be86aed7ba...a76562a9c4710a6763243f4f1e1b87f12461b429","Len":3}...
|
1789393970
|
Edit
Delete
|
|
29968
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/feat/u31-u33-u34-consumer-feedback
|
0
|
{"Commits":[{"Sha1":"727044996 {"Commits":[{"Sha1":"727044996fde65045ab4ca56a060c0a32fa24c0a","Message":"chore(reports): rebind after merging main into the U-31/33/34 branch\n\n合并 main（6 个提交）后重跑根 pnpm check：exit 0，31 项。\nmodule-imports 报告的合并冲突按「报告是运行产物」取 main 版本后由本轮重新生成。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T19:21:58-07:00"},{"Sha1":"9a7231221ba190a84f91f1f2771017927d991328","Message":"Merge branch 'main' into feat/u31-u33-u34-consumer-feedback\n\n# Conflicts:\n#\treports/module-imports.latest.json\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T19:21:34-07:00"},{"Sha1":"35e44a1d97cad7b20404416743167de2aa15c277","Message":"chore(reports): bind check:evidence baseline @ 5f0473b\n\n13 份已登记报告新鲜，5 条 warn（port-conformance、runtime/ui 验收、\nrevocation-sla、mainline-acceptance —— 都是需要真实库/容器才能重跑的，\n已在 evidence-scopes.json 写明 promoteBy），32 份未登记只计 info。\nmodule-imports 顺带在干净树重跑回绑（315 文件 0 违规）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T10:37:16-07:00"},{"Sha1":"5f0473b6d7bf2089d3715c6f637320d6d96ac862","Message":"feat(governance): gate machine-evidence freshness by scope, not commit distance\n\n仓纪律 5 只要求报告绑 gitSha + worktreeDirty=false，没有任何检查关心那个 SHA\n相对 HEAD 是否已经过期；runtime 的 check:docs-truth 断言 N 也只比对「文档声明的\nSHA == 报告 provenance 的 SHA」。于是 CLAUDE.md 的「当前状态」可以逐字引用一份\n早被后续提交推翻的报告，而全链门禁一片绿。\n\n2026-09-14 实锤：main 上 stack-image-pins.latest.json 绑 7e279c5，其后\nstack/compose.yaml 已被改（ai-gateway 去掉空 DATABASE_URL），那份「12 镜像\n0 未锁」的结论形式上已失效，无人察觉。\n\n判据特意不用「落后几个提交」——实测那样会误报 38 条（runtime 验收落后 32 个\n提交，作用域却一行没动）。判据是：绑定 SHA → HEAD 之间有没有改到该报告自己\n覆盖的文件，作用域逐条登记在 governance/evidence-scopes.json。\n\n- severity 逐条登记：静态检查 error，需真实库/容器重跑的验收先 warn 并写\n promoteBy，覆盖面与严格度都按登记涨，不搞一刀切。\n- 脏绑报告在干净树上判红（说明脏绑被提交了），在脏树上只 warn（改到一半）。\n- 例外须带 reason/recordedAt/resolveBy（G-13），失效判 EXCEPTION_STALE。\n- 未登记的报告只计 SCOPE_UNDECLARED（info），不判红。\n\n10 个用例，含一个真实 git 仓集成用例钉住核心判据：作用域外连改三个提交仍绿，\n作用域内一改即红。放在根 check 链尾。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T10:36:33-07:00"},{"Sha1":"9807535a2b81bc14a35ffc306d7b1b0910f0f99f","Message":"chore(reports): bind the ai-gateway first-start evidence @ 51351b3\n\nliveliness / readiness 200（db: Not connected）、带 master key 的 /v1/models\n200 返回 platform-default-chat、无 key 401 / 错 key 400；/v1/chat/completions\n401 是供应商侧 replace-me，链路本身通。干净树绑 51351b3。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T10:10:43-07:00"}],"HeadCommit":{"Sha1":"727044996fde65045ab4ca56a060c0a32fa24c0a","Message":"chore(reports): rebind after merging main into the U-31/33/34 branch\n\n合并 main（6 个提交）后重跑根 pnpm check：exit 0，31 项。\nmodule-imports 报告的合并冲突按「报告是运行产物」取 main 版本后由本轮重新生成。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T19:21:58-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/a76562a9c4710a6763243f4f1e1b87f12461b429...727044996fde65045ab4ca56a060c0a32fa24c0a","Len":8}...
|
1789445430
|
Edit
Delete
|
|
29934
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/uiux-workbench-20260909
|
0
|
|
1789445293
|
Edit
Delete
|
|
29935
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/uiux-workbench-20260909
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"eb9f043fa4c56dae0d634c3b9de9b7de82514b24","Message":"docs: record the uiux-script3 release and its recovery\n\nCo-Authored-By: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-09T18:32:42-07:00"},"CompareURL":"luoanwu/image-generation/compare/main...eb9f043fa4c56dae0d634c3b9de9b7de82514b24","Len":0}...
|
1789445293
|
Edit
Delete
|
|
28561
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/video-timeline-preview
|
0
|
|
1788930765
|
Edit
Delete
|
|
28562
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feat/video-timeline-preview
|
0
|
{"Commits":[{"Sha1":"f851b46ce {"Commits":[{"Sha1":"f851b46ceba3ad5487b18f779b5ad06dc863cd0c","Message":"feat(video): add interactive composition canvas candidate\n\nAdd source-frame composition gestures, shared export geometry and temporal frame fixtures. Preserve one-step undo and version-change cancellation.\n\nValidation: pnpm check, six focused tests and all 75 encoded fixture frames passed. Current-source heavy gates and strengthened browser frame checks remain pending; this is a user-requested candidate upload, not a production release.\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-08T22:11:39-07:00"},{"Sha1":"e7aa92db95b85e3d8eeaf8bc238f942db6cb261f","Message":"merge: integrate deployed admin brand management into video candidate\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-08T20:56:52-07:00"}],"HeadCommit":{"Sha1":"f851b46ceba3ad5487b18f779b5ad06dc863cd0c","Message":"feat(video): add interactive composition canvas candidate\n\nAdd source-frame composition gestures, shared export geometry and temporal frame fixtures. Preserve one-step undo and version-change cancellation.\n\nValidation: pnpm check, six focused tests and all 75 encoded fixture frames passed. Current-source heavy gates and strengthened browser frame checks remain pending; this is a user-requested candidate upload, not a production release.\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-08T22:11:39-07:00"},"CompareURL":"luoanwu/image-generation/compare/ac6493a9b8b714bba5e8cb54be76ee8f441bdaac...f851b46ceba3ad5487b18f779b5ad06dc863cd0c","Len":2}...
|
1788930765
|
Edit
Delete
|
|
25442
|
5
|
5
|
5
|
62
|
0
|
0
|
refs/heads/feat/voiceprint-ui-neutral-labels
|
0
|
|
1787563985
|
Edit
Delete
|
|
25443
|
7
|
5
|
5
|
62
|
0
|
0
|
refs/heads/feat/voiceprint-ui-neutral-labels
|
0
|
|
1787563985
|
Edit
Delete
|
|
25444
|
5
|
5
|
5
|
62
|
0
|
0
|
refs/heads/feat/voiceprint-ui-neutral-labels
|
0
|
{"Commits":[{"Sha1":"e9053d78a {"Commits":[{"Sha1":"e9053d78ad792bc6dc023b7e1cc96fd2d7d9ea9a","Message":"test: 补齐候选分项分数的 UI 断言覆盖\n\n反证发现：把候选行「证据A」改回「W」后 check:ui 仍然 8/8 全绿——\n说明分项分数那一行此前零断言覆盖，改文案不会红。既有断言只覆盖了\n判定原因文案、证据分歧徽章和底栏两条权重。\n\n新增一条对 identify-result 的 toContainText，锁住标签与数值：\n「证据A 0.920 · 证据B 0.900 · 分歧 0.020」（对应 stub match 分支\nwavlmScore=0.92 / ecapaScore=0.90 / scoreDisagreement=0.02）。\n\n断言有牙已实证：源码停在旧标签时该用例红（uiTestsPassed 7/8，\nReceived「W 0.920 · 证据B 0.900」），还原后 8/8 绿。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:07:07-07:00"},{"Sha1":"ccf8759df88298d325908e7a56837fe1c7778736","Message":"feat: 声纹 UI 改用中性证据标签与巨嗨品牌口径\n\n展示层不再出现模型名，技术真源保持不变。\n\n- 候选分项 W/E → 证据A/证据B，「差」→「分歧」，徽章「模型分歧」→「证据分歧」\n- 底栏决策有效权重 / 召回投影 W../E.. → A../B..\n- 判定原因单源（contracts）「WavLM 与 ECAPA 证据分歧过大」→「两路声纹证据分歧过大」\n- 页面主标题与首页入口「声纹工作台」→「巨嗨声音画像工作台」\n- 副标题「WavLM + ECAPA 融合」→「双路证据融合」\n\n刻意不动的部分：contracts 字段名（wavlmScore / retrievalWavlmWeight 等）与\nsidecar JSON 逐字对齐，改名会打断三层真源并触发 check:contract-consumers；\n路由段 /voiceprint 与组件名保持不变。分项分数继续展示，兑现\n「双模型可观测、不能只看黑盒融合分」的既有承诺。\n\nE2E 四条硬编码断言同步（分歧原因文案、证据分歧徽章、两条权重正则）。\n验证：typecheck 5/5、lint、check:naming、check:contract-consumers 全绿；\n真实运行服务上复验 7 人库与历史辨认结果渲染正确，控制台 0 错误。\ncheck:ui 未跑（需独立测试库 PG:55432 + Redis:6382）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:00:27-07:00"}],"HeadCommit":{"Sha1":"e9053d78ad792bc6dc023b7e1cc96fd2d7d9ea9a","Message":"test: 补齐候选分项分数的 UI 断言覆盖\n\n反证发现：把候选行「证据A」改回「W」后 check:ui 仍然 8/8 全绿——\n说明分项分数那一行此前零断言覆盖，改文案不会红。既有断言只覆盖了\n判定原因文案、证据分歧徽章和底栏两条权重。\n\n新增一条对 identify-result 的 toContainText，锁住标签与数值：\n「证据A 0.920 · 证据B 0.900 · 分歧 0.020」（对应 stub match 分支\nwavlmScore=0.92 / ecapaScore=0.90 / scoreDisagreement=0.02）。\n\n断言有牙已实证：源码停在旧标签时该用例红（uiTestsPassed 7/8，\nReceived「W 0.920 · 证据B 0.900」），还原后 8/8 绿。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:07:07-07:00"},"CompareURL":"luoanwu/voiceprint-recognition/compare/3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59...e9053d78ad792bc6dc023b7e1cc96fd2d7d9ea9a","Len":2}...
|
1787563985
|
Edit
Delete
|
|
25445
|
7
|
5
|
5
|
62
|
0
|
0
|
refs/heads/feat/voiceprint-ui-neutral-labels
|
0
|
{"Commits":[{"Sha1":"e9053d78a {"Commits":[{"Sha1":"e9053d78ad792bc6dc023b7e1cc96fd2d7d9ea9a","Message":"test: 补齐候选分项分数的 UI 断言覆盖\n\n反证发现：把候选行「证据A」改回「W」后 check:ui 仍然 8/8 全绿——\n说明分项分数那一行此前零断言覆盖，改文案不会红。既有断言只覆盖了\n判定原因文案、证据分歧徽章和底栏两条权重。\n\n新增一条对 identify-result 的 toContainText，锁住标签与数值：\n「证据A 0.920 · 证据B 0.900 · 分歧 0.020」（对应 stub match 分支\nwavlmScore=0.92 / ecapaScore=0.90 / scoreDisagreement=0.02）。\n\n断言有牙已实证：源码停在旧标签时该用例红（uiTestsPassed 7/8，\nReceived「W 0.920 · 证据B 0.900」），还原后 8/8 绿。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:07:07-07:00"},{"Sha1":"ccf8759df88298d325908e7a56837fe1c7778736","Message":"feat: 声纹 UI 改用中性证据标签与巨嗨品牌口径\n\n展示层不再出现模型名，技术真源保持不变。\n\n- 候选分项 W/E → 证据A/证据B，「差」→「分歧」，徽章「模型分歧」→「证据分歧」\n- 底栏决策有效权重 / 召回投影 W../E.. → A../B..\n- 判定原因单源（contracts）「WavLM 与 ECAPA 证据分歧过大」→「两路声纹证据分歧过大」\n- 页面主标题与首页入口「声纹工作台」→「巨嗨声音画像工作台」\n- 副标题「WavLM + ECAPA 融合」→「双路证据融合」\n\n刻意不动的部分：contracts 字段名（wavlmScore / retrievalWavlmWeight 等）与\nsidecar JSON 逐字对齐，改名会打断三层真源并触发 check:contract-consumers；\n路由段 /voiceprint 与组件名保持不变。分项分数继续展示，兑现\n「双模型可观测、不能只看黑盒融合分」的既有承诺。\n\nE2E 四条硬编码断言同步（分歧原因文案、证据分歧徽章、两条权重正则）。\n验证：typecheck 5/5、lint、check:naming、check:contract-consumers 全绿；\n真实运行服务上复验 7 人库与历史辨认结果渲染正确，控制台 0 错误。\ncheck:ui 未跑（需独立测试库 PG:55432 + Redis:6382）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:00:27-07:00"}],"HeadCommit":{"Sha1":"e9053d78ad792bc6dc023b7e1cc96fd2d7d9ea9a","Message":"test: 补齐候选分项分数的 UI 断言覆盖\n\n反证发现：把候选行「证据A」改回「W」后 check:ui 仍然 8/8 全绿——\n说明分项分数那一行此前零断言覆盖，改文案不会红。既有断言只覆盖了\n判定原因文案、证据分歧徽章和底栏两条权重。\n\n新增一条对 identify-result 的 toContainText，锁住标签与数值：\n「证据A 0.920 · 证据B 0.900 · 分歧 0.020」（对应 stub match 分支\nwavlmScore=0.92 / ecapaScore=0.90 / scoreDisagreement=0.02）。\n\n断言有牙已实证：源码停在旧标签时该用例红（uiTestsPassed 7/8，\nReceived「W 0.920 · 证据B 0.900」），还原后 8/8 绿。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:07:07-07:00"},"CompareURL":"luoanwu/voiceprint-recognition/compare/3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59...e9053d78ad792bc6dc023b7e1cc96fd2d7d9ea9a","Len":2}...
|
1787563985
|
Edit
Delete
|
|
29885
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/feat/workspace-manifest-anchor
|
0
|
|
1789444131
|
Edit
Delete
|
|
29886
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/feat/workspace-manifest-anchor
|
0
|
{"Commits":[{"Sha1":"02587c528 {"Commits":[{"Sha1":"02587c52835c0d763ab44c302cb862b5cb1a0125","Message":"feat(contracts): anchor workspace root on a manifest file, not directory names\n\ndetectWorkspaceRoot() only recognised an ancestor holding both 基础/ and doc/.\nThe directory migration splits 基础/ into 基础基座/ + 基础设施/ + 基础框架/ +\n平台治理/ and moves doc/ under 平台治理/, after which that probe returns null\nand every gate depending on it fails closed with WORKSPACE_ROOT_UNRESOLVED —\na one-constant breakage that is very hard to diagnose from the error alone.\n\nA candidate now qualifies when it holds the workspace.json manifest, falling\nback to the existing marker directories so checkouts without the manifest keep\nworking unchanged. Directory reshuffles then only touch the manifest.\n\nAdds 3 cases: manifest alone qualifies with both markers absent, an explicit\n--workspace-root carrying the manifest is accepted, and marker-only detection\nstill works. 101 → 104 tests, all passing.\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T20:40:01-07:00"},{"Sha1":"e0fb26df05caf3f1cecc8328b586aa304eff51eb","Message":"chore(contracts): rename hi-atelier app to 嗨赞造意\n\napp.name 由「嗨设首席」改为「嗨赞造意」，与目录名\n业务应用/嗨赞造意/image-generation 一致。id (hi-atelier)、\nrepository、domain、owner 均不变。\n\n来源冻结目录 platform-contracts/ 按 PF-04 阶段 1 规定不改\n（CHG-001 包指纹以该目录为准，改动会触发就绪度重基线），\n两边口径差随阶段 2 物理移除消除。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T20:35:51-07:00"}],"HeadCommit":{"Sha1":"02587c52835c0d763ab44c302cb862b5cb1a0125","Message":"feat(contracts): anchor workspace root on a manifest file, not directory names\n\ndetectWorkspaceRoot() only recognised an ancestor holding both 基础/ and doc/.\nThe directory migration splits 基础/ into 基础基座/ + 基础设施/ + 基础框架/ +\n平台治理/ and moves doc/ under 平台治理/, after which that probe returns null\nand every gate depending on it fails closed with WORKSPACE_ROOT_UNRESOLVED —\na one-constant breakage that is very hard to diagnose from the error alone.\n\nA candidate now qualifies when it holds the workspace.json manifest, falling\nback to the existing marker directories so checkouts without the manifest keep\nworking unchanged. Directory reshuffles then only touch the manifest.\n\nAdds 3 cases: manifest alone qualifies with both markers absent, an explicit\n--workspace-root carrying the manifest is accepted, and marker-only detection\nstill works. 101 → 104 tests, all passing.\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T20:40:01-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/517414d8806adba9ad700d6508e6c563513a583e...02587c52835c0d763ab44c302cb862b5cb1a0125","Len":2}...
|
1789444131
|
Edit
Delete
|
|
27206
|
4
|
5
|
4
|
24
|
0
|
0
|
refs/heads/feature/device-online-stats-admin
|
1
|
|
1788244393
|
Edit
Delete
|
|
27207
|
4
|
5
|
4
|
24
|
0
|
0
|
refs/heads/feature/device-online-stats-admin
|
1
|
{"Commits":[{"Sha1":"475a12034 {"Commits":[{"Sha1":"475a12034abf1fea354c960444a832b35d28ca11","Message":"fix: 修正 month 参数范围校验并排除未绑定门店设备的脏分组\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T14:28:55+08:00"},{"Sha1":"7a8398b310de4080487ac036006a76e178777318","Message":"feat: 新增 DeviceOnlineStats 控制器，暴露省份/城市统计接口\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T13:21:07+08:00"},{"Sha1":"18c1cd169646f0b162151817b334e933e8eebcf0","Message":"feat: 新增设备上线分布省份汇总/城市下钻查询\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T13:21:06+08:00"}],"HeadCommit":{"Sha1":"475a12034abf1fea354c960444a832b35d28ca11","Message":"fix: 修正 month 参数范围校验并排除未绑定门店设备的脏分组\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T14:28:55+08:00"},"CompareURL":"laiqiaojie/admin/compare/99e13e892139a4da82e6ec38678974696b9da59f...475a12034abf1fea354c960444a832b35d28ca11","Len":3}...
|
1788244393
|
Edit
Delete
|
|
27256
|
4
|
5
|
4
|
24
|
0
|
0
|
refs/heads/feature/device-online-stats-admin
|
1
|
{"Commits":[{"Sha1":"cc2efe159 {"Commits":[{"Sha1":"cc2efe159ea6a84675544dcf7511c2f3262f369a","Message":"docs: add frontend-facing API spec for device online stats by region\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T15:14:56+08:00"}],"HeadCommit":{"Sha1":"cc2efe159ea6a84675544dcf7511c2f3262f369a","Message":"docs: add frontend-facing API spec for device online stats by region\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T15:14:56+08:00"},"CompareURL":"laiqiaojie/admin/compare/475a12034abf1fea354c960444a832b35d28ca11...cc2efe159ea6a84675544dcf7511c2f3262f369a","Len":1}...
|
1788246900
|
Edit
Delete
|
|
27268
|
4
|
5
|
4
|
24
|
0
|
0
|
refs/heads/feature/device-online-stats-web
|
1
|
|
1788247080
|
Edit
Delete
|
|
27269
|
4
|
5
|
4
|
24
|
0
|
0
|
refs/heads/feature/device-online-stats-web
|
1
|
{"Commits":[{"Sha1":"6efac8091 {"Commits":[{"Sha1":"6efac809112f6384dd2bf6bc47372d72db0ddc2a","Message":"feat: 新增设备上线分布 Web 报表页面\n\n按省市统计设备月度新增上线数量，支持下钻查看城市分布。\n对接 DeviceOnlineStats 接口（Issue #5）。\n\nCo-Authored-By: Claude Sonnet 4.6 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T15:17:51+08:00"},{"Sha1":"145ff9f2f3159ae6a2961ea2209ec639ab80088e","Message":"fix: 修正 month 参数范围校验并排除未绑定门店设备的脏分组\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T14:28:55+08:00"},{"Sha1":"5990a2bca428127e7e794270ba4da5076c88eb66","Message":"test: 新增设备上线分布接口冒烟测试\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T13:21:08+08:00"},{"Sha1":"7f8c720e8682c559695891203ce844e572c3cc15","Message":"feat: 新增 DeviceOnlineStats 控制器，暴露省份/城市统计接口\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T13:21:07+08:00"},{"Sha1":"df0962ec7d027fa24ba0e26eb2d783d386c89e80","Message":"feat: 新增设备上线分布省份汇总/城市下钻查询\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T13:21:06+08:00"}],"HeadCommit":{"Sha1":"6efac809112f6384dd2bf6bc47372d72db0ddc2a","Message":"feat: 新增设备上线分布 Web 报表页面\n\n按省市统计设备月度新增上线数量，支持下钻查看城市分布。\n对接 DeviceOnlineStats 接口（Issue #5）。\n\nCo-Authored-By: Claude Sonnet 4.6 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-01T15:17:51+08:00"},"CompareURL":"laiqiaojie/admin/compare/99e13e892139a4da82e6ec38678974696b9da59f...6efac809112f6384dd2bf6bc47372d72db0ddc2a","Len":7}...
|
1788247080
|
Edit
Delete
|
|
29555
|
4
|
5
|
4
|
24
|
0
|
0
|
refs/heads/feature/device-online-stats-web
|
1
|
{"Commits":[{"Sha1":"de1d21cc9 {"Commits":[{"Sha1":"de1d21cc9cfda8d34fe7562f7329cf6f9a425a70","Message":"fix: 修复父菜单 url 为空时路由拼出双斜杠的问题\n\nmenuItemPath（menu.vue）和 secondMenu（index_content.vue）在父菜单\n_requester_url 为空时，拼接路由生成 //child，导致 Vue Router 无法匹配。\n改为空串时跳过 prefix，确保路由始终为 /child 格式。\n\nCo-Authored-By: Claude Sonnet 4.6 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-14T17:09:35+08:00"}],"HeadCommit":{"Sha1":"de1d21cc9cfda8d34fe7562f7329cf6f9a425a70","Message":"fix: 修复父菜单 url 为空时路由拼出双斜杠的问题\n\nmenuItemPath（menu.vue）和 secondMenu（index_content.vue）在父菜单\n_requester_url 为空时，拼接路由生成 //child，导致 Vue Router 无法匹配。\n改为空串时跳过 prefix，确保路由始终为 /child 格式。\n\nCo-Authored-By: Claude Sonnet 4.6 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"dqdy1517@gmail.com","AuthorName":"laiqiaojie","CommitterEmail":"dqdy1517@gmail.com","CommitterName":"laiqiaojie","Timestamp":"2026-09-14T17:09:35+08:00"},"CompareURL":"laiqiaojie/admin/compare/6efac809112f6384dd2bf6bc47372d72db0ddc2a...de1d21cc9cfda8d34fe7562f7329cf6f9a425a70","Len":1}...
|
1789377001
|
Edit
Delete
|
|
28466
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feature/web-playwright-e2e
|
0
|
|
1788881832
|
Edit
Delete
|
|
28467
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/feature/web-playwright-e2e
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"277e16585374bda952ebbc5f98f28b24e856ad76","Message":"docs(governance): record web Playwright e2e suite\n\nLog the scope, test discipline, verification runs (fresh self-managed\nstacks in dev and production-build mode, rebased onto main) and the\nremaining gaps of the new apps/web Playwright suite. Heavy-gate rows stay\n⚠️ 待复验 as already marked on main; no readiness claim is added.\n\nCo-Authored-By: Claude Fable 5.1 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-08T08:35:25-07:00"},"CompareURL":"luoanwu/image-generation/compare/main...277e16585374bda952ebbc5f98f28b24e856ad76","Len":0}...
|
1788881832
|
Edit
Delete
|
|
29936
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/fix/activity-filter-pagination-20260908
|
0
|
|
1789445298
|
Edit
Delete
|
|
29937
|
5
|
5
|
5
|
57
|
0
|
0
|
refs/heads/fix/activity-filter-pagination-20260908
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"c1a4fd73884e65bb050f92ca7454c7ca8d242719","Message":"fix(production): page activity filters on server\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-08T08:32:27-07:00"},"CompareURL":"luoanwu/image-generation/compare/main...c1a4fd73884e65bb050f92ca7454c7ca8d242719","Len":0}...
|
1789445298
|
Edit
Delete
|
|
39079
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/fix/c01-manifest-review-20261018
|
0
|
|
1792327769
|
Edit
Delete
|
|
39080
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/fix/c01-manifest-review-20261018
|
0
|
{"Commits":[{"Sha1":"2a72a0b99 {"Commits":[{"Sha1":"2a72a0b99ff0fcb66cc7555163259892a17f23d6","Message":"docs(registry): bind clean C01 verification and merge approval evidence\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-10-18T05:48:58-07:00"},{"Sha1":"235b31ead3b2439b399523e1949c3cac31a5e620","Message":"chore(registry): align review comments with domain vocabulary\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-10-18T05:43:34-07:00"},{"Sha1":"c3675d77ce67ecc3cc2ea0c78682a5fa74d136dc","Message":"docs(registry): track native Owner proof and preserve first assertions\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-10-18T05:42:14-07:00"},{"Sha1":"b6466220ce45fa10238d30552c0e450f7e228549","Message":"fix(registry): prepare and verify digest-bound reviews for fixed candidates\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-10-18T05:41:49-07:00"}],"HeadCommit":{"Sha1":"2a72a0b99ff0fcb66cc7555163259892a17f23d6","Message":"docs(registry): bind clean C01 verification and merge approval evidence\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-10-18T05:48:58-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/b863313825b3a26748d4446a3521c518e7bc8a6a...2a72a0b99ff0fcb66cc7555163259892a17f23d6","Len":4}...
|
1792327769
|
Edit
Delete
|
|
40036
|
5
|
17
|
5
|
76
|
0
|
0
|
refs/heads/fix/c01-manifest-review-20261018
|
0
|
|
1792550377
|
Edit
Delete
|
|
33004
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/fix/c19-e2e-tenant-20260926
|
0
|
|
1790464765
|
Edit
Delete
|
|
33005
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/fix/c19-e2e-tenant-20260926
|
0
|
{"Commits":[{"Sha1":"d7c7cd6e7 {"Commits":[{"Sha1":"d7c7cd6e7d0f2f5c74b5f851fe0e93f2e4daf445","Message":"feat(integration): 平台 dev 环境验收准备——C19 联调用例租户可配、dev E1 操作单、接缝台账记 dev 阻塞\n\n用户选定控制面接入 E0 → E1、先做不依赖管理员登录的部分（2026-09-26）。\n\n- llm.usage-export.platform-e2e（两后端）：企业 IdP 签发的 tenant_id 是随机 ten_…，用例写死\n tenant-c19-e2e-*，只能对假 token 的本地平台跑通。改为可用 C19_PLATFORM_E2E_TENANT_NESTJS / _FASTIFY\n 覆盖（两后端各自一个，平台读回按租户汇总），默认值不变；无平台变量时仍整组 skip（两后端各 1 skipped 实测）。\n 头注释把 azp 订正为 client_id（srv_…）并写明所需权限。\n- docs/operations/platform-dev-e1-usage-export-2026-09-26.md：dev E1 操作单——实测前提（dev 来源登记\n appId=os-usage-exporter 永远对不上 srv_ client_id；服务身份管理要人类租户管理员 token；Catalog 无 E1 枚举）、\n 登记 / 授权 / 权限 / dev env 修正、正反向验收与证据登记步骤。第 1 步须人登录，Claude 不代输密码。\n- governance/platform-integration.json：llm-usage-export 与 control-plane-mcp 的 openItems 写明 dev 阻塞\n （09-24 MCP 验收是宿主机独立进程，不在 dev 部署内）。check:app-manifest 通过。\n\ndocs-truth:assert / governance-docs / operations / naming / dual-backend / lint 通过。快照锚点前移。\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-26T16:18:19-07:00"}],"HeadCommit":{"Sha1":"d7c7cd6e7d0f2f5c74b5f851fe0e93f2e4daf445","Message":"feat(integration): 平台 dev 环境验收准备——C19 联调用例租户可配、dev E1 操作单、接缝台账记 dev 阻塞\n\n用户选定控制面接入 E0 → E1、先做不依赖管理员登录的部分（2026-09-26）。\n\n- llm.usage-export.platform-e2e（两后端）：企业 IdP 签发的 tenant_id 是随机 ten_…，用例写死\n tenant-c19-e2e-*，只能对假 token 的本地平台跑通。改为可用 C19_PLATFORM_E2E_TENANT_NESTJS / _FASTIFY\n 覆盖（两后端各自一个，平台读回按租户汇总），默认值不变；无平台变量时仍整组 skip（两后端各 1 skipped 实测）。\n 头注释把 azp 订正为 client_id（srv_…）并写明所需权限。\n- docs/operations/platform-dev-e1-usage-export-2026-09-26.md：dev E1 操作单——实测前提（dev 来源登记\n appId=os-usage-exporter 永远对不上 srv_ client_id；服务身份管理要人类租户管理员 token；Catalog 无 E1 枚举）、\n 登记 / 授权 / 权限 / dev env 修正、正反向验收与证据登记步骤。第 1 步须人登录，Claude 不代输密码。\n- governance/platform-integration.json：llm-usage-export 与 control-plane-mcp 的 openItems 写明 dev 阻塞\n （09-24 MCP 验收是宿主机独立进程，不在 dev 部署内）。check:app-manifest 通过。\n\ndocs-truth:assert / governance-docs / operations / naming / dual-backend / lint 通过。快照锚点前移。\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-26T16:18:19-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/ba2eb4b48ece4515f3e5ed5cd01b4988ef9476f0...d7c7cd6e7d0f2f5c74b5f851fe0e93f2e4daf445","Len":1}...
|
1790464765
|
Edit
Delete
|
|
33007
|
5
|
17
|
5
|
76
|
0
|
0
|
refs/heads/fix/c19-e2e-tenant-20260926
|
0
|
|
1790465192
|
Edit
Delete
|
|
32697
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/fix/colon-route-escape
|
0
|
|
1790167777
|
Edit
Delete
|
|
32698
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/fix/colon-route-escape
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"845429ae4583b761cb2a8a123014cc2b33656def","Message":"chore(reports): 根链静态门禁与 runtime 各环回绑 @ a8d261f6\n\na8d261f6（冒号路由转义）后在干净 worktree 重跑根 pnpm check 各环，回绑通过的报告（仅 provenance 变化）；\npermission-catalog 顺带在干净树上重生成，替掉 eb6e4c6 那份脏绑。\n\n未回绑、原因不在本提交：\n- runtime check:naming / check:governance（namingViolations 0 → 8）：a2228779 feat(mcp) 在 apps/mcp 引入\n 禁用词 business / reservation；naming / governance / governance-status / runtime-governance 四份报告不回绑。\n- catalog:drift 与 contracts governance-linter「retired entries…」一例：按主检出解析 Catalog 证据路径，\n 主检出里并行会话已暂存删除 configuration-snapshot-api.v1.openapi.json。\n- check:evidence：workbench-catalog-snapshot 过期（作用域变更来自上游）；runtime-governance 待 naming 修好后重跑。\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-23T05:49:07-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/main...845429ae4583b761cb2a8a123014cc2b33656def","Len":0}...
|
1790167777
|
Edit
Delete
|
|
32704
|
5
|
5
|
5
|
116
|
0
|
0
|
refs/heads/fix/colon-route-escape
|
0
|
{"Commits":[{"Sha1":"3537755f5 {"Commits":[{"Sha1":"3537755f50c139939dad21dbda29f613301811c8","Message":"merge: mcp 命名禁用词清零（0a2c1a7d）与 runtime-governance 回绑并入主线\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-23T06:19:36-07:00"},{"Sha1":"acead17bea1bf52a09f798db8083c6baf30454df","Message":"chore(reports): runtime-governance / naming / governance 与根链各环回绑 @ 0a2c1a7d\n\nmcp 禁用词清零后在干净 worktree 重跑根 pnpm check 各环：runtime check 全绿，namingViolations 回到 0；\nruntime-governance 不再过期。\n\n未回绑：catalog:drift（及 contracts governance-linter「retired entries…」一例）——按主检出解析 Catalog 证据路径，\n主检出里并行会话已暂存删除 configuration-snapshot-api.v1.openapi.json，与本提交无关。\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-23T06:19:07-07:00"},{"Sha1":"0a2c1a7d2a5a8447e8eebe42cbefcfe8a63c2e27","Message":"fix(mcp): 清掉 a2228779 引入的业务词典禁用词，命名门禁回到 0\n\na2228779 在 apps/mcp 留下 8 处禁用词（business ×6、reservation ×3 行），runtime check:naming 红、\ncheck:governance 的 namingViolations 从 0 回退到 8。\n\n- 这里的 business 指「业务验收」而非商家，按词典换 merchant 会改错语义；改为直接指向契约字段：\n 「acceptance (businessAccepted)」。字段名 businessAccepted 属工具契约，不改。\n- http.test.ts 占端口用的临时 server 由 reservation 改名 portProbe。\n- 工具描述 / instructions 属工具契约，重生成 tool-contracts.json（sha256 430f3e80… → e382077e…）。\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-23T06:17:43-07:00"},{"Sha1":"1936407f26beb26d795bb4568167790f6eca238c","Message":"chore(reports): 证据新鲜度回绑 @ 959309f3\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-23T06:05:24-07:00"},{"Sha1":"959309f3c24aff2fd7976fbb223480abe4deb1d3","Message":"chore(reports): 工作台快照回绑 @ 91f5d18d\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-23T06:05:18-07:00"}],"HeadCommit":{"Sha1":"3537755f50c139939dad21dbda29f613301811c8","Message":"merge: mcp 命名禁用词清零（0a2c1a7d）与 runtime-governance 回绑并入主线\n\nCo-Authored-By: Claude Opus 5.5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-23T06:19:36-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/845429ae4583b761cb2a8a123014cc2b33656def...3537755f50c139939dad21dbda29f613301811c8","Len":8}...
|
1790169584
|
Edit
Delete
|