| content |
{"Commits":[{"Sha1":"4a707c3d3 {"Commits":[{"Sha1":"4a707c3d3ec98b8ab45864a1b40b941589433914","Message":"chore(reports): 刷新治理证据至 b1510b5（clean，192 tests）\n\n静态 11 项门禁 + 治理棘轮 + lint + typecheck 全绿；\n真实 PG + Redis 验收 192 tests / 0 failures，provenance 绑定 clean commit b1510b5。\n\n⚠️ 作用域：本轮证据只覆盖静态与运行态两级。浏览器级 check:ui **未重跑**——\n本机无 Node 运行时（全部门禁在 node:22 容器内挂载工作树执行），而容器内没有\nLinux 版 Playwright 浏览器（宿主缓存的是 macOS 构建）。按事实作用域表，\n不得据此宣称 UI 层已验证。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-08-29T20:40:42-07:00"},{"Sha1":"b1510b5a203f7847dc99a0962cd30f36e6901dce","Message":"docs(standards): 修正与实现相悖的 API 标准 + 幽灵路径机器化（批次④·下）\n\n## api-standard 的四项核心约定与实现系统性相悖\n\nCLAUDE.md 真源地图把 docs/standards/*.md 列为「工程标准口径」，使用入口表还直接路由读者\n去读它。但 api-standard 的四项核心约定没有一项与两后端实际实现一致：\n`/api/v1/` 前缀（实际 `/api`，未版本化）、`{ data: ... }` 响应包裹（实际裸资源）、\n嵌套 `error.{code,statusCode,timestamp,path}` 错误体（实际是顶层扁平的 ApiErrorBody）、\n以及一个从不存在的 `packages/contracts/src/errors/error-codes.ts`。\n\n照着它落地新模块，会做出与 contracts `ApiErrorBody` 及 web `ApiError` 消费方直接冲突的接口。\n而 review-standard 的检查清单还会让 reviewer 去核对那个幽灵文件。\n\n- 按本仓既有的 C14「标准 vs 现状」惯例（frontend-standard / backend-standard / git-standard\n 都已有）在 api-standard 头部加对照表，逐项写明目标态与当前真相，并说明改动方向：\n 要落地目标态先改实现与契约，不要反过来照着文档改接口\n- 修正 review-standard 的检查项指向真实位置\n\n## 幽灵路径机器化（C14-⑤ 同族，扫描面扩到 standards）\n\n新增 docs-truth 断言：standards 引用的 `packages/contracts/src/**.ts` 路径必须真实存在，\n否则须在同一行显式标注「目标态 / 当前不存在」。扫描面用 readdirSync 覆盖 docs/standards 全量，\n不硬编码文件清单——旧的幽灵路径断言正是因为清单式扫描漏掉了 docs/README.md 本身而失守过。\n\n该断言上线即多抓到一处此前没人发现的幽灵路径（naming-standard 的\n`packages/contracts/src/store/store.types.ts`），已一并标注。\n负向测试：去掉 review-standard 的诚实标注即红。\n\n## owner-matrix 补录 OS 产品两张业务表\n\n「先登记后建表」是本仓自己立的规则，却被自己的 C20/G23 战役打破：OS 产品包新建了\n`juhai_baseframework_orders` / `..._order_events` 两张带状态机的表却从未登记。\n补录两行并写明 `products/` 下的对象同样要登记（归属真源是 product.manifest.json 的\npersistence.tenantModels，本表挂索引行）。\n\n验收：naming / docs-truth / governance-docs / 治理棘轮均 exit 0。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-08-29T20:39:02-07:00"},{"Sha1":"033e8159c23f4766493fd140ffa7aa923ebe1182","Message":"fix(ops): 优雅停机接线——Fastify 的 onClose 钩子此前全是死代码（批次④·中）\n\n## Fastify 从不优雅停机\n\nserver.ts 没有任何信号处理，也从不调用 app.close()：进程收到 SIGTERM 走默认处理直接终止。\n后果是 prisma / redis / outbox / queue 四个插件里**精心写好的 onClose 钩子从未被执行过**——\nBullMQ worker 不 close（在途 job 只能靠 stalled 恢复）、outbox 轮询事务可能被拦腰砍断、\nWS/SSE 连接收不到 close 帧。而 NestJS 侧早有 enableShutdownHooks，两后端停机行为实质分叉。\n\n存在性门禁看得见「钩子写了」，看不见「它从来没被调用过」——这正是 G17 说的行为级盲区。\n\n- server.ts 补 SIGTERM/SIGINT → app.close()（Fastify 会按注册逆序执行全部 onClose），\n 带 10s 超时兜底（卡住的清理不能让容器一直不退）与重复信号防抖\n\n## NestJS 的 Redis 连接从不 quit，且注释谎称有人管\n\nREDIS_PUB / REDIS_SUB 由 useFactory 裸建，没有任何销毁钩子；而 event-bus.service.ts\n的注释写着「redisSub 连接由 RedisModule 统一关闭」——注释与行为相反，于是没人会去查。\n真实后果：停机时连接不回收（两个 acceptance 测试的 afterAll 至今还得手动 quit 才能让进程退出）。\n\n- RedisModule 实现 onApplicationShutdown，quit 两个连接\n- 修正 event-bus 的失实注释\n\n## 防回潮\n\ncheck:dual-backend 新增 4 条停机接线绊网（两后端各自的信号处理 / app.close /\nenableShutdownHooks / Redis 关闭钩子），负向测试已验证删掉信号处理即红。\n\n验收：真实 PG + Redis 192 tests / 0 failures；静态门禁 + 棘轮 + typecheck 5/5 + lint 2/2 全绿。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-08-29T20:35:43-07:00"},{"Sha1":"44cbbaeacf5f53e08e6e3f48a6d8bd2c3327d2de","Message":"fix(governance): 写链守护补齐五条已验证绕过（批次④·上）\n\ncheck:write-guard 守的是 P4「所有写显式带 tenant_id + 状态迁移乐观锁」这条最高优先级红线，\n但它自身存在五条可复现的绕过——每一条都能让违规代码拿到绿盘：\n\n1. **折行**：逐行匹配下 `await tx.order\\n .update({...})` 完全隐形。这甚至无需恶意——\n Prettier 对长链式调用本来就这样折行。\n2. **方括号访问**：`tx[\"order\"].update(` 用 `\\w+` 匹配不到，换个写法整条溜过去。\n3. **upsert 不在禁止模式里**：它与 update/delete 同源（同样只接受唯一键定位），\n TOCTOU 缝隙一模一样，却从未被拦。\n4. **where 里的 tenantId 从未被验证**：门禁 reason 一直宣称 where 是 `{ id, tenantId }`，\n 但只检查了方法名与 state 前置条件——`updateMany({ where: { id } })` 照样绿，\n 而那正是跨租户写。\n5. **0 行拒绝可被一行注释满足**：断言对原始源码做 includes，\n `// if (updated.count === 0)` 就能让一段被注释掉的防护报绿。\n\n修法：\n- 新增 scripts/lib/source-text.mjs 作为公共单源（stripComments / blankComments / lineOf）。\n 「注释掉的代码仍满足断言」这个形态 check-schema-sync 在 2026-08-15 已实锤并就地修过，\n 但同类断言散布在多个脚本里各自对原始源码匹配——按 P5，实锤过的教训必须推广，\n 否则只是把同一个洞留在别处。\n- A 部分改为「注释置空但保持字符偏移」后整体跨行匹配，再由偏移反推行号\n （逐行挡不住折行，整体匹配又需要能定位）；禁止模式补 upsert 与方括号访问。\n- B 部分先提取 updateMany 的 where 块再逐项断言（state 前置条件 + tenantId），\n 且全部在剥注释后的源码上跑。\n\n验收：五条绕过逐一注入验证必红、逐一恢复现场；正向 10 项静态门禁 + 治理棘轮全绿。\nCLAUDE.md 基线表 write-guard 行同步为实际覆盖面（此前的描述比实际防线宽）。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-08-29T20:32:47-07:00"},{"Sha1":"c494fc7d2e6b1497647b2ca9601766626dd4775d","Message":"feat(auth): G8 生产级租户验签闭环——回退翻转 + 401 判责 + 降级通道清除（批次③）\n\nCLAUDE.md 里标注「动工前须用户点名」的最大 OPEN 缺口，验签半边落地。\n\n## 回退翻转（G8 的核心）\n\ndemo 期口径是 `Bearer 解析 ?? x-tenant-id`。接入验签后这个 `??` 会变成**降级攻击面**：\n伪造一个签名无效的 Bearer → 验签失败 → 自动落回客户端自报的 demo 头，等于没验。\n且只翻转这一处并不够——裸 `?tenantId=` 是另一条更彻底的通道，它连伪造 token 都不需要。\n\n- jwt 模式下：带 Authorization 或 ?access_token= 即**强制验签，失败一律 401，绝不回退**；\n x-tenant-id / ?tenantId= / `tenant:\u003cid\u003e` 简写整条不承认\n- demo 模式保留原型四级来源（本地与既有验收测试零改动），但**生产跑 demo 即拒绝启动**——\n 漏配鉴权应当是「起不来」，不是「起来了但谁都能进」\n\n## 架构切分：策略在 contracts，验签由后端注入\n\ncontracts 被 web 直接 import，把 jose 与密钥语义拉进去会泄漏到浏览器包。故：\n- `decideTenantResolution`（谁可信、失败怎么判）在 contracts，两后端共用，13 条单测覆盖\n- jose 验签在各后端（NestJS `src/auth/`、Fastify `src/plugins/auth.ts`）\n- `tenantFromBearerToken` 更名 `unsafeTenantClaimFromToken`：函数名里的 unsafe 是给 review 看的，\n 它只该用于浏览器 UI 预填与 demo 模式\n\nNestJS 的判定必须放 Guard 而非 `@TenantId()` 参数装饰器——后者的回调是同步的，\n判定留在那里就永远接不上异步的 JWKS 验签。\n\n## 顺带堵掉的三个额外攻击面（安全审计发现，均在已登记 G8 描述之外）\n\n1. **tenantId 是攻击者可控的自由文本**：无格式/长度约束时可凭空创建租户分区、\n 可用超长值撑爆 `@@unique([tenantId,email])` 的 btree 索引行打出稳定 500、\n 可用换行伪造日志行。现统一过 normalizeTenantId（≤128 + 受控字符集）。\n2. **重复查询参数的类型混淆**：Fastify 把 `?access_token=a\u0026access_token=b` 解析成数组，\n `typeof v === 'string'` 判定直接落空 → 静默跳过 token 分支 → 落到裸 ?tenantId=；\n 而 NestJS 的 `URLSearchParams.get()` 取第一个值。**同一条请求两后端两种身份判定**——\n 既是真实越权通道，也是 G17 行为分叉的活体实证。两侧统一取第一个值。\n3. **凭证进日志**：浏览器 EventSource/WS 无法自定义头，token 只能进 `?access_token=`，\n 而 pino 默认序列化器把完整 url 写进日志——接入真实验签后就是每次建连落盘一枚有效 JWT。\n Fastify logger 加 redact（authorization / cookie / req.url）。\n\n## 判责矩阵补上 401\n\n此前缺凭证一律回 400，把「未认证」伪装成「参数写错了」，客户端无从区分「该去登录」\n和「该改请求」。现 contracts 定义 UNAUTHENTICATED / INVALID_TOKEN / TENANT_FORBIDDEN；\n响应体**只回稳定错误码**，验签失败细节只进日志（区分「签名不对/已过期/issuer 不符」\n对攻击者是免费的探测反馈）。WS 保持 close(1008) 而非握手期 401——两后端同口径，\n且浏览器对握手 401 不暴露任何原因。\n\n## 验收\n\n真实 PG + Redis：**192 tests / 0 failures**（地板 161 → 192，只收紧）。\n两后端各 9 条 jwt 判责用例：正确签名放行 / 无凭证 401 / **伪造签名 + 合法 x-tenant-id 仍 401**\n/ 裸 demo 头 401 / 过期 401 / alg:none 401 / 无租户 claim 401 / health 免鉴权 / 重复参数不落 victim。\n新增 check:dual-backend 的 G8 绊网 5 条，每条均有负向红证据；其中「算法白名单」一条初版\n被自身的类型声明 `algorithms: string[]` 满足而无法变红，已改绑 jwtVerify 实参后重测。\n静态门禁 10/10 + 治理棘轮 + typecheck 5/5 + lint 2/2 全绿。\n\nRLS 未叠加（结构已就绪，阻碍在 CI 超级用户/单例 Prisma/dispatcher 跨租户扫描三处），\nweb 构建期内联 token 与 WS Origin 白名单同样登记为 G8 剩余项。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-08-29T20:27:41-07:00"}],"HeadCommit":{"Sha1":"4a707c3d3ec98b8ab45864a1b40b941589433914","Message":"chore(reports): 刷新治理证据至 b1510b5（clean，192 tests）\n\n静态 11 项门禁 + 治理棘轮 + lint + typecheck 全绿；\n真实 PG + Redis 验收 192 tests / 0 failures，provenance 绑定 clean commit b1510b5。\n\n⚠️ 作用域：本轮证据只覆盖静态与运行态两级。浏览器级 check:ui **未重跑**——\n本机无 Node 运行时（全部门禁在 node:22 容器内挂载工作树执行），而容器内没有\nLinux 版 Playwright 浏览器（宿主缓存的是 macOS 构建）。按事实作用域表，\n不得据此宣称 UI 层已验证。\n\nCo-Authored-By: Claude Opus 4.8 \u003cnoreply@anthropic.com\u003e\n","AuthorEmail":"hillao@juhailaoluodeMacBook-Pro.local","AuthorName":"juhailaoluo pro","CommitterEmail":"hillao@juhailaoluodeMacBook-Pro.local","CommitterName":"juhailaoluo pro","Timestamp":"2026-08-29T20:40:42-07:00"},"CompareURL":"luoanwu/base-framework/compare/53991090b821b76dff11eee3a2e92806ed3ab173...4a707c3d3ec98b8ab45864a1b40b941589433914","Len":10}... |