SQLite Web: gitea.db

id

Primary key. INTEGER NOT NULL

user_id

INTEGER

op_type

INTEGER

act_user_id

INTEGER

repo_id

INTEGER

comment_id

INTEGER

is_deleted

INTEGER NOT NULL (default 0

ref_name

TEXT

is_private

INTEGER NOT NULL (default 0

content

{"Commits":[{"Sha1":"63ff31f256e45886e0a52d5e819ef7b3730eba9b","Message":"feat(治理): check:pins 扩到第三方依赖——发布包严格，应用侧走存量基线\n\n此前 check:pins 只管 @juhai/*，第三方 pin 完全不看。量了一下：256 个第三方依赖声明里\n218 个（85%）是 range。直接全判红等于让门禁第一天就红 218 处；全量 pin 则要改 218 处并\n重建 runtime / identity 两个 lockfile、触碰整棵依赖树——而 lockfile + --frozen-lockfile\n已经保证了日常构建可复现，range 的真实风险只是有人跑 pnpm update 时意外升级。\n目录负责人裁决：分层。\n\n三层判据：\n\n  1. @juhai/*      一律 exact / workspace:*（原有）\n  2. 对外发布包    第三方依赖也一律 exact。判定依据是 publishConfig 的存在——它是「这个包会被\n                   发出去」的机器特征，比硬编码包目录好：新增发布包自动纳入，不必记得回来改门禁。\n                   消费者装到的是发布时解析的那棵树，range 在他们那边会解析成别的版本。\n  3. 其余（应用）  存量 209 处登记在 governance/pins-baseline.json，登记外的新增必须 exact。\n                   基线**只减不增**：登记项对应的依赖删了条目也要删，否则 BASELINE_STALE 判红。\n\n配套把 clients 三包的 9 处 devDeps pin 掉（@types/node 22.19.20 / typescript 5.9.3 /\nvitest 2.1.9，取自 lockfile 已解析的版本）。lockfile 只动了 9 行 specifier，\n**resolution 变更 0 行**，依赖树没变；pnpm install --frozen-lockfile 复验通过。\n\n**一处会炸下游的设计，改掉了：** 初版把「无基线」当空基线 fail closed。但 @juhai/governance\n是发布给消费者仓（HR / OS）的 CLI，他们跑 juhai-governance check:pins --require @juhai/contracts\n时仓里没有本仓基线，按空基线判会把他们全部第三方 range 判红——一次判据扩展直接炸掉所有下游。\n改为：无基线则第三方层不启用，且**在输出里明说**（不静默关闭）。测试钉住了这条契约。\n\n本机实测：本仓 37 处 @juhai/* + 第三方 256 处（47 exact，含发布包 17 处严格；209 处在基线内）\nexit 0；模拟消费者仓（无基线）exit 0 且第三方层未启用；四种违规场景（发布包 range、\n基线外新增、基线腐烂、无基线）行为逐一验过，退出码直取、不经管道。测试 10 → 17 例。\n\ngovernance/README.md 同步（它随包发布，判据表必须与实现一致）；CLAUDE.md 纪律 4 同步。\npins-baseline.json 不进 governance 包的 files——它是本仓的存量账，对消费者无意义。\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:37:14-07:00"},{"Sha1":"8939e8fc35a7c42d4957e2297c8dcb8eb58cb663","Message":"chore(reports): check:fixtures 回绑 @ 748492c —— 补上本会话四轮夹具增量欠的那一笔\n\nreports/fixtures.latest.json 此前绑在 7523bd0（17 套件 316 例），check:evidence 报 EVIDENCE_STALE：\n作用域内 14 个文件已变更。变更的大头是本会话四条加夹具的提交——1a1b37e（IM）、bdb662d（数据分析）、\n7a4b693（成本容量）、0b3dab6（Webhook）、4f36e22（注册中心）、4df190d（最后 9 条仅单测）。\n每轮提交信息里都写了「本次不回绑」，当时理由成立（工作树有并行会话 WIP，拿不到 worktreeDirty=false），\n但后续没人补，就成了欠账。\n\n回绑做法：在 企业控制面/.worktrees/rebind-fixtures 开 detached 干净检出（HEAD 748492c），\n把主检出的 node_modules 软链进去（软链不被 .gitignore 的 node_modules/ 目录规则匹配，故写进\n本地 info/exclude，不改仓内 .gitignore），build contracts 与七模块后跑 check:fixtures，\n确认 git status 为空再出报告，最后只把这一份 report 拷回主检出、按 pathspec 单独提交——\n主检出里并行会话另有 11 份报告在改，一份都没碰。\n\n结果：provenance gitSha=748492c、worktreeDirty=false，17 套件 458 例 0 失败 0 不可用\n（此前 316 例，+142 例即本会话四轮的夹具增量）。\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:33:25-07:00"}],"HeadCommit":{"Sha1":"63ff31f256e45886e0a52d5e819ef7b3730eba9b","Message":"feat(治理): check:pins 扩到第三方依赖——发布包严格，应用侧走存量基线\n\n此前 check:pins 只管 @juhai/*，第三方 pin 完全不看。量了一下：256 个第三方依赖声明里\n218 个（85%）是 range。直接全判红等于让门禁第一天就红 218 处；全量 pin 则要改 218 处并\n重建 runtime / identity 两个 lockfile、触碰整棵依赖树——而 lockfile + --frozen-lockfile\n已经保证了日常构建可复现，range 的真实风险只是有人跑 pnpm update 时意外升级。\n目录负责人裁决：分层。\n\n三层判据：\n\n  1. @juhai/*      一律 exact / workspace:*（原有）\n  2. 对外发布包    第三方依赖也一律 exact。判定依据是 publishConfig 的存在——它是「这个包会被\n                   发出去」的机器特征，比硬编码包目录好：新增发布包自动纳入，不必记得回来改门禁。\n                   消费者装到的是发布时解析的那棵树，range 在他们那边会解析成别的版本。\n  3. 其余（应用）  存量 209 处登记在 governance/pins-baseline.json，登记外的新增必须 exact。\n                   基线**只减不增**：登记项对应的依赖删了条目也要删，否则 BASELINE_STALE 判红。\n\n配套把 clients 三包的 9 处 devDeps pin 掉（@types/node 22.19.20 / typescript 5.9.3 /\nvitest 2.1.9，取自 lockfile 已解析的版本）。lockfile 只动了 9 行 specifier，\n**resolution 变更 0 行**，依赖树没变；pnpm install --frozen-lockfile 复验通过。\n\n**一处会炸下游的设计，改掉了：** 初版把「无基线」当空基线 fail closed。但 @juhai/governance\n是发布给消费者仓（HR / OS）的 CLI，他们跑 juhai-governance check:pins --require @juhai/contracts\n时仓里没有本仓基线，按空基线判会把他们全部第三方 range 判红——一次判据扩展直接炸掉所有下游。\n改为：无基线则第三方层不启用，且**在输出里明说**（不静默关闭）。测试钉住了这条契约。\n\n本机实测：本仓 37 处 @juhai/* + 第三方 256 处（47 exact，含发布包 17 处严格；209 处在基线内）\nexit 0；模拟消费者仓（无基线）exit 0 且第三方层未启用；四种违规场景（发布包 range、\n基线外新增、基线腐烂、无基线）行为逐一验过，退出码直取、不经管道。测试 10 → 17 例。\n\ngovernance/README.md 同步（它随包发布，判据表必须与实现一致）；CLAUDE.md 纪律 4 同步。\npins-baseline.json 不进 governance 包的 files——它是本仓的存量账，对消费者无意义。\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:37:14-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/748492c2a1013dbf03b6234f2a85dea73af7e9e6...63ff31f256e45886e0a52d5e819ef7b3730eba9b","Len":2}

TEXT

created_unix

INTEGER

Update row 31193 in action