|
24525
|
5
|
5
|
5
|
76
|
0
|
0
|
refs/heads/main
|
0
|
|
1787208429
|
Edit
Delete
|
|
24524
|
5
|
1
|
5
|
76
|
0
|
0
|
|
0
|
|
1787208388
|
Edit
Delete
|
|
25441
|
5
|
5
|
5
|
75
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"5b6ffb2fd {"Commits":[{"Sha1":"5b6ffb2fd47829470408617bee019a0a3912b7b7","Message":"Refine training framework workflows and governance coverage\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-24T02:29:00-07:00"}],"HeadCommit":{"Sha1":"5b6ffb2fd47829470408617bee019a0a3912b7b7","Message":"Refine training framework workflows and governance coverage\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-24T02:29:00-07:00"},"CompareURL":"luoanwu/training-framework/compare/27a28dd5a5a8aabd88832337fd5ffbc1216dbbf8...5b6ffb2fd47829470408617bee019a0a3912b7b7","Len":1}...
|
1787563748
|
Edit
Delete
|
|
23260
|
5
|
5
|
5
|
75
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"27a28dd5a {"Commits":[{"Sha1":"27a28dd5a5a8aabd88832337fd5ffbc1216dbbf8","Message":"docs(ai-mentor): 培训 AI 导师「嗨伙伴」设计稿\n\n定位：AI 演客户，人演顾问，AI 打首评，人做复检。\n\n核心判断：\n1. 角色反转把幻觉赶到无害的一侧——AI 只演客户（客户发言不构成巨嗨对外承诺），\n 并明令禁止 AI 以客户身份陈述巨嗨产品/价格/兼容性（客户本就不该知道），\n 从而把「输出巨嗨事实」从 AI 的可能行为里整个移除。\n 顺带补上文档 15.2「三人轮换」里最难安排的客户角色。\n2. AI 的目标函数是按案例卡「隐藏风险」诱导学员犯错，不是配合学员；学员没上钩才算通过。\n3. 评分分两层：红线层用 20.2 禁用清单做确定性扫描（可复现可审计），\n 评分层 LLM 按 18.1 八维打分但每维必须附学员原话；\n 并套用 19.4 教练校准——AI 与人类复检维度偏差超 10 个百分点即冻结 AI 评分回人工。\n\n与上游嗨伙伴产品线对齐（工作/嗨伙计 crew.ts + check:partner-truth）：\n- 防幻觉架构照搬已验证的 hallucination-guard 形状（renderQuote → renderFact(contentId)），\n 不重新发明；\n- 「执行完成只认领域终态，ToolCall ALLOWED 不算完成」映射为\n 「AI 打完分 ≠ 培训完成」，领域终态是学员通过复检并获得 18.2 操作授权；\n- 一期为内部工具，不进 CREW_ROSTER（未对外售卖即无产品就绪事实）。\n\n硬依赖点名：二期「官网事实问答」被 ContentLedger 阻塞——它尚未落地，\n没有它就等于让 LLM 直接产出巨嗨事实，是本设计第 4 节明令禁止的形态。\n\n未落地、未评审。对象模型与状态机为草案，未登记 owner-matrix。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T21:27:44-07:00"}],"HeadCommit":{"Sha1":"27a28dd5a5a8aabd88832337fd5ffbc1216dbbf8","Message":"docs(ai-mentor): 培训 AI 导师「嗨伙伴」设计稿\n\n定位：AI 演客户，人演顾问，AI 打首评，人做复检。\n\n核心判断：\n1. 角色反转把幻觉赶到无害的一侧——AI 只演客户（客户发言不构成巨嗨对外承诺），\n 并明令禁止 AI 以客户身份陈述巨嗨产品/价格/兼容性（客户本就不该知道），\n 从而把「输出巨嗨事实」从 AI 的可能行为里整个移除。\n 顺带补上文档 15.2「三人轮换」里最难安排的客户角色。\n2. AI 的目标函数是按案例卡「隐藏风险」诱导学员犯错，不是配合学员；学员没上钩才算通过。\n3. 评分分两层：红线层用 20.2 禁用清单做确定性扫描（可复现可审计），\n 评分层 LLM 按 18.1 八维打分但每维必须附学员原话；\n 并套用 19.4 教练校准——AI 与人类复检维度偏差超 10 个百分点即冻结 AI 评分回人工。\n\n与上游嗨伙伴产品线对齐（工作/嗨伙计 crew.ts + check:partner-truth）：\n- 防幻觉架构照搬已验证的 hallucination-guard 形状（renderQuote → renderFact(contentId)），\n 不重新发明；\n- 「执行完成只认领域终态，ToolCall ALLOWED 不算完成」映射为\n 「AI 打完分 ≠ 培训完成」，领域终态是学员通过复检并获得 18.2 操作授权；\n- 一期为内部工具，不进 CREW_ROSTER（未对外售卖即无产品就绪事实）。\n\n硬依赖点名：二期「官网事实问答」被 ContentLedger 阻塞——它尚未落地，\n没有它就等于让 LLM 直接产出巨嗨事实，是本设计第 4 节明令禁止的形态。\n\n未落地、未评审。对象模型与状态机为草案，未登记 owner-matrix。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T21:27:44-07:00"},"CompareURL":"luoanwu/training-framework/compare/299e9e73a28b31c10f2bd4a03db552811de642db...27a28dd5a5a8aabd88832337fd5ffbc1216dbbf8","Len":1}...
|
1786855126
|
Edit
Delete
|
|
23259
|
5
|
5
|
5
|
75
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"299e9e73a {"Commits":[{"Sha1":"299e9e73a28b31c10f2bd4a03db552811de642db","Message":"docs(governance): record gitea publish baseline for independent repo\n\n远端已建立并实测对齐：\ngitea = https://gitea.g-hi.com/luoanwu/training-framework.git（独立新仓）\nls-remote 实测 gitea/main=4bcef1bb，与推送时本地 HEAD 逐字一致。\n\n同时写明仍不成立的宣称：远端 CI 已绿、已部署、生产可用。\n并记录 push 打印 Everything up-to-date 不构成已发布证据。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T21:04:53-07:00"}],"HeadCommit":{"Sha1":"299e9e73a28b31c10f2bd4a03db552811de642db","Message":"docs(governance): record gitea publish baseline for independent repo\n\n远端已建立并实测对齐：\ngitea = https://gitea.g-hi.com/luoanwu/training-framework.git（独立新仓）\nls-remote 实测 gitea/main=4bcef1bb，与推送时本地 HEAD 逐字一致。\n\n同时写明仍不成立的宣称：远端 CI 已绿、已部署、生产可用。\n并记录 push 打印 Everything up-to-date 不构成已发布证据。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T21:04:53-07:00"},"CompareURL":"luoanwu/training-framework/compare/4bcef1bbfffbca2968adef922ca60afb8d4d5bfd...299e9e73a28b31c10f2bd4a03db552811de642db","Len":1}...
|
1786853096
|
Edit
Delete
|
|
23258
|
5
|
5
|
5
|
75
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"4bcef1bbf {"Commits":[{"Sha1":"4bcef1bbfffbca2968adef922ca60afb8d4d5bfd","Message":"docs(governance): record clean three-tier evidence SHAs and provenance blind spot\n\n三级证据现均 worktreeDirty=false，分别绑定 9c7586e/1ea36ef/4b8055e\n（相邻 commit 只差 reports/*.latest.json，源码逐字相同）。\n\n同时记录一个继承自源仓的治理盲区：governance-report 对 runtime/UI 报告\n只校验 gitSha 格式合法，不校验等于当前 HEAD——证据新鲜度只靠人工纪律，\n无机器守卫。判断三级状态须实际比对各报告 provenance.gitSha 与 HEAD。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T20:56:20-07:00"},{"Sha1":"9c7586eee8910f54f7805c411fa9a742b77fbfd5","Message":"chore(reports): bind UI acceptance evidence to clean commit\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T20:55:43-07:00"},{"Sha1":"4b8055e04b7dd0b4943fa712a7663ee4e11ec194","Message":"chore(reports): bind runtime acceptance evidence to clean commit\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T20:55:21-07:00"},{"Sha1":"1ea36ef0c0c09a93e20594dc31f10a4beef7877e","Message":"chore(reports): refresh static gate evidence on clean tree\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T20:55:00-07:00"},{"Sha1":"67310efba607e03c717fc0d3bb3c50b3f880427c","Message":"feat(recruitment): 前端作战台 + 3 个浏览器用例，三级门禁全绿\n\n前端（apps/web）：\n- RecruitmentPanel 招商作战台挂上首页：线索列表/创建/推进/转换、商机卡、\n 岗位切换器、看板（在途/高质量成交/阶段门拦截）\n- 动作按钮不硬编码 17 态，从 GET /api/opportunities/machine 的\n states[state].on 渲染；证据表单由 contracts 的 GATE_REQUIREMENTS 驱动，\n 后端加一项要求前端自动多一格\n- 阶段门反馈分两种：gate-blocked（缺证据 + missing[]）与 role-blocked（403）\n- lib/api.ts 增招商调用层，动作接口带 x-actor-role 头\n\n浏览器级验收（4 → 7 用例），把招商域证据等级从「真实 DB API」推到「浏览器交互」：\n- 线索 → 分配 → 接通 → 转商机，验证 CONVERTED 冻结\n- 阶段门：空证据提交被服务端拦下、UI 显示 missing[]、状态不动；补齐后放行\n- 回款门：SALES 填齐同样证据仍被 403，切 FINANCE 才通过\n （证据完全相同、唯一变量是岗位——锁死「角色门独立于证据门」）\n\n棘轮上调（只涨不降）：uiTestsPassed 4 → 7\n\n文档：CLAUDE.md 证据段与蓝图状态同步为「一期已落地」，并写明未覆盖项\n（Fastify 侧 UI 属 G17 既有缺口、Interaction 录入页、看板外读模型）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T20:53:03-07:00"}],"HeadCommit":{"Sha1":"4bcef1bbfffbca2968adef922ca60afb8d4d5bfd","Message":"docs(governance): record clean three-tier evidence SHAs and provenance blind spot\n\n三级证据现均 worktreeDirty=false，分别绑定 9c7586e/1ea36ef/4b8055e\n（相邻 commit 只差 reports/*.latest.json，源码逐字相同）。\n\n同时记录一个继承自源仓的治理盲区：governance-report 对 runtime/UI 报告\n只校验 gitSha 格式合法，不校验等于当前 HEAD——证据新鲜度只靠人工纪律，\n无机器守卫。判断三级状态须实际比对各报告 provenance.gitSha 与 HEAD。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-15T20:56:20-07:00"},"CompareURL":"","Len":8}...
|
1786853015
|
Edit
Delete
|
|
23257
|
5
|
5
|
5
|
75
|
0
|
0
|
refs/heads/main
|
0
|
|
1786853015
|
Edit
Delete
|
|
23256
|
5
|
1
|
5
|
75
|
0
|
0
|
|
0
|
|
1786852991
|
Edit
Delete
|
|
23634
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"c6049fee7 {"Commits":[{"Sha1":"c6049fee7c14933da0e4ff1e6a534eb44cfe1a03","Message":"fix(governance): 更正上一提交的证据绑定声明——静态那一级当时并非 clean-bound\n\nb33f650 的提交信息与 CLAUDE.md 都写「三份报告均 worktreeDirty=false」,实测不成立:\n当时 17 份静态报告是 dirty=true,只有 runtime / UI 两份是 false。\n\n根因是执行顺序错了:先改 CLAUDE.md、再跑 pnpm check——那一刻工作区已因文档改动而脏,\n静态报告的 dirty 位被如实记成 true,而提交信息照抄了改动前的说法。\n\n本次在工作区 clean 状态下重跑静态门禁,现状态:\n- 静态 17 份:gitSha=b33f650 + worktreeDirty=false\n- runtime / UI 2 份:gitSha=5acf362 + worktreeDirty=false\n两个 SHA 是刻意如此:5acf362→b33f650 的差异只有 CLAUDE.md 一个文件\n(git diff --name-only 实测),不含任何 apps/ packages/ scripts/ 改动,\n因此 runtime / UI 证据仍绑定当前代码。\n\n已把这条教训写进 CLAUDE.md:报告的 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-17T17:36:54-07:00"}],"HeadCommit":{"Sha1":"c6049fee7c14933da0e4ff1e6a534eb44cfe1a03","Message":"fix(governance): 更正上一提交的证据绑定声明——静态那一级当时并非 clean-bound\n\nb33f650 的提交信息与 CLAUDE.md 都写「三份报告均 worktreeDirty=false」,实测不成立:\n当时 17 份静态报告是 dirty=true,只有 runtime / UI 两份是 false。\n\n根因是执行顺序错了:先改 CLAUDE.md、再跑 pnpm check——那一刻工作区已因文档改动而脏,\n静态报告的 dirty 位被如实记成 true,而提交信息照抄了改动前的说法。\n\n本次在工作区 clean 状态下重跑静态门禁,现状态:\n- 静态 17 份:gitSha=b33f650 + worktreeDirty=false\n- runtime / UI 2 份:gitSha=5acf362 + worktreeDirty=false\n两个 SHA 是刻意如此:5acf362→b33f650 的差异只有 CLAUDE.md 一个文件\n(git diff --name-only 实测),不含任何 apps/ packages/ scripts/ 改动,\n因此 runtime / UI 证据仍绑定当前代码。\n\n已把这条教训写进 CLAUDE.md:报告的 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-17T17:36:54-07:00"},"CompareURL":"luoanwu/haimate/compare/b33f650552dbc4adad6df5ee670b6d9eba8eb125...c6049fee7c14933da0e4ff1e6a534eb44cfe1a03","Len":1}...
|
1787013419
|
Edit
Delete
|
|
23633
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"b33f65055 {"Commits":[{"Sha1":"b33f650552dbc4adad6df5ee670b6d9eba8eb125","Message":"chore(reports): 刷新治理证据,绑定提交 5acf362——容器化落地后三级重跑\n\n三份报告 provenance 均为 gitSha=5acf362 + worktreeDirty=false。\n\n- 静态 pnpm check 00:32Z 16 道门禁 + 棘轮 + lint + typecheck 全绿\n- 真实 DB check:runtime 00:33Z status=passed, 380 tests / 0 failures (floor 380)\n- 浏览器 check:ui 00:34Z status=passed, 14 用例 / 0 unexpected (floor 14)\n\n本轮为什么必须重跑而不能沿用上一份(fe9a6ae)绿盘:\nCI 修复 b673ff8 改动了双端 security.http.test.ts 与 scripts/check-runtime-acceptance.mjs\n——被测代码与测试运行器都变了,旧 runtime 证据随即失效。已把这条判据写进 CLAUDE.md:\n凡 apps/*/test、packages/contracts/src、apps/*/src、prisma 或验收 runner 自身发生改动,\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-17T17:35:11-07:00"},{"Sha1":"5acf36269dc9ac57017fb9d77c43ac28fca73395","Message":"feat(ops): 容器化全栈——三份应用 Dockerfile + compose 编排,G20 部分推进\n\nG20 此前记为\"生产运维平面为空:无应用 Dockerfile / 生产 compose 或编排\"。\n本次把容器化这一段做实并实测跑通,其余运维项仍 OPEN。\n\n新增\n- docker/Dockerfile.api-{fastify,nestjs} / .web:node:20-slim + openssl 基座\n (Prisma engine 在 musl 上需另一套二进制目标,alpine 极易出现\"本机能跑、容器里\n engine 找不到\");多阶段构建,依赖层只拷 manifest 以命中缓存\n- compose.yml:PG/Redis + 双后端各自的迁移 job + 双后端 + 前端;\n healthcheck 打 /api/health(真探 DB+Redis,非探活);端口用 +100 段,\n 可与本机 dev 栈同时运行\n- .dockerignore:仓库 1.7G 中 node_modules 占 1.5G,不排除会撑爆构建上下文;\n 宿主机依赖含平台相关二进制,拷进 linux 镜像必然是错的\n\n两个构建期参数(写错不报错、只静默坏掉,已写进 Dockerfile 顶部)\n- API_PROXY_TARGET:next rewrites 在 next build 时序列化进 routes-manifest,\n 是构建参数不是运行时变量;取值走 compose 内网服务名\n- NEXT_PUBLIC_WS_URL:NEXT_PUBLIC_* 构建期内联进客户端 bundle,而 WebSocket 由\n 浏览器直连(rewrites 只代理 /api 与 /sse),取值必须是宿主机可达地址\n 两者取值域相反,搞混的症状是\"页面能开、实时永远未连接\"\n\n迁移刻意拆成两个 job 不合并:双后端各有自己的 prisma/migrations,\"跑一个等于跑两个\"\n是 check:schema / check:migrations 保证的结论,不是编排可以预设的前提。\n实测 migrate-nestjs 独立复核报\"6 个迁移、无待应用\",一致性是被验证而非被假设的。\n\n本地实测证据\n- 五服务全部 healthy;双端容器内 /api/health 均 database/redis: up\n- 租户边界在容器栈同样生效:带租户 200 / 不带 400\n- 浏览器写入后 user.created 经 outbox→Redis→WS 落到 EventFeed(含 tenantId/eventId)\n- web 容器 /api/health 返回 service: fastify,证明内网代理参数正确\n- 容器栈与本机 dev 栈同时运行、数据互不可见\n\n仍 OPEN(CLAUDE.md G20 已按实分栏,不得据此宣称可上生产)\n镜像各约 2.1GB 未裁剪(pnpm 符号链接虚拟 store 与 node_modules/.prisma 耦合,\nprod-only 裁剪易做出\"能构建但运行时缺 engine\"的镜像,首版优先保证真能跑);\n安全模式仍 demo 且 DB 口令明文;无灰度回滚 Runbook / OTel / 限流熔断 / 审计日志 /\n备份恢复演练 / SLO 告警 / 镜像仓库与版本策略;未在任何非本机环境部署过。\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-17T17:31:42-07:00"},{"Sha1":"b0b189c813b46ab3b6903cc4a13cd1ce1ad34d81","Message":"fix(dev): launch.json 指向本仓专属库,并补齐 demo 模式与 worker 开关\n\n启动本地开发栈时发现三处会让人\"跑起来了但其实是坏的\"的问题:\n\n1. DATABASE_URL 原先指向 base_framework_dev——实测该库里同时装着另一个项目的\n 8 个迁移(material_factory / brand_kit_profile / voiceprint_tasks / voice_cloning 等),\n 且缺本仓最新的 20260817090000_add_crew_engagement。按原配置启动会把本仓迁移\n 打进别的项目的库,正是 CLAUDE.md G15 记录的\"本机 PG:55432 被多项目共用\"事故模式。\n 改为本仓专属库 base_framework_haimate_dev(已建库并应用 6 个迁移),\n 对 base_framework_dev 未执行任何写操作。\n\n2. 缺 HAIMATE_SECURITY_MODE=demo——非测试环境默认 signed,缺 JWT 配置时 fail closed,\n 不显式开 demo 则本地所有请求 401(ADR-0011)。\n\n3. 缺 PLATFORM_WORKERS_ENABLED=1——不开则 KB 投影 / Trust 投影 / 审批过期等 worker\n 不运行,页面看起来能用但异步链路是死的。\n\n顺带记录一处认知缺口:G15 的机器防线只装在验收链上(check:runtime / check:ui 强制\n显式 URL + 库名前缀守卫),而开发启动路径没有守卫——launch.json 是手写配置,没人检查\n它指向哪。于是\"验收比开发更安全\",而开发才是每天都在跑的那条路径。已在文件内写明原因,\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-17T17:31:16-07:00"}],"HeadCommit":{"Sha1":"b33f650552dbc4adad6df5ee670b6d9eba8eb125","Message":"chore(reports): 刷新治理证据,绑定提交 5acf362——容器化落地后三级重跑\n\n三份报告 provenance 均为 gitSha=5acf362 + worktreeDirty=false。\n\n- 静态 pnpm check 00:32Z 16 道门禁 + 棘轮 + lint + typecheck 全绿\n- 真实 DB check:runtime 00:33Z status=passed, 380 tests / 0 failures (floor 380)\n- 浏览器 check:ui 00:34Z status=passed, 14 用例 / 0 unexpected (floor 14)\n\n本轮为什么必须重跑而不能沿用上一份(fe9a6ae)绿盘:\nCI 修复 b673ff8 改动了双端 security.http.test.ts 与 scripts/check-runtime-acceptance.mjs\n——被测代码与测试运行器都变了,旧 runtime 证据随即失效。已把这条判据写进 CLAUDE.md:\n凡 apps/*/test、packages/contracts/src、apps/*/src、prisma 或验收 runner 自身发生改动,\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-17T17:35:11-07:00"},"CompareURL":"luoanwu/haimate/compare/15248a4a041b4e0b1716d65ce7327315a8d39176...b33f650552dbc4adad6df5ee670b6d9eba8eb125","Len":3}...
|
1787013326
|
Edit
Delete
|
|
23632
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"15248a4a0 {"Commits":[{"Sha1":"15248a4a041b4e0b1716d65ce7327315a8d39176","Message":"docs(governance): 修正 G14 认知——CI 不是没跑,是连红 7 次无人当真,现已首次全绿\n\n此前 G14 写作「尚未在 GitHub 上跑出绿盘证据」，实测是错的：Governance workflow\n自 2026-08-14 起已运行 8 次（6 红 1 取消 1 绿），红盘一直存在、一直没人看。\n\n根因两处，均只在 CI 环境暴露（本机跑多少次绿盘都推不出来），已于 b673ff8 修复：\n- 假红：CI 着色让测试计数恒为 0，报成看似灾难性回归的「got 0」\n- flaky：篡改 JWT 约 1/64 概率篡改了个寂寞，把安全断言变成偶发假通过\n\n修复后 CI 首次全绿（Static ✓ 1m29s、Runtime and UI ✓ 5m21s）。\n\n回灌的判据：**一个永远红的门禁与一个不存在的门禁，治理价值相同——都不产生信息。**\n「假红」比「假绿」更隐蔽，因为它表面上更严格；且负向测试与空转测试都发现不了它\n（那些都在本地跑）。\n\nG14 仍 OPEN，剩余关闭条件两项：required checks / 分支保护可定位；\n用受控失败 PR 证明违规确实被阻断。\n\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-17T17:02:49-07:00"}],"HeadCommit":{"Sha1":"15248a4a041b4e0b1716d65ce7327315a8d39176","Message":"docs(governance): 修正 G14 认知——CI 不是没跑,是连红 7 次无人当真,现已首次全绿\n\n此前 G14 写作「尚未在 GitHub 上跑出绿盘证据」，实测是错的：Governance workflow\n自 2026-08-14 起已运行 8 次（6 红 1 取消 1 绿），红盘一直存在、一直没人看。\n\n根因两处，均只在 CI 环境暴露（本机跑多少次绿盘都推不出来），已于 b673ff8 修复：\n- 假红：CI 着色让测试计数恒为 0，报成看似灾难性回归的「got 0」\n- flaky：篡改 JWT 约 1/64 概率篡改了个寂寞，把安全断言变成偶发假通过\n\n修复后 CI 首次全绿（Static ✓ 1m29s、Runtime and UI ✓ 5m21s）。\n\n回灌的判据：**一个永远红的门禁与一个不存在的门禁，治理价值相同——都不产生信息。**\n「假红」比「假绿」更隐蔽，因为它表面上更严格；且负向测试与空转测试都发现不了它\n（那些都在本地跑）。\n\nG14 仍 OPEN，剩余关闭条件两项：required checks / 分支保护可定位；\n用受控失败 PR 证明违规确实被阻断。\n\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-17T17:02:49-07:00"},"CompareURL":"luoanwu/haimate/compare/b673ff8c2e248dbea016f88702215123aa58fd03...15248a4a041b4e0b1716d65ce7327315a8d39176","Len":1}...
|
1787011374
|
Edit
Delete
|
|
23631
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"b673ff8c2 {"Commits":[{"Sha1":"b673ff8c2e248dbea016f88702215123aa58fd03","Message":"fix(ci): 修复 CI 恒红两处根因——测试计数被 ANSI 吞掉、篡改 JWT 构造可能零改动\n\n远端 CI 自 2026-08-14 起每次推送都红，共 7 次，无人当真。实测根因有二，\n都与本地环境差异有关，本机绿盘无法暴露（这正是 G14 不可被本地证据替代的原因）。\n\n根因一：假红——测试计数在 CI 下恒为 0\n`CI=true` 时 turbo 给子进程输出着色，实际字节是\n`Tests \\x1b[22m \\x1b[1m\\x1b[32m140 passed`；countPassedTests 的\n/Tests\\s+(\\d+)\\s+passed/ 匹配不到转义序列，于是本地 380、CI 0，\n报成「expected \u003e= 380, got 0」这种看似灾难性回归的消息。\n测试其实全过，坏的是计数器。修复：匹配前先剥 ANSI。\n注意这类假红不会被负向测试或空转测试发现——它们都在本地跑。\n\n根因二：flaky——「篡改 JWT」有约 1/64 概率篡改了个寂寞\ntampered 把签名第 5 位替换成 'A'，但 payload 含 exp=now+600，签名每次都变；\n当该位恰好就是 'A' 时，产出的是与合法 token 逐字节相同的串，验签通过，\n断言 401 收到 200。base64url 64 字符 → 每次运行约 1.6% 触发，双后端同款。\n修复：先读该位，改成一个必定不同的字符。这类 flake 会悄悄削弱安全断言。\n\n验证：CI=true 条件下本地复现两处失败，修复后 pnpm check:runtime\nstatus=passed、testsPassed=380（地板 380）。\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-17T16:52:28-07:00"}],"HeadCommit":{"Sha1":"b673ff8c2e248dbea016f88702215123aa58fd03","Message":"fix(ci): 修复 CI 恒红两处根因——测试计数被 ANSI 吞掉、篡改 JWT 构造可能零改动\n\n远端 CI 自 2026-08-14 起每次推送都红，共 7 次，无人当真。实测根因有二，\n都与本地环境差异有关，本机绿盘无法暴露（这正是 G14 不可被本地证据替代的原因）。\n\n根因一：假红——测试计数在 CI 下恒为 0\n`CI=true` 时 turbo 给子进程输出着色，实际字节是\n`Tests \\x1b[22m \\x1b[1m\\x1b[32m140 passed`；countPassedTests 的\n/Tests\\s+(\\d+)\\s+passed/ 匹配不到转义序列，于是本地 380、CI 0，\n报成「expected \u003e= 380, got 0」这种看似灾难性回归的消息。\n测试其实全过，坏的是计数器。修复：匹配前先剥 ANSI。\n注意这类假红不会被负向测试或空转测试发现——它们都在本地跑。\n\n根因二：flaky——「篡改 JWT」有约 1/64 概率篡改了个寂寞\ntampered 把签名第 5 位替换成 'A'，但 payload 含 exp=now+600，签名每次都变；\n当该位恰好就是 'A' 时，产出的是与合法 token 逐字节相同的串，验签通过，\n断言 401 收到 200。base64url 64 字符 → 每次运行约 1.6% 触发，双后端同款。\n修复：先读该位，改成一个必定不同的字符。这类 flake 会悄悄削弱安全断言。\n\n验证：CI=true 条件下本地复现两处失败，修复后 pnpm check:runtime\nstatus=passed、testsPassed=380（地板 380）。\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-17T16:52:28-07:00"},"CompareURL":"luoanwu/haimate/compare/470495fbe7a9692bbb9ef869546e0050c9c73b7e...b673ff8c2e248dbea016f88702215123aa58fd03","Len":1}...
|
1787010753
|
Edit
Delete
|
|
23630
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"470495fbe {"Commits":[{"Sha1":"470495fbe7a9692bbb9ef869546e0050c9c73b7e","Message":"docs(governance): 收口发布声明——fe9a6ae 已推送,把免责句换成可支撑的合并声明\n\n上一提交写的免责句「不可外推为远端已发布该提交(fe9a6ae 尚未推送时本段成立)」\n在推送完成后其前提已不成立,留着就是一条自我失效的治理记录。\n\n按发布口径表改为可支撑的合并声明:\n「双远端已发布 fe9a6ae,且该提交在本地 clean 检出点通过三级门禁」。\n\n同时把剩余边界写死:仍不可外推为「远端 CI 已拦截 / 已部署 / 生产可用」——\n远端从未跑出过一次门禁运行,上述声明的证据来源始终是本机,\n与远端只共享同一个 commit SHA(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-08-17T16:42:32-07:00"}],"HeadCommit":{"Sha1":"470495fbe7a9692bbb9ef869546e0050c9c73b7e","Message":"docs(governance): 收口发布声明——fe9a6ae 已推送,把免责句换成可支撑的合并声明\n\n上一提交写的免责句「不可外推为远端已发布该提交(fe9a6ae 尚未推送时本段成立)」\n在推送完成后其前提已不成立,留着就是一条自我失效的治理记录。\n\n按发布口径表改为可支撑的合并声明:\n「双远端已发布 fe9a6ae,且该提交在本地 clean 检出点通过三级门禁」。\n\n同时把剩余边界写死:仍不可外推为「远端 CI 已拦截 / 已部署 / 生产可用」——\n远端从未跑出过一次门禁运行,上述声明的证据来源始终是本机,\n与远端只共享同一个 commit SHA(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-08-17T16:42:32-07:00"},"CompareURL":"luoanwu/haimate/compare/a369f4ee008c621f3ef5ada67880cb52a9ad7c9b...470495fbe7a9692bbb9ef869546e0050c9c73b7e","Len":1}...
|
1787010157
|
Edit
Delete
|
|
23629
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a369f4ee0 {"Commits":[{"Sha1":"a369f4ee008c621f3ef5ada67880cb52a9ad7c9b","Message":"chore(reports): 刷新治理证据,绑定提交 fe9a6ae——三级首次 clean-bound\n\n本次刷新的三级证据 provenance 均为 gitSha=fe9a6ae + worktreeDirty=false,\n是本仓第一次在 clean 检出点上取得完整三级绿盘(此前所有轮次都是 dirty 工作区)。\n按发布口径表严格解读,可宣称「本地在 commit fe9a6ae 这一 clean 检出点通过三级门禁」,\n仍不可外推为「远端已发布」或「远端 CI 已拦截」(G14 仍 OPEN)。\n\n- 静态 pnpm check 23:37Z 16 道门禁 + 棘轮 + lint + typecheck 全绿\n- 真实 DB check:runtime 23:38Z status=passed, 380 tests / 0 failures (floor 380)\n- 浏览器 check:ui 23:39Z status=passed, 14 用例 / 0 unexpected (floor 14)\n- 门禁对抗探针 probe:gates 11/11 挡下,并用三项元测试反证该套件本身会失败\n\nCLAUDE.md 动态区同步:\n- 发布快照按实更正。本快照在一个 session 内过期四次\n (66f0513 → b0d8e83 → 6b3be1d → a0563c4 → fe9a6ae),并实测遇到远端 503 不可达——\n 据此补记:发布状态只能实时 ls-remote 判定,远端不可达时只能声明\n 「最后一次成功验证的时刻与结果」,不得含糊成「当前已对齐」。\n- 证据新鲜度段标注三级 clean-bound,并新增 probe:gates 一行。\n- 真源地图「状态迁移并发写入」条按实改为 22 条 updateMany + 10 条 raw SQL,\n 写明 raw SQL 是受检的逃生阀而非免检通道。\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-17T16:41:22-07:00"},{"Sha1":"fe9a6ae90e99138fc09be0f7b2e75971b51f1275","Message":"feat(governance): 固化对抗探针 pnpm probe:gates,把三类攻破路径变成可重复执行\n\n手工做负向测试不可靠且不可重复。本次把对抗性验收当天用到的攻击手法固化为\n11 条探针（scripts/adversarial-probes.mjs），覆盖三类攻破路径：\n- negative：注入真违规，门禁必须报红（证明有牙）\n- vacuous ：破坏门禁的输入定位（改表格列数 / 改被扫描的表名），\n 门禁必须报红而不是「检查了 0 项然后通过」（证明关不掉）\n- binding ：用无关代码满足泛化断言（unrelated.length \u003e 0 / 注释里写符号名），\n 门禁必须仍然报红（证明断言绑定到被检查对象本身）\n\n设计取舍\n- 刻意不进 pnpm check：它会临时改写源文件，只适合按需运行；\n 结束时逐字节还原现场并还原 latest 报告，探针产生的污染报告不进证据链\n- 锚点失效单独报 ANCHOR-STALE 且 exit 1：源码重构后锚点对不上，\n 意味着该路径本次无人验证，不等于安全——不得当成通过\n\n实测：11 条全部 BLOCKED，被攻破 0、锚点失效 0；运行前后 git status 指纹一致。\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-17T16:32:54-07:00"},{"Sha1":"a0563c40434d93ba1535ce1de39141bdd2b7889a","Message":"fix(governance): 门禁空转加固 + 移除审批工单死负载,并回灌空转测试纪律\n\n对抗性验收（2026-08-17）发现「负向测试通过」并不足以证明门禁有牙：\n门禁还可能被**静默关掉**——扫描出 0 项然后宣布通过。两处实测：\n- check:owner-matrix 改表格列数后报「0 行登记，校验通过」\n- check:concurrency-guard 改表名后 raw 写链从 10 条静默降到 5 条仍 exit 0\n两者都是当天刚做完负向测试的门禁。\n\n修复\n- check:owner-matrix 增加 BUILT 行数下溢守卫（地板 25），识别不足即红\n- check:concurrency-guard 的 raw「0 行拒绝」判据绑定到该语句自身的结果变量，\n 避免被无关的 `unrelated.length \u003e 0` 骗过\n- 移除 ApprovalTicket 查询中三处 `include: { toolCalls: true }` 死负载：\n 无组件消费、无测试断言，属白付 JOIN；ToolCall 的读模型消费方按 owner-matrix\n 登记只有 ToolCallsPanel，自行取数\n\n回灌 CLAUDE.md\n- 收尾清单新增「空转测试」与「断言绑定」两条：凡是「扫描出 N 项并逐项断言」的门禁，\n N 本身必须有地板，否则 N=0 是最容易伪造的绿\n- 真源地图补记 10 条 raw SQL 写链为「受检的逃生阀」而非免检通道\n- 发布快照更新至 6b3be1d，并明确区分「已发布」与「已验收」：\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-17T16:24:24-07:00"}],"HeadCommit":{"Sha1":"a369f4ee008c621f3ef5ada67880cb52a9ad7c9b","Message":"chore(reports): 刷新治理证据,绑定提交 fe9a6ae——三级首次 clean-bound\n\n本次刷新的三级证据 provenance 均为 gitSha=fe9a6ae + worktreeDirty=false,\n是本仓第一次在 clean 检出点上取得完整三级绿盘(此前所有轮次都是 dirty 工作区)。\n按发布口径表严格解读,可宣称「本地在 commit fe9a6ae 这一 clean 检出点通过三级门禁」,\n仍不可外推为「远端已发布」或「远端 CI 已拦截」(G14 仍 OPEN)。\n\n- 静态 pnpm check 23:37Z 16 道门禁 + 棘轮 + lint + typecheck 全绿\n- 真实 DB check:runtime 23:38Z status=passed, 380 tests / 0 failures (floor 380)\n- 浏览器 check:ui 23:39Z status=passed, 14 用例 / 0 unexpected (floor 14)\n- 门禁对抗探针 probe:gates 11/11 挡下,并用三项元测试反证该套件本身会失败\n\nCLAUDE.md 动态区同步:\n- 发布快照按实更正。本快照在一个 session 内过期四次\n (66f0513 → b0d8e83 → 6b3be1d → a0563c4 → fe9a6ae),并实测遇到远端 503 不可达——\n 据此补记:发布状态只能实时 ls-remote 判定,远端不可达时只能声明\n 「最后一次成功验证的时刻与结果」,不得含糊成「当前已对齐」。\n- 证据新鲜度段标注三级 clean-bound,并新增 probe:gates 一行。\n- 真源地图「状态迁移并发写入」条按实改为 22 条 updateMany + 10 条 raw SQL,\n 写明 raw SQL 是受检的逃生阀而非免检通道。\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-17T16:41:22-07:00"},"CompareURL":"luoanwu/haimate/compare/6b3be1dafc25b3d82703595f7542769eae6b7744...a369f4ee008c621f3ef5ada67880cb52a9ad7c9b","Len":3}...
|
1787010092
|
Edit
Delete
|
|
23628
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"6b3be1daf {"Commits":[{"Sha1":"6b3be1dafc25b3d82703595f7542769eae6b7744","Message":"chore(reports): 刷新治理证据,绑定提交 b0d8e83\n\n三级门禁在 b0d8e83 上重跑后的报告：\n- pnpm check exit 0（16 项静态门禁）\n- check:runtime passed：380 tests / 0 failures\n- check:ui passed：14 用例 / 0 失败\n\n诚实标注：provenance 的 worktreeDirty 仍为 true。原因不是本提交遗漏了文件，\n而是**同一工作区存在并发会话**，其在制品（CLAUDE.md、两端 approval-tickets.service、\nweb/src/lib/types.ts、check-order-concurrency-guard.mjs、check-owner-matrix.mjs）\n在重跑期间处于未提交状态，已刻意不纳入本提交。\n\n因此本组报告只能宣称「本地工作区（含上述并发在制品）在 2026-08-17 通过三级门禁」，\n不得外推为 clean checkout 通过、远端已发布或 CI 已拦截。\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-17T16:16:17-07:00"},{"Sha1":"b0d8e837396f6e0f15c0ceeb46b236f14f40f5c9","Message":"feat: 合并提交长期未落库的批次——Finance Phase A、安全边界、outbox 租约与 crew 雇佣纵切\n\n本次是一次「补提交」：工作区此前累积了大量从未进入任何提交的成果，\n其中包含三个只存在于本地的门禁脚本（partner-truth / security-boundary /\noutbox-lease），clean checkout 根本跑不出当前的治理结论。一并落库。\n\n主要内容\n- Finance 对账 Phase A：12 个 model、双后端服务与 worker、/finance 工作面与 e2e\n- 应用安全边界（C21）：显式 demo/signed 分界、principal 取 tenant/actor、\n 治理动作 RBAC、支付 webhook raw-body HMAC\n- Outbox 多实例租约（C22）：CTE + FOR UPDATE SKIP LOCKED 原子领取、行锁 fencing、\n 租约过期崩溃恢复\n- crew 雇佣纵切（L7，新）：crewEngagementMachine 落 contracts 单源，双后端对等写链\n （updateMany + stage/version 双前置条件，0 行即 409），两端迁移逐字一致，\n /team 的 employment 由写死的 UNKNOWN 变为 crew_engagements 真实阶段\n- 新门禁：check:partner-truth / check:security-boundary / check:outbox-lease /\n check:owner-matrix，并把 crew 写链接入 check:concurrency-guard（20→22 条）\n- a11y 与 Tailwind token 修复及其静默失效门禁\n\ncrew 纵切的两个设计要点\n- 无行即未雇佣，不设 NOT_HIRED 状态（与 TrustState 缺行=UNCONFIGURED 同构）\n- 实习期强制人审、转正后才准进入信任爬坡放行：商业分层直接就是授权分层，\n 实习期本质上是在攒 approval.decided 样本，转正把信任兑现为自治\n- PLANNED 的 SKU 不可雇佣，避免造出「实习中却没有任何工作面」的假雇佣事实\n\n验收（本地 dirty 工作区，2026-08-17；不得外推为远端已发布或生产就绪）\n- pnpm check exit 0（16 项静态门禁；新增并发写链守卫已做负向测试，确认会红）\n- check:runtime passed：380 tests / 0 failures（地板 355→380）\n- check:ui passed：14 用例 / 0 失败（地板 13→14）\n\n按 CLAUDE.md 提交纪律，baseline.json 的地板与支撑它的测试文件在同一提交内。\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-17T16:09:30-07:00"},{"Sha1":"44fed27603c1bd264192d1ce05016c1cd5b1c8ea","Message":"fix(a11y): 修复侧栏隐形导航 + 颜色 token 全面达标 AA,并新增 Tailwind 静默失效门禁\n\n根因:Tailwind 颜色类透明度修饰符只有落在预设刻度(5 的倍数)或方括号任意值\n才生成 CSS。侧栏写 text-white/68 属死类,文字回退继承 --hm-ink 压在深蓝\n--hm-nav 上,实测对比度 1.02——导航区在浏览器里等于隐形,而 TypeScript\n与 ESLint 均不报,只有量计算样式才暴露。\n\n- 侧栏 6 处非法透明度(/38 /58 /68 /78)改为合法刻度,导航项对比度 1.02 → 5.18~17.64,6/6 达标\n- 全站实测 187 个文本节点原有 45 处不达 AA,根因集中在 token 自身取值偏浅;\n 按 token 层修复(text-tertiary/warning/success/danger/ai),每个新值在白底与\n 各自浅色底双双达标才采用,注释写进 globals.css。结果 45 → 0\n- 新增 check:tailwind-tokens 绊网并接入 pnpm check 与棘轮(地板 0);\n 负向测试已验证:注入 text-white/68 即 exit 1,恢复即 exit 0\n- 团队总览按用户拍板退回外壳设计语言(--hm-* / 12px 圆角 / 无衬线),\n 补回此前被重构弄丢的「昨天那一页」与雇佣价目,触控目标统一 44px\n- 花名册单源 contracts CREW_ROSTER + deriveCrewStatus(计费跳档将复用同一口径)\n- e2e 重写为一条覆盖全模块的用例(旧两条因 testid 重命名已失效)\n- CLAUDE.md 基线表 + 治理经验库 ⑬ 回灌\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-14T19:18:43-07:00"}],"HeadCommit":{"Sha1":"6b3be1dafc25b3d82703595f7542769eae6b7744","Message":"chore(reports): 刷新治理证据,绑定提交 b0d8e83\n\n三级门禁在 b0d8e83 上重跑后的报告：\n- pnpm check exit 0（16 项静态门禁）\n- check:runtime passed：380 tests / 0 failures\n- check:ui passed：14 用例 / 0 失败\n\n诚实标注：provenance 的 worktreeDirty 仍为 true。原因不是本提交遗漏了文件，\n而是**同一工作区存在并发会话**，其在制品（CLAUDE.md、两端 approval-tickets.service、\nweb/src/lib/types.ts、check-order-concurrency-guard.mjs、check-owner-matrix.mjs）\n在重跑期间处于未提交状态，已刻意不纳入本提交。\n\n因此本组报告只能宣称「本地工作区（含上述并发在制品）在 2026-08-17 通过三级门禁」，\n不得外推为 clean checkout 通过、远端已发布或 CI 已拦截。\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-17T16:16:17-07:00"},"CompareURL":"luoanwu/haimate/compare/66f0513cfb65a0eb27fe77ff8b5bd158c0901623...6b3be1dafc25b3d82703595f7542769eae6b7744","Len":3}...
|
1787008617
|
Edit
Delete
|
|
23255
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"66f0513cf {"Commits":[{"Sha1":"66f0513cfb65a0eb27fe77ff8b5bd158c0901623","Message":"docs(finance): 财务对账模块蓝图与 money 契约(在制品,尚无运行时消费方)\n\nADR-0010 + finance-reconciliation-blueprint + owner-matrix/domain-glossary 登记 +\npackages/contracts/src/money.ts。money.ts 未从 index 导出、双端零消费方,\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-14T16:07:13-07:00"},{"Sha1":"cc2759215b871373a7df54e410fb788f4c8cc8be","Message":"fix: 对抗性验收发现的三项修复——中文短词检索/分区覆盖/实时偶发\n\n- KbStore(双端): trigram 只为 ≥3 字符查询产出 trigram,2 字中文词(房态/报价)\n 命中 0 行且不抛错,原 LIKE 兜底只在抛错时触发 → 空结果继续走 LIKE 子串兜底;\n 双端各补 HTTP 层中文短词回归(负向测试:撤掉兜底两端同时红)\n- ApprovalsPanel: 补 approvals-pending/approvals-decided 语义容器与 e2e 分区断言。\n 实测原用例在分区回潮后仍全绿(零覆盖),新断言可让审批闭环用例由绿转红\n- e2e 实时断言 15s→30s: dispatcher 1s 轮询在并行负载下抖动导致偶发红;\n 放宽等待不掩盖回归,禁用 retries(会把真回归记成 flaky 且仍计入 uiTestsPassed)\n- 边界断言钉死 contracts 真实上限(200 放行/201 拒绝/未知参数 400)\n- CLAUDE.md G18 补记 UI 层实时偶发与\"禁用 retries\"纪律\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-14T16:07:03-07:00"}],"HeadCommit":{"Sha1":"66f0513cfb65a0eb27fe77ff8b5bd158c0901623","Message":"docs(finance): 财务对账模块蓝图与 money 契约(在制品,尚无运行时消费方)\n\nADR-0010 + finance-reconciliation-blueprint + owner-matrix/domain-glossary 登记 +\npackages/contracts/src/money.ts。money.ts 未从 index 导出、双端零消费方,\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-14T16:07:13-07:00"},"CompareURL":"luoanwu/haimate/compare/a7b05c570031d440008da58d5cd13d7c9097b687...66f0513cfb65a0eb27fe77ff8b5bd158c0901623","Len":2}...
|
1786748944
|
Edit
Delete
|
|
23254
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"a7b05c570 {"Commits":[{"Sha1":"a7b05c570031d440008da58d5cd13d7c9097b687","Message":"chore(reports): 刷新治理证据,绑定双远端对齐快照提交\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-14T15:24:05-07:00"},{"Sha1":"38a5b9eff3b427df3010450beb499ad886cd47f2","Message":"docs(governance): 发布状态快照——双远端 haimate 均对齐 950d7e3\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-14T15:24:05-07:00"}],"HeadCommit":{"Sha1":"a7b05c570031d440008da58d5cd13d7c9097b687","Message":"chore(reports): 刷新治理证据,绑定双远端对齐快照提交\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-14T15:24:05-07:00"},"CompareURL":"luoanwu/haimate/compare/950d7e3d2189ba40de3049c4f10df0cad414c691...a7b05c570031d440008da58d5cd13d7c9097b687","Len":2}...
|
1786746304
|
Edit
Delete
|
|
23253
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"950d7e3d2 {"Commits":[{"Sha1":"950d7e3d2189ba40de3049c4f10df0cad414c691","Message":"chore(reports): 刷新治理证据,绑定发布状态快照提交\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-14T15:17:56-07:00"},{"Sha1":"5261c63466442dec3dfed5282117e8e700d22aea","Message":"docs(governance): 发布状态快照切换为 haimate 独立远端事实\n\norigin=GitHub laoluojuhai/haimate(私有)已推送对齐;gitea 远端项目待建(push-to-create 关闭)。\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-14T15:17:56-07:00"},{"Sha1":"5aba5a36e8958a21696e895693aa69bdc54a3308","Message":"chore(reports): 刷新治理证据,绑定产品全景图归档提交(worktreeDirty=false)\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-14T15:09:08-07:00"},{"Sha1":"7e2efd8626198ee54b5c98a118eadfa349ead8f8","Message":"docs(product): 归档产品全景图 + 忽略 playwright-cli 调试产物\n\nmermaid 导出的产品全景图移入 docs/product/ 并在 README 登记(说明性快照,\n状态标注不作真源);.playwright-cli/ 为浏览器交互调试缓存,非验收证据,入 ignore。\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-14T15:08:55-07:00"},{"Sha1":"5f4af5cd5ddb5188f410e292d5066def03fcf982","Message":"chore(reports): 刷新治理证据,绑定 P0 收口加固提交\n\n静态门禁绑定 8c986f5;runtime(252 tests)/UI(11 用例)证据为提交前 dirty 工作区实跑,\nworktreeDirty=true 仅余未跟踪的 mermaid-diagram.svg(未入库的本地产物)。\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-14T15:04:05-07:00"}],"HeadCommit":{"Sha1":"950d7e3d2189ba40de3049c4f10df0cad414c691","Message":"chore(reports): 刷新治理证据,绑定发布状态快照提交\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-14T15:17:56-07:00"},"CompareURL":"luoanwu/haimate/compare/b4c2a8dcb155eeb7b28c2a2ee55520c649dd3d49...950d7e3d2189ba40de3049c4f10df0cad414c691","Len":10}...
|
1786746163
|
Edit
Delete
|
|
23252
|
5
|
5
|
5
|
74
|
0
|
0
|
refs/heads/main
|
0
|
|
1786746163
|
Edit
Delete
|
|
23251
|
5
|
1
|
5
|
74
|
0
|
0
|
|
0
|
|
1786746150
|
Edit
Delete
|
|
22535
|
5
|
5
|
5
|
73
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"5756bf365 {"Commits":[{"Sha1":"5756bf3650630520be67b4d5373a82937d065311","Message":"feat(content-analysis): add vocal score physical projection\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-13T03:30:36-07:00"}],"HeadCommit":{"Sha1":"5756bf3650630520be67b4d5373a82937d065311","Message":"feat(content-analysis): add vocal score physical projection\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-13T03:30:36-07:00"},"CompareURL":"luoanwu/highpraise-content-management-platform/compare/5adfbb1177c24e9a9ddb95ab1b5e5865baa60642...5756bf3650630520be67b4d5373a82937d065311","Len":1}...
|
1786617045
|
Edit
Delete
|
|
22446
|
5
|
5
|
5
|
73
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"5adfbb117 {"Commits":[{"Sha1":"5adfbb1177c24e9a9ddb95ab1b5e5865baa60642","Message":"feat(content-analysis): integrate canonical vocal score metrics\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-13T01:35:39-07:00"},{"Sha1":"e64a62b0b11460ac8ac0965fa3f755a6e23963a5","Message":"feat(content-analysis): add isolated vocal score gold metrics\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-13T00:43:04-07:00"},{"Sha1":"43f31bf8615c32aa70532927d9f34fcdcce68717","Message":"feat(score): harden evaluation eligibility\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-12T23:10:30-07:00"},{"Sha1":"5f47fc13a7039417186241b5f6d2a6fe60f0a0f8","Message":"fix(stem): align realtime endpoint and seal publish evidence\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-12T21:20:21-07:00"},{"Sha1":"3eb89b087903c1657bca1927cf18941a303029a1","Message":"feat(三线完善): run 工作台 + 评分真实链 + 舞谱回放对拍 + 灯谱修订对比；全量门禁首绿\n\n- Web：/content-analysis/runs 持久编排工作台（素材载入/歌词证据浏览器内容寻址/实时列表与详情）\n- 评分工作台接通 WAV→3351→DSP→P0 真实链（补 next.config DSP rewrite），DSP 成熟度徽标不弱化诚实边界\n- 舞谱工作台本地回放对拍（SHA 绑定回放源 + 播放头 + 越拍高亮）\n- 灯谱 RevisionDiffPanel（基准快照 cue 级 diff + 修订链视图）+ A–E 报告钻取\n- 注册表/门禁成对更新（integrationStatus、runs 工作台、activeScope）\n- 修复三处历史死断言（首页 spec 漂移）+ C16 式容器锚定；首页 runs 链接标签\n- 目标仓首次全绿：check:runtime 80 tests、check:ui 15 用例、pnpm check 含棘轮全通过，\n reportProvenanceViolations 13→0，棘轮地板收紧至 15 文件/95 用例/80 tests/15 UI 用例\n- CLAUDE.md 动态区 8 行基线表 + 4 段说明同步为目标仓新鲜证据口径\n\nCo-Authored-By: Claude Fable 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"ailaoluo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"ailaoluo","Timestamp":"2026-08-12T08:26:31-07:00"}],"HeadCommit":{"Sha1":"5adfbb1177c24e9a9ddb95ab1b5e5865baa60642","Message":"feat(content-analysis): integrate canonical vocal score metrics\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-13T01:35:39-07:00"},"CompareURL":"","Len":7}...
|
1786612368
|
Edit
Delete
|
|
22445
|
5
|
5
|
5
|
73
|
0
|
0
|
refs/heads/main
|
0
|
|
1786612368
|
Edit
Delete
|
|
22265
|
5
|
1
|
5
|
73
|
0
|
0
|
|
0
|
|
1786594169
|
Edit
Delete
|
|
26204
|
7
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"fc0729c51 {"Commits":[{"Sha1":"fc0729c51eaa6fb61e5c2c39bdc6d4bd30696570","Message":"fix(vm): make smoke honor the web base path\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:51:23+08:00"}],"HeadCommit":{"Sha1":"fc0729c51eaa6fb61e5c2c39bdc6d4bd30696570","Message":"fix(vm): make smoke honor the web base path\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:51:23+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/08df317afac31db70f0394580a0bb8686f49671c...fc0729c51eaa6fb61e5c2c39bdc6d4bd30696570","Len":1}...
|
1787723483
|
Edit
Delete
|
|
26123
|
7
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"08df317af {"Commits":[{"Sha1":"08df317afac31db70f0394580a0bb8686f49671c","Message":"Merge remote-tracking branch 'origin/codex/catalog-customer-quotation-workflows' into hljTest\n\n# Conflicts:\n#\tdeploy/vm/Dockerfile\n#\tscripts/lib/component-size.mjs\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:12:50+08:00"},{"Sha1":"8f11b6bc4df9f709414e306e9c9225bd45bccb65","Message":"feat: complete catalog customer and quotation workflows\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-24T01:18:51-07:00"},{"Sha1":"2de7545076ac90e4aa88e89cdf310f72ca9692ce","Message":"fix(vm): Prisma 生成物拷到运行时真正解析的位置——旧断言查的是拷贝目标而非读取路径\n\n`pnpm vm:up` 首次真跑起整栈，api-nestjs 容器启动即崩溃重启循环：\n`@prisma/client did not initialize yet. Please run \"prisma generate\"`。\n而构建期那条\"Prisma Client 必须在部署树里\"的断言是**绿的**。\n\n根因：`pnpm deploy` 把 @prisma/client 放进\n`node_modules/.pnpm/@prisma+client@\u003chash\u003e/node_modules/`，而 @prisma/client 是相对\n**自身**去找同级 `.prisma` 的——部署树顶层那份它根本不看。上一版把生成物拷到了顶层\n扁平路径，于是：\n- 运行时解析到 .pnpm 内嵌的那份，那是 @prisma/client **自带的桩**\n （`default.js` 第 43 行专门抛 \"did not initialize yet\"），没有 query engine；\n- 而断言 `test -d /runtime/\u003capp\u003e/node_modules/.prisma/client` 查的正是我刚拷过去的\n 顶层目录，\"往哪拷就查哪\"，必然通过。\n\n这是「断言检查的位置 ≠ 运行时读取的位置」，与 C23（typecheck 读 src、运行时读 dist）\n同型：不是断言写得弱，而是它锚在一条运行时不走的路径上。\n\n两处一起修：\n1. 拷贝目标改为 .pnpm 内嵌位置（顶层那份保留，覆盖 hoist 布局），glob 取不到即 fail。\n2. 断言改为**按运行时同一方式推导路径**（从 require.resolve('@prisma/client/package.json')\n 反推同级 .prisma），并断言 **query engine 二进制存在**——只 `test -d` 等于没查，\n 因为那个桩目录永远存在。\n\n负向测试（实跑）：去掉 .pnpm 拷贝那行后构建 EXIT=1，报\n`ERROR: no generated query engine at /runtime/api-nestjs/node_modules/.pnpm/@prisma+client@.../.prisma/client`\n——新断言会在构建期拦下这个 bug，而不是等容器启动才炸。\n\n证据（作用域＝本地工作区）：\n- pnpm vm:up 全流程通过：6 个服务全 healthy、migrate Exited(0)\n- 迁移真实应用到部署库（含 20260805120000_product_image_thumbnail /\n 20260807120000_quotation_void_and_restore）\n- 冒烟：Gateway + web + NestJS health passed；\n Write-chain smoke passed（create + read-back under a throwaway tenant）\n- 独立复核（不依赖脚本自述）：curl 网关 /api/health -\u003e ok(db=up,redis=up)、首页 200、\n 容器内 `new PrismaClient()` 实例化成功\n- pnpm check 22 项全绿 exit=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-17T17:36:43-07:00"}],"HeadCommit":{"Sha1":"08df317afac31db70f0394580a0bb8686f49671c","Message":"Merge remote-tracking branch 'origin/codex/catalog-customer-quotation-workflows' into hljTest\n\n# Conflicts:\n#\tdeploy/vm/Dockerfile\n#\tscripts/lib/component-size.mjs\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:12:50+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/04432cff2b306ecd33ca2bea6e2e256814f978f0...08df317afac31db70f0394580a0bb8686f49671c","Len":3}...
|
1787721223
|
Edit
Delete
|
|
24580
|
7
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"04432cff2 {"Commits":[{"Sha1":"04432cff2b306ecd33ca2bea6e2e256814f978f0","Message":"fix(web): preserve /jh authentication and realtime paths\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-20T16:25:36+08:00"}],"HeadCommit":{"Sha1":"04432cff2b306ecd33ca2bea6e2e256814f978f0","Message":"fix(web): preserve /jh authentication and realtime paths\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-20T16:25:36+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/083385f1c38217147aacf74d0f2251a65fbce450...04432cff2b306ecd33ca2bea6e2e256814f978f0","Len":1}...
|
1787214380
|
Edit
Delete
|
|
24190
|
7
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"083385f1c {"Commits":[{"Sha1":"083385f1c38217147aacf74d0f2251a65fbce450","Message":"feat(integrations): 接入报价优惠券核销\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-19T13:12:36+08:00"},{"Sha1":"be60de1f7e3c6183500ea7d65fc2bf039a86f1d0","Message":"Merge remote-tracking branch 'origin/main' into hljTest\n\n# Conflicts:\n#\tCLAUDE.md\n#\tapps/api-fastify/prisma/schema.prisma\n#\tapps/api-fastify/src/routes/quotations.ts\n#\tapps/api-nestjs/prisma/schema.prisma\n#\tapps/api-nestjs/src/quotations/quotations.service.ts\n#\tapps/web/src/features/quotations/api/quotations-api.ts\n#\tapps/web/src/features/quotations/components/PublicQuotationView.tsx\n#\tapps/web/src/hooks/useRealtime.ts\n#\tdeploy/vm/Dockerfile\n#\tdeploy/vm/compose.yaml\n#\tdocs/governance-experience.md\n#\tpackages/contracts/src/index.ts\n#\tpackages/contracts/src/quotation.ts\n#\tpackages/contracts/src/realtime.ts\n#\tscripts/vm-deploy.sh\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-19T09:54:43+08:00"},{"Sha1":"125c54d328d3da221b5d91c0a2dd0475712c6e96","Message":"Merge pull request #12 from laoluojuhai/fix/vm-dockerfile-build-path\n\nfix(vm): 打通容器构建路径——保住 slim 运行镜像，不靠放宽红线换构建成功","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T07:09:44-07:00"},{"Sha1":"6f13a78de9c02ae6a36fcebfb4bde63fbd092158","Message":"fix(vm): 打通容器构建路径——保住 slim 运行镜像，不靠放宽红线换构建成功\n\n`deploy/vm/Dockerfile` 的构建路径从未真正跑通过（并发治理会话只用 pnpm/turbo 跑门禁，\n从不 docker build）。而 check:vm-deploy 一直是绿的——它查 Dockerfile 的**结构**\n（每个 stage 用哪个 FROM、有没有 fat runtime），不查它**能不能构建出来**。\n于是棘轮报告写着「镜像瘦身非 root、可回滚、备份可恢复」✅，而那个镜像根本产不出来。\n\n5 处构建 bug：\n1. contracts 的 `prepare`(tsc) 在只有 manifest 的依赖层里跑，找不到 tsconfig/src → TS5058。\n 先 COPY contracts 的 tsconfig + src 给它当输入。\n2. 新 workspace 包 @repo/password-auth（两后端 runtime 依赖）未进 manifest COPY、\n 也没被显式 build。\n3. `pnpm deploy --prod --legacy`：pnpm 9.15.9 不认 `--legacy`（Unknown option）。\n 旧注释称「未开启 inject-workspace-packages 时需要 --legacy」——实测在本仓版本上\n 不成立，去掉即可正常打平 workspace 包（sharp 这类 lockfile 原生依赖也照常带出）。\n4. `pnpm deploy` 只按 lockfile 物化依赖，而 .prisma/client（含平台相关 query engine）\n 是 `prisma generate` **生成**的、不在任何 lockfile 里，永远不会被带出去 →\n 新增一步从 build 树复制。路径由 @prisma/client 的解析结果反推，不硬编码 pnpm store\n 的哈希目录名；且必须从 app 目录解析（workspace 根 node_modules 里没有它）。\n5. web stage `COPY apps/web/public` 失败——git 未跟踪任何 public 资产。\n ⚠️ 本机可能有个空的 public/（git 不跟踪空目录），docker build 读本地上下文因而能过，\n CI 与全新 clone 上必挂，注释已写明这个陷阱。\n\n**刻意不采用**此前 `dockerfile-vm-deploy-fixes-ec411c0.patch` 的策略（放弃 slim、\n运行镜像改 FROM build）：那会撞 4 条门禁红线（runtime-from-base-* / no-fat-runtime-*），\n而实测 slim 路径的两个阻塞点（3、4）都可解，「镜像瘦身作为后续项不阻塞」的前提不成立。\n体积实测：api-nestjs 741MB / api-fastify 695MB / web 546MB，\n对照 fat 方案 8.46GB、2026-08-06 实际部署的 2.69GB。非 root 由镜像层 USER node 保证，\n而非仅靠 compose 的 user: 覆盖。\n\n顺带两处断链（均为 MinIO 进 compose 后没人跟上）：\n- .env.example 与 vm:init 都不认识 S3_*，而它们是 compose 的必填变量 → 新机器\n `vm:init` 后 `vm:up` 必然卡在变量插值。已补占位符 + 随机生成 + 存量 .env 自愈。\n- .dockerignore 只写 `**/.next`，匹配不到本仓工具链自建的 distDir\n （.next-ui-* / .next-dev-* / .next-manual-*），也没排除 sites/（G26 那套独立\n Cloudflare 系统，其 .sites-runtime 本机 1.0GB）→ COPY . . 层 3.79GB → 270MB。\n\n证据（作用域＝本地工作区）：\n- docker build 四个 target 全部 EXIT=0（api-nestjs / api-fastify / web / migrate）\n- 镜像内实测 @prisma/client 与原生模块 sharp 均可加载、dist 入口就位、uid=1000 非 root\n- Dockerfile 里那条「Prisma Client 缺失即构建失败」的断言**首次真正执行并通过**\n- pnpm vm:config EXIT=0（7 个服务解析通过）\n- pnpm check 22 项全绿 exit=0\n\n未验证：未跑 vm:up / vm:smoke（整栈起停与真实写链冒烟），故不得宣称「可部署」。\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-17T06:57:55-07:00"},{"Sha1":"8ae98649e077fa188f8e9c1b0a11b78a2377c836","Message":"Merge pull request #11 from laoluojuhai/feat/product-catalog-search-and-image-upload\n\nfeat(products): 商品库服务端搜索筛选 + 图片上传至对象存储","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T04:16:44-07:00"}],"HeadCommit":{"Sha1":"083385f1c38217147aacf74d0f2251a65fbce450","Message":"feat(integrations): 接入报价优惠券核销\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-19T13:12:36+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/d2c99c9fc71e8a1c48d1aa3684c30ead3eb110c0...083385f1c38217147aacf74d0f2251a65fbce450","Len":51}...
|
1787116369
|
Edit
Delete
|
|
20364
|
7
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"d2c99c9fc {"Commits":[{"Sha1":"d2c99c9fc71e8a1c48d1aa3684c30ead3eb110c0","Message":"chore(dockerfile): drop leftover debug prints from prisma cp step\n\n前次 commit 进了 set -x + 多处 ls -la 调试输出。功能等价，纯粹清理。\ncp 失败时 echo message 从 \"cp ok for X\" 改成 \"cp prisma client for X: ok/FAIL\"\n以匹配同文件其他步骤的可读风格。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-03T15:03:44+08:00"},{"Sha1":"f97d67dbc0d53eeb203d205164c493a7b30a1116","Message":"chore: ship deployment integration + VM env layering\n\n合并远端 main 36 个新提交，并把本机部署整合的 basePath + BASE 双链路方案\n一起入仓；VM 镜像里 apt 镜像源抽成 APT_MIRROR build-arg，业务层/环境层解耦。\n\n业务/部署整合（来自 basePath 整合方案，对应 CLAUDE.md 真源地图「整合到\ngeneration.g-hi.com 的地址口径」）：\n\n- apps/web/next.config.ts: basePath '/jh'（与 songGeneration/voicePrintRecognition\n 同款），同时取并集远端的 output: 'standalone' + outputFileTracingRoot\n- apps/web/src/hooks/useRealtime.ts: SSE_BASE = BASE；defaultWebSocketUrl 区分\n 绝对 URL / 相对前缀两种情况\n- apps/web/src/lib/api.ts: BASE = NEXT_PUBLIC_API_URL || NEXT_PUBLIC_BASE_PATH ||\n ''（必须 || 不是 ??，build 时 env 是字符串 '' 非 null，?? 不会把空串当\n fallback），USER_ROLE 改 runtime（data-user-role）来自 layout.tsx\n- deploy/vm/nginx.conf: gateway 加 = /jh/ws { proxy_pass http://api-nestjs:3001/ws; }\n （显式 URI 剥 /jh 前缀，转发到 NestJS WsAdapter 实际注册路径 /ws）；/api/ /sse/\n 保留以便本机直连 8180（无前缀）调试\n- deploy/vm/compose.yaml: 与远端取并集（migrate 拆 target / non root / 资源\n 上限 / 日志轮转）\n- scripts/vm-deploy.sh: 显式注入 NEXT_PUBLIC_BASE_PATH 给 web 构建；与远端的\n IMAGE_TAG 时间戳机制取并集\n\n环境分层（Mac / 海外 CI / 国内 GFW 互不影响）：\n\n- deploy/vm/Dockerfile: 硬编码的 aliyun 源 sed 抽成 ARG APT_MIRROR=；\n vm-deploy.sh 自动从 .env 注入所有 build target；空 = 走 deb.debian.org 官方源\n- deploy/vm/.env.example: 文档化 APT_MIRROR 留空行为\n- 理由：之前硬编码 mirrors.aliyun.com 在 Mac/海外 CI 上 build 会做无用 sed\n 且让外人看不出这是环境特化；现在抽成 build-arg 任何环境只需一行配置\n\n部署 bug 修（不分环境，本机 pnpm 9.15 行为差异）：\n\n- deploy/vm/Dockerfile: 删 @repo/contracts 的 prepare 钩子（pnpm 9.15 跨\n workspace install 找不到子目录的 tsconfig.json）\n- deploy/vm/Dockerfile: 删 pnpm deploy --legacy（pnpm 9.7+ 已删除该 flag）\n- deploy/vm/Dockerfile: deploy 之后 cp -a --remove-destination 强制覆盖 .prisma/\n client；deploy 阶段的 @prisma/client postinstall 会把真实 client 还原成\n 2KB 占位，缺 17MB libquery_engine 二进制，runtime 抛 \"did not initialize\"\n- deploy/vm/Dockerfile: web 镜像 public 目录用 RUN mkdir -p 兜底（apps/web 当前\n 无 public 资产，但 next standalone 仍可能因目录存在与否决定路由）\n- deploy/vm/Dockerfile: runtime-base 阶段加 APT_MIRROR 注入（同 build 阶段）\n- packages/contracts/package.json: 删 prepare 字段（Dockerfile 显式\n pnpm --filter @repo/contracts build 触发）\n\nCLAUDE.md 同步（远端 36 提交 + 治理增量 +222 行）。\n\n验证：\n- pnpm check exit 0（5/5 packages，绿；ownTests=19, ownTestCases=227）\n- 部署到本机 tag 20260803T055150Z 后 /api/health 200，DB+Redis 探活正常\n- 5 个 juhai-quotation 容器 healthy（postgres/redis/api-nestjs/web/gateway）\n\n未覆盖：22 个 reports/*.latest.json（机器产物，commit 后下次 check 即变 dirty）\n与 packages/contracts/node-compile-cache/（node 22 编译缓存）未入 commit。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-03T14:34:32+08:00"}],"HeadCommit":{"Sha1":"d2c99c9fc71e8a1c48d1aa3684c30ead3eb110c0","Message":"chore(dockerfile): drop leftover debug prints from prisma cp step\n\n前次 commit 进了 set -x + 多处 ls -la 调试输出。功能等价，纯粹清理。\ncp 失败时 echo message 从 \"cp ok for X\" 改成 \"cp prisma client for X: ok/FAIL\"\n以匹配同文件其他步骤的可读风格。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-03T15:03:44+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/7619cf79681794bf28a8dceeb606c9dcfec21a5c...d2c99c9fc71e8a1c48d1aa3684c30ead3eb110c0","Len":2}...
|
1785740632
|
Edit
Delete
|
|
20362
|
7
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
|
1785740632
|
Edit
Delete
|
|
31179
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"6908c19f9 {"Commits":[{"Sha1":"6908c19f9faf3b006d73054657b97c6cb8f945d9","Message":"fix(quotation): 通知投递显式传重试上限——领取与死信判定不再各用一份常数\n\n服务里的 MAX_ATTEMPTS = 3 只进领取查询与死信清扫，decideNotificationFailure 没传 maxAttempts、\n走的是 @repo/notification-delivery 的包默认 3。今天两个 3 相等所以看不出来，改任一边即静默不一致：\n领取按新上限继续捡，死信判定仍按旧上限提前把行判死。同仓 event-delivery.service.ts 一直是显式传的。\n\n两后端各一行，语义不变。验证：typecheck 绿；pnpm check 22 道全绿；包单测 4/4 未受影响。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:06:42-07:00"}],"HeadCommit":{"Sha1":"6908c19f9faf3b006d73054657b97c6cb8f945d9","Message":"fix(quotation): 通知投递显式传重试上限——领取与死信判定不再各用一份常数\n\n服务里的 MAX_ATTEMPTS = 3 只进领取查询与死信清扫，decideNotificationFailure 没传 maxAttempts、\n走的是 @repo/notification-delivery 的包默认 3。今天两个 3 相等所以看不出来，改任一边即静默不一致：\n领取按新上限继续捡，死信判定仍按旧上限提前把行判死。同仓 event-delivery.service.ts 一直是显式传的。\n\n两后端各一行，语义不变。验证：typecheck 绿；pnpm check 22 道全绿；包单测 4/4 未受影响。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-18T16:06:42-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/ec9e07de44a5619a8a6b5648f00f5ea7f7dcafcf...6908c19f9faf3b006d73054657b97c6cb8f945d9","Len":1}...
|
1789772844
|
Edit
Delete
|
|
29814
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"ec9e07de4 {"Commits":[{"Sha1":"ec9e07de44a5619a8a6b5648f00f5ea7f7dcafcf","Message":"feat(quotation): 接入公共文件平台并补齐 outbox 重放与通知投递\n\n- 新增 packages/public-file，对象存储改走公共文件平台契约，\n 两端 object-storage 与 files 路由同步重构\n- 新增 outbox-operations 模块与路由，配套 outbox_replay_operations 迁移，\n 支持事件重放运维操作\n- 新增 notification-delivery 模块与 packages/notification-delivery，\n 配套 quotation_notification_delivery 迁移\n- packages/contracts 补 notification / outbox-operations 契约与测试\n- 刷新 reports 证据\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T19:52:39-07:00"}],"HeadCommit":{"Sha1":"ec9e07de44a5619a8a6b5648f00f5ea7f7dcafcf","Message":"feat(quotation): 接入公共文件平台并补齐 outbox 重放与通知投递\n\n- 新增 packages/public-file，对象存储改走公共文件平台契约，\n 两端 object-storage 与 files 路由同步重构\n- 新增 outbox-operations 模块与路由，配套 outbox_replay_operations 迁移，\n 支持事件重放运维操作\n- 新增 notification-delivery 模块与 packages/notification-delivery，\n 配套 quotation_notification_delivery 迁移\n- packages/contracts 补 notification / outbox-operations 契约与测试\n- 刷新 reports 证据\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-09-14T19:52:39-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/125c54d328d3da221b5d91c0a2dd0475712c6e96...ec9e07de44a5619a8a6b5648f00f5ea7f7dcafcf","Len":1}...
|
1789440856
|
Edit
Delete
|
|
26205
|
5
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"fc0729c51 {"Commits":[{"Sha1":"fc0729c51eaa6fb61e5c2c39bdc6d4bd30696570","Message":"fix(vm): make smoke honor the web base path\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:51:23+08:00"}],"HeadCommit":{"Sha1":"fc0729c51eaa6fb61e5c2c39bdc6d4bd30696570","Message":"fix(vm): make smoke honor the web base path\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:51:23+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/08df317afac31db70f0394580a0bb8686f49671c...fc0729c51eaa6fb61e5c2c39bdc6d4bd30696570","Len":1}...
|
1787723483
|
Edit
Delete
|
|
26124
|
5
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"08df317af {"Commits":[{"Sha1":"08df317afac31db70f0394580a0bb8686f49671c","Message":"Merge remote-tracking branch 'origin/codex/catalog-customer-quotation-workflows' into hljTest\n\n# Conflicts:\n#\tdeploy/vm/Dockerfile\n#\tscripts/lib/component-size.mjs\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:12:50+08:00"},{"Sha1":"8f11b6bc4df9f709414e306e9c9225bd45bccb65","Message":"feat: complete catalog customer and quotation workflows\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-24T01:18:51-07:00"},{"Sha1":"2de7545076ac90e4aa88e89cdf310f72ca9692ce","Message":"fix(vm): Prisma 生成物拷到运行时真正解析的位置——旧断言查的是拷贝目标而非读取路径\n\n`pnpm vm:up` 首次真跑起整栈，api-nestjs 容器启动即崩溃重启循环：\n`@prisma/client did not initialize yet. Please run \"prisma generate\"`。\n而构建期那条\"Prisma Client 必须在部署树里\"的断言是**绿的**。\n\n根因：`pnpm deploy` 把 @prisma/client 放进\n`node_modules/.pnpm/@prisma+client@\u003chash\u003e/node_modules/`，而 @prisma/client 是相对\n**自身**去找同级 `.prisma` 的——部署树顶层那份它根本不看。上一版把生成物拷到了顶层\n扁平路径，于是：\n- 运行时解析到 .pnpm 内嵌的那份，那是 @prisma/client **自带的桩**\n （`default.js` 第 43 行专门抛 \"did not initialize yet\"），没有 query engine；\n- 而断言 `test -d /runtime/\u003capp\u003e/node_modules/.prisma/client` 查的正是我刚拷过去的\n 顶层目录，\"往哪拷就查哪\"，必然通过。\n\n这是「断言检查的位置 ≠ 运行时读取的位置」，与 C23（typecheck 读 src、运行时读 dist）\n同型：不是断言写得弱，而是它锚在一条运行时不走的路径上。\n\n两处一起修：\n1. 拷贝目标改为 .pnpm 内嵌位置（顶层那份保留，覆盖 hoist 布局），glob 取不到即 fail。\n2. 断言改为**按运行时同一方式推导路径**（从 require.resolve('@prisma/client/package.json')\n 反推同级 .prisma），并断言 **query engine 二进制存在**——只 `test -d` 等于没查，\n 因为那个桩目录永远存在。\n\n负向测试（实跑）：去掉 .pnpm 拷贝那行后构建 EXIT=1，报\n`ERROR: no generated query engine at /runtime/api-nestjs/node_modules/.pnpm/@prisma+client@.../.prisma/client`\n——新断言会在构建期拦下这个 bug，而不是等容器启动才炸。\n\n证据（作用域＝本地工作区）：\n- pnpm vm:up 全流程通过：6 个服务全 healthy、migrate Exited(0)\n- 迁移真实应用到部署库（含 20260805120000_product_image_thumbnail /\n 20260807120000_quotation_void_and_restore）\n- 冒烟：Gateway + web + NestJS health passed；\n Write-chain smoke passed（create + read-back under a throwaway tenant）\n- 独立复核（不依赖脚本自述）：curl 网关 /api/health -\u003e ok(db=up,redis=up)、首页 200、\n 容器内 `new PrismaClient()` 实例化成功\n- pnpm check 22 项全绿 exit=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-17T17:36:43-07:00"}],"HeadCommit":{"Sha1":"08df317afac31db70f0394580a0bb8686f49671c","Message":"Merge remote-tracking branch 'origin/codex/catalog-customer-quotation-workflows' into hljTest\n\n# Conflicts:\n#\tdeploy/vm/Dockerfile\n#\tscripts/lib/component-size.mjs\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-26T13:12:50+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/04432cff2b306ecd33ca2bea6e2e256814f978f0...08df317afac31db70f0394580a0bb8686f49671c","Len":3}...
|
1787721223
|
Edit
Delete
|
|
25374
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/codex/catalog-customer-quotation-workfl refs/heads/codex/catalog-customer-quotation-workflows...
|
0
|
{"Commits":[{"Sha1":"8f11b6bc4 {"Commits":[{"Sha1":"8f11b6bc4df9f709414e306e9c9225bd45bccb65","Message":"feat: complete catalog customer and quotation workflows\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-24T01:18:51-07:00"}],"HeadCommit":{"Sha1":"8f11b6bc4df9f709414e306e9c9225bd45bccb65","Message":"feat: complete catalog customer and quotation workflows\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-24T01:18:51-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/2de7545076ac90e4aa88e89cdf310f72ca9692ce...8f11b6bc4df9f709414e306e9c9225bd45bccb65","Len":1}...
|
1787559678
|
Edit
Delete
|
|
25373
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/codex/catalog-customer-quotation-workfl refs/heads/codex/catalog-customer-quotation-workflows...
|
0
|
|
1787559677
|
Edit
Delete
|
|
25166
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/fix/vm-prisma-runtime-path
|
0
|
{"Commits":[{"Sha1":"2de754507 {"Commits":[{"Sha1":"2de7545076ac90e4aa88e89cdf310f72ca9692ce","Message":"fix(vm): Prisma 生成物拷到运行时真正解析的位置——旧断言查的是拷贝目标而非读取路径\n\n`pnpm vm:up` 首次真跑起整栈，api-nestjs 容器启动即崩溃重启循环：\n`@prisma/client did not initialize yet. Please run \"prisma generate\"`。\n而构建期那条\"Prisma Client 必须在部署树里\"的断言是**绿的**。\n\n根因：`pnpm deploy` 把 @prisma/client 放进\n`node_modules/.pnpm/@prisma+client@\u003chash\u003e/node_modules/`，而 @prisma/client 是相对\n**自身**去找同级 `.prisma` 的——部署树顶层那份它根本不看。上一版把生成物拷到了顶层\n扁平路径，于是：\n- 运行时解析到 .pnpm 内嵌的那份，那是 @prisma/client **自带的桩**\n （`default.js` 第 43 行专门抛 \"did not initialize yet\"），没有 query engine；\n- 而断言 `test -d /runtime/\u003capp\u003e/node_modules/.prisma/client` 查的正是我刚拷过去的\n 顶层目录，\"往哪拷就查哪\"，必然通过。\n\n这是「断言检查的位置 ≠ 运行时读取的位置」，与 C23（typecheck 读 src、运行时读 dist）\n同型：不是断言写得弱，而是它锚在一条运行时不走的路径上。\n\n两处一起修：\n1. 拷贝目标改为 .pnpm 内嵌位置（顶层那份保留，覆盖 hoist 布局），glob 取不到即 fail。\n2. 断言改为**按运行时同一方式推导路径**（从 require.resolve('@prisma/client/package.json')\n 反推同级 .prisma），并断言 **query engine 二进制存在**——只 `test -d` 等于没查，\n 因为那个桩目录永远存在。\n\n负向测试（实跑）：去掉 .pnpm 拷贝那行后构建 EXIT=1，报\n`ERROR: no generated query engine at /runtime/api-nestjs/node_modules/.pnpm/@prisma+client@.../.prisma/client`\n——新断言会在构建期拦下这个 bug，而不是等容器启动才炸。\n\n证据（作用域＝本地工作区）：\n- pnpm vm:up 全流程通过：6 个服务全 healthy、migrate Exited(0)\n- 迁移真实应用到部署库（含 20260805120000_product_image_thumbnail /\n 20260807120000_quotation_void_and_restore）\n- 冒烟：Gateway + web + NestJS health passed；\n Write-chain smoke passed（create + read-back under a throwaway tenant）\n- 独立复核（不依赖脚本自述）：curl 网关 /api/health -\u003e ok(db=up,redis=up)、首页 200、\n 容器内 `new PrismaClient()` 实例化成功\n- pnpm check 22 项全绿 exit=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-17T17:36:43-07:00"}],"HeadCommit":{"Sha1":"2de7545076ac90e4aa88e89cdf310f72ca9692ce","Message":"fix(vm): Prisma 生成物拷到运行时真正解析的位置——旧断言查的是拷贝目标而非读取路径\n\n`pnpm vm:up` 首次真跑起整栈，api-nestjs 容器启动即崩溃重启循环：\n`@prisma/client did not initialize yet. Please run \"prisma generate\"`。\n而构建期那条\"Prisma Client 必须在部署树里\"的断言是**绿的**。\n\n根因：`pnpm deploy` 把 @prisma/client 放进\n`node_modules/.pnpm/@prisma+client@\u003chash\u003e/node_modules/`，而 @prisma/client 是相对\n**自身**去找同级 `.prisma` 的——部署树顶层那份它根本不看。上一版把生成物拷到了顶层\n扁平路径，于是：\n- 运行时解析到 .pnpm 内嵌的那份，那是 @prisma/client **自带的桩**\n （`default.js` 第 43 行专门抛 \"did not initialize yet\"），没有 query engine；\n- 而断言 `test -d /runtime/\u003capp\u003e/node_modules/.prisma/client` 查的正是我刚拷过去的\n 顶层目录，\"往哪拷就查哪\"，必然通过。\n\n这是「断言检查的位置 ≠ 运行时读取的位置」，与 C23（typecheck 读 src、运行时读 dist）\n同型：不是断言写得弱，而是它锚在一条运行时不走的路径上。\n\n两处一起修：\n1. 拷贝目标改为 .pnpm 内嵌位置（顶层那份保留，覆盖 hoist 布局），glob 取不到即 fail。\n2. 断言改为**按运行时同一方式推导路径**（从 require.resolve('@prisma/client/package.json')\n 反推同级 .prisma），并断言 **query engine 二进制存在**——只 `test -d` 等于没查，\n 因为那个桩目录永远存在。\n\n负向测试（实跑）：去掉 .pnpm 拷贝那行后构建 EXIT=1，报\n`ERROR: no generated query engine at /runtime/api-nestjs/node_modules/.pnpm/@prisma+client@.../.prisma/client`\n——新断言会在构建期拦下这个 bug，而不是等容器启动才炸。\n\n证据（作用域＝本地工作区）：\n- pnpm vm:up 全流程通过：6 个服务全 healthy、migrate Exited(0)\n- 迁移真实应用到部署库（含 20260805120000_product_image_thumbnail /\n 20260807120000_quotation_void_and_restore）\n- 冒烟：Gateway + web + NestJS health passed；\n Write-chain smoke passed（create + read-back under a throwaway tenant）\n- 独立复核（不依赖脚本自述）：curl 网关 /api/health -\u003e ok(db=up,redis=up)、首页 200、\n 容器内 `new PrismaClient()` 实例化成功\n- pnpm check 22 项全绿 exit=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-17T17:36:43-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/125c54d328d3da221b5d91c0a2dd0475712c6e96...2de7545076ac90e4aa88e89cdf310f72ca9692ce","Len":1}...
|
1787540013
|
Edit
Delete
|
|
25165
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/fix/vm-prisma-runtime-path
|
0
|
|
1787540013
|
Edit
Delete
|
|
24581
|
5
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"04432cff2 {"Commits":[{"Sha1":"04432cff2b306ecd33ca2bea6e2e256814f978f0","Message":"fix(web): preserve /jh authentication and realtime paths\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-20T16:25:36+08:00"}],"HeadCommit":{"Sha1":"04432cff2b306ecd33ca2bea6e2e256814f978f0","Message":"fix(web): preserve /jh authentication and realtime paths\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-20T16:25:36+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/083385f1c38217147aacf74d0f2251a65fbce450...04432cff2b306ecd33ca2bea6e2e256814f978f0","Len":1}...
|
1787214380
|
Edit
Delete
|
|
24191
|
5
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
{"Commits":[{"Sha1":"083385f1c {"Commits":[{"Sha1":"083385f1c38217147aacf74d0f2251a65fbce450","Message":"feat(integrations): 接入报价优惠券核销\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-19T13:12:36+08:00"},{"Sha1":"be60de1f7e3c6183500ea7d65fc2bf039a86f1d0","Message":"Merge remote-tracking branch 'origin/main' into hljTest\n\n# Conflicts:\n#\tCLAUDE.md\n#\tapps/api-fastify/prisma/schema.prisma\n#\tapps/api-fastify/src/routes/quotations.ts\n#\tapps/api-nestjs/prisma/schema.prisma\n#\tapps/api-nestjs/src/quotations/quotations.service.ts\n#\tapps/web/src/features/quotations/api/quotations-api.ts\n#\tapps/web/src/features/quotations/components/PublicQuotationView.tsx\n#\tapps/web/src/hooks/useRealtime.ts\n#\tdeploy/vm/Dockerfile\n#\tdeploy/vm/compose.yaml\n#\tdocs/governance-experience.md\n#\tpackages/contracts/src/index.ts\n#\tpackages/contracts/src/quotation.ts\n#\tpackages/contracts/src/realtime.ts\n#\tscripts/vm-deploy.sh\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-19T09:54:43+08:00"},{"Sha1":"125c54d328d3da221b5d91c0a2dd0475712c6e96","Message":"Merge pull request #12 from laoluojuhai/fix/vm-dockerfile-build-path\n\nfix(vm): 打通容器构建路径——保住 slim 运行镜像，不靠放宽红线换构建成功","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T07:09:44-07:00"},{"Sha1":"6f13a78de9c02ae6a36fcebfb4bde63fbd092158","Message":"fix(vm): 打通容器构建路径——保住 slim 运行镜像，不靠放宽红线换构建成功\n\n`deploy/vm/Dockerfile` 的构建路径从未真正跑通过（并发治理会话只用 pnpm/turbo 跑门禁，\n从不 docker build）。而 check:vm-deploy 一直是绿的——它查 Dockerfile 的**结构**\n（每个 stage 用哪个 FROM、有没有 fat runtime），不查它**能不能构建出来**。\n于是棘轮报告写着「镜像瘦身非 root、可回滚、备份可恢复」✅，而那个镜像根本产不出来。\n\n5 处构建 bug：\n1. contracts 的 `prepare`(tsc) 在只有 manifest 的依赖层里跑，找不到 tsconfig/src → TS5058。\n 先 COPY contracts 的 tsconfig + src 给它当输入。\n2. 新 workspace 包 @repo/password-auth（两后端 runtime 依赖）未进 manifest COPY、\n 也没被显式 build。\n3. `pnpm deploy --prod --legacy`：pnpm 9.15.9 不认 `--legacy`（Unknown option）。\n 旧注释称「未开启 inject-workspace-packages 时需要 --legacy」——实测在本仓版本上\n 不成立，去掉即可正常打平 workspace 包（sharp 这类 lockfile 原生依赖也照常带出）。\n4. `pnpm deploy` 只按 lockfile 物化依赖，而 .prisma/client（含平台相关 query engine）\n 是 `prisma generate` **生成**的、不在任何 lockfile 里，永远不会被带出去 →\n 新增一步从 build 树复制。路径由 @prisma/client 的解析结果反推，不硬编码 pnpm store\n 的哈希目录名；且必须从 app 目录解析（workspace 根 node_modules 里没有它）。\n5. web stage `COPY apps/web/public` 失败——git 未跟踪任何 public 资产。\n ⚠️ 本机可能有个空的 public/（git 不跟踪空目录），docker build 读本地上下文因而能过，\n CI 与全新 clone 上必挂，注释已写明这个陷阱。\n\n**刻意不采用**此前 `dockerfile-vm-deploy-fixes-ec411c0.patch` 的策略（放弃 slim、\n运行镜像改 FROM build）：那会撞 4 条门禁红线（runtime-from-base-* / no-fat-runtime-*），\n而实测 slim 路径的两个阻塞点（3、4）都可解，「镜像瘦身作为后续项不阻塞」的前提不成立。\n体积实测：api-nestjs 741MB / api-fastify 695MB / web 546MB，\n对照 fat 方案 8.46GB、2026-08-06 实际部署的 2.69GB。非 root 由镜像层 USER node 保证，\n而非仅靠 compose 的 user: 覆盖。\n\n顺带两处断链（均为 MinIO 进 compose 后没人跟上）：\n- .env.example 与 vm:init 都不认识 S3_*，而它们是 compose 的必填变量 → 新机器\n `vm:init` 后 `vm:up` 必然卡在变量插值。已补占位符 + 随机生成 + 存量 .env 自愈。\n- .dockerignore 只写 `**/.next`，匹配不到本仓工具链自建的 distDir\n （.next-ui-* / .next-dev-* / .next-manual-*），也没排除 sites/（G26 那套独立\n Cloudflare 系统，其 .sites-runtime 本机 1.0GB）→ COPY . . 层 3.79GB → 270MB。\n\n证据（作用域＝本地工作区）：\n- docker build 四个 target 全部 EXIT=0（api-nestjs / api-fastify / web / migrate）\n- 镜像内实测 @prisma/client 与原生模块 sharp 均可加载、dist 入口就位、uid=1000 非 root\n- Dockerfile 里那条「Prisma Client 缺失即构建失败」的断言**首次真正执行并通过**\n- pnpm vm:config EXIT=0（7 个服务解析通过）\n- pnpm check 22 项全绿 exit=0\n\n未验证：未跑 vm:up / vm:smoke（整栈起停与真实写链冒烟），故不得宣称「可部署」。\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-17T06:57:55-07:00"},{"Sha1":"8ae98649e077fa188f8e9c1b0a11b78a2377c836","Message":"Merge pull request #11 from laoluojuhai/feat/product-catalog-search-and-image-upload\n\nfeat(products): 商品库服务端搜索筛选 + 图片上传至对象存储","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T04:16:44-07:00"}],"HeadCommit":{"Sha1":"083385f1c38217147aacf74d0f2251a65fbce450","Message":"feat(integrations): 接入报价优惠券核销\n\nCo-authored-by: Qwen-Coder \u003cqwen-coder@alibabacloud.com\u003e\n","AuthorEmail":"hlj@g-hi.com","AuthorName":"huangliujian","CommitterEmail":"hlj@g-hi.com","CommitterName":"huangliujian","Timestamp":"2026-08-19T13:12:36+08:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/d2c99c9fc71e8a1c48d1aa3684c30ead3eb110c0...083385f1c38217147aacf74d0f2251a65fbce450","Len":51}...
|
1787116369
|
Edit
Delete
|
|
23627
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"125c54d32 {"Commits":[{"Sha1":"125c54d328d3da221b5d91c0a2dd0475712c6e96","Message":"Merge pull request #12 from laoluojuhai/fix/vm-dockerfile-build-path\n\nfix(vm): 打通容器构建路径——保住 slim 运行镜像，不靠放宽红线换构建成功","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T07:09:44-07:00"},{"Sha1":"6f13a78de9c02ae6a36fcebfb4bde63fbd092158","Message":"fix(vm): 打通容器构建路径——保住 slim 运行镜像，不靠放宽红线换构建成功\n\n`deploy/vm/Dockerfile` 的构建路径从未真正跑通过（并发治理会话只用 pnpm/turbo 跑门禁，\n从不 docker build）。而 check:vm-deploy 一直是绿的——它查 Dockerfile 的**结构**\n（每个 stage 用哪个 FROM、有没有 fat runtime），不查它**能不能构建出来**。\n于是棘轮报告写着「镜像瘦身非 root、可回滚、备份可恢复」✅，而那个镜像根本产不出来。\n\n5 处构建 bug：\n1. contracts 的 `prepare`(tsc) 在只有 manifest 的依赖层里跑，找不到 tsconfig/src → TS5058。\n 先 COPY contracts 的 tsconfig + src 给它当输入。\n2. 新 workspace 包 @repo/password-auth（两后端 runtime 依赖）未进 manifest COPY、\n 也没被显式 build。\n3. `pnpm deploy --prod --legacy`：pnpm 9.15.9 不认 `--legacy`（Unknown option）。\n 旧注释称「未开启 inject-workspace-packages 时需要 --legacy」——实测在本仓版本上\n 不成立，去掉即可正常打平 workspace 包（sharp 这类 lockfile 原生依赖也照常带出）。\n4. `pnpm deploy` 只按 lockfile 物化依赖，而 .prisma/client（含平台相关 query engine）\n 是 `prisma generate` **生成**的、不在任何 lockfile 里，永远不会被带出去 →\n 新增一步从 build 树复制。路径由 @prisma/client 的解析结果反推，不硬编码 pnpm store\n 的哈希目录名；且必须从 app 目录解析（workspace 根 node_modules 里没有它）。\n5. web stage `COPY apps/web/public` 失败——git 未跟踪任何 public 资产。\n ⚠️ 本机可能有个空的 public/（git 不跟踪空目录），docker build 读本地上下文因而能过，\n CI 与全新 clone 上必挂，注释已写明这个陷阱。\n\n**刻意不采用**此前 `dockerfile-vm-deploy-fixes-ec411c0.patch` 的策略（放弃 slim、\n运行镜像改 FROM build）：那会撞 4 条门禁红线（runtime-from-base-* / no-fat-runtime-*），\n而实测 slim 路径的两个阻塞点（3、4）都可解，「镜像瘦身作为后续项不阻塞」的前提不成立。\n体积实测：api-nestjs 741MB / api-fastify 695MB / web 546MB，\n对照 fat 方案 8.46GB、2026-08-06 实际部署的 2.69GB。非 root 由镜像层 USER node 保证，\n而非仅靠 compose 的 user: 覆盖。\n\n顺带两处断链（均为 MinIO 进 compose 后没人跟上）：\n- .env.example 与 vm:init 都不认识 S3_*，而它们是 compose 的必填变量 → 新机器\n `vm:init` 后 `vm:up` 必然卡在变量插值。已补占位符 + 随机生成 + 存量 .env 自愈。\n- .dockerignore 只写 `**/.next`，匹配不到本仓工具链自建的 distDir\n （.next-ui-* / .next-dev-* / .next-manual-*），也没排除 sites/（G26 那套独立\n Cloudflare 系统，其 .sites-runtime 本机 1.0GB）→ COPY . . 层 3.79GB → 270MB。\n\n证据（作用域＝本地工作区）：\n- docker build 四个 target 全部 EXIT=0（api-nestjs / api-fastify / web / migrate）\n- 镜像内实测 @prisma/client 与原生模块 sharp 均可加载、dist 入口就位、uid=1000 非 root\n- Dockerfile 里那条「Prisma Client 缺失即构建失败」的断言**首次真正执行并通过**\n- pnpm vm:config EXIT=0（7 个服务解析通过）\n- pnpm check 22 项全绿 exit=0\n\n未验证：未跑 vm:up / vm:smoke（整栈起停与真实写链冒烟），故不得宣称「可部署」。\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-17T06:57:55-07:00"}],"HeadCommit":{"Sha1":"125c54d328d3da221b5d91c0a2dd0475712c6e96","Message":"Merge pull request #12 from laoluojuhai/fix/vm-dockerfile-build-path\n\nfix(vm): 打通容器构建路径——保住 slim 运行镜像，不靠放宽红线换构建成功","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T07:09:44-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/8ae98649e077fa188f8e9c1b0a11b78a2377c836...125c54d328d3da221b5d91c0a2dd0475712c6e96","Len":2}...
|
1786975808
|
Edit
Delete
|
|
23626
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/main
|
0
|
{"Commits":[{"Sha1":"8ae98649e {"Commits":[{"Sha1":"8ae98649e077fa188f8e9c1b0a11b78a2377c836","Message":"Merge pull request #11 from laoluojuhai/feat/product-catalog-search-and-image-upload\n\nfeat(products): 商品库服务端搜索筛选 + 图片上传至对象存储","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T04:16:44-07:00"},{"Sha1":"6a67a7abf58201b2b407aab3e500b463d3f08bc7","Message":"Merge branch 'feat/product-catalog-search-and-image-upload' of https://github.com/laoluojuhai/juhai-quotation-system into feat/product-catalog-search-and-image-upload\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-17T04:04:06-07:00"},{"Sha1":"874115874d1ce6a322367e0553a620a531ebdaf9","Message":"fix(e2e): 修两条潜伏五天的失效断言——\u0026\u0026 串行链把 UI 验收挡在门外\n\n上一条提交让 static governance 转绿后，CI 的 Runtime and UI acceptance 才**首次真正\n跑起来**（自 2026-08-06 起每轮都是 SKIPPED），当场暴露两条 E2E 失效断言。二者均由\n35ebc86（2026-08-12）改文案引入而断言没跟上，与本轮重构无关：\n\n① 侧栏入口叫「报价审核」，子页标题已改为「待我审核」——入口名与标题是两个口径，\n 不能因为同一个入口就复用同一个词。\n② 版本徽标由「版本 1」改为紧凑的「v1」（与版本中心的「V1」看齐）。\n 断言收紧为 /·\\s*v1\\s*·/：裸 `v1` 会被报价号或客户名里任何含 v1 的片段撞上，\n 会让断言以错误理由变绿，那恰恰是它该防的漂移。\n\nmodule-integration 的浏览器证据标记同步跟到**标题**而非入口名——写成入口名会被\nopenWorkspaceEntry(page, \"报价审核\") 白白喂饱，标记就不再证明任何事（负向实测：\n把 E2E 里该断言改掉即 exit=1 并命中 browser-name: \"待我审核\"）。\n\n顺带删掉上一条提交遗留的死代码：权限判据已随创建卡下沉进 QuotationCreateCard，\nQuotationWorkbench 里的 userCan 不再有消费者，留着会让下一个人以为还有权限逻辑要接。\n\n三级门禁证据（作用域＝本地工作区）：\n- 静态 pnpm check：22 项全绿 exit=0，16 组负向自检有牙\n- check:runtime：548/548（地板 503；contracts 436 + NestJS 56 + Fastify 56）\n- check:ui：12/12 全绿\n\n教训已回灌 CLAUDE.md：串行 \u0026\u0026 门禁链报出的违规数是**下界不是总数**，\n本轮 CI 报「共 1 处违规」，实际是 4 处静态 + 2 处 E2E。\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-17T04:03:39-07:00"},{"Sha1":"c7d8d5944215315512254bb9a8f6cc2bd937c88f","Message":"Merge branch 'main' into feat/product-catalog-search-and-image-upload","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T03:48:25-07:00"},{"Sha1":"3afb568a1d13a2ceeaf49a2a9bf1d8634f422c23","Message":"fix(gate): 版本中心断言重锚为结构式——距离窗口误杀且漏杀，顺带逼出报价域拆分\n\nPR #11 的 CI 红在 quotation-version-detail-visible。查证为**门禁误杀**：版本中心的\n快照详情一直正常渲染（浏览器实测展开 V1 可见「经济方案 ¥910,000.00 · 1 项明细」），\n只是行内补了 diff 段落与三段设计裁决注释后，两个锚点间距涨到 1309 字符、超过\n{0,500} 距离窗口（after-sales-order-options-hook 同型，本仓第二次踩）。\n\n断言重锚为否定环视 (?:(?!\u003c\\/details\u003e)[\\s\\S])*，语义由「两锚点挨得近」改为\n「快照摘要在版本行元素内部」。差分真值表显示旧写法 4 例错 2 例、两个方向都错：\n不仅误杀，还漏杀「快照挪到行外但离得近」——重锚顺手补上那个洞，并固化为\ncontract-integration.test.mjs 第 24b 条负向用例（实跑 exit=1 且命中预期断言 id）。\n\ncomponent-size 同轮逼出真拆分（门禁明说「先拆分而不是上调登记值」）：\n- QuotationWorkbench 661→169：创建卡连同表单状态提为 QuotationCreateCard、\n 单档编辑器提为 QuotationOptionEditor、版本中心提为 QuotationVersionCenter\n- MobileOverview 473→413：报价经营四指标卡提为 OverviewQuoteMetrics\n全部抽为**同文件兄弟组件**——搬到独立文件会让按路径锚定的门禁锚点落空。\nQuotationCreateCard 刻意始终挂载、在 hooks 之后才 return null，保证候选查询的\n发起时机与重构前逐字一致（只搬行不改行为）。登记值同步下调/毕业锁住进步。\n\n⚠️ 抽 OverviewQuoteMetrics 时一度把三元中段当 JSX 搬走并用 \u003c\u003e 包裹，`) : (`\n降格为文本节点原样上屏，且两个分支同时渲染——给有权限的管理员显示「未向当前\n角色开放」。tsc 与 22 项静态门禁全绿，只有浏览器截图抓得到。已修并留档。\n\n证据（作用域＝本地工作区）：pnpm check 22 项全绿 exit=0、16 组负向自检有牙、\n浏览器实测总览/新建报价/版本中心三处渲染正常。未重跑 check:runtime / check:ui\n（两后端与 contracts 一行未动，那两级证据仍绑定上一轮 commit）。\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-17T03:47:39-07:00"}],"HeadCommit":{"Sha1":"8ae98649e077fa188f8e9c1b0a11b78a2377c836","Message":"Merge pull request #11 from laoluojuhai/feat/product-catalog-search-and-image-upload\n\nfeat(products): 商品库服务端搜索筛选 + 图片上传至对象存储","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T04:16:44-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/7619cf79681794bf28a8dceeb606c9dcfec21a5c...8ae98649e077fa188f8e9c1b0a11b78a2377c836","Len":41}...
|
1786965499
|
Edit
Delete
|
|
23625
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/product-catalog-search-and-image-u refs/heads/feat/product-catalog-search-and-image-upload...
|
0
|
{"Commits":[{"Sha1":"6a67a7abf {"Commits":[{"Sha1":"6a67a7abf58201b2b407aab3e500b463d3f08bc7","Message":"Merge branch 'feat/product-catalog-search-and-image-upload' of https://github.com/laoluojuhai/juhai-quotation-system into feat/product-catalog-search-and-image-upload\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-17T04:04:06-07:00"},{"Sha1":"c7d8d5944215315512254bb9a8f6cc2bd937c88f","Message":"Merge branch 'main' into feat/product-catalog-search-and-image-upload","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-17T03:48:25-07:00"},{"Sha1":"e3fc771d3e1769a970dd0638d0ce694fae74a023","Message":"Merge pull request #8 from laoluojuhai/feat/g8-verified-auth\n\nfeat(g8): 已验签身份落地 + 业务闭环五切片 + 工作区卫生门禁","AuthorEmail":"158980461+laoluojuhai@users.noreply.github.com","AuthorName":"laoluojuhai","CommitterEmail":"noreply@github.com","CommitterName":"GitHub","Timestamp":"2026-08-02T19:06:51-07:00"}],"HeadCommit":{"Sha1":"6a67a7abf58201b2b407aab3e500b463d3f08bc7","Message":"Merge branch 'feat/product-catalog-search-and-image-upload' of https://github.com/laoluojuhai/juhai-quotation-system into feat/product-catalog-search-and-image-upload\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-17T04:04:06-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/874115874d1ce6a322367e0553a620a531ebdaf9...6a67a7abf58201b2b407aab3e500b463d3f08bc7","Len":3}...
|
1786964711
|
Edit
Delete
|
|
23624
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/product-catalog-search-and-image-u refs/heads/feat/product-catalog-search-and-image-upload...
|
0
|
{"Commits":[{"Sha1":"874115874 {"Commits":[{"Sha1":"874115874d1ce6a322367e0553a620a531ebdaf9","Message":"fix(e2e): 修两条潜伏五天的失效断言——\u0026\u0026 串行链把 UI 验收挡在门外\n\n上一条提交让 static governance 转绿后，CI 的 Runtime and UI acceptance 才**首次真正\n跑起来**（自 2026-08-06 起每轮都是 SKIPPED），当场暴露两条 E2E 失效断言。二者均由\n35ebc86（2026-08-12）改文案引入而断言没跟上，与本轮重构无关：\n\n① 侧栏入口叫「报价审核」，子页标题已改为「待我审核」——入口名与标题是两个口径，\n 不能因为同一个入口就复用同一个词。\n② 版本徽标由「版本 1」改为紧凑的「v1」（与版本中心的「V1」看齐）。\n 断言收紧为 /·\\s*v1\\s*·/：裸 `v1` 会被报价号或客户名里任何含 v1 的片段撞上，\n 会让断言以错误理由变绿，那恰恰是它该防的漂移。\n\nmodule-integration 的浏览器证据标记同步跟到**标题**而非入口名——写成入口名会被\nopenWorkspaceEntry(page, \"报价审核\") 白白喂饱，标记就不再证明任何事（负向实测：\n把 E2E 里该断言改掉即 exit=1 并命中 browser-name: \"待我审核\"）。\n\n顺带删掉上一条提交遗留的死代码：权限判据已随创建卡下沉进 QuotationCreateCard，\nQuotationWorkbench 里的 userCan 不再有消费者，留着会让下一个人以为还有权限逻辑要接。\n\n三级门禁证据（作用域＝本地工作区）：\n- 静态 pnpm check：22 项全绿 exit=0，16 组负向自检有牙\n- check:runtime：548/548（地板 503；contracts 436 + NestJS 56 + Fastify 56）\n- check:ui：12/12 全绿\n\n教训已回灌 CLAUDE.md：串行 \u0026\u0026 门禁链报出的违规数是**下界不是总数**，\n本轮 CI 报「共 1 处违规」，实际是 4 处静态 + 2 处 E2E。\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-17T04:03:39-07:00"}],"HeadCommit":{"Sha1":"874115874d1ce6a322367e0553a620a531ebdaf9","Message":"fix(e2e): 修两条潜伏五天的失效断言——\u0026\u0026 串行链把 UI 验收挡在门外\n\n上一条提交让 static governance 转绿后，CI 的 Runtime and UI acceptance 才**首次真正\n跑起来**（自 2026-08-06 起每轮都是 SKIPPED），当场暴露两条 E2E 失效断言。二者均由\n35ebc86（2026-08-12）改文案引入而断言没跟上，与本轮重构无关：\n\n① 侧栏入口叫「报价审核」，子页标题已改为「待我审核」——入口名与标题是两个口径，\n 不能因为同一个入口就复用同一个词。\n② 版本徽标由「版本 1」改为紧凑的「v1」（与版本中心的「V1」看齐）。\n 断言收紧为 /·\\s*v1\\s*·/：裸 `v1` 会被报价号或客户名里任何含 v1 的片段撞上，\n 会让断言以错误理由变绿，那恰恰是它该防的漂移。\n\nmodule-integration 的浏览器证据标记同步跟到**标题**而非入口名——写成入口名会被\nopenWorkspaceEntry(page, \"报价审核\") 白白喂饱，标记就不再证明任何事（负向实测：\n把 E2E 里该断言改掉即 exit=1 并命中 browser-name: \"待我审核\"）。\n\n顺带删掉上一条提交遗留的死代码：权限判据已随创建卡下沉进 QuotationCreateCard，\nQuotationWorkbench 里的 userCan 不再有消费者，留着会让下一个人以为还有权限逻辑要接。\n\n三级门禁证据（作用域＝本地工作区）：\n- 静态 pnpm check：22 项全绿 exit=0，16 组负向自检有牙\n- check:runtime：548/548（地板 503；contracts 436 + NestJS 56 + Fastify 56）\n- check:ui：12/12 全绿\n\n教训已回灌 CLAUDE.md：串行 \u0026\u0026 门禁链报出的违规数是**下界不是总数**，\n本轮 CI 报「共 1 处违规」，实际是 4 处静态 + 2 处 E2E。\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-17T04:03:39-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/3afb568a1d13a2ceeaf49a2a9bf1d8634f422c23...874115874d1ce6a322367e0553a620a531ebdaf9","Len":1}...
|
1786964630
|
Edit
Delete
|
|
23623
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/product-catalog-search-and-image-u refs/heads/feat/product-catalog-search-and-image-upload...
|
0
|
{"Commits":[{"Sha1":"3afb568a1 {"Commits":[{"Sha1":"3afb568a1d13a2ceeaf49a2a9bf1d8634f422c23","Message":"fix(gate): 版本中心断言重锚为结构式——距离窗口误杀且漏杀，顺带逼出报价域拆分\n\nPR #11 的 CI 红在 quotation-version-detail-visible。查证为**门禁误杀**：版本中心的\n快照详情一直正常渲染（浏览器实测展开 V1 可见「经济方案 ¥910,000.00 · 1 项明细」），\n只是行内补了 diff 段落与三段设计裁决注释后，两个锚点间距涨到 1309 字符、超过\n{0,500} 距离窗口（after-sales-order-options-hook 同型，本仓第二次踩）。\n\n断言重锚为否定环视 (?:(?!\u003c\\/details\u003e)[\\s\\S])*，语义由「两锚点挨得近」改为\n「快照摘要在版本行元素内部」。差分真值表显示旧写法 4 例错 2 例、两个方向都错：\n不仅误杀，还漏杀「快照挪到行外但离得近」——重锚顺手补上那个洞，并固化为\ncontract-integration.test.mjs 第 24b 条负向用例（实跑 exit=1 且命中预期断言 id）。\n\ncomponent-size 同轮逼出真拆分（门禁明说「先拆分而不是上调登记值」）：\n- QuotationWorkbench 661→169：创建卡连同表单状态提为 QuotationCreateCard、\n 单档编辑器提为 QuotationOptionEditor、版本中心提为 QuotationVersionCenter\n- MobileOverview 473→413：报价经营四指标卡提为 OverviewQuoteMetrics\n全部抽为**同文件兄弟组件**——搬到独立文件会让按路径锚定的门禁锚点落空。\nQuotationCreateCard 刻意始终挂载、在 hooks 之后才 return null，保证候选查询的\n发起时机与重构前逐字一致（只搬行不改行为）。登记值同步下调/毕业锁住进步。\n\n⚠️ 抽 OverviewQuoteMetrics 时一度把三元中段当 JSX 搬走并用 \u003c\u003e 包裹，`) : (`\n降格为文本节点原样上屏，且两个分支同时渲染——给有权限的管理员显示「未向当前\n角色开放」。tsc 与 22 项静态门禁全绿，只有浏览器截图抓得到。已修并留档。\n\n证据（作用域＝本地工作区）：pnpm check 22 项全绿 exit=0、16 组负向自检有牙、\n浏览器实测总览/新建报价/版本中心三处渲染正常。未重跑 check:runtime / check:ui\n（两后端与 contracts 一行未动，那两级证据仍绑定上一轮 commit）。\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-17T03:47:39-07:00"}],"HeadCommit":{"Sha1":"3afb568a1d13a2ceeaf49a2a9bf1d8634f422c23","Message":"fix(gate): 版本中心断言重锚为结构式——距离窗口误杀且漏杀，顺带逼出报价域拆分\n\nPR #11 的 CI 红在 quotation-version-detail-visible。查证为**门禁误杀**：版本中心的\n快照详情一直正常渲染（浏览器实测展开 V1 可见「经济方案 ¥910,000.00 · 1 项明细」），\n只是行内补了 diff 段落与三段设计裁决注释后，两个锚点间距涨到 1309 字符、超过\n{0,500} 距离窗口（after-sales-order-options-hook 同型，本仓第二次踩）。\n\n断言重锚为否定环视 (?:(?!\u003c\\/details\u003e)[\\s\\S])*，语义由「两锚点挨得近」改为\n「快照摘要在版本行元素内部」。差分真值表显示旧写法 4 例错 2 例、两个方向都错：\n不仅误杀，还漏杀「快照挪到行外但离得近」——重锚顺手补上那个洞，并固化为\ncontract-integration.test.mjs 第 24b 条负向用例（实跑 exit=1 且命中预期断言 id）。\n\ncomponent-size 同轮逼出真拆分（门禁明说「先拆分而不是上调登记值」）：\n- QuotationWorkbench 661→169：创建卡连同表单状态提为 QuotationCreateCard、\n 单档编辑器提为 QuotationOptionEditor、版本中心提为 QuotationVersionCenter\n- MobileOverview 473→413：报价经营四指标卡提为 OverviewQuoteMetrics\n全部抽为**同文件兄弟组件**——搬到独立文件会让按路径锚定的门禁锚点落空。\nQuotationCreateCard 刻意始终挂载、在 hooks 之后才 return null，保证候选查询的\n发起时机与重构前逐字一致（只搬行不改行为）。登记值同步下调/毕业锁住进步。\n\n⚠️ 抽 OverviewQuoteMetrics 时一度把三元中段当 JSX 搬走并用 \u003c\u003e 包裹，`) : (`\n降格为文本节点原样上屏，且两个分支同时渲染——给有权限的管理员显示「未向当前\n角色开放」。tsc 与 22 项静态门禁全绿，只有浏览器截图抓得到。已修并留档。\n\n证据（作用域＝本地工作区）：pnpm check 22 项全绿 exit=0、16 组负向自检有牙、\n浏览器实测总览/新建报价/版本中心三处渲染正常。未重跑 check:runtime / check:ui\n（两后端与 contracts 一行未动，那两级证据仍绑定上一轮 commit）。\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-17T03:47:39-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/6e260f9edb613a60434dd3c0b38c78068c346022...3afb568a1d13a2ceeaf49a2a9bf1d8634f422c23","Len":1}...
|
1786963673
|
Edit
Delete
|
|
22536
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/product-catalog-search-and-image-u refs/heads/feat/product-catalog-search-and-image-upload...
|
0
|
{"Commits":[{"Sha1":"6e260f9ed {"Commits":[{"Sha1":"6e260f9edb613a60434dd3c0b38c78068c346022","Message":"feat(ui): 交互审计全项收口——成功回执、状态机中文报错、子页交互三缺口\n\n同日两轮，基线 2c0409a 干净树，全部改动可干净归属。\n\n轮一（审计项 3/4）：\n- 成功回执：保存方案/收款登记/确认到账/发送报价四处 mutation 补 toast\n （按售后成例「结果 + 下一站归谁」；收款文案显式说清「登记≠到账，\n 确认后才解锁发货门禁」的三责分离）。ToastProvider 早已挂载，\n 此前 81 个 mutation 只有售后 1 个消费者。\n- 双后端 24 处状态机报错去英文枚举：`状态 ${STATE} 不允许执行 ${event}`\n → `…当前状态为「中文标签」，不支持该操作`（9 通用 + 3 动作变体 ×2 后端，\n 文案逐字一致）；消费 contracts 既有 *_STATE_LABELS——错误路径此前从未用过它们，\n 与 error-messages.ts 的发现同构。内部事件动词不外泄（标注 21）；\n code/state/allowed 结构字段原样保留，前端零影响。\n\n轮二（子页交互审计 P1-P3；shell 骨架已把 08-04 诊断 §2.7 实质关闭，本轮修行为缺口）：\n- P1 履约 Orders 六 mode 同实例：page/搜索词/状态筛选/选中补 [mode] 重置，\n 镜像售后纪律；「切队列不换单」由 selectedOrderId ?? focusId 回退结构保住。\n- P2 售后流水线胶囊接 AfterSalesSummary.byState 出每段积压数\n （共用 query cache；徽标 aria-hidden，0 不渲染）。\n- P3 新建 WorkspaceMain：main landmark + aria-label=入口名 + tabIndex=-1，\n 子页切换后焦点移入播报并滚回顶部；首帧不抢焦点；带 focusId 的跳转不滚顶\n （报价卡自滚，父效应后跑会砸掉它——标注 16）。\n Home 借道 activeEntry 单查找瘦身回 399/400，下一个动 Home 的必须先拆分。\n\n证据（2026-08-13 本地，详见 CLAUDE.md 动态区两条新记录）：\ncheck:runtime 全量 548 用例绿（地板 503，分包 436/56/56，全新库 gov25）；\n三端 typecheck / web lint / design-tokens / dual-backend / workspace-hygiene 绿；\n真实 Chromium 全新库（ui19）「商品客户」「客户方案闭环」两章全绿；\n浏览器实测：保存方案 toast 落 aria-live、409 新文案「方案当前状态为「可设计」…」、\n物流搜索词切队列后清空、切维修复检焦点落 main 且 scrollY 600→0、\n流水线徽标计数与真数据一致。module-integration/component-size 仍剩的红\n均属报价版本中心在途战役（quotation-version-detail-visible + 3 处体积），非本轮引入。\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-13T08:00:31-07:00"}],"HeadCommit":{"Sha1":"6e260f9edb613a60434dd3c0b38c78068c346022","Message":"feat(ui): 交互审计全项收口——成功回执、状态机中文报错、子页交互三缺口\n\n同日两轮，基线 2c0409a 干净树，全部改动可干净归属。\n\n轮一（审计项 3/4）：\n- 成功回执：保存方案/收款登记/确认到账/发送报价四处 mutation 补 toast\n （按售后成例「结果 + 下一站归谁」；收款文案显式说清「登记≠到账，\n 确认后才解锁发货门禁」的三责分离）。ToastProvider 早已挂载，\n 此前 81 个 mutation 只有售后 1 个消费者。\n- 双后端 24 处状态机报错去英文枚举：`状态 ${STATE} 不允许执行 ${event}`\n → `…当前状态为「中文标签」，不支持该操作`（9 通用 + 3 动作变体 ×2 后端，\n 文案逐字一致）；消费 contracts 既有 *_STATE_LABELS——错误路径此前从未用过它们，\n 与 error-messages.ts 的发现同构。内部事件动词不外泄（标注 21）；\n code/state/allowed 结构字段原样保留，前端零影响。\n\n轮二（子页交互审计 P1-P3；shell 骨架已把 08-04 诊断 §2.7 实质关闭，本轮修行为缺口）：\n- P1 履约 Orders 六 mode 同实例：page/搜索词/状态筛选/选中补 [mode] 重置，\n 镜像售后纪律；「切队列不换单」由 selectedOrderId ?? focusId 回退结构保住。\n- P2 售后流水线胶囊接 AfterSalesSummary.byState 出每段积压数\n （共用 query cache；徽标 aria-hidden，0 不渲染）。\n- P3 新建 WorkspaceMain：main landmark + aria-label=入口名 + tabIndex=-1，\n 子页切换后焦点移入播报并滚回顶部；首帧不抢焦点；带 focusId 的跳转不滚顶\n （报价卡自滚，父效应后跑会砸掉它——标注 16）。\n Home 借道 activeEntry 单查找瘦身回 399/400，下一个动 Home 的必须先拆分。\n\n证据（2026-08-13 本地，详见 CLAUDE.md 动态区两条新记录）：\ncheck:runtime 全量 548 用例绿（地板 503，分包 436/56/56，全新库 gov25）；\n三端 typecheck / web lint / design-tokens / dual-backend / workspace-hygiene 绿；\n真实 Chromium 全新库（ui19）「商品客户」「客户方案闭环」两章全绿；\n浏览器实测：保存方案 toast 落 aria-live、409 新文案「方案当前状态为「可设计」…」、\n物流搜索词切队列后清空、切维修复检焦点落 main 且 scrollY 600→0、\n流水线徽标计数与真数据一致。module-integration/component-size 仍剩的红\n均属报价版本中心在途战役（quotation-version-detail-visible + 3 处体积），非本轮引入。\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-13T08:00:31-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/2c0409a3cbd22aaba6d36a123d8ba9bea5711059...6e260f9edb613a60434dd3c0b38c78068c346022","Len":1}...
|
1786633238
|
Edit
Delete
|
|
22302
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/product-catalog-search-and-image-u refs/heads/feat/product-catalog-search-and-image-upload...
|
0
|
{"Commits":[{"Sha1":"2c0409a3c {"Commits":[{"Sha1":"2c0409a3cbd22aaba6d36a123d8ba9bea5711059","Message":"chore(dev): dev 端口防跨仓劫持——API 迁 13099、web 改 autoPort\n\n实锤：本机多仓并发会话互抢 3xxx 段端口，3098 被他仓 Next 占、3099 被\n「图像生成」的 fastify 占——后者 /api/health 报文与本仓逐字同构\n（fastify + database/redis up），探活全绿而业务路由全 404，页面表现为\n「Route GET:/api/solutions not found」（G15「端口通≠基座对」的跨仓变体）。\n\n- api-fastify：固定端口 3099 → 13099，迁出拥挤段；\n- web：去掉写死的 -p 3098，改 autoPort（next dev 吃 PORT env），\n API_PROXY_TARGET / NEXT_PUBLIC_WS_URL 同步指向 13099。\n判断「端口上是不是本仓服务」以后要打带 token 的业务路由，不能只看 health。\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-12T23:35:20-07:00"}],"HeadCommit":{"Sha1":"2c0409a3cbd22aaba6d36a123d8ba9bea5711059","Message":"chore(dev): dev 端口防跨仓劫持——API 迁 13099、web 改 autoPort\n\n实锤：本机多仓并发会话互抢 3xxx 段端口，3098 被他仓 Next 占、3099 被\n「图像生成」的 fastify 占——后者 /api/health 报文与本仓逐字同构\n（fastify + database/redis up），探活全绿而业务路由全 404，页面表现为\n「Route GET:/api/solutions not found」（G15「端口通≠基座对」的跨仓变体）。\n\n- api-fastify：固定端口 3099 → 13099，迁出拥挤段；\n- web：去掉写死的 -p 3098，改 autoPort（next dev 吃 PORT env），\n API_PROXY_TARGET / NEXT_PUBLIC_WS_URL 同步指向 13099。\n判断「端口上是不是本仓服务」以后要打带 token 的业务路由，不能只看 health。\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-12T23:35:20-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/35ebc8613b168219ce82c0b3cf9336d32e958821...2c0409a3cbd22aaba6d36a123d8ba9bea5711059","Len":1}...
|
1786602927
|
Edit
Delete
|
|
22301
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/product-catalog-search-and-image-u refs/heads/feat/product-catalog-search-and-image-upload...
|
0
|
{"Commits":[{"Sha1":"35ebc8613 {"Commits":[{"Sha1":"35ebc8613b168219ce82c0b3cf9336d32e958821","Message":"feat(ui): 方案商品多选批量添加 + 交互模式采纳率收口（全量落盘，含并发在途批次）\n\n整棵混合工作区的全量提交：多个战役共树、文件内手笔交错，无法按文件拆分归属，\n经用户裁决全量提交推送；已知红盘如实列出，等对应战役收口后 CI 自然转绿。\n\n本轮两个战役（已验证）：\n- 方案设计三档选品改多选批量：新增 TierProductPicker（checkbox 候选 + 分类/关键词\n 收窄 + 待添加纸片跨筛选常驻 + 已添加禁勾），SolutionDesigner 416→252 行并从\n component-size 棘轮毕业；E2E 方案章改写为「勾 2 件一次落 2 行」的多选证明。\n- 交互模式采纳率收口：裸 {x.error.message} 29→1（统一走 ErrorAlert/QueryErrorState，\n receivables 本地 ErrorText 裸实现改包装、13 调用点一次收口，消掉 text-red-600 与\n 「操作失败，请重试」兜底）；裸 disabled={isPending} 59→31（单动作按钮换 Button\n loading 保焦点带 aria-busy；行共享 mutation/批准驳回对/兄弟禁用具名保留）；\n check:design-tokens 新增 designTokenRawErrorMessage=1 / designTokenBareIsPendingDisable=31\n 两条采纳率棘轮（计数单源 scripts/lib/design-adoption.mjs），design-adoption.test.mjs\n 13 例负向自检进 gate-selftest，活体注入实跑 exit=1 判红后恢复。\n\n同树落盘的并发/前序批次（未逐一复验，以各自战役记录为准）：\n- 报价版本中心（进行中，已知红：module-integration 的 quotation-version-detail-visible\n + component-size 3 处【MobileOverview 473\u003e430、QuotationCard 437、QuotationWorkbench\n 665\u003e566】+ gate-selftest 基线用例如实继承）\n- 事件业务编号按域推广、售后/方案后端切片、设计稿真源目录与 08-07 迁移目录等\n\n证据（本地混合工作区，2026-08-13，详见 CLAUDE.md 动态区新条目）：\ntypecheck / lint / design-tokens / role-permissions / naming / schema / validation /\ncontract-consumers / governance-docs / workspace-hygiene 绿；真实 Chromium 定向验收\n「商品客户」「客户方案闭环」两章通过（全新库 ui18）；「报价闭环」红属版本中心在途，\n「履约闭环」被串行阻断——fulfillment/receivables 的 loading 换写暂只有 typecheck+lint\n级证据，全量 check:ui 复跑时重点看这两章。\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-12T23:22:47-07:00"},{"Sha1":"0b2e3703fed8f72749a8dc1824848d0601f1c9ea","Message":"docs(governance): 回灌远端 CI 证据——run 31072021158 @ ac22869 全绿\n\n作用域是**这个提交与这条分支**，不是 main（main 仍落后 21 个提交）。\nstatic ✅ / runtime 497 用例（contracts 395 + 双端各 51）/ UI 12 用例，\nCI 侧真起 MinIO 跑上传写链。\n\n同时记下两次实测判红的插曲：check:runtime 加了 S3 preflight 却没同步 CI 环境；\nMinIO 放进 services: 起不来（Actions 的 service 容器没有传 command 的字段）。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:52:52-07:00"},{"Sha1":"ac228691be9468a1345b4f3669a7c5aa0ca86bef","Message":"ci: MinIO 改用显式 step 启动——services 传不了启动参数\n\n上一提交把 MinIO 放进 `services:`，CI 实测判红：\n「Failed to initialize container minio/minio:latest」。\n\n根因：Actions 的 service 容器只支持 image/env/ports/options/credentials/volumes，\n**没有传 command/args 的字段**；而 minio 镜像的 entrypoint 需要 `server /data`。\n不带参数时它打印 usage 后正常退出，于是健康检查永远 unhealthy。\n\n改为在 runtime job 里显式 `docker run -d ... server /data` 并轮询\n/minio/health/live。步骤跑在 runner 宿主机上，端口映射到 127.0.0.1:9000，\n与 S3_ENDPOINT 一致。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:42:48-07:00"},{"Sha1":"6a2a86ba23719de7baa4940fb278b2df8b72b95e","Message":"ci: 补 MinIO 服务与 S3 环境——check:runtime 现在硬要求对象存储\n\n上一提交给 check:runtime / check:ui 的 preflight 加了 S3_ENDPOINT / S3_BUCKET\n强制显式传参与桶名归属守卫（G15 同型：本机与 CI 都可能共用对象存储，\n静默写进别人的桶就是拿别仓存储当验收基座）。\n\nCI 只起了 postgres + redis，因此上一提交推上去会在 preflight 处直接判红——\n这不是回归，是我加了硬要求却没同步跑它的环境。\n\n桶名用 juhai-quotation-ci（须匹配 juhai-quotation* 前缀守卫）。\n健康检查用 /minio/health/live：容器镜像里没有 mc 客户端，`mc ready` 不可用。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:38:10-07:00"},{"Sha1":"8feb39921ea8a404b09e287154f4c6fd1f7bd3e3","Message":"feat(products): 商品库服务端搜索筛选 + 图片上传至对象存储\n\n## 一、服务端搜索与筛选（此前 115 个商品只能翻页找）\n\n商品列表新增 keyword / kind 两个过滤维度，与既有 active 一并落 DB where。\n谓词收进 contracts `buildProductListFilter` 单源，两后端各自\n`{ tenantId, ...buildProductListFilter(query) }`——行为对等由结构保证，\n任一侧自己拼 where 就会搜出不同结果而无红盘（G17 漂移形态）。\n\n- 关键词语义（SKU + 名称双列 contains、大小写不敏感、不含 description）\n 单独抽 `buildProductKeywordFilter`，换口径只改这一个函数。\n- 空串/纯空白在契约层归一为 undefined（C24 同型：清空搜索框最易发出空串），\n 前端另在 api 层直接不发该参数——双层防御。\n- tenantId 刻意不由该函数产出：租户隔离不能依赖一个可被调用方忘记展开的返回值。\n\n页面同步重构：录入表单默认收起、卡片压缩、展开管理时横跨整行、分页条下移、\n空态区分「筛选无结果」与「库里没商品」、成本 ¥0 改显「成本未录入」\n（导入时成本列整列为空是已知缺口，直显 ¥0.00 会被读成毛利 100%）。\n配件行由固定列宽改 flex-wrap + 最小宽度：视口断点用在 1/3 视口宽的卡片里\n是容器语境错配，断点满足了容器并没有变宽。\n\nProductLibrary 443 → 183 行，拆出 5 个子组件并从 component-size 债务登记毕业。\n\n## 二、图片上传至对象存储（此前只能粘贴外链 URL）\n\nMinIO 进 compose，两后端走 S3 SDK——换阿里云 OSS / 腾讯云 COS 只改 endpoint\n与凭证，写链代码不动。上传链：multipart → 按真实字节魔数判类型 → sharp 转\nWebP + 缩略图 → 写对象存储 → 落库（与 outbox 同 tx）。\n\n- 类型判定收进 contracts，连判定顺序也收：Content-Type 与扩展名都是攻击者\n 可控输入；顺序决定 0 字节文件报「没收到文件」还是「类型不支持」。\n 不收 SVG（可执行文档，直出即存储型 XSS）与 GIF。\n- S3 写入必须先于落库且在事务外：先落库则上传失败留下指向空对象的行（破图），\n 先上传则落库失败只留下无人引用的对象（垃圾，可清理）。代价不对称。\n- 公开回读 /api/files/:tenantId/:imageId/:variant 不鉴权（对客报价页没有内部\n 身份），路径穿越由 schema 校验后重建 key 结构性排除，非法参数回 404 不回 400。\n- DB 存相对路径而非对象存储绝对地址：换存储那天不必迁移存量 URL。\n- backup/restore 成对覆盖 minio 卷：只备份 Postgres 时恢复演练照常报绿，\n 但每行 ProductImage 都指向不存在的对象。卷名问 Docker 要而不是按\n 「项目名_卷名」拼——拼错会备份一个空卷而命令成功。\n\n## 三、修复与门禁\n\n- 修 `after-sales-order-options-hook` 在 HEAD 上的存量误杀（C29 修复插入\n ~700 字符把距离顶到 1749，撑破 1600 窗口，接线本身完好）。\n- 三条断言随组件拆分重新锚定（成本可见性/公开配件/配件确认框/元→分转换）。\n- 新增 6 条上传链断言；其中 2 条初版无牙被负向测试当场抓出并重写：\n 距离型顺序断言不测顺序、`id: imageId` 锚点在 removeImage 里不唯一（G13 同型）。\n 窗口取值均由实测距离确定，不拍脑袋。\n- DIVERGENCE_CEILINGS.products 142→152 属扩容非放水：同轮 PARITY_FLOORS.products\n 74.1→76.9（实测 77.4 高于校准时 74.6），只放松绝对判据是净削弱。\n- turbo globalEnv 补 S3_* 六项（不补则测试进程拿不到凭证，表现为 500）。\n\n## 证据（作用域＝本地工作区）\n\n- pnpm check：21 项全绿；负向注入 40 → 44 条\n- check:runtime：497/497（contracts 395 + 双端各 51），真上传打真 MinIO，地板已收紧\n- check:ui：12/12，上传段断言 naturalWidth \u003e 0（src 有值只证明存了个字符串）\n\n尚未核验远端 CI。\n\nCo-Authored-By: Claude Opus 5 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-05T21:35:24-07:00"}],"HeadCommit":{"Sha1":"35ebc8613b168219ce82c0b3cf9336d32e958821","Message":"feat(ui): 方案商品多选批量添加 + 交互模式采纳率收口（全量落盘，含并发在途批次）\n\n整棵混合工作区的全量提交：多个战役共树、文件内手笔交错，无法按文件拆分归属，\n经用户裁决全量提交推送；已知红盘如实列出，等对应战役收口后 CI 自然转绿。\n\n本轮两个战役（已验证）：\n- 方案设计三档选品改多选批量：新增 TierProductPicker（checkbox 候选 + 分类/关键词\n 收窄 + 待添加纸片跨筛选常驻 + 已添加禁勾），SolutionDesigner 416→252 行并从\n component-size 棘轮毕业；E2E 方案章改写为「勾 2 件一次落 2 行」的多选证明。\n- 交互模式采纳率收口：裸 {x.error.message} 29→1（统一走 ErrorAlert/QueryErrorState，\n receivables 本地 ErrorText 裸实现改包装、13 调用点一次收口，消掉 text-red-600 与\n 「操作失败，请重试」兜底）；裸 disabled={isPending} 59→31（单动作按钮换 Button\n loading 保焦点带 aria-busy；行共享 mutation/批准驳回对/兄弟禁用具名保留）；\n check:design-tokens 新增 designTokenRawErrorMessage=1 / designTokenBareIsPendingDisable=31\n 两条采纳率棘轮（计数单源 scripts/lib/design-adoption.mjs），design-adoption.test.mjs\n 13 例负向自检进 gate-selftest，活体注入实跑 exit=1 判红后恢复。\n\n同树落盘的并发/前序批次（未逐一复验，以各自战役记录为准）：\n- 报价版本中心（进行中，已知红：module-integration 的 quotation-version-detail-visible\n + component-size 3 处【MobileOverview 473\u003e430、QuotationCard 437、QuotationWorkbench\n 665\u003e566】+ gate-selftest 基线用例如实继承）\n- 事件业务编号按域推广、售后/方案后端切片、设计稿真源目录与 08-07 迁移目录等\n\n证据（本地混合工作区，2026-08-13，详见 CLAUDE.md 动态区新条目）：\ntypecheck / lint / design-tokens / role-permissions / naming / schema / validation /\ncontract-consumers / governance-docs / workspace-hygiene 绿；真实 Chromium 定向验收\n「商品客户」「客户方案闭环」两章通过（全新库 ui18）；「报价闭环」红属版本中心在途，\n「履约闭环」被串行阻断——fulfillment/receivables 的 loading 换写暂只有 typecheck+lint\n级证据，全量 check:ui 复跑时重点看这两章。\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-12T23:22:47-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/be1e0734c39315b61a7bf452231a853f44866085...35ebc8613b168219ce82c0b3cf9336d32e958821","Len":5}...
|
1786602303
|
Edit
Delete
|
|
22300
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/product-catalog-search-and-image-u refs/heads/feat/product-catalog-search-and-image-upload...
|
0
|
|
1786602303
|
Edit
Delete
|
|
20884
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/multi-role-assignment
|
0
|
{"Commits":[{"Sha1":"be1e0734c {"Commits":[{"Sha1":"be1e0734c39315b61a7bf452231a853f44866085","Message":"test(manual): 采集 spec 适配工作台 UI 改版（1–11 章绿，余记 backlog）\n\n2026-08-04 UI 改版（侧栏 6 组折叠 + 视图切换器、收款抽屉、后果确认框铺开、\n公开页一方案一链接单档投影、合同定稿成为激活前置）让手册截图采集大面积失效\n（采集是「有环境才跑、非门禁」的真实运行任务，改版后没有门禁会红——正是本仓\n两次为文档漂移付代价的形态 C14/C25）。\n\n本轮适配并经 build:manual 实跑通过第 1–11 章：\n- 移植 openWorkspaceEntry + workspaceTab helper，折叠入口（报价5/履约4/售后8）\n 改走「组条目 → 视图切换器 tab」的真实用户路径；第 1 章 nav-group 标注按 6 组重写\n- 报价发送补 send-quotation-dialog「确认发送」；申请合同补\n quotation-request-contract-dialog 确认；客户报价页去掉已下线的「选择方案」下拉、\n 「打开客户页」多档链接取 .first()\n- 第 13 章收款改为「选单 → 开 open-receivables-drawer 抽屉 → 切分期/收款 tab」，\n 状态标签改中文（RECORDED→待确认到账）\n\n未完成（文件头 backlog 详列）：合同定稿新章节（激活前置，需先建模板）、收款抽屉\n后半（14 章开票/红冲/退款）、确认框簇、售后流水线；正文与 manifest 待全章绿后统一重生成。\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-05T18:32:06-07:00"}],"HeadCommit":{"Sha1":"be1e0734c39315b61a7bf452231a853f44866085","Message":"test(manual): 采集 spec 适配工作台 UI 改版（1–11 章绿，余记 backlog）\n\n2026-08-04 UI 改版（侧栏 6 组折叠 + 视图切换器、收款抽屉、后果确认框铺开、\n公开页一方案一链接单档投影、合同定稿成为激活前置）让手册截图采集大面积失效\n（采集是「有环境才跑、非门禁」的真实运行任务，改版后没有门禁会红——正是本仓\n两次为文档漂移付代价的形态 C14/C25）。\n\n本轮适配并经 build:manual 实跑通过第 1–11 章：\n- 移植 openWorkspaceEntry + workspaceTab helper，折叠入口（报价5/履约4/售后8）\n 改走「组条目 → 视图切换器 tab」的真实用户路径；第 1 章 nav-group 标注按 6 组重写\n- 报价发送补 send-quotation-dialog「确认发送」；申请合同补\n quotation-request-contract-dialog 确认；客户报价页去掉已下线的「选择方案」下拉、\n 「打开客户页」多档链接取 .first()\n- 第 13 章收款改为「选单 → 开 open-receivables-drawer 抽屉 → 切分期/收款 tab」，\n 状态标签改中文（RECORDED→待确认到账）\n\n未完成（文件头 backlog 详列）：合同定稿新章节（激活前置，需先建模板）、收款抽屉\n后半（14 章开票/红冲/退款）、确认框簇、售后流水线；正文与 manifest 待全章绿后统一重生成。\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-05T18:32:06-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/1334a6214585274050083c387a7fbbb5a591d308...be1e0734c39315b61a7bf452231a853f44866085","Len":1}...
|
1785979947
|
Edit
Delete
|