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":"6fbebf5285a9a335410c5f884d81314d0394429c","Message":"chore(reports): candidate-contracts 回绑 @ 16459e0 —— 9 条探针零豁免\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-18T19:55:24-07:00"},{"Sha1":"16459e09061655eb29b432aa5a9334b9685cbced","Message":"test(contracts): 跨域流程的 plan 补第一条 ACCEPT 用例——最后一条 shape 探针豁免清零\n\ncheck:candidate-contracts 此前带着一条豁免：planWorkflowInstance 取不到 ACCEPT 载荷，\n因为 cross-domain-workflow 的 plan 规则在 28 例夹具里全是反例。查隔壁——\ncollaboration-messaging 的同类规则 P03 是有正例的。所以这不是「夹具只固定失败关闭一侧」\n的设计口径，是这一域缺了一条，而豁免让它看起来像是有意为之。\n\n补 P04-approved-snapshot-plans-an-instance：已批准快照 + 合法请求，载荷直接取自该域单测里\n那条已在跑的 planner 正例（不是新造的场景）。夹具 28 → 29 例（正 4 / 反 25），\ncheck:fixtures 该套件 29/29 失败 0，fixture-coverage 三档仍全为 0。\n\n连带把 C15 契约的探针由 skip 换成真探针（planWorkflowInstance ← plan.request）：\n9 条探针全部比对通过、零豁免。门禁单测两处计数同步，并把断言从「豁免恰好是这一条」\n改成「豁免必须为空；再出现必须带理由」——前者会在下次加豁免时静默通过。\n\n数字声明同步：仓根 CLAUDE.md 的 17 套件 706 例 → 707，宿主协议 C15 单与索引底账的夹具数\n同步；check-workspace-consistency CLEAN，L13 无漂移。contracts 测试 416/416。\n\n跑这两道门禁都用 GOV_REPORT_DIR 重定向，仓里在途的 fixtures 报告一个字节未动——\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-18T19:55:21-07:00"},{"Sha1":"05497f5a3cad8b4a82d07b81504c06fe6338c972","Message":"chore(reports): candidate-contracts 回绑 @ 864231d —— 含 11 个操作 ↔ 参考处理器的双向对账\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-18T19:49:18-07:00"},{"Sha1":"864231dc64629e58ddd53faf5c38b4f58fdf05f9","Message":"feat(contracts): 五份候选契约有了可挂载的参考实现——11 个操作，传输无关、零框架依赖\n\nC-3 把这五个域的运行宿主裁给上层既有宿主、本仓不建模块，所以「完善 HTTP 实现」不能是在\nruntime 里加路由。但「每个宿主各写一遍入参解码与决策映射」必然各写各的：REJECT 被压成 4xx、\nSKIP_DUPLICATE 被当成失败、now 忘了从 ISO 串还原成 Date——每一个都是一次就足以让语义走样。\n把这一段写在 contracts/src/http/，判定与映射同源，宿主实现 = 挂载 + 鉴权 + 持有快照。\n\n本层不做任何入参校验，这是实测后的决定，不是省事。首版写了信封校验（非对象或缺顶层键回 400），\n被夹具 N06-definition-is-not-an-object 当场戳穿——那条用例期望的是 WORKFLOW_DEFINITION_INVALID，\n400 把它盖掉了。随后逐个实测七个规则入口：传非对象 / 空对象 / undefined，一律 REJECT 并带自己的\n原因码，没有一个抛异常。校验层不是多一道保险，是多一套词汇：同一个错两种表达，消费侧必然挑更\n好读的那套，规则的原因码就此架空。五份契约的 400 描述同步改为「宿主的 JSON 解析失败」。\n\n唯一的边界处理是 Date 还原：context.now（体验）与 context.policy.now（成本，嵌深一层）过 HTTP\n是 ISO 串而规则侧是 Date。漏了不会报错，只会让时间判定永远不触发——一条静默放行的路径。\n\n测试拿规则自己的夹具载荷经处理器走一遍：ACCEPT 例仍非 REJECT，REJECT 例 reasons 与夹具逐条一致，\n无快照时 planner 失败关闭仍是 200 REJECT 而非 5xx。contracts 测试 408 → 416/416，\ncheck:generated 无漂移。\n\n门禁加 HANDLER_MISSING / HANDLER_ORPHAN 双向对账。按文本解析 index.ts 而不是 import dist——\n本门禁在 ZERO_DEP_GATES 里，要能在没装依赖的临时检出里重跑，改成 import 就会退化成未构建即\nunavailable，干净回绑随之失效。负向实测：把 assessResourceTags 改名，两条规则各报一次。\n\n未做：catalogs/ 一字未动；本仓不挂路由、不建库、不新增模块，C-3 的「不新增 M8」未被触碰；\n401 / 403 / 503 属宿主责任，不在本层。\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-18T19:49:15-07:00"},{"Sha1":"fb371d6cec3a76db97335f51a352cef8c2d7c7b4","Message":"chore(reports): candidate-contracts 回绑 @ fdbefc9 —— 补 rules-entry 后重跑，仍 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-09-18T19:41:03-07:00"}],"HeadCommit":{"Sha1":"6fbebf5285a9a335410c5f884d81314d0394429c","Message":"chore(reports): candidate-contracts 回绑 @ 16459e0 —— 9 条探针零豁免\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-18T19:55:24-07:00"},"CompareURL":"luoanwu/enterprise-platform/compare/b69710a74604d55a435971103dc033025cbc6e6b...6fbebf5285a9a335410c5f884d81314d0394429c","Len":24}

TEXT

created_unix

INTEGER

Update row 31229 in action