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":"5f3f6084506e2a173759f07f882713ffdd4111ae","Message":"test(contracts): 注册中心 upgrade 的请求体检面——15 条原因码只有实现没有用例\n\n同日「注册中心入参体检的门禁覆盖」补的是 snapshot / transition 两条规则；按同一口径把 upgrade 也算了\n一遍，15 条「哪里都没有」，全部在四条就绪闸门下面那层请求校验：\n\n  两个 pin 的锁定四要素（snapshotVersion / snapshotDigest / sourceCommit / lockMode=exact_digest）\n    与消费者归属                                                        10 条\n  目标制品的 schemaApiVersion 与 linter 证据                             2 条\n  影响面的受影响清单、已确认清单与消费者归属比对                          3 条\n\n此前 6 个 upgrade 用例全部对着四条就绪闸门（independentGitSourceReady 等各一条真值用例，那部分做得\n完整）。闸门开了之后请求本身长什么样，门禁不看——这 15 条删掉不会红。我今天早些时候说「upgrade 那半边\n做得很扎实」是说窄了：说的是闸门，不是闸门下面的请求面。\n\n补：夹具 25 → 32 例（N21–N27），单测 49 → 53 例。成组声明是有意的——门禁要求声明的原因逐条出现，\n所以一条用例同时钉住四要素，比四条各钉一条更严。补后重算：本域「哪里都没有」归 0。\n\n负向实测：给 N21 加一条不会产生的声明原因 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补覆盖，没有改任何判定；snapshot-upgrade-review.ts 一行未动。\n九个契约包至此「哪里都没有」全部归零。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 53/53、contract-application-contract-registry 32/32。\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:59:45-07:00"}],"HeadCommit":{"Sha1":"5f3f6084506e2a173759f07f882713ffdd4111ae","Message":"test(contracts): 注册中心 upgrade 的请求体检面——15 条原因码只有实现没有用例\n\n同日「注册中心入参体检的门禁覆盖」补的是 snapshot / transition 两条规则；按同一口径把 upgrade 也算了\n一遍，15 条「哪里都没有」，全部在四条就绪闸门下面那层请求校验：\n\n  两个 pin 的锁定四要素（snapshotVersion / snapshotDigest / sourceCommit / lockMode=exact_digest）\n    与消费者归属                                                        10 条\n  目标制品的 schemaApiVersion 与 linter 证据                             2 条\n  影响面的受影响清单、已确认清单与消费者归属比对                          3 条\n\n此前 6 个 upgrade 用例全部对着四条就绪闸门（independentGitSourceReady 等各一条真值用例，那部分做得\n完整）。闸门开了之后请求本身长什么样，门禁不看——这 15 条删掉不会红。我今天早些时候说「upgrade 那半边\n做得很扎实」是说窄了：说的是闸门，不是闸门下面的请求面。\n\n补：夹具 25 → 32 例（N21–N27），单测 49 → 53 例。成组声明是有意的——门禁要求声明的原因逐条出现，\n所以一条用例同时钉住四要素，比四条各钉一条更严。补后重算：本域「哪里都没有」归 0。\n\n负向实测：给 N21 加一条不会产生的声明原因 → 门禁 exit 1 并点名该例，恢复后转绿。\n\n本条只补覆盖，没有改任何判定；snapshot-upgrade-review.ts 一行未动。\n九个契约包至此「哪里都没有」全部归零。\n\n证据：在仅含本提交改动的导出树上 tsc 绿、定向 53/53、contract-application-contract-registry 32/32。\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:59:45-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/352e61531916d12d6eb804674f5e49796104fd06...5f3f6084506e2a173759f07f882713ffdd4111ae","Len":1}

TEXT

created_unix

INTEGER

Update row 31168 in action