|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
20282
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/solution-tier-multi-product
|
0
|
|
1785590611
|
Edit
Delete
|
|
20281
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/g24-list-pagination-and-options
|
0
|
{"Commits":[{"Sha1":"ccbb031fd {"Commits":[{"Sha1":"ccbb031fdb47bc913ed2b4ba270c0a49889eb88d","Message":"feat(g24): 列表分页 + 选择器 options 双读路径（contracts 单源/双后端对等/三层负向证据）\n\n- contracts 新增 pagination.ts 单源：Paginated\u003cT\u003e{items,page,pageSize,total}（total=租户全量）、\n paginationQuerySchema（默认 20/上限 100，越界 Zod 400 不静默 clamp）、toPrismaPage/makePaginated、\n OptionList\u003cT\u003e{items,truncated} + OPTION_LIST_LIMIT=200 + makeOptionList，\n 三个 Option 投影重建对象字面量做字段白名单（成本/底价结构性缺席；按选择器反推补 versionNo/taxRateBps）\n- 两后端对等：quotations/products/customers/sales-orders 四列表改 Paginated 信封；\n 新增 /products/options（只返在售）、/customers/options（联系人 id/name/mobile）、\n /fulfillment/contract-requests/options（只返 REQUESTED）；权限沿用列表同一 capability\n- 前端真实对接：9 个选择器站点切 options hook（key 挂既有根继承实时失效，\n sales_order.* 额外失效合同 options）；合同激活手填 UUID 换真实下拉；\n page.tsx contracts/products prop 下钻退役；4 列表接分页条；truncated 显式提示\n- 对抗性测试三层负向均实跑判红后恢复：contracts 投影透传红 / module-integration\n degrade-selector-to-paginated-list 注入红 / E2E 选择器退化红（第 9 条浏览器用例）；\n 顺带发现并修复 drop-fulfillment-realtime 注入被 payment 分支同字面量代码静默拔牙（replace→replaceAll）\n- 棘轮抬地板：testsPassed 265→279、uiTestsPassed 8→9、ownTests 17→18、ownTestCases 194→209\n- 回灌：CLAUDE.md 真源地图+动态区（G24 移入已关闭）、governance-experience 战役记录、\n owner-matrix 登记三个 options 读模型、api-standard 分页章节按裁决修正\n\n证据（本地工作区，2026-08-01）：pnpm check exit 0；check:runtime 279/0（PG:55432/juhai_quotation_g24_20260801）；\ncheck:ui 9/0（juhai_quotation_ui_g24_20260801）\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-01T05:57:57-07:00"}],"HeadCommit":{"Sha1":"ccbb031fdb47bc913ed2b4ba270c0a49889eb88d","Message":"feat(g24): 列表分页 + 选择器 options 双读路径（contracts 单源/双后端对等/三层负向证据）\n\n- contracts 新增 pagination.ts 单源：Paginated\u003cT\u003e{items,page,pageSize,total}（total=租户全量）、\n paginationQuerySchema（默认 20/上限 100，越界 Zod 400 不静默 clamp）、toPrismaPage/makePaginated、\n OptionList\u003cT\u003e{items,truncated} + OPTION_LIST_LIMIT=200 + makeOptionList，\n 三个 Option 投影重建对象字面量做字段白名单（成本/底价结构性缺席；按选择器反推补 versionNo/taxRateBps）\n- 两后端对等：quotations/products/customers/sales-orders 四列表改 Paginated 信封；\n 新增 /products/options（只返在售）、/customers/options（联系人 id/name/mobile）、\n /fulfillment/contract-requests/options（只返 REQUESTED）；权限沿用列表同一 capability\n- 前端真实对接：9 个选择器站点切 options hook（key 挂既有根继承实时失效，\n sales_order.* 额外失效合同 options）；合同激活手填 UUID 换真实下拉；\n page.tsx contracts/products prop 下钻退役；4 列表接分页条；truncated 显式提示\n- 对抗性测试三层负向均实跑判红后恢复：contracts 投影透传红 / module-integration\n degrade-selector-to-paginated-list 注入红 / E2E 选择器退化红（第 9 条浏览器用例）；\n 顺带发现并修复 drop-fulfillment-realtime 注入被 payment 分支同字面量代码静默拔牙（replace→replaceAll）\n- 棘轮抬地板：testsPassed 265→279、uiTestsPassed 8→9、ownTests 17→18、ownTestCases 194→209\n- 回灌：CLAUDE.md 真源地图+动态区（G24 移入已关闭）、governance-experience 战役记录、\n owner-matrix 登记三个 options 读模型、api-standard 分页章节按裁决修正\n\n证据（本地工作区，2026-08-01）：pnpm check exit 0；check:runtime 279/0（PG:55432/juhai_quotation_g24_20260801）；\ncheck:ui 9/0（juhai_quotation_ui_g24_20260801）\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-01T05:57:57-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/8fe17cd57002bf1ed691e63a80c71db5c03d0f5f...ccbb031fdb47bc913ed2b4ba270c0a49889eb88d","Len":1}...
|
1785589103
|
Edit
Delete
|
|
20280
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/g24-list-pagination-and-options
|
0
|
|
1785589103
|
Edit
Delete
|
|
20279
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/chore/governance-ghost-assets-and-readm refs/heads/chore/governance-ghost-assets-and-readmodel...
|
0
|
{"Commits":[{"Sha1":"8fe17cd57 {"Commits":[{"Sha1":"8fe17cd57002bf1ed691e63a80c71db5c03d0f5f","Message":"feat(solutions): 项目名称默认取客户名称 + 经营目标/目标客群/硬性约束标签化\n\n本轮直接改动（客户方案域）：\n\n- 建项表单选定客户后默认预填客户名称，且**只覆盖上一次自动填入的值**——用户手改过\n 就彻底交还给他，换客户也不再动它。仍是纯 UI 预填：name 在 contracts 里照旧 min(1)\n 必填，后端不替任何调用方脑补名称。\n- 经营目标、目标客群、硬性约束统一改为标签（chips）录入，候选从本租户已有方案现算、\n 按频次排序，不建标签字典表（用户裁决：只做到「表单内标签输入 + 历史候选」这一层；\n 租户级标签库是独立主数据对象，要走 owner-matrix 登记与完整模块流程）。\n- 标签归一（去空白 → 拒空串 → 去重保序）提为 contracts 单源 tagListSchema，读取侧\n 归一为 normalizeTagList。只在前端 chips 去重挡不住 curl（[\"A\",\"A \"] 就能撑破上限、\n 读模型里并排出现两个肉眼一样的标签，C26 同一条教训），两后端各补一条读回断言，\n 证明规则真在服务端生效。\n- targetSegment 由单值 VARCHAR(500) 迁为 Json 标签数组，迁移\n 20260731090000_solution_target_segment_tags（两后端同份）：就地\n ALTER ... TYPE ... USING，空串→[]、非空单值→单元素数组；**刻意不按分隔符拆**——\n 存量是自由文本，猜标签边界会造出谁也没确认过的半句话标签。转换语义已在真实\n PostgreSQL 上用 legacy 值单独验证。\n- 发布闸门判空由 .trim() 改为经 normalizeTagList 后 length===0，并同步\n check:role-permissions 的绊网正则；normalizeTagList 同时兜住迁移前写下的冻结快照\n （公开页读的就是快照，按定义不可回填）。\n- 定位确认凭证比对标签改用集合语义 sameTagSet：纯拖动排序不改变复核人确认过的那组\n 客群，按数组逐位比对会把已确认误判成 POSITIONING_STALE，逼销售重走复核。\n- E2E 首跑抓到一个真问题：标签成签会让输入框长高一行、提交按钮随之下移，mousedown\n 与 mouseup 落到不同元素上，那一下点击被浏览器吞掉。测试改为显式 Tab 失焦，并保留\n 「只失焦不回车也不丢标签」这条断言（失焦即成签，避免静默丢数据）。\n\n⚠️ 共享工作区提交：提交时本仓有并行会话在途（收款域、报价对客策略与发送对话框、\n操作手册生成、队列隔离与设计令牌门禁、商品目录导入等），其改动一并进入本提交。\n无法按文件拆分——packages/contracts/src/solution.ts 同时含两边内容。\n\n验收（作用域＝本地工作区，提交时 dirty，不得外推为远端已验证）：\n- pnpm check 全绿（14 个静态门禁 + lint + typecheck）\n- pnpm check:runtime 267 用例 / 地板 265，{contracts:187, api-nestjs:40, api-fastify:40}\n- pnpm check:ui 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-01T00:21:22-07:00"},{"Sha1":"a79aa437569cad73ecee4ede960c6f80a88bf98d","Message":"docs: 记录 G24 分页形态裁决（方案①：列表分页 + 独立 options 接口）并说明本轮未落地的原因\n\n用户已裁决方案①，设计细节（Paginated/OptionList 契约形状、3 个 options 接口的字段\n及其反推依据）一并写入 G24，下一轮直接落地，不必重新讨论。\n\n本轮未落地的原因写明：这是会改变 4 个接口响应形状的跨层迁移，而同一 checkout 上\n有并行会话正在开发收款域——改到一半的跨层 API 迁移留在共享工作区会直接卡住对方，\n因此整体回退、只留裁决结论。\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-31T08:15:46-07:00"},{"Sha1":"cafbd90f352d9fae794c4cae88c8435d84ebf132","Message":"feat(overview): 关闭 C27——把总览 KPI 从浏览器搬到服务端聚合 owner\n\n问题不在今天，在加分页那天\n总览 6 个指标全部在 MobileOverview.tsx 里对 GET /api/quotations 的全量返回 reduce，\n且「什么算已提交/已通过/已确认」「主报价金额怎么取」只以三个本地 Set + 一个函数的形式\n存在于这一个前端组件里。当前列表无分页，所以指标确实是对的——但它的正确性依赖\n一个没人承诺过的前提。只要给列表加分页或后端加截断，指标会静默退化成「当前页的统计」，\n页面还印着「全部来自当前租户」，没有任何测试会红。\n\n修法：把「谁决定聚合范围」搬回拥有数据的那一层\n- contracts 出单源：QUOTATION_{SUBMITTED,APPROVED,CONFIRMED,WAITING_CUSTOMER}_STATES\n + summarizeQuotations + countQuotationStates\n- 两后端 GET /api/quotations/summary 只做窄投影取行，算账一律调那个纯函数；\n 采购侧 GET /api/fulfillment/purchase-orders/summary 用 groupBy 让数据库出计数\n- 前端只做展示与单位换算（分→元、小时→天）\n\n顺带买到 G17 的一小块：聚合逻辑放 contracts 而非两后端各写一遍，\n双后端行为对等在这条路径上是结构保证，不需要门禁，因为不存在两份实现。\n\n同轮下线两处假值\n- 写死的「你好，本地报价管理员」→ 按 contracts 角色显示，不编造用户姓名\n- 最近报价表每行恒为「当前团队」的「负责人」列 → 整列移除（Quotation 无归属人字段），\n 口径同「开票收款尚未建模」：宁可不显示，也不用假值占位；同步收窄 grid 列数\n\n证据\n- pnpm check exit=0\n- pnpm check:runtime：本轮净贡献 87 用例（地板 83→87、ownTestCases 93→95）\n 两后端各 1 条聚合验收：空集均值 0 而非 NaN／byState 覆盖状态全集／跨租户不参与／403 负例\n- pnpm check:ui：8/8 全绿\n\n未闭环并显式登记为 G24：列表本身仍无分页。分页形态是真岔路——这 4 个列表同时喂着\n展示列表和 15 个关联对象下拉，天真分页会让 C22 的「关联对象来自真实读模型选择」\n退化成「只能选到第一页」。三个候选方案已写入 G24，待裁决。\n\n注：本仓有并行会话正在开发收款域。本次提交按文件路径逐个对账，\nquotation.ts 用补丁级 hunk 过滤剔除了对方的 ROLE_PERMISSIONS 改动；\nreports/*.latest.json 因计数被对方未提交的测试污染，本轮不提交，只提交经独立核算的 baseline.json。\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-31T08:06:50-07:00"},{"Sha1":"ec76984fa40261041bf89feeb5d64680a77ad577","Message":"feat(products,customers): 补编辑入口并关闭 C26——partial 更新 schema 丢掉的价格不变量\n\n审计口径「后端有写接口、前端无入口」：PATCH /api/products/:id 与 /api/customers/:id 在\n两后端都已实现且写链治理齐全（权限 + 租户条件写 + 0 行 404 + outbox 同 tx），\n但前端全仓只有 solutions 用过 PATCH——商品和客户建完就再也改不了。\n\n动工前核契约，先发现一个必须先补的洞（C26）\n- 价格不变量「底价/成本价 ≤ 标准价」只写在 createProductSchema 的 superRefine 里；\n updateProductSchema = productBaseSchema.partial() 从 base 派生，PATCH 完全绕过它。\n- 长期不可达只因前端没有编辑入口——补 UI 会把它立刻变成可达。\n- 修法不是给 update schema 也加个 refine：PATCH 可能只带 minimumPriceCents，\n 单看请求体判不出来。拆两半：contracts 提单源 checkProductPriceInvariant；\n update schema 只判同一请求内同时出现的字段，两后端在 tx 内合并现有记录后调同一函数兜底。\n\n前端\n- products/customers 各补 update API + mutation hook + 内联编辑器。\n- 编辑表单刻意用 createProductSchema 校验（它带不变量），让前后端拦同一件事。\n- SKU 与商品类型不开放编辑：已被历史报价明细固化为不可变快照，事后改会让旧报价口径漂移。\n- useUpdateCustomer 一并失效 quotations 缓存：客户名是报价抬头来源，否则报价列表继续显示旧抬头。\n\n证据\n- pnpm check exit=0\n- pnpm check:runtime：85 用例（31/27/27），地板同步 83→85、ownTestCases 91→93\n 新增两后端各 1 条 HTTP 负例：单字段 PATCH→400、双字段 PATCH→400、失败后读回未变、合法 PATCH 写库\n- pnpm check:ui：8/8 全绿，新增编辑闭环与不变量提示断言\n\n过程中自伤两次并已修正（记入 C26）\n- 编辑用例改了共享商品 PRODUCT_NAME → 下游 3 条用例全挂；改用专用 EDIT_SKU 商品并在常量处写明禁令\n- 新增商品让报价下拉选项从 3 变 4 → 更新计数并注明构成，保留其「挡重复项/挡漏建」的作用\n- 顺带把 productLibrary.locator(\"form\") 收窄为 getByTestId(\"product-create-form\")（C16 同款规则）\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-31T07:48:35-07:00"},{"Sha1":"aed0147384ea12244797a17c46bfe98c4cdeb0a2","Message":"fix(governance): 关闭 C25——删除幽灵 UI 资产并给「文档点名的代码符号」上门禁\n\n审计「每个菜单的真实对接」时发现 OrdersPanel/UsersPanel 在整个 apps/web/src 里\n没有任何 import，且是 9 个 API helper 的唯一消费者——一整棵约 560 行的死子树。\n\n真正的问题不是死代码，是三份治理文档仍拿它们当活资产：\n- owner-matrix 把 User/Order/OrderEvent 的读模型消费方写成这两个面板（追不到可达 UI）；\n- CLAUDE.md C16 宣称的防线 getByTestId(\"users-panel\") 在 E2E 里早已不存在；\n- CLAUDE.md 的「apps/web 三面板样板」指向的布局已被 18 入口工作台取代。\n既有门禁交集恰好为空：typecheck 不报未使用导出；check:docs-truth 的幽灵资产断言\n管的是「文档给示例但文件不存在」（这里正相反）；check:module-integration 只扫菜单内条目。\n\n处置（用户裁决：删除而非挂回 ADMIN 入口）\n- 删 OrdersPanel/UsersPanel + 9 个仅供其消费的 helper + 0 引用且注释失真的 api 泛型对象\n + 0 引用的 USD 版 formatCentsToCurrency；\n- /api/users、/api/orders、/api/jobs 后端与双后端 HTTP/DB 测试一律不动，只是不再有 UI 路径；\n- owner-matrix 三行改「无 UI 消费方」并加登记规则 5；C16 行改「规则仍生效、原实例已下线」；\n 「三面板样板」更正为现网 shell 结构；quotation-blueprint 两处同步；经验库补 C25 完整叙事。\n\n新增/重锚两处门禁（均已负向测试）\n- check:module-integration 加 owner-matrix-consumer-*：文档点名的组件必须在 apps/web 真实可达。\n 负向证据：真实磁盘造一个无人 import 的 ZombiePanel 并被点名 → 红；\n 摘掉 EventFeed 唯一 import → 红（证明正向路径不是空跑，Outbox 行确实在被断言）。\n- check:contract-consumers 的前端半边原本三条断言全锚在 OrdersPanel 上——即长期在守一个\n 没人走的路口。重锚到报价/商品/履约三个真实工作台，并从「好模式存在」改为「坏模式不存在」：\n 原断言局部改坏 1/3 处不会红（实测），新 reject 改坏一处即红（实测）。\n\n证据：pnpm check exit=0（本地工作区，7f1be32 基线同样 exit=0）\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-31T07:32:18-07:00"}],"HeadCommit":{"Sha1":"8fe17cd57002bf1ed691e63a80c71db5c03d0f5f","Message":"feat(solutions): 项目名称默认取客户名称 + 经营目标/目标客群/硬性约束标签化\n\n本轮直接改动（客户方案域）：\n\n- 建项表单选定客户后默认预填客户名称，且**只覆盖上一次自动填入的值**——用户手改过\n 就彻底交还给他，换客户也不再动它。仍是纯 UI 预填：name 在 contracts 里照旧 min(1)\n 必填，后端不替任何调用方脑补名称。\n- 经营目标、目标客群、硬性约束统一改为标签（chips）录入，候选从本租户已有方案现算、\n 按频次排序，不建标签字典表（用户裁决：只做到「表单内标签输入 + 历史候选」这一层；\n 租户级标签库是独立主数据对象，要走 owner-matrix 登记与完整模块流程）。\n- 标签归一（去空白 → 拒空串 → 去重保序）提为 contracts 单源 tagListSchema，读取侧\n 归一为 normalizeTagList。只在前端 chips 去重挡不住 curl（[\"A\",\"A \"] 就能撑破上限、\n 读模型里并排出现两个肉眼一样的标签，C26 同一条教训），两后端各补一条读回断言，\n 证明规则真在服务端生效。\n- targetSegment 由单值 VARCHAR(500) 迁为 Json 标签数组，迁移\n 20260731090000_solution_target_segment_tags（两后端同份）：就地\n ALTER ... TYPE ... USING，空串→[]、非空单值→单元素数组；**刻意不按分隔符拆**——\n 存量是自由文本，猜标签边界会造出谁也没确认过的半句话标签。转换语义已在真实\n PostgreSQL 上用 legacy 值单独验证。\n- 发布闸门判空由 .trim() 改为经 normalizeTagList 后 length===0，并同步\n check:role-permissions 的绊网正则；normalizeTagList 同时兜住迁移前写下的冻结快照\n （公开页读的就是快照，按定义不可回填）。\n- 定位确认凭证比对标签改用集合语义 sameTagSet：纯拖动排序不改变复核人确认过的那组\n 客群，按数组逐位比对会把已确认误判成 POSITIONING_STALE，逼销售重走复核。\n- E2E 首跑抓到一个真问题：标签成签会让输入框长高一行、提交按钮随之下移，mousedown\n 与 mouseup 落到不同元素上，那一下点击被浏览器吞掉。测试改为显式 Tab 失焦，并保留\n 「只失焦不回车也不丢标签」这条断言（失焦即成签，避免静默丢数据）。\n\n⚠️ 共享工作区提交：提交时本仓有并行会话在途（收款域、报价对客策略与发送对话框、\n操作手册生成、队列隔离与设计令牌门禁、商品目录导入等），其改动一并进入本提交。\n无法按文件拆分——packages/contracts/src/solution.ts 同时含两边内容。\n\n验收（作用域＝本地工作区，提交时 dirty，不得外推为远端已验证）：\n- pnpm check 全绿（14 个静态门禁 + lint + typecheck）\n- pnpm check:runtime 267 用例 / 地板 265，{contracts:187, api-nestjs:40, api-fastify:40}\n- pnpm check:ui 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-01T00:21:22-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/9618d78da3e668f14e3c1611d7090f45eef0c085...8fe17cd57002bf1ed691e63a80c71db5c03d0f5f","Len":7}...
|
1785568903
|
Edit
Delete
|
|
20278
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/chore/governance-ghost-assets-and-readm refs/heads/chore/governance-ghost-assets-and-readmodel...
|
0
|
|
1785568903
|
Edit
Delete
|
|
20277
|
5
|
17
|
5
|
72
|
0
|
0
|
refs/heads/chore/gate-negative-proof
|
0
|
|
1785507542
|
Edit
Delete
|
|
20276
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/do-not-merge/gate-negative-proof
|
0
|
{"Commits":[],"HeadCommit":{"S {"Commits":[],"HeadCommit":{"Sha1":"ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Message":"test(negative): 受控失败——删除一个测试文件以验证远端门禁真会阻断\n\nG14 关闭条件的最后一项：证明违规确实被 CI + 分支保护阻断，而不是\n「门禁存在但从没拦住过任何东西」（假绿五形态第 5 形态：假生效门禁）。\n\n刻意注入的违规：删除 apps/api-fastify/test/outbox.deadletter.test.ts。\n预期 ownTests 从 11 掉到 10，低于 reports/baseline.json 的地板 11，\nstatic job 的 check:governance 棘轮应判红；runtime job 因 needs 依赖不会启动。\n\n预期结果：PR 无法合并（required checks: Static governance +\nRuntime and UI acceptance，enforce_admins=true）。\n验证完毕后本 PR 直接关闭，绝不合并。\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-07-31T06:49:50-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/main...ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Len":0}...
|
1785507509
|
Edit
Delete
|
|
20275
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/do-not-merge/gate-negative-proof
|
0
|
|
1785507509
|
Edit
Delete
|
|
20274
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/chore/gate-negative-proof
|
0
|
{"Commits":[{"Sha1":"ec4bf7fde {"Commits":[{"Sha1":"ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Message":"test(negative): 受控失败——删除一个测试文件以验证远端门禁真会阻断\n\nG14 关闭条件的最后一项：证明违规确实被 CI + 分支保护阻断，而不是\n「门禁存在但从没拦住过任何东西」（假绿五形态第 5 形态：假生效门禁）。\n\n刻意注入的违规：删除 apps/api-fastify/test/outbox.deadletter.test.ts。\n预期 ownTests 从 11 掉到 10，低于 reports/baseline.json 的地板 11，\nstatic job 的 check:governance 棘轮应判红；runtime job 因 needs 依赖不会启动。\n\n预期结果：PR 无法合并（required checks: Static governance +\nRuntime and UI acceptance，enforce_admins=true）。\n验证完毕后本 PR 直接关闭，绝不合并。\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-07-31T06:49:50-07:00"}],"HeadCommit":{"Sha1":"ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Message":"test(negative): 受控失败——删除一个测试文件以验证远端门禁真会阻断\n\nG14 关闭条件的最后一项：证明违规确实被 CI + 分支保护阻断，而不是\n「门禁存在但从没拦住过任何东西」（假绿五形态第 5 形态：假生效门禁）。\n\n刻意注入的违规：删除 apps/api-fastify/test/outbox.deadletter.test.ts。\n预期 ownTests 从 11 掉到 10，低于 reports/baseline.json 的地板 11，\nstatic job 的 check:governance 棘轮应判红；runtime job 因 needs 依赖不会启动。\n\n预期结果：PR 无法合并（required checks: Static governance +\nRuntime and UI acceptance，enforce_admins=true）。\n验证完毕后本 PR 直接关闭，绝不合并。\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-07-31T06:49:50-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/9618d78da3e668f14e3c1611d7090f45eef0c085...ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Len":1}...
|
1785507322
|
Edit
Delete
|
|
20273
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/chore/gate-negative-proof
|
0
|
|
1785507322
|
Edit
Delete
|
|
20272
|
5
|
17
|
5
|
72
|
0
|
0
|
refs/heads/fix/contracts-build-chain-and-review-pa refs/heads/fix/contracts-build-chain-and-review-panel...
|
0
|
|
1785507126
|
Edit
Delete
|
|
20271
|
5
|
17
|
5
|
72
|
0
|
0
|
refs/heads/docs/ci-green-on-main
|
0
|
|
1785507095
|
Edit
Delete
|
|
20270
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/docs/ci-green-on-main
|
0
|
{"Commits":[{"Sha1":"ec4bf7fde {"Commits":[{"Sha1":"ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Message":"test(negative): 受控失败——删除一个测试文件以验证远端门禁真会阻断\n\nG14 关闭条件的最后一项：证明违规确实被 CI + 分支保护阻断，而不是\n「门禁存在但从没拦住过任何东西」（假绿五形态第 5 形态：假生效门禁）。\n\n刻意注入的违规：删除 apps/api-fastify/test/outbox.deadletter.test.ts。\n预期 ownTests 从 11 掉到 10，低于 reports/baseline.json 的地板 11，\nstatic job 的 check:governance 棘轮应判红；runtime job 因 needs 依赖不会启动。\n\n预期结果：PR 无法合并（required checks: Static governance +\nRuntime and UI acceptance，enforce_admins=true）。\n验证完毕后本 PR 直接关闭，绝不合并。\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-07-31T06:49:50-07:00"}],"HeadCommit":{"Sha1":"ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Message":"test(negative): 受控失败——删除一个测试文件以验证远端门禁真会阻断\n\nG14 关闭条件的最后一项：证明违规确实被 CI + 分支保护阻断，而不是\n「门禁存在但从没拦住过任何东西」（假绿五形态第 5 形态：假生效门禁）。\n\n刻意注入的违规：删除 apps/api-fastify/test/outbox.deadletter.test.ts。\n预期 ownTests 从 11 掉到 10，低于 reports/baseline.json 的地板 11，\nstatic job 的 check:governance 棘轮应判红；runtime job 因 needs 依赖不会启动。\n\n预期结果：PR 无法合并（required checks: Static governance +\nRuntime and UI acceptance，enforce_admins=true）。\n验证完毕后本 PR 直接关闭，绝不合并。\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-07-31T06:49:50-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/9618d78da3e668f14e3c1611d7090f45eef0c085...ec4bf7fdec43629ca034c3b16fa6fd8b3b456286","Len":1}...
|
1785506104
|
Edit
Delete
|
|
20269
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/docs/ci-green-on-main
|
0
|
|
1785506104
|
Edit
Delete
|
|
20268
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"9618d78da {"Commits":[{"Sha1":"9618d78da3e668f14e3c1611d7090f45eef0c085","Message":"Merge pull request #1: 打通契约构建链、补齐方案复核依据，并按真实 CI 证据更正治理记录\n\nfix: 打通契约构建链、补齐方案复核依据，并按真实 CI 证据更正治理记录","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-07-31T06:46:17-07:00"},{"Sha1":"de7d09aee2a89208f006bc3ca829f289619a64b7","Message":"docs: 记录首份远端 CI 绿盘证据（PR #1 / run 30634897066）\n\nGitHub run 30634897066（PR #1，head 0d85a3d）两 job 全绿：\nstatic ✅；runtime 83 用例（contracts 31 / nestjs 26 / fastify 26）、\nUI 8 用例，与本地逐项一致，耗时 3m21s。这是本仓第一份远端绿盘证据。\n\n对照上一次 run 30603461723（push main fdf7b59）：runtime 失败于\ntests-floor「expected \u003e= 74, got 0」，整步仅 24s。\n\n刻意不把这次转绿归因到本轮任何一个提交：PR #1 含 7 个提交，除本轮 3 个外\n还有 4 个存量提交（283f1bf…7638e94），其中任一都可能是真正修好它的那个，\n且 7638e94 从未单独在 CI 上跑过。要归因需另构造对照 run。\n\nG14 仍 OPEN：绿盘只覆盖该 PR 分支，github main 最近一次 run 仍红；\n尚未用受控失败 PR 证明违规真被阻断，分支保护 / required checks 也未定位。\nci-gate 行同步改写，明确「不得宣称 PR 已被机器拦截」。\n\npnpm check ✅ 绿。\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-07-31T06:39:36-07:00"},{"Sha1":"0d85a3de6efbf4ca42ba1345bfbc66f9d1f9ac0d","Message":"docs: 按真实 CI 证据更正 C23 与 G14\n\n上一提交把一个未经正确验证的结论写进了治理真源，此处更正。\n\nC23 原文断言「全新 clone/CI 上 pnpm check 必红（contracts dist 不存在）」。\n该结论来自 `pnpm --filter \u003capp\u003e typecheck` 的负向测试，而它绕过 turbo；\nCI 实际走 `pnpm typecheck` → `turbo run typecheck`，而 turbo.json 的\ntypecheck/lint/test 均带 dependsOn ^build，contracts 会被自动构建。\nGitHub run 30603461723 的 static job 实际通过，证伪原结论。\nC23 仍然成立的部分：绕过 turbo 的调用路径（.claude/launch.json 直接\npnpm dev、check:ui 的 pnpm --filter build）确实会吃到陈旧 dist——本轮\n409 STALE_VERSION 即由此而来；clean 不删 tsconfig.tsbuildinfo 导致\nclean \u0026\u0026 build 空 emit 是独立真 bug。修复本身保留。\n\nG14 原记「尚无远端 CI 运行证据」已过时。实际已有 run 30603461723\n（push main fdf7b59，2026-07-31T04:10Z）：static ✅、runtime ❌\n`tests-floor: expected \u003e= 74, got 0`，整步仅 24s，真实 DB 测试没跑起来。\n地板断言拦住了这次「0 tests 假绿」，但根因未定位，需专项排查 CI 上\nturbo run test --force 为何产不出 vitest 报告。基线表 ci-gate 行同步\n改为「已有远端证据但为红盘」，仍 OPEN。\n\n另记：两个远端 main 不同步（origin 7638e94 / github fdf7b59），\nCI 只挂 github 侧，且只在 pull_request 或 push main 触发。\n\npnpm check ✅ 绿（含 check:governance-docs / check:docs-truth）。\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-07-31T06:30:18-07:00"},{"Sha1":"67849d6aad796878e6fd40b2e54307780b01442f","Message":"chore: 重跑三级门禁并绑定干净工作区证据\n\n上一提交的报告生成于 dirty 工作区（gitSha 指向父提交 7638e94、\nworktreeDirty=true），只能支撑「本地工作区通过」。此处在 a015400 的\n干净检出上重跑三级门禁，让三份 latest 报告的 provenance 统一绑定\n该提交且 worktreeDirty=false——可支撑「提交 a015400 在本机干净工作区\n通过三级门禁」。\n\npnpm check ✅ 5/5\npnpm check:runtime ✅ 83 用例 / 0 失败（PG:55432/juhai_quotation_runtime_20260731d + Redis:6382）\npnpm check:ui ✅ 8 用例 / 0 失败（PG:55432/juhai_quotation_ui_20260731d + Redis:6382）\n\n仍不得外推为远端已发布或 CI 已通过：本分支未推送，无远端 run 证据（G14）。\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-07-31T06:16:25-07:00"},{"Sha1":"a015400b8aa901246315eb213d20354d6ded3133","Message":"fix: 打通契约构建链并补齐方案复核依据\n\n本提交包含两批改动。工作区里它们已交织到同一行/同一 hunk\n（package.json 的 check 串、next.config.ts 的 output），无法拆开单独提交。\n\n── 批次 A：本轮定位并修复（Claude 作业）────────────────────────────\n\n契约包 src/dist 漂移（C23）——P1「运行时到底读哪一份」的隐藏变体：\ntypecheck 与 contracts 单测读 src，两后端运行时经 package main 读 dist。\n`pnpm --filter` 不走 turbo 的 dependsOn ^build，dist 又被 gitignore，\n于是门禁全绿而运行时按旧契约行为。实测症状：dist 缺 versionNo →\nZod 静默 strip → 技术复核恒返 409 STALE_VERSION。\n负向验证：移走 dist 后 typecheck 立刻 TS2307，证明全新 clone/CI 上必红。\n- package.json: check 前置 build:contracts\n- scripts/check-{runtime,ui}-acceptance.mjs: 各加 contracts 构建步骤\n- .claude/launch.json: 四个配置均前置 contracts 构建\n- packages/contracts/package.json: 补 prepare；clean 补删 tsconfig.tsbuildinfo\n （composite 下留着 buildinfo 会让 clean+build 空 emit）\n\n方案表单默认路径不可用（C24）：\n「使用客户主联系人」value 为空串，contactId 契约是 uuid().optional()，\n空串不过校验，导致默认状态下表单永不可提交，错误还被汇总成一句\n指不到联系人的话。register 处归一为 undefined。\n\n客户方案复核依据面板：\n技术复核/经理批准需在同一屏看到客户需求、空间与工区、平面图、逐档配置清单。\n清单只渲染规格字段，刻意不展开 product 以免带出 standardPriceCents\n（角色权限单源里技术角色不继承报价域敏感读取）。缺图纸显式标注但不阻断。\n补填资料入口接上此前零消费者的 useUpdateSolution + PATCH /solutions/:id，\n仅在 DRAFT/NEEDS_INFORMATION/REVISION_REQUIRED 开放——修复「目标客群留空\n的方案走到 APPROVED 后永远发布不了且无处补填」的死路。\n\n契约类型补齐：SolutionProduct 增补 product/surveySpace 嵌套（服务端一直下发，\n此前类型比载荷窄）。\n\nE2E 回归锁：新增专打默认联系人路径的用例，兼测复核依据面板与价格红线。\n负向验证：撤回 contactId 修复 → check:ui 报红；还原 → 8 用例全绿。\n\n附带：next.config.ts 的 output 重复定义（TS2783，本轮之前即存在，\n导致 pnpm check 红）改为三元计算，行为等价；check-vm-deploy 的 standalone\n绊网相应收窄为「字面量或该正确三元」，不放宽成 /output:.*standalone/\n（负向验证：三元写反即红）。\n\n── 批次 B：进入本轮前工作区已有的未提交改动（非本轮作业）──────────\n\nVM 部署强化（Dockerfile/compose/vm-deploy.sh/check-vm-deploy.mjs、restore/\ndrill/rollback）、移动端导航 MobileNav、客户方案域后端与验收测试、\n角色权限与模块对接门禁、方案蓝图与验收记录等。这批未经逐项复核，\n如需单独审阅可 `git reset --soft HEAD~1` 后重新拆分。\n\n── 证据（本地工作区，2026-07-31，工作区 dirty）──────────────────\npnpm check ✅ 5/5\npnpm check:runtime ✅ 83 用例 / 0 失败（地板 79→83）\npnpm check:ui ✅ 8 用例 / 0 失败（地板 7→8）\nownTestCases 地板 90→91。未推送、无远端 CI 运行证据（G14 仍 OPEN）。\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-07-31T06:13:59-07:00"}],"HeadCommit":{"Sha1":"9618d78da3e668f14e3c1611d7090f45eef0c085","Message":"Merge pull request #1: 打通契约构建链、补齐方案复核依据，并按真实 CI 证据更正治理记录\n\nfix: 打通契约构建链、补齐方案复核依据，并按真实 CI 证据更正治理记录","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-07-31T06:46:17-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/7638e946e8817308b94a23c028a18ac465c342c6...9618d78da3e668f14e3c1611d7090f45eef0c085","Len":5}...
|
1785505644
|
Edit
Delete
|
|
20267
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/fix/contracts-build-chain-and-review-pa refs/heads/fix/contracts-build-chain-and-review-panel...
|
0
|
{"Commits":[{"Sha1":"de7d09aee {"Commits":[{"Sha1":"de7d09aee2a89208f006bc3ca829f289619a64b7","Message":"docs: 记录首份远端 CI 绿盘证据（PR #1 / run 30634897066）\n\nGitHub run 30634897066（PR #1，head 0d85a3d）两 job 全绿：\nstatic ✅；runtime 83 用例（contracts 31 / nestjs 26 / fastify 26）、\nUI 8 用例，与本地逐项一致，耗时 3m21s。这是本仓第一份远端绿盘证据。\n\n对照上一次 run 30603461723（push main fdf7b59）：runtime 失败于\ntests-floor「expected \u003e= 74, got 0」，整步仅 24s。\n\n刻意不把这次转绿归因到本轮任何一个提交：PR #1 含 7 个提交，除本轮 3 个外\n还有 4 个存量提交（283f1bf…7638e94），其中任一都可能是真正修好它的那个，\n且 7638e94 从未单独在 CI 上跑过。要归因需另构造对照 run。\n\nG14 仍 OPEN：绿盘只覆盖该 PR 分支，github main 最近一次 run 仍红；\n尚未用受控失败 PR 证明违规真被阻断，分支保护 / required checks 也未定位。\nci-gate 行同步改写，明确「不得宣称 PR 已被机器拦截」。\n\npnpm check ✅ 绿。\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-07-31T06:39:36-07:00"}],"HeadCommit":{"Sha1":"de7d09aee2a89208f006bc3ca829f289619a64b7","Message":"docs: 记录首份远端 CI 绿盘证据（PR #1 / run 30634897066）\n\nGitHub run 30634897066（PR #1，head 0d85a3d）两 job 全绿：\nstatic ✅；runtime 83 用例（contracts 31 / nestjs 26 / fastify 26）、\nUI 8 用例，与本地逐项一致，耗时 3m21s。这是本仓第一份远端绿盘证据。\n\n对照上一次 run 30603461723（push main fdf7b59）：runtime 失败于\ntests-floor「expected \u003e= 74, got 0」，整步仅 24s。\n\n刻意不把这次转绿归因到本轮任何一个提交：PR #1 含 7 个提交，除本轮 3 个外\n还有 4 个存量提交（283f1bf…7638e94），其中任一都可能是真正修好它的那个，\n且 7638e94 从未单独在 CI 上跑过。要归因需另构造对照 run。\n\nG14 仍 OPEN：绿盘只覆盖该 PR 分支，github main 最近一次 run 仍红；\n尚未用受控失败 PR 证明违规真被阻断，分支保护 / required checks 也未定位。\nci-gate 行同步改写，明确「不得宣称 PR 已被机器拦截」。\n\npnpm check ✅ 绿。\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-07-31T06:39:36-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/0d85a3de6efbf4ca42ba1345bfbc66f9d1f9ac0d...de7d09aee2a89208f006bc3ca829f289619a64b7","Len":1}...
|
1785505181
|
Edit
Delete
|
|
20266
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/fix/contracts-build-chain-and-review-pa refs/heads/fix/contracts-build-chain-and-review-panel...
|
0
|
{"Commits":[{"Sha1":"0d85a3de6 {"Commits":[{"Sha1":"0d85a3de6efbf4ca42ba1345bfbc66f9d1f9ac0d","Message":"docs: 按真实 CI 证据更正 C23 与 G14\n\n上一提交把一个未经正确验证的结论写进了治理真源，此处更正。\n\nC23 原文断言「全新 clone/CI 上 pnpm check 必红（contracts dist 不存在）」。\n该结论来自 `pnpm --filter \u003capp\u003e typecheck` 的负向测试，而它绕过 turbo；\nCI 实际走 `pnpm typecheck` → `turbo run typecheck`，而 turbo.json 的\ntypecheck/lint/test 均带 dependsOn ^build，contracts 会被自动构建。\nGitHub run 30603461723 的 static job 实际通过，证伪原结论。\nC23 仍然成立的部分：绕过 turbo 的调用路径（.claude/launch.json 直接\npnpm dev、check:ui 的 pnpm --filter build）确实会吃到陈旧 dist——本轮\n409 STALE_VERSION 即由此而来；clean 不删 tsconfig.tsbuildinfo 导致\nclean \u0026\u0026 build 空 emit 是独立真 bug。修复本身保留。\n\nG14 原记「尚无远端 CI 运行证据」已过时。实际已有 run 30603461723\n（push main fdf7b59，2026-07-31T04:10Z）：static ✅、runtime ❌\n`tests-floor: expected \u003e= 74, got 0`，整步仅 24s，真实 DB 测试没跑起来。\n地板断言拦住了这次「0 tests 假绿」，但根因未定位，需专项排查 CI 上\nturbo run test --force 为何产不出 vitest 报告。基线表 ci-gate 行同步\n改为「已有远端证据但为红盘」，仍 OPEN。\n\n另记：两个远端 main 不同步（origin 7638e94 / github fdf7b59），\nCI 只挂 github 侧，且只在 pull_request 或 push main 触发。\n\npnpm check ✅ 绿（含 check:governance-docs / check:docs-truth）。\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-07-31T06:30:18-07:00"}],"HeadCommit":{"Sha1":"0d85a3de6efbf4ca42ba1345bfbc66f9d1f9ac0d","Message":"docs: 按真实 CI 证据更正 C23 与 G14\n\n上一提交把一个未经正确验证的结论写进了治理真源，此处更正。\n\nC23 原文断言「全新 clone/CI 上 pnpm check 必红（contracts dist 不存在）」。\n该结论来自 `pnpm --filter \u003capp\u003e typecheck` 的负向测试，而它绕过 turbo；\nCI 实际走 `pnpm typecheck` → `turbo run typecheck`，而 turbo.json 的\ntypecheck/lint/test 均带 dependsOn ^build，contracts 会被自动构建。\nGitHub run 30603461723 的 static job 实际通过，证伪原结论。\nC23 仍然成立的部分：绕过 turbo 的调用路径（.claude/launch.json 直接\npnpm dev、check:ui 的 pnpm --filter build）确实会吃到陈旧 dist——本轮\n409 STALE_VERSION 即由此而来；clean 不删 tsconfig.tsbuildinfo 导致\nclean \u0026\u0026 build 空 emit 是独立真 bug。修复本身保留。\n\nG14 原记「尚无远端 CI 运行证据」已过时。实际已有 run 30603461723\n（push main fdf7b59，2026-07-31T04:10Z）：static ✅、runtime ❌\n`tests-floor: expected \u003e= 74, got 0`，整步仅 24s，真实 DB 测试没跑起来。\n地板断言拦住了这次「0 tests 假绿」，但根因未定位，需专项排查 CI 上\nturbo run test --force 为何产不出 vitest 报告。基线表 ci-gate 行同步\n改为「已有远端证据但为红盘」，仍 OPEN。\n\n另记：两个远端 main 不同步（origin 7638e94 / github fdf7b59），\nCI 只挂 github 侧，且只在 pull_request 或 push main 触发。\n\npnpm check ✅ 绿（含 check:governance-docs / check:docs-truth）。\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-07-31T06:30:18-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/67849d6aad796878e6fd40b2e54307780b01442f...0d85a3de6efbf4ca42ba1345bfbc66f9d1f9ac0d","Len":1}...
|
1785504640
|
Edit
Delete
|
|
20265
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/fix/contracts-build-chain-and-review-pa refs/heads/fix/contracts-build-chain-and-review-panel...
|
0
|
{"Commits":[{"Sha1":"67849d6aa {"Commits":[{"Sha1":"67849d6aad796878e6fd40b2e54307780b01442f","Message":"chore: 重跑三级门禁并绑定干净工作区证据\n\n上一提交的报告生成于 dirty 工作区（gitSha 指向父提交 7638e94、\nworktreeDirty=true），只能支撑「本地工作区通过」。此处在 a015400 的\n干净检出上重跑三级门禁，让三份 latest 报告的 provenance 统一绑定\n该提交且 worktreeDirty=false——可支撑「提交 a015400 在本机干净工作区\n通过三级门禁」。\n\npnpm check ✅ 5/5\npnpm check:runtime ✅ 83 用例 / 0 失败（PG:55432/juhai_quotation_runtime_20260731d + Redis:6382）\npnpm check:ui ✅ 8 用例 / 0 失败（PG:55432/juhai_quotation_ui_20260731d + Redis:6382）\n\n仍不得外推为远端已发布或 CI 已通过：本分支未推送，无远端 run 证据（G14）。\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-07-31T06:16:25-07:00"},{"Sha1":"a015400b8aa901246315eb213d20354d6ded3133","Message":"fix: 打通契约构建链并补齐方案复核依据\n\n本提交包含两批改动。工作区里它们已交织到同一行/同一 hunk\n（package.json 的 check 串、next.config.ts 的 output），无法拆开单独提交。\n\n── 批次 A：本轮定位并修复（Claude 作业）────────────────────────────\n\n契约包 src/dist 漂移（C23）——P1「运行时到底读哪一份」的隐藏变体：\ntypecheck 与 contracts 单测读 src，两后端运行时经 package main 读 dist。\n`pnpm --filter` 不走 turbo 的 dependsOn ^build，dist 又被 gitignore，\n于是门禁全绿而运行时按旧契约行为。实测症状：dist 缺 versionNo →\nZod 静默 strip → 技术复核恒返 409 STALE_VERSION。\n负向验证：移走 dist 后 typecheck 立刻 TS2307，证明全新 clone/CI 上必红。\n- package.json: check 前置 build:contracts\n- scripts/check-{runtime,ui}-acceptance.mjs: 各加 contracts 构建步骤\n- .claude/launch.json: 四个配置均前置 contracts 构建\n- packages/contracts/package.json: 补 prepare；clean 补删 tsconfig.tsbuildinfo\n （composite 下留着 buildinfo 会让 clean+build 空 emit）\n\n方案表单默认路径不可用（C24）：\n「使用客户主联系人」value 为空串，contactId 契约是 uuid().optional()，\n空串不过校验，导致默认状态下表单永不可提交，错误还被汇总成一句\n指不到联系人的话。register 处归一为 undefined。\n\n客户方案复核依据面板：\n技术复核/经理批准需在同一屏看到客户需求、空间与工区、平面图、逐档配置清单。\n清单只渲染规格字段，刻意不展开 product 以免带出 standardPriceCents\n（角色权限单源里技术角色不继承报价域敏感读取）。缺图纸显式标注但不阻断。\n补填资料入口接上此前零消费者的 useUpdateSolution + PATCH /solutions/:id，\n仅在 DRAFT/NEEDS_INFORMATION/REVISION_REQUIRED 开放——修复「目标客群留空\n的方案走到 APPROVED 后永远发布不了且无处补填」的死路。\n\n契约类型补齐：SolutionProduct 增补 product/surveySpace 嵌套（服务端一直下发，\n此前类型比载荷窄）。\n\nE2E 回归锁：新增专打默认联系人路径的用例，兼测复核依据面板与价格红线。\n负向验证：撤回 contactId 修复 → check:ui 报红；还原 → 8 用例全绿。\n\n附带：next.config.ts 的 output 重复定义（TS2783，本轮之前即存在，\n导致 pnpm check 红）改为三元计算，行为等价；check-vm-deploy 的 standalone\n绊网相应收窄为「字面量或该正确三元」，不放宽成 /output:.*standalone/\n（负向验证：三元写反即红）。\n\n── 批次 B：进入本轮前工作区已有的未提交改动（非本轮作业）──────────\n\nVM 部署强化（Dockerfile/compose/vm-deploy.sh/check-vm-deploy.mjs、restore/\ndrill/rollback）、移动端导航 MobileNav、客户方案域后端与验收测试、\n角色权限与模块对接门禁、方案蓝图与验收记录等。这批未经逐项复核，\n如需单独审阅可 `git reset --soft HEAD~1` 后重新拆分。\n\n── 证据（本地工作区，2026-07-31，工作区 dirty）──────────────────\npnpm check ✅ 5/5\npnpm check:runtime ✅ 83 用例 / 0 失败（地板 79→83）\npnpm check:ui ✅ 8 用例 / 0 失败（地板 7→8）\nownTestCases 地板 90→91。未推送、无远端 CI 运行证据（G14 仍 OPEN）。\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-07-31T06:13:59-07:00"}],"HeadCommit":{"Sha1":"67849d6aad796878e6fd40b2e54307780b01442f","Message":"chore: 重跑三级门禁并绑定干净工作区证据\n\n上一提交的报告生成于 dirty 工作区（gitSha 指向父提交 7638e94、\nworktreeDirty=true），只能支撑「本地工作区通过」。此处在 a015400 的\n干净检出上重跑三级门禁，让三份 latest 报告的 provenance 统一绑定\n该提交且 worktreeDirty=false——可支撑「提交 a015400 在本机干净工作区\n通过三级门禁」。\n\npnpm check ✅ 5/5\npnpm check:runtime ✅ 83 用例 / 0 失败（PG:55432/juhai_quotation_runtime_20260731d + Redis:6382）\npnpm check:ui ✅ 8 用例 / 0 失败（PG:55432/juhai_quotation_ui_20260731d + Redis:6382）\n\n仍不得外推为远端已发布或 CI 已通过：本分支未推送，无远端 run 证据（G14）。\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-07-31T06:16:25-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/7638e946e8817308b94a23c028a18ac465c342c6...67849d6aad796878e6fd40b2e54307780b01442f","Len":2}...
|
1785504181
|
Edit
Delete
|
|
20264
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/fix/contracts-build-chain-and-review-pa refs/heads/fix/contracts-build-chain-and-review-panel...
|
0
|
|
1785504180
|
Edit
Delete
|
|
20149
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"7638e946e {"Commits":[{"Sha1":"7638e946e8817308b94a23c028a18ac465c342c6","Message":"chore: refresh verified acceptance evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T22:30:59-07:00"},{"Sha1":"4d854d156ce4b4fb7791f427ced17f6fda6e4814","Message":"fix: keep UI acceptance workspace clean\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T22:29:46-07:00"},{"Sha1":"2cbed6d88071e721e4c854e79485efe61b780aa1","Message":"feat: ship customer solution design workflow\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T22:27:22-07:00"}],"HeadCommit":{"Sha1":"7638e946e8817308b94a23c028a18ac465c342c6","Message":"chore: refresh verified acceptance evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T22:30:59-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/283f1bfb6b2f049b0476abb92698db0539bc832f...7638e946e8817308b94a23c028a18ac465c342c6","Len":3}...
|
1785475887
|
Edit
Delete
|
|
20147
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"283f1bfb6 {"Commits":[{"Sha1":"283f1bfb6b2f049b0476abb92698db0539bc832f","Message":"feat: wire sales modules and adversarial governance\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T21:56:00-07:00"}],"HeadCommit":{"Sha1":"283f1bfb6b2f049b0476abb92698db0539bc832f","Message":"feat: wire sales modules and adversarial governance\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T21:56:00-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/fdf7b594e1d70ff3b5a54d51e55eeb4bb0262b7a...283f1bfb6b2f049b0476abb92698db0539bc832f","Len":1}...
|
1785473782
|
Edit
Delete
|
|
20145
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"fdf7b594e {"Commits":[{"Sha1":"fdf7b594e1d70ff3b5a54d51e55eeb4bb0262b7a","Message":"feat: ship quotation fulfillment and quote center parity\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T20:56:44-07:00"}],"HeadCommit":{"Sha1":"fdf7b594e1d70ff3b5a54d51e55eeb4bb0262b7a","Message":"feat: ship quotation fulfillment and quote center parity\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T20:56:44-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/bd4b413c9f284e33472f905c047eb4bbb99b2717...fdf7b594e1d70ff3b5a54d51e55eeb4bb0262b7a","Len":1}...
|
1785470839
|
Edit
Delete
|
|
20061
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"bd4b413c9 {"Commits":[{"Sha1":"bd4b413c9f284e33472f905c047eb4bbb99b2717","Message":"Document quotation module blueprint and refresh governance reports\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T13:04:36-07:00"}],"HeadCommit":{"Sha1":"bd4b413c9f284e33472f905c047eb4bbb99b2717","Message":"Document quotation module blueprint and refresh governance reports\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T13:04:36-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/aef43abd7ee47a8b0e3b245bafbbd4025dd15e34...bd4b413c9f284e33472f905c047eb4bbb99b2717","Len":1}...
|
1785441882
|
Edit
Delete
|
|
20060
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"aef43abd7 {"Commits":[{"Sha1":"aef43abd7ee47a8b0e3b245bafbbd4025dd15e34","Message":"docs: record initial Gitea publication\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T12:58:21-07:00"}],"HeadCommit":{"Sha1":"aef43abd7ee47a8b0e3b245bafbbd4025dd15e34","Message":"docs: record initial Gitea publication\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T12:58:21-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/5e1d3d6748f60f625f7cd20b8a5defc957497e81...aef43abd7ee47a8b0e3b245bafbbd4025dd15e34","Len":1}...
|
1785441505
|
Edit
Delete
|
|
20059
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"5e1d3d674 {"Commits":[{"Sha1":"5e1d3d6748f60f625f7cd20b8a5defc957497e81","Message":"chore: refresh quotation acceptance evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T12:53:13-07:00"},{"Sha1":"ce6add1f419d50f150baffe78acbc6adc81b0ea3","Message":"feat: implement quotation core workflow\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T12:52:01-07:00"},{"Sha1":"4285699248e5f7d702171ee66f7ea2d5e57a4aed","Message":"chore: refresh local acceptance reports\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T12:22:09-07:00"},{"Sha1":"37e3a10e3f530299526a984beacd597b13ab098a","Message":"chore: refresh migration evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:55:08-07:00"},{"Sha1":"e6336ca3f8154422a56269945d3f39343dd952fa","Message":"chore: migrate base framework\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:42:32-07:00"}],"HeadCommit":{"Sha1":"5e1d3d6748f60f625f7cd20b8a5defc957497e81","Message":"chore: refresh quotation acceptance evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T12:53:13-07:00"},"CompareURL":"","Len":5}...
|
1785441430
|
Edit
Delete
|
|
20058
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
|
1785441430
|
Edit
Delete
|
|
20057
|
5
|
1
|
5
|
72
|
0
|
0
|
|
0
|
|
1785441069
|
Edit
Delete
|
|
20056
|
5
|
5
|
5
|
54
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"03ef2eb6d {"Commits":[{"Sha1":"03ef2eb6d9d8f94868d95821c22f3c23f7dc7f38","Message":"chore(reports): refresh clean publish evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:43:05-07:00"}],"HeadCommit":{"Sha1":"03ef2eb6d9d8f94868d95821c22f3c23f7dc7f38","Message":"chore(reports): refresh clean publish evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:43:05-07:00"},"CompareURL":"luoanwu/base-framework/compare/94e3f1b529034c902d205637ed69033238b5b594...03ef2eb6d9d8f94868d95821c22f3c23f7dc7f38","Len":1}...
|
1785422600
|
Edit
Delete
|
|
20055
|
5
|
5
|
5
|
54
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"94e3f1b52 {"Commits":[{"Sha1":"94e3f1b529034c902d205637ed69033238b5b594","Message":"docs(governance): record Gitea publish baseline\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:41:37-07:00"}],"HeadCommit":{"Sha1":"94e3f1b529034c902d205637ed69033238b5b594","Message":"docs(governance): record Gitea publish baseline\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:41:37-07:00"},"CompareURL":"luoanwu/base-framework/compare/da8f52db37f5b42d035f92ad27a45067bc57dfa9...94e3f1b529034c902d205637ed69033238b5b594","Len":1}...
|
1785422513
|
Edit
Delete
|
|
20054
|
5
|
5
|
5
|
54
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"da8f52db3 {"Commits":[{"Sha1":"da8f52db37f5b42d035f92ad27a45067bc57dfa9","Message":"feat(governance): harden report provenance and UI acceptance\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:40:06-07:00"},{"Sha1":"4940be24ba6bfff2eefb2284f8ce66c9cbd1f326","Message":"docs(governance): record remote branch consolidation\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-22T01:35:33-07:00"}],"HeadCommit":{"Sha1":"da8f52db37f5b42d035f92ad27a45067bc57dfa9","Message":"feat(governance): harden report provenance and UI acceptance\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T07:40:06-07:00"},"CompareURL":"luoanwu/base-framework/compare/02a656716b10d2a5a4937ba01086cbd0a9ff4b85...da8f52db37f5b42d035f92ad27a45067bc57dfa9","Len":2}...
|
1785422433
|
Edit
Delete
|
|
20045
|
7
|
5
|
5
|
62
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"3e9e11cd8 {"Commits":[{"Sha1":"3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59","Message":"feat: harden voiceprint query integrity\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T02:09:01-07:00"},{"Sha1":"7d5bf03ace3e1daf460a271e6fabff8c5da00b8b","Message":"feat: improve voiceprint recognition governance\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T01:32:56-07:00"}],"HeadCommit":{"Sha1":"3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59","Message":"feat: harden voiceprint query integrity\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T02:09:01-07:00"},"CompareURL":"luoanwu/voiceprint-recognition/compare/3d3d1a4d8c4ab00b1cefbc239838007a04296172...3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59","Len":2}...
|
1785407062
|
Edit
Delete
|
|
20044
|
5
|
5
|
5
|
62
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"3e9e11cd8 {"Commits":[{"Sha1":"3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59","Message":"feat: harden voiceprint query integrity\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T02:09:01-07:00"},{"Sha1":"7d5bf03ace3e1daf460a271e6fabff8c5da00b8b","Message":"feat: improve voiceprint recognition governance\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T01:32:56-07:00"}],"HeadCommit":{"Sha1":"3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59","Message":"feat: harden voiceprint query integrity\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-30T02:09:01-07:00"},"CompareURL":"luoanwu/voiceprint-recognition/compare/3d3d1a4d8c4ab00b1cefbc239838007a04296172...3e9e11cd8aef1d8572f13e41bfc4a9ad091cea59","Len":2}...
|
1785407062
|
Edit
Delete
|
|
19778
|
5
|
5
|
5
|
67
|
0
|
0
|
refs/heads/governance/adversarial-audit-fixes-2026 refs/heads/governance/adversarial-audit-fixes-20260728...
|
0
|
{"Commits":[{"Sha1":"7d093d6ff {"Commits":[{"Sha1":"7d093d6ffa01151af6a18fbd41e0d3d8fb82e9ed","Message":"fix: stabilize review runs and parse song metadata\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-29T08:36:24-07:00"}],"HeadCommit":{"Sha1":"7d093d6ffa01151af6a18fbd41e0d3d8fb82e9ed","Message":"fix: stabilize review runs and parse song metadata\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-29T08:36:24-07:00"},"CompareURL":"luoanwu/songformer-structure-lyrics/compare/711c4d0dc336dd782bd2e3b8c2a5c8084489c831...7d093d6ffa01151af6a18fbd41e0d3d8fb82e9ed","Len":1}...
|
1785339402
|
Edit
Delete
|
|
19777
|
5
|
5
|
5
|
67
|
0
|
0
|
refs/heads/governance/adversarial-audit-fixes-2026 refs/heads/governance/adversarial-audit-fixes-20260728...
|
0
|
{"Commits":[{"Sha1":"711c4d0dc {"Commits":[{"Sha1":"711c4d0dc336dd782bd2e3b8c2a5c8084489c831","Message":"feat: add vocal-fast lyric block alignment\n\nDisable SongFormer in vocal_fast mode, split singing regions into lyric blocks, batch existing Qwen transcription, and preserve global monotonic official-lyric alignment. Include cross-structure VAD tail bounds and refreshed governance evidence.\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-29T05:56:50-07:00"}],"HeadCommit":{"Sha1":"711c4d0dc336dd782bd2e3b8c2a5c8084489c831","Message":"feat: add vocal-fast lyric block alignment\n\nDisable SongFormer in vocal_fast mode, split singing regions into lyric blocks, batch existing Qwen transcription, and preserve global monotonic official-lyric alignment. Include cross-structure VAD tail bounds and refreshed governance evidence.\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-29T05:56:50-07:00"},"CompareURL":"luoanwu/songformer-structure-lyrics/compare/ada639232a2eaf958115b36b989295eff4c75eff...711c4d0dc336dd782bd2e3b8c2a5c8084489c831","Len":1}...
|
1785329834
|
Edit
Delete
|
|
19674
|
5
|
5
|
5
|
68
|
0
|
0
|
refs/heads/main
|
1
|
{"Commits":[{"Sha1":"9d1021cf9 {"Commits":[{"Sha1":"9d1021cf95b6f0feb75dacbe348c0b4103744398","Message":"docs: add website content audit\n","AuthorEmail":"codex-sites@openai.com","AuthorName":"Codex Sites","CommitterEmail":"codex-sites@openai.com","CommitterName":"Codex Sites","Timestamp":"2026-07-28T23:15:04-07:00"},{"Sha1":"fe79133839999083532629c1e3a45c2e9e1b7ed4","Message":"feat: strengthen SEO and AI discovery\n","AuthorEmail":"codex-sites@openai.com","AuthorName":"Codex Sites","CommitterEmail":"codex-sites@openai.com","CommitterName":"Codex Sites","Timestamp":"2026-07-28T20:13:28-07:00"},{"Sha1":"079946aac0593e866c9ac9727ba762581c8f2c6f","Message":"fix: swap intelligent system product rows\n","AuthorEmail":"codex-sites@openai.com","AuthorName":"Codex Sites","CommitterEmail":"codex-sites@openai.com","CommitterName":"Codex Sites","Timestamp":"2026-07-28T19:55:44-07:00"},{"Sha1":"f3b85a2a795e16776018fc7a5d46765e75c4b13f","Message":"fix: render governed detail forms\n","AuthorEmail":"codex-sites@openai.com","AuthorName":"Codex Sites","CommitterEmail":"codex-sites@openai.com","CommitterName":"Codex Sites","Timestamp":"2026-07-28T19:52:51-07:00"},{"Sha1":"a2c5b8e96a8a6edef66172f308665785e69f4093","Message":"fix: balance product catalog layout\n","AuthorEmail":"codex-sites@openai.com","AuthorName":"Codex Sites","CommitterEmail":"codex-sites@openai.com","CommitterName":"Codex Sites","Timestamp":"2026-07-28T19:47:37-07:00"}],"HeadCommit":{"Sha1":"9d1021cf95b6f0feb75dacbe348c0b4103744398","Message":"docs: add website content audit\n","AuthorEmail":"codex-sites@openai.com","AuthorName":"Codex Sites","CommitterEmail":"codex-sites@openai.com","CommitterName":"Codex Sites","Timestamp":"2026-07-28T23:15:04-07:00"},"CompareURL":"luoanwu/juhai-official-website/compare/5035903b66b07ac2c6ffdbf04b62f48ef90a2d9d...9d1021cf95b6f0feb75dacbe348c0b4103744398","Len":10}...
|
1785306312
|
Edit
Delete
|
|
19673
|
5
|
5
|
5
|
68
|
0
|
0
|
refs/heads/main
|
1
|
|
1785306312
|
Edit
Delete
|
|
19672
|
5
|
1
|
5
|
68
|
0
|
0
|
|
1
|
|
1785306293
|
Edit
Delete
|
|
19663
|
5
|
5
|
5
|
53
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"d28a8594e {"Commits":[{"Sha1":"d28a8594e6cf9091cdf9ccd0fad377041dfaf727","Message":"feat: 完善 Tesla P4 GPU 部署链路\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-28T23:05:20-07:00"},{"Sha1":"6560bc5e5d9063cabf3af62b0b6287ebbc67f38d","Message":"feat: 接入嗨赞声浪模型别名并刷新验收\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-28T21:52:33-07:00"},{"Sha1":"24aa37882d5e85cd043071b232c7e4a12ea25382","Message":"feat(web): add brief-driven lyric drafting\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-06T01:17:00-07:00"}],"HeadCommit":{"Sha1":"d28a8594e6cf9091cdf9ccd0fad377041dfaf727","Message":"feat: 完善 Tesla P4 GPU 部署链路\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-28T23:05:20-07:00"},"CompareURL":"luoanwu/song-generation/compare/a146df273f4b5ba09c490cb67458ae8dc8c2fc12...d28a8594e6cf9091cdf9ccd0fad377041dfaf727","Len":3}...
|
1785305211
|
Edit
Delete
|
|
19604
|
5
|
5
|
5
|
6
|
0
|
0
|
refs/heads/react-migration
|
0
|
{"Commits":[{"Sha1":"f23014a01 {"Commits":[{"Sha1":"f23014a01acfc11abb251f3a76ea6c904a44ecac","Message":"docs(governance): 订正 view-g2=17 定性——首次诚实测量而非回归\n\n深挖推翻此前「真实视图成熟度回归」的判断，五条独立证据：\n\n1. maturityCounts 从 5-08 到 7-09 长期是 G4=300 全满级，7-21\n e756bd9203 突变为 G2=17\n2. 该提交的父提交里 git grep view-module-audit 只命中消费方，\n 无任何文件写入该报告——旧全 G4 报告无可执行生产器\n3. 该提交新增 view-audit.mjs(1348 行)并把 audit:view-governance\n 扩成 generate+verify+view:audit:generate 三段式\n4. 该提交 views 下测试文件增 1 删 0，无测试被删\n5. realViewModuleCount 299→284，归位 canonical 口径\n\n抽验 6 模块确认零 smoke 测试属实；admin 的 2 处引用是 vi.mock 桩掉，\n扫描器只认真实 from 导入是正确的保守设计。\n\n附：真实整改 backlog 19 项；生产器缺陷 1 项(mobile-prototype 因\nglobal-shell 拓扑在两条规则间不自洽而永远卡 G2 且无可修 gap)。\n受控块处置属棘轮「迁移后重存基线」分支，需 PR review，未单方面改。\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-07-28T18:21:14-07:00"}],"HeadCommit":{"Sha1":"f23014a01acfc11abb251f3a76ea6c904a44ecac","Message":"docs(governance): 订正 view-g2=17 定性——首次诚实测量而非回归\n\n深挖推翻此前「真实视图成熟度回归」的判断，五条独立证据：\n\n1. maturityCounts 从 5-08 到 7-09 长期是 G4=300 全满级，7-21\n e756bd9203 突变为 G2=17\n2. 该提交的父提交里 git grep view-module-audit 只命中消费方，\n 无任何文件写入该报告——旧全 G4 报告无可执行生产器\n3. 该提交新增 view-audit.mjs(1348 行)并把 audit:view-governance\n 扩成 generate+verify+view:audit:generate 三段式\n4. 该提交 views 下测试文件增 1 删 0，无测试被删\n5. realViewModuleCount 299→284，归位 canonical 口径\n\n抽验 6 模块确认零 smoke 测试属实；admin 的 2 处引用是 vi.mock 桩掉，\n扫描器只认真实 from 导入是正确的保守设计。\n\n附：真实整改 backlog 19 项；生产器缺陷 1 项(mobile-prototype 因\nglobal-shell 拓扑在两条规则间不自洽而永远卡 G2 且无可修 gap)。\n受控块处置属棘轮「迁移后重存基线」分支，需 PR review，未单方面改。\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-07-28T18:21:14-07:00"},"CompareURL":"luoanwu/juhi-omni-knowledge-hub/compare/b94f71f09dc50f1a267a97bd72bdc2417fa41014...f23014a01acfc11abb251f3a76ea6c904a44ecac","Len":1}...
|
1785288087
|
Edit
Delete
|
|
19603
|
5
|
5
|
5
|
6
|
0
|
0
|
refs/heads/react-migration
|
0
|
{"Commits":[{"Sha1":"b94f71f09 {"Commits":[{"Sha1":"b94f71f09dc50f1a267a97bd72bdc2417fa41014","Message":"docs(governance): 沉淀反向断言剧场与 2026-07-28 全量对抗验收结论\n\n两节新增经验（经验库约定最新置顶，同步 最后更新 → 2026-07-28）：\n\n1. 反向断言剧场：事件常量漂移让「真派发」consumer 测试静默空转。\n 真派发 ≠ 真命中——架构上确实捕获并调用了 handler，但事件类型\n 打不中路由表，0===0 的断言掩盖哑火。含幂等测试非空前置断言铁律、\n 常量取值范式与 `_created` 去重分支陷阱（不能只替换字符串）。\n\n2. 全量对抗验收实测：leads 主链运行态对抗探测全通过，但\n governance-gate（stale=46）与 baseline-reconcile（7 VALUE_DRIFT，\n 其中 4 处来自最新报告）双双报红。运行态扎实 ≠ 工作区级可放行，\n 两层必须分开陈述；禁止上调 ceiling 洗绿。\n\n对应代码修复见 f0f7ca8627。\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-07-28T17:47:57-07:00"},{"Sha1":"f0f7ca86271a2530ef901fe3b4472100452a02f3","Message":"test(hr): 修复因事件常量漂移而空转的消费者幂等测试\n\nhr.consumer 的路由键从 HR_ATTENDANCE_EVENTS.LEAVE_SUBMITTED\n('hr_leave_submitted') 改为 HR_EVENTS.LEAVE_REQUEST_CREATED\n('leave_request_created') 后，本测试仍硬编码旧字面量，导致\neventHandlers 查不到 handler、静默零副作用，测试退化为空转。\nproducer (leave.service.ts:612) 与 consumer 已对齐，生产代码无需改动。\n\n- 事件类型改从 HR_EVENTS 常量取值，后续重命名将直接编译失败而非静默失效\n- occurredAt 去重语义改用非 _created 事件验证：isEventProcessed 对\n `_created` 结尾事件按 eventType:entityId 去重（忽略 occurredAt），\n 用 created 事件断言「不同 occurredAt 都生效」在语义上必然失败\n- 两个用例补 afterFirst \u003e 0 防空转断言，杜绝 0 === 0 的假通过\n- 新增用例固定 _created 分支按 entityId 去重的语义\n\nbackend test:run: 653 files / 8945 tests 全通过（此前 2 failed）\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-07-28T17:40:14-07:00"},{"Sha1":"e756bd9203bbaacc6fc41c2f89f50259eeaf7e5d","Message":"Refactor governance workflows and frontend contracts\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-21T08:15:12-07:00"},{"Sha1":"33a0e20a1f45a68e6f951709fcf06742557cecba","Message":"Harden IM member boundaries and streamline governance guidance\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-21T04:01:44-07:00"},{"Sha1":"5f2d2c14951aaf1c46ad7d55b7152fe70e66395c","Message":"Improve governance workflows and frontend contract alignment\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-07-21T03:36:40-07:00"}],"HeadCommit":{"Sha1":"b94f71f09dc50f1a267a97bd72bdc2417fa41014","Message":"docs(governance): 沉淀反向断言剧场与 2026-07-28 全量对抗验收结论\n\n两节新增经验（经验库约定最新置顶，同步 最后更新 → 2026-07-28）：\n\n1. 反向断言剧场：事件常量漂移让「真派发」consumer 测试静默空转。\n 真派发 ≠ 真命中——架构上确实捕获并调用了 handler，但事件类型\n 打不中路由表，0===0 的断言掩盖哑火。含幂等测试非空前置断言铁律、\n 常量取值范式与 `_created` 去重分支陷阱（不能只替换字符串）。\n\n2. 全量对抗验收实测：leads 主链运行态对抗探测全通过，但\n governance-gate（stale=46）与 baseline-reconcile（7 VALUE_DRIFT，\n 其中 4 处来自最新报告）双双报红。运行态扎实 ≠ 工作区级可放行，\n 两层必须分开陈述；禁止上调 ceiling 洗绿。\n\n对应代码修复见 f0f7ca8627。\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-07-28T17:47:57-07:00"},"CompareURL":"luoanwu/juhi-omni-knowledge-hub/compare/c4f0c2eabbf729ae2f7cc6de2eda4416f0e7b3bb...b94f71f09dc50f1a267a97bd72bdc2417fa41014","Len":7}...
|
1785286209
|
Edit
Delete
|
|
19602
|
5
|
5
|
5
|
67
|
0
|
0
|
refs/heads/main
|
1
|
{"Commits":[{"Sha1":"205116d7e {"Commits":[{"Sha1":"205116d7e6e0ff602d1773c2ec986b02223b1e0e","Message":"Merge pull request '治理: 关闭对抗性验收发现的假绿装置、导出层静默数据损坏与文档幽灵资产' (#1) from governance/adversarial-audit-fixes-20260728 into main\n\nReviewed-on: https://gitea.g-hi.com/luoanwu/songformer-structure-lyrics/pulls/1\n","AuthorEmail":"law@g-hi.com","AuthorName":"luoanwu","CommitterEmail":"law@g-hi.com","CommitterName":"luoanwu","Timestamp":"2026-07-29T08:39:53+08:00"},{"Sha1":"ada639232a2eaf958115b36b989295eff4c75eff","Message":"韩语真歌首跑入基线 + 流水线阶段耗时 stage_timings 落盘与工作台展示\n\n- CLAUDE.md 动态区：韩语真歌首跑（SINGASONG 声明 ko）✅——谚文 g2pk 音变\n jamo-RR 字级时间真歌闭环、ASR 跨语言滑移韩语第二例（官方文本入 CTC 防线再兑现）；\n 本轮新抓两缺陷已识别未修（工作台重跑同曲面板不刷新、声明污染独立投票），\n 同步 G18 盲区清单与「真歌未验证清单」（仅剩越南语）\n- run_song.py：enter() 逐阶段记录耗时秒数落 stage_timings（含模型加载；\n error 时保留失败前已跑时长），状态文件对外可见\n- review/page.tsx：轮询状态展示各阶段耗时与总时长（执行中/完成/失败均带）\n- reports/governance-docs.latest.json：check:governance-docs 复跑刷新\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-07-28T11:12:50-07:00"},{"Sha1":"8d1868d15b122595a29dd35b7684035b285d0d6c","Message":"治理: 关闭对抗性验收发现的假绿装置、导出层静默数据损坏与文档幽灵资产\n\n对抗性验收审计（2026-07-28）发现并关闭 5 个问题，每条都留下机器防线且做了负向测试。\n\nG23 假绿装置（三层防线）\n 三个运行链地板（testsPassed/uiTestsPassed/pipelineTestsPassed）由各自 runner 消费、\n 却存放在 governance-report 托管的 baseline.json 里，而后者写基线是整体替换——\n 一次 --update-baseline 即静默抹掉；抹掉后 runtime/ui 消费端的 `?? 0` 让 x\u003c0 恒 false\n 即永绿。修：写入端改合并 + 消费端缺地板即红 + 棘轮端 EXTERNAL_FLOORS 存在性校验。\n\nC17 导出层三类静默数据损坏\n 丢行不报数（24 首真歌 1368 行丢 157）、全丢仍回 200 空文件、行级与逐字格式导出\n 两份不同歌词（1292 行中 155 行不一致）、未对齐字被跳过导致缺字歌词行。\n 修：export_stats + X-Export-* 会计、全丢判责 409、逐字忠实性判据 perCharIsFaithful\n （只用 Unicode \\p{L}/\\p{M}，不复刻 phase2 分词策略以免造第二真源）不忠实即降级。\n 另修判责错层：format 校验前置，避免非法 format 被报成 409。\n\nC18 line_words 吃掉 Unicode 组合标记\n isalpha() 判字使 Mn/Mc 落入 else 被丢弃：泰文 สวัสดี 丢 2 码位、NFD 越南语丢声调\n 且连段被劈开导致下游 chars[] 下标偏移。判据陷阱：combining() 对泰文 ั/ี 返回 0，\n 必须用 category in (Mn,Mc,Me)。新增 tests/test_tokenize.py 30 用例（先红后绿已验证）。\n\nC19 文档幽灵资产\n worker 文档整段描述兄弟仓架构（点名本仓不存在的 workers/hubertfa、\n packages/contracts/src/alignment-models.ts），断言 apps/ 下无实现且与现行许可口径\n 冲突的 ALLOW_NON_COMMERCIAL_MODELS 门禁，引用不可定位的跨仓编号 C23/C28/C29。\n 修：docs-truth 新增四条断言（资产计数/幽灵门禁/跨仓编号/幽灵路径），加入即抓到\n 两处人工 grep 漏掉的编号。\n\nG24 CI 结构性必红（非\"未验证\"）\n 真实 clone 实证：权重被 gitignore 排除而 check:model-assets 无模式开关 → 静态 job\n 必红 98 项 → runtime/ui job 因 needs 永不启动；库名 base_framework_ci 亦被 G15 拒。\n 修：MODEL_ASSETS_MANIFEST_ONLY 真检查模式（结构/许可/SHA 格式/字节自洽，非 skip，\n 报告写明 weightsVerified:false）+ 库名改 songformer_lyrics_ci。\n\n门禁卫生：eslint 忽略从枚举 .next/** 改为模式 .next*/**（.next-verify 构建产物曾\n以 736 个 error 打红 lint）；.gitignore 同步模式化。\n\n同时包含并发会话的第一/二阶段流水线改进（phase1 语言路由、phase2 双轨映射与统计、\nqwen3-asr / mms-fa / structure worker 更新、曲名单源 song-name.ts、错误边界页面）。\n\n证据（均绑定本地工作区，工作区 dirty，未绑定 commit SHA，见 G22）：\n pnpm check exit 0\n pnpm check:runtime exit 0 56 tests / 地板 56\n pnpm check:ui exit 0 4 用例 / 地板 4\n pnpm check:pipeline exit 0 114 tests / 地板 114\n负向测试：G23 三层、C19 四条断言、G24 七例，均确认先红后绿并恢复现场。\n\n新登记 OPEN：G25 存量陈旧 phase2 产物需重跑（GUNCHARLIE 48/48、有你有我 10/39）、\nG26 demucs 无正向离线强制、G27 worker 单曲 CLI 仍有 C18 同款缺陷、G28 CI 侧权重\n真伪永不校验。G14 远端 CI 拦截仍未验证——本轮只解除本地可推理的阻塞点。\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-07-28T10:50:48-07:00"}],"HeadCommit":{"Sha1":"205116d7e6e0ff602d1773c2ec986b02223b1e0e","Message":"Merge pull request '治理: 关闭对抗性验收发现的假绿装置、导出层静默数据损坏与文档幽灵资产' (#1) from governance/adversarial-audit-fixes-20260728 into main\n\nReviewed-on: https://gitea.g-hi.com/luoanwu/songformer-structure-lyrics/pulls/1\n","AuthorEmail":"law@g-hi.com","AuthorName":"luoanwu","CommitterEmail":"law@g-hi.com","CommitterName":"luoanwu","Timestamp":"2026-07-29T08:39:53+08:00"},"CompareURL":"luoanwu/songformer-structure-lyrics/compare/9d1500477039a937bafd4451d5b557515fc6fe23...205116d7e6e0ff602d1773c2ec986b02223b1e0e","Len":3}...
|
1785285594
|
Edit
Delete
|
|
19601
|
5
|
11
|
5
|
67
|
0
|
0
|
|
1
|
1|治理: 关闭对抗性验收发现的假绿装置、导出层静默数据损坏与文档幽灵资产
|
1785285593
|
Edit
Delete
|