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":"fd3ba87ed111d9245012f0578178cccb4743ab20","Message":"chore(reports): B1 的二十八份静态证据 回绑 @ fb2fb1a，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 fb2fb1a（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=fb2fb1a、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次内两把锁各重签一次，都是「变更即复核」而非绕过：\n- kernel.exports.lock.json 763 → 755（statemachine 的 8 个导出归属转移给 @juhai/kernel）\n- check:kernel-downstream 的仓外夹具改为携带 scoped registry 后转绿；缺声明即 fail-closed\n  的分支已实活验证\n\n运行态未跑：B1 只动契约包的一个转发文件，contracts 312/312 与 typecheck 13/13 已覆盖；\n按仓规矩三级证据分开陈述，不用静态绿冒充运行态绿。runtime 报告仍绑在 dcd1c14，\n下次动到两后端（B3′ 采纳上游加固）时必须重跑。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\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-18T02:08:00-07:00"},{"Sha1":"fb2fb1a730a522c6210afc0223c84aaa6946194d","Message":"feat(contracts): B1 内核首次 exact pin @juhai/kernel@0.22.0，statemachine 改为转发\n\nB1 的目的是**验证机制**，不是搬最多的代码：装包、转发、门禁、锁四条链路全走一遍，\n用唯一可证明零行为变化的模块做载体。\n\n- packages/contracts exact pin @juhai/kernel@0.22.0（registry 上有 0.16.0/0.16.1/0.22.0）\n- statemachine.ts 改为**具名**转发 8 个符号。不用 `export * from \"@juhai/kernel\"`：\n  收口前本仓还留着 10 个未迁内核模块，整体 re-export 会与它们的同名导出冲突\n- 机制验证结果：typecheck 13/13 · contracts 312/312（statemachine.test.ts 打的就是转发后的\n  实现）· 整轮 28 步前 27 绿 · **check:platform-provenance 接受新 pin**（lock 解析到 Gitea\n  registry tarball）· 所有权锁 763 → 755，8 个导出的归属转移给内核包\n\n**开工即修正一处自己的判断。** 上一轮我把五个模块叫「白拿」，依据只到导出名重合率。\n逐文件 diff 后：**只有 statemachine 逐字一致**（104 行 diff 0），其余四个实现都不同，\n且方向一致——框架领先、本仓落后，落后的正好是加固：\n\n  replay            框架有 maxSeq + 「游标超前于现存最大 seq ⇒ 报缺口（cursor-unknown）」，\n                    本仓没有 ⇒ 伪造/串号游标被静默判成「已追平」，客户端永远收不到补发；\n                    框架同时修了契约文件内部自相矛盾的 dispatchedAt 注释\n  realtime-command  框架有 REALTIME_WS_MAX_PAYLOAD_BYTES，本仓 WS 载荷无上限\n  subscription      框架有 REALTIME_MAX_SUBSCRIPTION_IDS/_TYPES，本仓订阅列表无上限\n  realtime-stats    本仓是严格超集（多 10 个死信域导出），采纳时要保留\n\n前两类偏 DoS 面。这四个不是「白拿」而是「采纳上游加固」，要改两后端并重跑运行态，\n已从 B1 移入 B3′。立项 §2 加了修正块、§5 改了批次表。\n\n**两处实测新增风险（立项 §6）：**\n\n一、跨层 peer 不一致。已发布的 @juhai/client-fact@1.0.0-rc.3 声明 peer @juhai/kernel: 0.16.1\n（lockfile 权威），而控制面仓里**同版本的源码**声明 0.22.0——控制面昨天做框架同步时改了\n源码却没重新发布。本仓 pin 0.22.0 后 pnpm install 报 unmet peer（警告，不阻断），\n**且现有门禁一条都抓不到**。三条出路（等平台重发 / 本仓退回 0.16.1 / 登记偏差并加 peer\n判据）本提交不代为决定，登记在立项 §6 等裁。\n\n二、pin 的下游代价，由 check:kernel-downstream 第一时间抓到：它在仓外装 contracts 以证明\n下游可消费，而仓外没有 .npmrc，@juhai/kernel 落到 npmjs.org 上 404。这不是门禁的毛病，\n是 pin 的真实代价——**任何消费方不配 @juhai scoped registry 就装不上**（框架 F11 原文同样\n这么声明）。处理：夹具复制仓内 .npmrc 的 scoped registry 行，把断言坐实为「配了 registry\n的消费者装得上」；并在「pin 了 @juhai/* 却无 registry 声明」时 **fail-closed**，绝不静默\n回落到公共 registry（实活验证：去掉声明即 D4 红）。新前提已写进接入手册，五个产品仓\n迁移时要同步配置。\n\n顺带一个可复用的性质：check:kernel-admission 的 K1 只计**直接声明**，所以每迁走一个模块，\n锁里的自有导出数就降一次——它天然成了这条线的进度计（763 → 755）。\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-18T02:06:23-07:00"}],"HeadCommit":{"Sha1":"fd3ba87ed111d9245012f0578178cccb4743ab20","Message":"chore(reports): B1 的二十八份静态证据 回绑 @ fb2fb1a，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 fb2fb1a（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n二十八份 reports/*.latest.json 全部 clean 绑定（gitSha=fb2fb1a、worktreeDirty:false）。\n整轮 28 步全执行，前 27 步全绿，末步 check:kernel-admission 仍是那 8 处已知诚实红。\n\n本批次内两把锁各重签一次，都是「变更即复核」而非绕过：\n- kernel.exports.lock.json 763 → 755（statemachine 的 8 个导出归属转移给 @juhai/kernel）\n- check:kernel-downstream 的仓外夹具改为携带 scoped registry 后转绿；缺声明即 fail-closed\n  的分支已实活验证\n\n运行态未跑：B1 只动契约包的一个转发文件，contracts 312/312 与 typecheck 13/13 已覆盖；\n按仓规矩三级证据分开陈述，不用静态绿冒充运行态绿。runtime 报告仍绑在 dcd1c14，\n下次动到两后端（B3′ 采纳上游加固）时必须重跑。\n\n工作区内三份 reports/ui-*.latest.json 的改动早于本批次，未提交也未还原。\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-18T02:08:00-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/ee4bc06608d88515f025c3a2dcffacb9f47c5417...fd3ba87ed111d9245012f0578178cccb4743ab20","Len":2}

TEXT

created_unix

INTEGER

Update row 31101 in action