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":"56039d0a57c27a4ec97ad38e4fc982ec28f136c1","Message":"docs(治理): CODEOWNERS 占位维持原样——裁决与理由写进文件本身，不再让下一个人重新吵\n\nPR #36 把全部团队占位改指 @laoluojuhai（修 GitHub API 的 16 条 Unknown owner），rebase 试算时\n这处是六个 PR 里唯一一处不能机械合的冲突：照它合会抹掉 main 里 CHG-018 条件 D 要求的工作台实名行，\n照 main 合又等于默默丢掉它的修复意图。2026-09-18 由目录负责人裁决：**维持占位。**\n\n裁决时核到的事实（都写进 .github/CODEOWNERS 头注释了）：\n- GitHub 仓是个人仓（owner.type=User、private、唯一协作者 laoluojuhai/admin）。个人账号下不可能有团队，\n  `@juhai-platform/*` 这 16 行永远解析不了；API 实测正是 16 条 Unknown owner，工作台那行实名反而可解析。\n- 真源远端是 Gitea（luoanwu），`@laoluojuhai` 在那边同样解析不了——这份文件当前在**两个远端都不产生\n  required reviewer**，它现在只是路径 → 角色的登记。\n- 所以 16 条 Unknown owner 是「治理尚未接线」的真实信号，与本仓「显式 skipped 不冒充 passed」同口径。\n- 反面代价：唯一 owner = 唯一协作者，一旦启用 require review from Code Owners，Owner 自己的 PR 无人可批、\n  全部卡死。现在分支保护没启用所以无实害，但那正是这份文件将来要用的地方。\n\n解除条件：仓库迁入 GitHub Organization 并建出 @juhai-platform/* 团队（SRE / Owner 的仓库设置动作）。\nCLAUDE.md 未完成清单那条同步标注为「已裁 + 解除条件」，不再挂成无人认领的欠账。\n\n本提交不改任何 owner 行，只加注释：codeowners.test.mjs 2/2 通过（八条路径覆盖、七模块各有独立行）。\ntrial/rebase-36 上这处本就取的 main 侧，裁决与该分支现状一致，无需再改。\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-18T15:24:55-07:00"},{"Sha1":"de532d4cdc4577caab37df28e8775d4291a8290b","Message":"chore(reports): check:fixtures 回绑 @ 94366bc\n\n17 套件 302 例，失败 0，不可用 0；provenance 绑 94366bc、worktreeDirty=false。\n\n生成方式与既往不同，记在这里以便复核：主工作区连续 4 小时没有出现过干净树\n（并行会话常驻 2—3 份在途文件），因此按偏差 #34-A 裁决立的那条路径——「不放宽\nworktreeDirty 判据，改为换个干净的地方生成报告」——在 HEAD 开 git worktree、装依赖、\n构建后在该检出内跑门禁，再把报告带回。reports:rebind 工具本身拒绝 check:fixtures，\n理由是它需要构建产物（工具靠 governance/ 零依赖才能免 install），那是工具能力边界，\n不是判据边界；本次手工补上了它缺的 install 与 build 两步。\n\n检出必须落在工作区内（本次用 企业控制面/.worktrees/）：dec-039-party-model 是\nworkspaceRelative 套件，要向上找到含 workspace.json 的工作区根，放在 /private/tmp\n会以 unavailable 让门禁 exit 1。\n\n本报告作用域内（governance/fixtures、check-fixtures.mjs、lib/json-schema.mjs、\nruntime/modules、contracts/src/domain、contracts/test/fixtures、contracts/schemas）\n无任何未提交输入；当时主工作区脏的 3 个文件（CLAUDE.md 与 check-module-imports 及其\n测试）全部在作用域之外。\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-18T12:25:54-07:00"},{"Sha1":"94366bc03cb9ba137cd353d50151a01023e9a9c7","Message":"fix(contracts): 注册中心四条就绪闸门只认字面 true，并把持有它们的 393 行接进夹具门禁\n\n不是恢复 9ac9914。那版实现已由 7f82399 的合并整体放弃、取远端那套；本条只在现行\n实现上补它缺的一类判定，用现行实现自己的命名与写法。\n\n现行实现已经做到的，本轮一行未动：崩溃面在远端那版就已收口（REGISTRY_SNAPSHOT_REQUIRED /\nUPGRADE_REQUEST_REQUIRED / UPGRADE_REVIEW_CONTEXT_REQUIRED 等）；摘要大小写的处理比\n本地那版更好——normalizeDigest 归一化成小写、sameHexRef 做大小写无关比较，是规范化\n而不是拒绝，这条采纳远端口径。\n\n仍缺的一条：independentGitSourceReady / codeownersReady / requiredCheckEvidenceReady /\nrollbackEvidenceReady 写作 !context.x。实测传 \"false\"——JSON 里最常见的假值写法——\n一律判为已就绪并直达 READY_FOR_CONSUMER_UPGRADE_REVIEW，1 / \"no\" / {} 同理。同一文件的\nsourceWorktreeDirty !== false 与 compatible / manualReviewRequired 本来就是严格写法，\n本轮把这四条与之对齐。\n\n门禁覆盖：snapshot-upgrade-review.ts 在夹具评估器上仍是零覆盖（规则只有 snapshot /\ntransition / plan），而它正是这四条闸门的所在。补 upgrade 规则，BLOCKED 不算放行。\n\n核验：定向 44 → 46 例（既有 44 例一条未改）；夹具 15 → 21 例（正 5 / 反 16）0 失败，\n两个方向都钉（真值字符串与字面 false 各一组）；负向实做：把\nN13-truthy-string-must-not-mark-codeowners-ready 的声明原因改成不会产生的串，门禁\nexit 1 并点名该例，还原后 exit 0。Catalog 登记未动。\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-18T12:24:22-07:00"}],"HeadCommit":{"Sha1":"56039d0a57c27a4ec97ad38e4fc982ec28f136c1","Message":"docs(治理): CODEOWNERS 占位维持原样——裁决与理由写进文件本身，不再让下一个人重新吵\n\nPR #36 把全部团队占位改指 @laoluojuhai（修 GitHub API 的 16 条 Unknown owner），rebase 试算时\n这处是六个 PR 里唯一一处不能机械合的冲突：照它合会抹掉 main 里 CHG-018 条件 D 要求的工作台实名行，\n照 main 合又等于默默丢掉它的修复意图。2026-09-18 由目录负责人裁决：**维持占位。**\n\n裁决时核到的事实（都写进 .github/CODEOWNERS 头注释了）：\n- GitHub 仓是个人仓（owner.type=User、private、唯一协作者 laoluojuhai/admin）。个人账号下不可能有团队，\n  `@juhai-platform/*` 这 16 行永远解析不了；API 实测正是 16 条 Unknown owner，工作台那行实名反而可解析。\n- 真源远端是 Gitea（luoanwu），`@laoluojuhai` 在那边同样解析不了——这份文件当前在**两个远端都不产生\n  required reviewer**，它现在只是路径 → 角色的登记。\n- 所以 16 条 Unknown owner 是「治理尚未接线」的真实信号，与本仓「显式 skipped 不冒充 passed」同口径。\n- 反面代价：唯一 owner = 唯一协作者，一旦启用 require review from Code Owners，Owner 自己的 PR 无人可批、\n  全部卡死。现在分支保护没启用所以无实害，但那正是这份文件将来要用的地方。\n\n解除条件：仓库迁入 GitHub Organization 并建出 @juhai-platform/* 团队（SRE / Owner 的仓库设置动作）。\nCLAUDE.md 未完成清单那条同步标注为「已裁 + 解除条件」，不再挂成无人认领的欠账。\n\n本提交不改任何 owner 行，只加注释：codeowners.test.mjs 2/2 通过（八条路径覆盖、七模块各有独立行）。\ntrial/rebase-36 上这处本就取的 main 侧，裁决与该分支现状一致，无需再改。\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-18T15:24:55-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/34403ffdfeda4af776b5f4063a40b9b04340895a...56039d0a57c27a4ec97ad38e4fc982ec28f136c1","Len":3}

TEXT

created_unix

INTEGER

Update row 31156 in action