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":"74c732d8d4b88957365dd80770032bab706e84e2","Message":"chore(reports): B3′ 的四十一份三级证据 回绑 @ df72512，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 df72512（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=df72512、worktreeDirty:false）：\n静态 28 + 运行态 13。静态整轮 **28/28 步骤全部通过**（退出码 0），运行态 733 tests /\n行为矩阵 204/204 / 87 项指标零违规。\n\n本批改的是两后端的 WS 传输层与 replay 查询，两个预设风险点均未兑现：\n- 16 KiB 传输层上限**未挡住任何测试**——正常控制帧远在其下，上限值选得合适\n- outbox 查询由 findFirst 改为 aggregate(_min/_max) 后，在 RLS enforce 下行为与原先一致\n\nruntime 跑了两轮，**数字完全一致**（733 / 204-204 / 零违规），无非确定性；第一轮因改动\n尚未提交而 worktreeDirty:true，按仓规矩只绑定本地、不能作阶段门证据，故提交实现后重跑。\n这是顺序问题不是结果问题——记下来是为了下次先提交再跑，省一轮 20 分钟。\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-18T08:15:17-07:00"},{"Sha1":"df72512110999b668b00c5cbf94ce0691ec7f3af","Message":"feat(realtime): B3′ 采纳上游两处加固——重放游标缺口判定与 WS 传输层单帧上限\n\n立项 §2 的「采纳上游加固 4」批次。逐个比对后实收两处真加固、一处口径收敛，另有两处\n开工时的判断被实测推翻，一并更正在代码注释里。\n\n一、replay 转发到 @juhai/kernel，补上 cursor-unknown\n\n本仓的 replay.ts 是框架 0.1.0 时代的拷贝，导出名与框架一致但实现落后一代，缺\n`maxSeq` 与策略「游标超前于现存最大 seq ⇒ 报缺口」。旧实现下，客户端报一个本租户\n从未产生过的游标（伪造 / 串号 / DB 被重置）会命中 pendingCount === 0 而返回 none——\n「已追平」与「真的没有新事件」在数值上无从区分，客户端**永远停在一个不存在的进度上、\n再也收不到补发**，与本仓「绝不静默缺口」的判据直接冲突。\n\n实证（打转发后的实现）：\n  since=999999, maxSeq=42 → {\"kind\":\"gap\",\"reason\":\"cursor-unknown\"}\n  since=42,     maxSeq=42 → {\"kind\":\"none\"}     ← 真已追平，无误报\n\n框架同时修了契约文件内部的自相矛盾：pendingCount 旧注释写「且已投递」，与两后端刻意\n选定的账本语义相反（outbox 是「发生过什么」的账本，补发范围是全部留存行，重叠由客户端\n按信封 id 去重）——docs-truth 扫不到这类矛盾。\n\n两后端各改一处查询：findFirst(minSeq) → aggregate(_min/_max)，一次拿两个边界，\n比原先还少一次往返。\n\n二、WS 传输层单帧上限（REALTIME_WS_MAX_PAYLOAD_BYTES = 16 KiB）\n\n框架注释记了一次真实事故，而**本仓此前正处在那个状态**：只有应用层的\nREALTIME_MAX_COMMAND_BYTES = 4096，没有接线传输层，而 ws 的默认 maxPayload 是 100MiB\n——任意客户端反复发 100MiB 帧即可制造内存压力，而「防撑爆」的守卫在内存被完整缓冲\n之后才生效。本批同时接线两后端并取同值（G17）：\n  Fastify  app.register(websocket, { options: { maxPayload: … } })\n  NestJS   @WebSocketGateway({ path: \"/ws\", maxPayload: … })\n传输层 16384 比应用层 4096 留一档余量，使「超协议约束」与「超传输上限」成为两种可区分\n的失败：4096~16384 的帧仍拿到语义清晰的 connection.error(too-large)，真正的巨帧在协议层\n即被 close 1009 掐断。**只加常量不接线正是该注释批评的形态**，故两者同批落地。\n\n三、两处开工判断被实测推翻，已更正在注释里\n\n1) 「订阅列表无上限」不成立：本仓原本就有 .max(50) / .max(200)，只是写成字面量，\n   值与框架一致。本批只是把魔法数字收敛成具名单源，不是补安全缺口。\n2) subscription 不是单纯落后，而是**互有领先**：框架有那两个上限，本仓有\n   `envelope.resourceRefs` 这条「新事件唯一扩展协议」（禁止为产品主键继续追加字段名猜测，\n   否则行业对象会反向污染内核），框架那份仍是「取第一个以 Id 结尾的键」的启发式。\n   整份转发会删掉本仓这个设计，故**不转发**——按迁移手册 §6 走分歧账本，只取上限、\n   保留本仓实现。这是三个模块里唯一的合并式采纳。\n\n@repo/contracts 1.19.0 → 1.20.0。注意 P7 **没有要求**这次升版：根与 kernel 两个 barrel 的\nexport 行都没变，而 apiDigest 只哈希入口 .d.ts。但公开面实际多了 3 个符号，按语义应升——\n真正记录这次面变化的是 K1 锁（replay.ts 的 4 个导出转移给内核包、另两处各 +1/+2，\n40 模块 / 755 导出）。\n\n验证：contracts 312/312 · typecheck 13/13 · 静态整轮 28/28 · runtime 733 / 行为矩阵 204/204 /\n零违规（16 KiB 上限未挡住任何测试，aggregate 在 RLS enforce 下行为与 findFirst 一致）。\nruntime 报告在本提交后重跑回绑。\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-18T08:03:00-07:00"}],"HeadCommit":{"Sha1":"74c732d8d4b88957365dd80770032bab706e84e2","Message":"chore(reports): B3′ 的四十一份三级证据 回绑 @ df72512，刷新快照锚点\n\n本批次最后一个提交，按 C241 同时刷新快照锚点到 df72512（声明落后 0，本提交自身使实测\n落后 1，在 +1 自指窗内）。\n\n四十一份 reports/*.latest.json 全部 clean 绑定（gitSha=df72512、worktreeDirty:false）：\n静态 28 + 运行态 13。静态整轮 **28/28 步骤全部通过**（退出码 0），运行态 733 tests /\n行为矩阵 204/204 / 87 项指标零违规。\n\n本批改的是两后端的 WS 传输层与 replay 查询，两个预设风险点均未兑现：\n- 16 KiB 传输层上限**未挡住任何测试**——正常控制帧远在其下，上限值选得合适\n- outbox 查询由 findFirst 改为 aggregate(_min/_max) 后，在 RLS enforce 下行为与原先一致\n\nruntime 跑了两轮，**数字完全一致**（733 / 204-204 / 零违规），无非确定性；第一轮因改动\n尚未提交而 worktreeDirty:true，按仓规矩只绑定本地、不能作阶段门证据，故提交实现后重跑。\n这是顺序问题不是结果问题——记下来是为了下次先提交再跑，省一轮 20 分钟。\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-18T08:15:17-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/4da2c656ae691428be3f177563952cba66c37b88...74c732d8d4b88957365dd80770032bab706e84e2","Len":2}

TEXT

created_unix

INTEGER

Update row 31155 in action