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":"3c9f6df78f540226554cb4ecc6115741fe478c41","Message":"chore(governance): 接真实 DB 重跑，13→15 通过，并暴露 outbox 多实例的可复现失败\n\n按本目录\"每轮新建空验收库\"的口径建独立库：\n  juhai_ai_hr_system_parity_20260915（prisma migrate deploy 后为空库）\n  REDIS_URL 用 /14 号逻辑库\n\n库名前缀不是随便起的——G15 守卫按 package.json 的 name 推导（juhai_ai_hr_system），\n首次用 juhai_hr_parity_* 被三条门禁正确拒绝：\"Database … does not belong to …\"。\n守卫工作正常，是库名起错了。\n\n接上实例后两条转绿：check-dual-backend-behavior、check-health-dependency-failure。\n\n**新暴露一条可复现失败：check-outbox-multi-instance**\n  nestjs / fastify 双侧同样结果：dispatched=120, observed=0, subscriberStatus=ready\n连跑两次一致。门禁本身跑完了全程，不是\"缺环境变量跑不起来\"那一类。根因未定——\n可能是缺少未文档化的 relay / worker 配置（本仓 .env 里没有任何 REDIS/DATABASE 项），\n也可能是真实缺陷。不在此下结论，交仓 Owner；报告如实记录该结果。\n\n仍失败的另外 4 条：api-migration-safety 需 MIGRATION_TEST_ADMIN_URL；\nos-product-host-ui 需浏览器；os-product-layer 与 os-product-registration 分别级联于\nhost-ui 报告与 target OS checkout / runtime 验收证据。\n\n18 份报告 provenance 全部绑定 d970541 且 worktreeDirty=false；连接串中口令已按仓内\n既有口径脱敏为 app:***，仅余本机地址与库名。\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-15T00:50:03-07:00"},{"Sha1":"d970541bd56e5f82659322c8f738d2f5d49c1770","Message":"chore(governance): 命名门禁修复后在新 HEAD 上重跑，静态面由 12 通过升为 13\n\n上一提交（8d74d4d）改了 scripts/ 下四个治理模块，按证据纪律旧报告随即失效——\n本提交只动 reports/，绑定 8d74d4d，与源码内容一一对应。\n\n静态门禁 13 通过 / 7 失败。7 条里没有一条是本仓代码质量问题：\n- 4 条缺实例：dual-backend-behavior / health-dependency-failure /\n  outbox-multi-instance 需 DATABASE_URL，api-migration-safety 需\n  MIGRATION_TEST_ADMIN_URL（这三份报告刻意不提交，见上一轮说明）\n- 1 条崩栈：os-product-host-ui\n- 2 条级联：os-product-layer 卡在 host-ui 报告，\n  os-product-registration-verification 卡在 target OS checkout 与 runtime 验收证据\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-15T00:41:17-07:00"},{"Sha1":"8d74d4d814aad8e2df43f867e1dd61baf59b9075","Message":"fix(governance): 命名门禁 32 条违规逐行豁免 —— 治理脚本里的 terminal 是终态不是终端\n\na0ebf77（当前 HEAD 的前一提交）引入 scripts/lib/database-rls-*-governance.mjs 与\nos-product-migration-governance.mjs 时，命名门禁没跑过——提交后 naming 由 0 条变\n32 条，而 reports/naming.latest.json 停在 09-01 的 violations: 0，没人看得见。\n这正是\"无一份证据绑定当前 HEAD\"的实际后果。\n\n32 条全部是误报类：\n- 31 × terminal：`employment-terminal-late-authority-revoke` 这类指的是**迁移序列\n  与 RLS 的终态**，业务词典要求改成 device（设备）在这里是错的\n- 1 × business：`shared business database` 是 PostgreSQL 术语，不是业务方\n\n扫描面与词典自 2026-08-25 bootstrap 起未变，所以不是门禁改严了，是新代码撞上了\n一直存在的词表。\n\n用门禁自带的逐行 `// naming-ignore` 机制，并逐条写明理由——不收窄 SCAN_DIRS：\n治理脚本里同样会出现业务概念名，去掉 scripts/ 会让真的违规漏网。豁免要作者写明，\n不能按路径猜，与工作区一致性门禁的 `\u003c!-- 一致性门禁豁免 --\u003e` 同一口径。\n\n改动只在行尾追加注释，5 处含模板字符串的行已逐一核对反引号在同行闭合。\n三份治理模块的自有测试 311/311 通过，四个文件 node --check 通过。\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-15T00:40:57-07:00"},{"Sha1":"7d14ff2472a4204046b7d6bbea1a4d84f408e7f3","Message":"chore(governance): 在 clean HEAD 上重跑静态门禁，并记下 naming 的 32 条真实违规\n\n迁移后本仓 37 份 reports/*.latest.json 无一绑定当前 HEAD，全部生成于脏树，其中\n15 份正文还带着 /Users/ailaoluo/ 的两代前绝对根——那是另一台机器。所以此前既不能\n说\"当前 HEAD 是绿的\"，也不能说\"是红的\"，它一直是未知数。\n\n本次在 clean HEAD (a0ebf77) 上重跑全部静态门禁：12 通过 / 8 失败，提交其中 15 份\n（provenance 全部 gitSha=a0ebf77 且 worktreeDirty=false）。\n\n**一条真实失败：check-naming 32 条违规。** 上一份报告（09-01）记的是 violations: 0。\n命中全部落在门禁脚本自己身上——scripts/lib/database-rls-history-governance.mjs 的\n`terminal`（RLS 终态）被业务词典判成应改为 device，check-api-migration-safety.mjs 的\n`business database` 判成应改为 merchant。业务词典的扫描面覆盖到了治理脚本，而那里的\n词是技术义不是业务义。这是扫描面扩大后出现的误报类失败，词典或扫描面需收敛。\n\n**刻意不提交 3 份**：dual-backend-behavior / health-dependency-failure /\noutbox-multi-instance 因缺 DATABASE_URL 写出 failed——那是跑不起来，不是判定失败，\n记进去会把环境缺失伪装成质量问题。\n\n**保留两份 OS 产品的失败报告**：os-product-layer 与 os-product-registration-verification\n这次的失败理由是当前的（前者卡 host-ui 报告、后者卡 target OS checkout 与 runtime\n验收证据），且不再含两代前的绝对根——比它们替换掉的旧报告更可用。\n\n按证据等级\"静态 \u003c 真实 DB \u003c 浏览器\"，本次只提升到静态一级。\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-15T00:35:28-07:00"}],"HeadCommit":{"Sha1":"3c9f6df78f540226554cb4ecc6115741fe478c41","Message":"chore(governance): 接真实 DB 重跑，13→15 通过，并暴露 outbox 多实例的可复现失败\n\n按本目录\"每轮新建空验收库\"的口径建独立库：\n  juhai_ai_hr_system_parity_20260915（prisma migrate deploy 后为空库）\n  REDIS_URL 用 /14 号逻辑库\n\n库名前缀不是随便起的——G15 守卫按 package.json 的 name 推导（juhai_ai_hr_system），\n首次用 juhai_hr_parity_* 被三条门禁正确拒绝：\"Database … does not belong to …\"。\n守卫工作正常，是库名起错了。\n\n接上实例后两条转绿：check-dual-backend-behavior、check-health-dependency-failure。\n\n**新暴露一条可复现失败：check-outbox-multi-instance**\n  nestjs / fastify 双侧同样结果：dispatched=120, observed=0, subscriberStatus=ready\n连跑两次一致。门禁本身跑完了全程，不是\"缺环境变量跑不起来\"那一类。根因未定——\n可能是缺少未文档化的 relay / worker 配置（本仓 .env 里没有任何 REDIS/DATABASE 项），\n也可能是真实缺陷。不在此下结论，交仓 Owner；报告如实记录该结果。\n\n仍失败的另外 4 条：api-migration-safety 需 MIGRATION_TEST_ADMIN_URL；\nos-product-host-ui 需浏览器；os-product-layer 与 os-product-registration 分别级联于\nhost-ui 报告与 target OS checkout / runtime 验收证据。\n\n18 份报告 provenance 全部绑定 d970541 且 worktreeDirty=false；连接串中口令已按仓内\n既有口径脱敏为 app:***，仅余本机地址与库名。\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-15T00:50:03-07:00"},"CompareURL":"luoanwu/juhai-ai-hr-system/compare/a0ebf7769727344892ab96c1240bd809b5791430...3c9f6df78f540226554cb4ecc6115741fe478c41","Len":4}

TEXT

created_unix

INTEGER

Update row 30101 in action