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":"a9bf41341677134557538182b87a1339aa7b7616","Message":"docs(governance): 动态区回灌至 clean @ 3bb349d + 把「动态区与报告同步」机器化\n\n回灌\n- 三级证据新鲜度从 `dirty @ a9e18b9` 更正为 **clean @ `3bb349d`**（静态 exit 0、\n  runtime 202 tests / 差分 0 differences、UI 8 用例），并记录本轮实际基座库名与端口覆盖；\n- G0 余项（clean commit 三级重跑）标记完成；\n- 基线表 6 行「本地 dirty」改为 clean 绑定；\n- OS 两级本轮 SKIPPED / 未实跑，诚实标为 🟡 STALE——不随其他行一起蹭 clean。\n\n机器化（P5：机器门禁 \u003e 手册条目 \u003e 口头经验）\ncheck:docs-truth 新增 freshness-sha-runtime / freshness-sha-ui 两条断言：\n动态区声明的 SHA 必须等于对应 latest 报告的 provenance.gitSha。\n\n实锤依据：连续两轮报告刷新提交都没回灌动态区（报告 clean @ 3bb349d，\n动态区仍写 dirty @ a9e18b9）；而 CLAUDE.md 自己规定「判定治理状态只认动态区 + reports」，\n两份真源打架时该规矩直接失效。同一轮人工回灌时我又把「本轮根本没跑」的 OS 行\n误标成 clean——人肉同步不可靠，正是 P5 要求机器化的形态。\n\n刻意不含静态级：governance.latest.json 每次 pnpm check 都重新生成并绑定当时 HEAD，\n对它断言等价于「每次提交都必须改文档」、提交报告后必红，那是会误杀的门禁。\nruntime/UI 报告只有显式跑真实验收才会变，「报告动了而文档没跟上」才是真信号。\n\n负向测试（收尾清单要求）：\n① 把 runtime 行 SHA 篡改为 a9e18b9 → freshness-sha-runtime 精确红；\n② 删掉 UI 行的 SHA 声明 → freshness-sha-ui 精确红；\n两次均恢复现场后复跑转绿。pnpm check exit 0。\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-08-31T17:00:44-07:00"}],"HeadCommit":{"Sha1":"a9bf41341677134557538182b87a1339aa7b7616","Message":"docs(governance): 动态区回灌至 clean @ 3bb349d + 把「动态区与报告同步」机器化\n\n回灌\n- 三级证据新鲜度从 `dirty @ a9e18b9` 更正为 **clean @ `3bb349d`**（静态 exit 0、\n  runtime 202 tests / 差分 0 differences、UI 8 用例），并记录本轮实际基座库名与端口覆盖；\n- G0 余项（clean commit 三级重跑）标记完成；\n- 基线表 6 行「本地 dirty」改为 clean 绑定；\n- OS 两级本轮 SKIPPED / 未实跑，诚实标为 🟡 STALE——不随其他行一起蹭 clean。\n\n机器化（P5：机器门禁 \u003e 手册条目 \u003e 口头经验）\ncheck:docs-truth 新增 freshness-sha-runtime / freshness-sha-ui 两条断言：\n动态区声明的 SHA 必须等于对应 latest 报告的 provenance.gitSha。\n\n实锤依据：连续两轮报告刷新提交都没回灌动态区（报告 clean @ 3bb349d，\n动态区仍写 dirty @ a9e18b9）；而 CLAUDE.md 自己规定「判定治理状态只认动态区 + reports」，\n两份真源打架时该规矩直接失效。同一轮人工回灌时我又把「本轮根本没跑」的 OS 行\n误标成 clean——人肉同步不可靠，正是 P5 要求机器化的形态。\n\n刻意不含静态级：governance.latest.json 每次 pnpm check 都重新生成并绑定当时 HEAD，\n对它断言等价于「每次提交都必须改文档」、提交报告后必红，那是会误杀的门禁。\nruntime/UI 报告只有显式跑真实验收才会变，「报告动了而文档没跟上」才是真信号。\n\n负向测试（收尾清单要求）：\n① 把 runtime 行 SHA 篡改为 a9e18b9 → freshness-sha-runtime 精确红；\n② 删掉 UI 行的 SHA 声明 → freshness-sha-ui 精确红；\n两次均恢复现场后复跑转绿。pnpm check exit 0。\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-08-31T17:00:44-07:00"},"CompareURL":"luoanwu/base-framework/compare/6449421518ff6b2dd62b6ff862ff44aedcbbea29...a9bf41341677134557538182b87a1339aa7b7616","Len":1}

TEXT

created_unix

INTEGER

Update row 26935 in action