|
20363
|
5
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
|
1785740632
|
Edit
Delete
|
|
20365
|
5
|
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
|
|
20407
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/multi-role-assignment
|
0
|
|
1785765661
|
Edit
Delete
|
|
20408
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/multi-role-assignment
|
0
|
{"Commits":[{"Sha1":"744d532b8 {"Commits":[{"Sha1":"744d532b80ba3fd239cfbdd2b3700e3d73c08675","Message":"test(governance): 三级门禁全绿——runtime 396/396、UI 12/12，合同与多角色补齐验收\n\n本轮把欠了整条线的运行态证据补齐：静态 → 真实 DB → 浏览器三级全部实跑通过。\n\n## 合同域门禁（5 条断言 + 自检固化）\n`check:module-integration` 新增：渲染必须调 contracts 纯函数、清单必须走 contracts\n清洗、定稿必须校验金额、激活必须要求合同已定稿、合同列表必须有自己的读模型。\n5 条负向注入逐条实跑判红，并固化进 `scripts/lib/contract-integration.test.mjs`\n（fixture 隔离，不碰真文件；配「未注入 → 绿」基线用例，防止所有\"期望红\"\n以完全错误的理由通过）。gateSelftests 地板 6 → 7。\n\n其中「合同列表必须有自己的读模型」防的是真实发生过的缺陷：\n借用「待激活申请」options（只返 REQUESTED）会让财务一激活，刚签的合同就从界面消失。\n\n## 状态机不变量逼出的设计修正\n`contractMachine` 原本是 `DRAFT ⇄ FINALIZED` 的**无终态环**——合同永远走不完，\n而\"订单已激活则不可修改\"只是运行时守卫。contracts 的状态机不变量测试\n（\"从任一状态都能走到终态\"）当场判红。加终态 `EFFECTIVE`，由财务激活时迁入：\n`revise` 从 EFFECTIVE 出发在**状态机层面就不存在**，运行时检查降为第二层。\n\n## 修掉一个我自己制造的严重问题\n早先用批量正则把测试里的 `role:` 改成 `roles:`，**误伤 153 处 `api()` helper 入参**。\n该 helper 收的是 `role`，`roles` 被静默忽略并回落成默认 ADMIN——\n**测试照样绿，但所有「某角色应当 403」的负例都退化成「ADMIN 当然 200」**。\n已全部回退。教训：批量正则改测试比改源码危险得多，源码有编译器兜底，测试没有。\n\n## 修掉一处静默降级（用户反馈两次）\n`draft()` 里 `template ? render(...) : \"\"`——取不到默认模板就给空正文，不报错不提示。\n而\"合同建出来了、正文是空的\"在界面上与\"模板没生效\"完全一样。改为：\n默认模板优先，没设默认但只有一个模板时直接采用；仍取不到时界面明确说明原因。\n另补「套用模板」选择器——此前 `templateId` 存了却从不重渲染，已有合同换不了模板。\n\n## 版式\n按反馈调整为：套用模板 → 合同正文 → 合同清单。\n打印改为只打这一份合同：`@media print` 内 5 条规则（全页隐藏 → 放行合同卡 →\n正文去滚动上限并允许换行 → 按钮与留证快照不打印），沿用配货单打印同一模式，\n含「window.print() 必须在原始 click 内同步调用」那条硬约束。\n\n## 三级门禁证据（本地工作区）\n- `pnpm check` exit 0；门禁自检 8 组\n- `pnpm check:runtime` **396/396**（地板抬至 380），双后端 HTTP 各 45/45\n- `pnpm check:ui` **12/12**，unexpected 0（地板抬至 12）\n- 新增双后端 HTTP 验收：未定稿激活 409 CONTRACT_NOT_FINALIZED、\n 改金额定稿 409 CONTRACT_TOTAL_MISMATCH、合同清单只有对客七列且不含 cost\n- 新增 E2E 真实界面链路：建模板 → 生成合同 → 断言正文按模板渲染 →\n 定稿 → 只读预览 → 激活\n\n## 顺带修复的真账\n多角色改造遗留：两后端测试夹具签单值 role、fromRole/toRole 断言、\nNestJS api() helper 签发、E2E 建账号入参、合同外键 Restrict 导致的清理顺序。\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-03T06:17:45-07:00"},{"Sha1":"0e13b856b65685957296087a642c46a9b57c8d0a","Message":"feat(contract): 合同管理界面——模板维护、清单改写、预览与定稿\n\n## 界面三段\n- **模板维护**：正文编辑 + 可用变量清单（真源是 contracts 白名单，不手抄）；\n 默认模板里乙方那几行留了「请填写」占位提示，免得有人以为忘了配变量\n- **合同面板**：清单可改名称/规格/单位/备注，**单价与金额只读**——\n 金额与报价锁死，改写法不改钱，只读比\"改了再被服务端拒绝\"少一次挫败\n- **定稿后**：正文转只读预览 + 打印 + 撤回定稿；留证快照可展开查看\n\n## 浏览器验证时抓到一个真实缺陷\n最初用「待激活申请」的 options 驱动合同列表——而它只返 `status=REQUESTED`。\n结果是**财务一激活，刚签的合同就从界面上凭空消失**。\n补了 `GET /api/contracts` 作为合同自己的读模型（两后端对等），\n视图改为「已有合同 + 尚未起草的待激活申请」两段驱动，后者按 contractRequestId 去重。\n\n这个 bug 单测抓不到，也不会有任何红盘——它只在\"数据恰好处于某状态\"时显形，\n而 dev 库里正好一条 REQUESTED 都没有，所以一打开就是空白。\n\n## 前端不做第二份渲染\n预览直接显示服务端渲染好的 `body`，前端**没有任何占位符处理**。\n在前端补一套 replace 会变成第二份渲染实现（G17 漂移形态）：\n两边看起来一样，直到某天对空值的处理不同，界面上好好的合同打印出来金额是空的。\n\n## 证据（本地工作区）\n- `pnpm check` exit 0；全仓 typecheck 0 错误\n- 浏览器实测：模板维护渲染、合同面板 1 个、状态「已定稿」、清单 1 行、\n 合计 ¥660000.00、预览/撤回定稿/打印按钮齐全（截图见会话）\n- `GET /api/contracts` 返回真实合同（编号、报价号、客户名、合计、定稿时间）\n\n## 未做\nE2E 用例、两后端 HTTP 验收、`check:module-integration` 合同断言均未补（#31）。\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-02T23:19:14-07:00"},{"Sha1":"ef882dee3f2d670038bff1151a04e6cb4a4d3d45","Message":"feat(contract): 合同管理落地——模板、清单清洗、预览、定稿快照与激活前置\n\n动手前先证伪了「优化完善」这个词：**本仓此前没有合同**。\n`ContractRequest` 只是流程凭证（状态 + 报价引用 + 拒绝留痕），没有正文、条款、\n甲乙方、签署；「合同管理」视图做的是财务把报价激活成订单，本质是审批队列。\n所以这是新建业务对象，不是加按钮。\n\n## 用户裁决（五条）\n模板+变量填充 / 定稿即快照 / 仅内部预览打印 / 乙方写进模板正文 / 定稿为激活前置。\n另就清单追加两条：只改写法金额锁死 / PUBLIC 附件归入主行备注。\n\n## 合同清单与报价清单是两份不同明细\n报价行 26 列里 9 列是内部的——成本价、底价、成本合计、低于底价标记、调价原因、\n标准价、三种折扣构成。投影**重建对象字面量**而不是删字段，成本列在结构上进不来\n（单测断言 Object.keys 恰为七列，并扫描序列化结果确认成本数字不出现）。\n最隐蔽的一条是 `QuoteLineAccessory.visibility=INTERNAL`：「别显示成本」人人记得，\n「别显示内部附件」没人会想到，因为它藏在子表里。\n\n**金额锁死**先验了算术前提才敢定：dev 库 `sum(quote_lines.total_cents)` 恒等于\n`quote_options.total_cents`，差额全为 0，否则这条不变量会一上线就误杀所有合同（C1 同型）。\n校验放在**定稿**而非每次保存——草稿期正在合并行，中间态必然对不上，\n每次都校验会让「合并两行」这个动作根本做不完。\n\n## 渲染两层 fail-closed\n未知变量、取不到值的变量都抛错并点名。理由：一份看起来正常、金额那行却空白的合同\n被打印去签，比当场报错危险一个量级。另单独检查未闭合 `{{`——它会被正则整段跳过，\n不专门查就会原样印进合同且无人报错。\n\n## 真实链路验证抓出两个 bug\n① `variablesSnapshot` 恒为空：起草时正文已渲染，到定稿时里面早没有 `{{}}` 可提取。\n 改为快照**全部可解析变量**——留证本就该全记，不该取决于模板作者当初印没印。\n② Fastify 路由多写了 `/api` 前缀（注册作用域已带 prefix），实际成了 `/api/api/...`。\n\n## 又踩了一次同字面量陷阱\nNestJS 激活前置最初插错位置——「仓库不存在」那段在文件里出现多次，\n`replace` 只换第一处，守卫落进了 `createStocktake`（盘点）。\n已改为断言锚点唯一性后再插入。CLAUDE.md 点名过两次的坑，我这是第三次踩。\n\n## 证据（本地工作区，Fastify 真实链路）\n- `pnpm check` exit 0；contracts 单测 302（新增 22 条合同用例）\n- 模板：经理可建 201 / 销售 403 / 未登记变量 409 点名「甲方开户行」\n- 合同：起草生成 1 行清单（七列，含\"含：附件\"备注）、正文变量全替换、大写金额正确\n- 定稿：改金额 → 409 报出差额 -10000.00 元；销售定稿 403；正确金额 → FINALIZED\n- 撤回定稿：订单已激活 → 409 ORDER_ALREADY_ACTIVATED\n- 缺税号时起草 → 409 MISSING_VALUE 点名「甲方税号」（真实数据触发，非构造）\n- 留证快照 12 项（缺签署人两项因该报价未走客户接受，属正确 fail-closed）\n\n## 未做（不隐藏）\n前端界面（模板维护/预览/修改）未做；两后端 HTTP 验收测试与 E2E 未补；\n`check:runtime`/`check:ui` 本轮未跑；激活前置只在代码与单测层验证，\n未构造完整「未定稿→拒绝激活」的真实 HTTP 流程（dev 库无待激活申请，\n且 quotation_id 唯一约束挡住了造数）。\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-02T23:07:37-07:00"},{"Sha1":"e0b780d18833713a675d8903f407bd7afd55e650","Message":"feat(auth): 多角色并存——一个账号可持多个角色，能力取并集，互斥组合硬禁止\n\n用户裁决两条：① 多角色并存（而非租户自定义角色）；② 互斥组合硬禁止（而非仅警示）。\n\n## 为什么是多角色而不是自定义角色\n备选方案是「租户自建角色 + 勾选任意 capability 子集」。不选它只有一条理由但足够硬：\n那会把「谁能做什么」的真源从 ROLE_PERMISSION_MAP **搬进数据库**，\n`check:role-permissions` 里「数据库不另存权限副本」这条核心断言随即失效，\n排查越权要同时看代码和数据。多角色只在 DB 存**角色分配**，真源不动，门禁继续有牙。\n代价是表达力：拼不出「销售但能看成本」这种现有角色组合不出的能力集。**已知取舍，非遗漏。**\n\n## 互斥矩阵为什么按角色对而不是 capability 对\n按能力对看着更本质，实则注册即红：`FINANCE` 单角色本身就同时持有 `payment.record`\n与 `payment.confirm`，门禁上线当天就判自己违规（C1 同型：扫到自身定义源）。\n故定义在角色层，并由 `it.each(MANAGED_USER_ROLES)`「每个单角色都不触发冲突」常驻断言守住。\n三组：采购三责分离 / 收款与发货放行 / 财务发起与审批；ADMIN 须单独持有。\n**这挡不住 ADMIN**——它持全部 capability，三责分离对它本就不成立，\n所以审批动作仍按 actor 硬校验 `approver !== requester`，两层缺一不可。\n\n## 删掉 requestRole 是本次最关键的决定\n`hasRolePermission` 改为同时接受单角色与角色集，好让 185 处调用点逐字不变。\n但这带来一个隐患：若保留 `requestRole`/`RequestRole` 单值访问器，\n调用点会**照常编译通过、静默只按主角色授权**——并集悄悄失效，零红盘。\n删掉它，编译器逼出 122+29 个错误，一个都跑不掉。\n\n编译器抓不到的恰是最危险的一处：`lockActiveAdmins` 的裸 SQL `\"role\" = 'ADMIN'`。\n它绕过 Prisma 类型检查；若当初保留 role 列做「兼容」，这句会静默匹配陈旧数据——\n**最后管理员保护看似还在，锁的却是错的行**。这是坚持 DROP COLUMN（并按门禁写\n`migration-allow` 留痕）的真正理由。计数侧同理：数组列上等值查询恒不匹配，\n`count` 恒为 0 会让保护永远放行。\n\n## 顺带修掉一个存量 bug\n两后端 `reverseAllocation` 把**角色名当操作人**存进 `reversedBy`（`reversedBy: role` → \"FINANCE\"）。\n列是 String? 所以静默收下，反核销记录追不到人。多角色改造让它变成类型错误才暴露，已改传 actor。\n\n## token 与失效语义\nclaims `role` → `roles`，**无兼容分支**：留着它，只带 `role` 的旧令牌会走进「按单角色授权」\n的窄路径而调用方以为拿到并集，这种不一致比直接 401 难查得多。旧令牌一律 401 CLAIMS。\n受管理令牌回查用 `sameRoleSet` **集合语义**——按数组逐位比会让管理员调整勾选顺序\n就把在线用户全部踢下线（同 sameTagSet 那条教训）。\n\n## 迁移\n两端对等：users.role → users.roles、user_events 角色快照转集合，先回填再删旧列。\nDROP COLUMN 与 CREATE INDEX 均按门禁要求加 `-- migration-allow:` 留痕。\n\n## 前端\n账号页角色由单选下拉改多选勾选，实时显示并集能力数与互斥冲突——\n预览调 contracts 同一个 `previewRoleAssignment`，不在前端另写一套 if。\n**前端只提示不裁决**：绕过 UI 直接 curl 照样 400。\n\n## 证据（本地工作区）\n- `pnpm check` exit 0；contracts 273/273（新增 33 条多角色单测）；全仓 typecheck 0 错误\n- 门禁负向已实跑判红：注入「退化成只按主角色授权」→ check:role-permissions exit 1；\n 注入「待办中心放行全集」→ check:module-integration exit 1；均恢复后转绿\n- 迁移在 dev 库实跑：单角色→单元素集合、0 个空角色集账号、旧列已删\n- 真实 HTTP 四条对抗：仓库+采购 400 点名冲突／空集 400／ADMIN 混搭 400／销售+技术 201\n- 浏览器：多选控件 10 角色、并集能力数实时更新、互斥冲突当场提示\n\n## 未做（不隐藏）\n`check:runtime` 与 `check:ui` 本轮未实跑；两后端多角色 HTTP 验收与 E2E 用例尚未补齐。\n动态区 runtime/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-02T22:26:56-07:00"}],"HeadCommit":{"Sha1":"744d532b80ba3fd239cfbdd2b3700e3d73c08675","Message":"test(governance): 三级门禁全绿——runtime 396/396、UI 12/12，合同与多角色补齐验收\n\n本轮把欠了整条线的运行态证据补齐：静态 → 真实 DB → 浏览器三级全部实跑通过。\n\n## 合同域门禁（5 条断言 + 自检固化）\n`check:module-integration` 新增：渲染必须调 contracts 纯函数、清单必须走 contracts\n清洗、定稿必须校验金额、激活必须要求合同已定稿、合同列表必须有自己的读模型。\n5 条负向注入逐条实跑判红，并固化进 `scripts/lib/contract-integration.test.mjs`\n（fixture 隔离，不碰真文件；配「未注入 → 绿」基线用例，防止所有\"期望红\"\n以完全错误的理由通过）。gateSelftests 地板 6 → 7。\n\n其中「合同列表必须有自己的读模型」防的是真实发生过的缺陷：\n借用「待激活申请」options（只返 REQUESTED）会让财务一激活，刚签的合同就从界面消失。\n\n## 状态机不变量逼出的设计修正\n`contractMachine` 原本是 `DRAFT ⇄ FINALIZED` 的**无终态环**——合同永远走不完，\n而\"订单已激活则不可修改\"只是运行时守卫。contracts 的状态机不变量测试\n（\"从任一状态都能走到终态\"）当场判红。加终态 `EFFECTIVE`，由财务激活时迁入：\n`revise` 从 EFFECTIVE 出发在**状态机层面就不存在**，运行时检查降为第二层。\n\n## 修掉一个我自己制造的严重问题\n早先用批量正则把测试里的 `role:` 改成 `roles:`，**误伤 153 处 `api()` helper 入参**。\n该 helper 收的是 `role`，`roles` 被静默忽略并回落成默认 ADMIN——\n**测试照样绿，但所有「某角色应当 403」的负例都退化成「ADMIN 当然 200」**。\n已全部回退。教训：批量正则改测试比改源码危险得多，源码有编译器兜底，测试没有。\n\n## 修掉一处静默降级（用户反馈两次）\n`draft()` 里 `template ? render(...) : \"\"`——取不到默认模板就给空正文，不报错不提示。\n而\"合同建出来了、正文是空的\"在界面上与\"模板没生效\"完全一样。改为：\n默认模板优先，没设默认但只有一个模板时直接采用；仍取不到时界面明确说明原因。\n另补「套用模板」选择器——此前 `templateId` 存了却从不重渲染，已有合同换不了模板。\n\n## 版式\n按反馈调整为：套用模板 → 合同正文 → 合同清单。\n打印改为只打这一份合同：`@media print` 内 5 条规则（全页隐藏 → 放行合同卡 →\n正文去滚动上限并允许换行 → 按钮与留证快照不打印），沿用配货单打印同一模式，\n含「window.print() 必须在原始 click 内同步调用」那条硬约束。\n\n## 三级门禁证据（本地工作区）\n- `pnpm check` exit 0；门禁自检 8 组\n- `pnpm check:runtime` **396/396**（地板抬至 380），双后端 HTTP 各 45/45\n- `pnpm check:ui` **12/12**，unexpected 0（地板抬至 12）\n- 新增双后端 HTTP 验收：未定稿激活 409 CONTRACT_NOT_FINALIZED、\n 改金额定稿 409 CONTRACT_TOTAL_MISMATCH、合同清单只有对客七列且不含 cost\n- 新增 E2E 真实界面链路：建模板 → 生成合同 → 断言正文按模板渲染 →\n 定稿 → 只读预览 → 激活\n\n## 顺带修复的真账\n多角色改造遗留：两后端测试夹具签单值 role、fromRole/toRole 断言、\nNestJS api() helper 签发、E2E 建账号入参、合同外键 Restrict 导致的清理顺序。\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-03T06:17:45-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/4e06b62635319faead311e0b6799c2e47877f859...744d532b80ba3fd239cfbdd2b3700e3d73c08675","Len":4}...
|
1785765661
|
Edit
Delete
|
|
20409
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/multi-role-assignment
|
0
|
{"Commits":[{"Sha1":"7a0c7fc47 {"Commits":[{"Sha1":"7a0c7fc472beebeaac8232aaff49889c3cb97fa0","Message":"chore(governance): 刷新报告与证据行，清理 tsconfig 临时产物残留\n\n- `apps/web/tsconfig.json`：C28 工作区卫生自愈剥掉 `.next-ui-14845` 残留\n （check:ui 的独立 distDir 会把该路径写进被跟踪的 tsconfig）\n- `reports/*.latest.json`：本轮 `pnpm check` 重跑产物，provenance 绑定当前工作区\n- `CLAUDE.md` 证据行：**含并行会话在同一 checkout 的更新**（客户勘测提交相关，\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-03T10:40:43-07:00"},{"Sha1":"167d026f912b2b17c9e4380a5eb18d1d50130751","Message":"feat(fulfillment): 交付培训成为硬卡点——安装完成前使用培训、服务关闭前运维培训\n\n用户裁决两条：培训是**硬卡点**而非记录；由各自角色做、记录客方参加人，\n不引入客户在线签收（本仓无实名认证，凭链接签收只能是具名降级）。\n\n## 卡点做成结构约束，不是运行时 if\n- 安装：`IN_PROGRESS --deliver_training--\u003e TRAINING --complete--\u003e COMPLETED`\n- 客服：`IN_SERVICE --deliver_operation_training--\u003e OPERATION_TRAINING --close--\u003e CLOSED`\n\n⚠️ **安装工单此前根本没有状态机**——三个状态靠 `updateMany` 的 where 条件硬走，\n不受 assertTransition 与状态机不变量守护。本轮补齐 `installationMachine` 并登记进\n不变量表（11 条结构断言自动生效）。否则新卡点又是一条只靠 if、没有结构保障的规则。\n\n客服侧相反：它本来就走 assertTransition，所以在 contracts 插入 `OPERATION_TRAINING`\n态之后，「服务中直接关单」**一行服务端代码都不用改**就自动变成 INVALID_TRANSITION。\n这个对比正是状态机单源的价值。\n\n## 参加人必填是刻意的\n`attendees` 记的是**客方名单**——培训的价值在于「谁被教会了」，不是「谁去讲了」。\n讲师取已验签 actor，不由客户端填，免得填错或冒名。一场没有参加人的培训等于没培训，\n允许留空就等于允许走过场。\n\n## 过程中挖出两处真问题\n1. **动作白名单是双真源**：两端各有一份手抄的 `[\"accept\",\"start\",\"close\"]`，\n 与 contracts 的 `SERVICE_HANDOFF_EVENTS` 平行维护。加了新事件而拷贝不知道，\n 表现是 400「Unsupported action」——排查时很难联想到「白名单没跟上」。\n 已改为两端都读 contracts 事件全集。\n2. **Zod 静默剥字段**：`acceptServiceHandoffSchema` 没登记 `attendees`，\n 请求里填了也会被剥掉，服务端于是说「没填参加人」——**调用方明明填了却被告知没填**，\n 这类不一致最难自查。已在 contracts 补登记并注明。\n\n## 一处「类型绿但数据没出来」\n客服读模型是**白名单重建对象字面量**（C20：不得泄漏成本/毛利/审批意见），\n返回类型是推断的，漏投影新字段**不会有任何编译错误**。安装侧是泛型透传所以自动带上，\n客服侧必须显式列出。已补，并由 `handoff-training-projected-*` 断言守住。\n\n## 界面\n安装工单进度四段（待开始/现场安装/使用培训/客户验收），段位改为按状态映射——\n原来是硬编码 if 链，新增状态会静默停在旧段位。安装中显示培训表单，\n完工表单挪到培训之后；客服服务中显示运维培训表单，关单挪到培训之后。\n\n## 门禁（4 条断言 + 4 条负向注入）\n`installation-training-required-*`、`training-attendees-required-*`、\n`handoff-action-allowlist-single-source-*`、`handoff-training-projected-*`。\n另收紧一条既有断言：完工表单必须挂在 **TRAINING** 段（原来锚的是两个标记的邻近性，\n插入培训表单后被撑开而误报；真正该守的是「完工在培训之后」，锚这个既更强也不怕插内容）。\n自检从 5 条扩到 9 条，均实跑判红。\n\n## 三级门禁证据（本地工作区，PG:55432 + Redis:6382）\n- `pnpm check` exit 0；门禁自检 9 条负向注入\n- `pnpm check:runtime` **413/413**（地板 380→400）\n- `pnpm check:ui` **12/12**，unexpected 0；E2E 断言「安装中不应出现完工按钮」\n ——卡点只在服务端而界面仍能诱导用户走错路，同样是缺陷\n\n## 未做\n客服交接的 E2E 里没有关单步骤，**运维培训卡点缺浏览器级证据**（HTTP 层已覆盖）。\n本次 runtime 增量含并行会话在同一 checkout 写入的约 400 行 HTTP 验收，非本会话产出。\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-03T10:36:05-07:00"}],"HeadCommit":{"Sha1":"7a0c7fc472beebeaac8232aaff49889c3cb97fa0","Message":"chore(governance): 刷新报告与证据行，清理 tsconfig 临时产物残留\n\n- `apps/web/tsconfig.json`：C28 工作区卫生自愈剥掉 `.next-ui-14845` 残留\n （check:ui 的独立 distDir 会把该路径写进被跟踪的 tsconfig）\n- `reports/*.latest.json`：本轮 `pnpm check` 重跑产物，provenance 绑定当前工作区\n- `CLAUDE.md` 证据行：**含并行会话在同一 checkout 的更新**（客户勘测提交相关，\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-03T10:40:43-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/744d532b80ba3fd239cfbdd2b3700e3d73c08675...7a0c7fc472beebeaac8232aaff49889c3cb97fa0","Len":2}...
|
1785778851
|
Edit
Delete
|
|
20660
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/multi-role-assignment
|
0
|
{"Commits":[{"Sha1":"dddca3924 {"Commits":[{"Sha1":"dddca39245dbd8ff6caea7a87c7e48de227e2daa","Message":"Enforce after-sales lifecycle gates and approval inbox integration\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-04T04:24:41-07:00"},{"Sha1":"c3ea882a2a67fdb7799a39b0d69278e7de50124b","Message":"feat: complete governed business lifecycle\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-03T20:59:05-07:00"}],"HeadCommit":{"Sha1":"dddca39245dbd8ff6caea7a87c7e48de227e2daa","Message":"Enforce after-sales lifecycle gates and approval inbox integration\n","AuthorEmail":"luoguoguo@gmail.com","AuthorName":"luoguoguo","CommitterEmail":"luoguoguo@gmail.com","CommitterName":"luoguoguo","Timestamp":"2026-08-04T04:24:41-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/7a0c7fc472beebeaac8232aaff49889c3cb97fa0...dddca39245dbd8ff6caea7a87c7e48de227e2daa","Len":2}...
|
1785842687
|
Edit
Delete
|
|
20661
|
5
|
5
|
5
|
72
|
0
|
0
|
refs/heads/feat/multi-role-assignment
|
0
|
{"Commits":[{"Sha1":"3ab4474b6 {"Commits":[{"Sha1":"3ab4474b6c62c031d9016986285fed531904c82c","Message":"chore(governance): REDIS_URL 运行时 fail-closed 绊网与报告聚合接线（并发治理会话收尾）\n\nN6：G15 只在 runner preflight 强制显式 REDIS_URL，应用运行时仍会静默默认\nlocalhost:6379——队列投空、pub/sub 静默丢事件且零日志。四个连接位点\n（双后端 BullMQ + pub/sub）全部接入 fail-closed 判定，governance-report 聚合随之扩展。\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-04T06:57:12-07:00"},{"Sha1":"a82bc613d079d5b14ccdc66d2b901d99d980403f","Message":"chore(governance): 刷新证据行与棘轮——tests 470、own-test-cases 332、UI 12 含死路恢复链\n\n- CLAUDE.md 真源地图新增「履约死路恢复」条目；G16 条目按事务级咨询锁机制修正\n （含连接池滞留 bug 的完整教训与绊网口径）\n- 动态区证据行：静态/runtime/UI 三级 2026-08-04 实跑全绿，作用域＝本地工作区\n- 棘轮收紧：testsPassed 465→470（byPackage 372/49/49）、ownTestCases 327→332、\n gateSelftests 8→14\n- reports/*.latest.json 为终链同 run 产物（provenance 一致）\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-04T06:56:25-07:00"},{"Sha1":"68fe619dbf7752a2bdd058e16fa81fa13653e323","Message":"chore(governance): 新增 sites/component-size 门禁、Redis fail-closed 与依赖范围对齐（并发治理会话）\n\n- check:sites-governance / check:component-size 两个新门禁接入 check 链（含负向自检）\n- Redis URL fail-closed 与队列前缀模块收口\n- 双后端依赖范围从 ^X.0.0 对齐到实际锁定版本邻域（N7 断言配套）\n- pnpm-lock.yaml 同步 specifier（仅 5 行，锁定版本零变化）——不同步则干净\n checkout 上 frozen install 直接 ERR_PNPM_OUTDATED_LOCKFILE\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-04T06:56:01-07:00"},{"Sha1":"4b637592aa9a1af503cbc7bf02e9e7fafa166f49","Message":"style(web): 移动导航搜索与首页视觉打磨（并发治理会话工作，随本轮一并落库）\n\n移动端「更多」菜单搜索、退款入口定位与首页布局打磨及配套 E2E 断言。\n本切片由并发治理会话实现并已随本轮三级门禁（check / runtime 470 / UI 12）整体验证。\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-04T06:56:01-07:00"},{"Sha1":"da3230ece27359e62fd0945dd9d74a79f04fef83","Message":"fix(events): outbox 选主改事务级咨询锁——会话级锁在连接池上滞留导致投递饿死\n\nG16 领取锁闭环（初版为并发治理会话实现，本提交含其 dispatcher 失败判责拆分与\ndual-backend N7 依赖断言，一并落库）。当日实锤修正：\n\n会话级 pg_try_advisory_lock + pg_advisory_unlock 各发一条 $queryRaw——Prisma 是\n连接池，加锁与解锁大概率落在不同池化连接：锁被闲置连接永久滞留，集群投递静默\n饿死。欺骗性极强：低并发 vitest 全绿（池内单连接复用），check:ui 高并发下三连红\n且失败点漂移（前几步实时刷新正常、后面某步等失效超时）。\n\n改为事务级 pg_try_advisory_xact_lock：在 $transaction 事务客户端上取锁，提交/回滚\n自动释放，「解锁落错连接」结构上不可达；锁查询失败＝事务抛错＝本轮不跑批\n（fail-closed 不变）。事务只为持锁而存在，批内行更新仍走连接池。\n\n绊网同步翻转：xact 锁在位/事务客户端取锁/锁结果闸住跑批/会话级回潮即红/失败阶段\n判责/双端锁键对齐；定位锚用调用形态而非裸词（防注释锁名抢占第一处匹配，G13 同型）。\n12 条负向自检全绿，check:ui 12/12 复绿实证实时链恢复。\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-04T06:55:43-07:00"}],"HeadCommit":{"Sha1":"3ab4474b6c62c031d9016986285fed531904c82c","Message":"chore(governance): REDIS_URL 运行时 fail-closed 绊网与报告聚合接线（并发治理会话收尾）\n\nN6：G15 只在 runner preflight 强制显式 REDIS_URL，应用运行时仍会静默默认\nlocalhost:6379——队列投空、pub/sub 静默丢事件且零日志。四个连接位点\n（双后端 BullMQ + pub/sub）全部接入 fail-closed 判定，governance-report 聚合随之扩展。\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-04T06:57:12-07:00"},"CompareURL":"luoanwu/juhai-quotation-system/compare/dddca39245dbd8ff6caea7a87c7e48de227e2daa...3ab4474b6c62c031d9016986285fed531904c82c","Len":6}...
|
1785852216
|
Edit
Delete
|
|
20362
|
7
|
5
|
7
|
72
|
0
|
0
|
refs/heads/hljTest
|
0
|
|
1785740632
|
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
|