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":"3c100f855828a6b046679818aafce7f1bbf3bfb8","Message":"feat(deps): pin client-fact 1.0.0-rc.3 and drop the STALE boundary translation\n\n平台已修 U-29（enterprise-platform main 036a308）：applyOne 在 version \u003c= watermark 时\n返回 \"STALE\" 并清掉该事实留在 gap 缓冲里的副本，不再抛 FactRejected 被 handle 计入\nattempts——此前至少一次投递下的正常迟到重投三次即被打进死信，与\"内容有毒\"共用一套判据。\n\n该修复随 1.0.0-rc.3 发布（同一本地旁路通道，见基础设施仓 G-12），本仓两后端 pin 到\nrc.3 后删除 ingest 里的「错误码 → 结果词」边界翻译：判定完全回到 SDK，本仓只留事务、\n可信回查与 apply。FactRejected 的 import 保留——回查逻辑仍在用。\n\n验证：typecheck 13/13；两后端 employment 真实 DB 验收各 9/9 在无翻译的情况下通过\n（含\"落后版本 STALE：投影停在较新的版本，不回滚\"这条）；check:platform-provenance 仍绿。\n\n边界不变：rc.3 与 rc.2 一样没有任何 CI 阶段门证据，可宣称\"依赖来源合规\"，\n不得宣称\"经过发布门禁验证\"。\n\nscripts/ 与 reports/ 的并发改动不在本提交内（另有会话在本仓工作）。\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-13T23:00:25-07:00"},{"Sha1":"6fc1ecc41ab5e4e1283e84efa1a4964111293ec5","Message":"feat(employment): 接通 Kafka 投递通道并按平台 fact-read 契约回查\n\nG25① 投递通道：此前只有受权限保护的 HTTP 投递入口，生产形态（平台 fact 模块按 source_domain\n中继到 broker）无人消费。现两后端各加一个消费者，挂在 dispatcher 进程（C56：API 进程不跑后台交接）：\n- PLATFORM_FACT_BROKERS 未配置就**不启动**，不造空转的假消费者；\n- autoCommit:false，ingest 成功才提交位点，抛错不提交交给 broker 重投（SDK 幂等表保证无副作用）；\n- 同一 topic 承载该域全部事实类型，形状不匹配即\"不是我们的消息\"：跳过并提交，否则别人的消息\n  会永远卡住本消费组的分区头。\n信任判断仍全在 FactInbox：消费者只搬运，落库前一样要过 M5 权威回查。\n\nG25② 回查契约：路径与状态码改为平台候选契约 fact-read-api.v1\n（GET {base}/v1/facts/accepted/{factId}，Bearer JWT），错误码 FACT_EXPORT_* → FACT_READ_*；\n**只有 404 是\"不存在\"**，其余状态一律当依赖故障抛错——返回 null 会让 SDK 判 UNTRUSTED 并计毒消息，\n把平台的一次 502 变成消费者的死信。平台实现仍只在基础设施仓分支 codex/ms3-fact-read-http，\n未合入 main；合入后本仓应改用 SDK 的 createFactReader 并删掉本地 fetch。\n\n证据（本地，工作树 dirty）：\n- 真实 Redpanda（127.0.0.1:59092）两后端各 3 例：落投影 / 异类型跳过不挡后续 / 重投单次效果；\n- 改名后 HTTP 验收两后端各 9/9 复跑；lint 5/5、typecheck 13/13；\n- 内核边界 142/142 受管面、242/242 文件锁（消费者归 Enterprise Fact Consumer pack）；\n- 根 pnpm check 仍止于 docs-truth 的 governance-number-evidence-shape——它要求 passed 的\n  runtime-acceptance，而整轮 check:runtime 在本机环境卡在 db-credential-separation\n  （已在**未带本改动的 HEAD** 上复现同一失败，属环境问题，非本轮回归）。\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-13T22:24:55-07:00"}],"HeadCommit":{"Sha1":"3c100f855828a6b046679818aafce7f1bbf3bfb8","Message":"feat(deps): pin client-fact 1.0.0-rc.3 and drop the STALE boundary translation\n\n平台已修 U-29（enterprise-platform main 036a308）：applyOne 在 version \u003c= watermark 时\n返回 \"STALE\" 并清掉该事实留在 gap 缓冲里的副本，不再抛 FactRejected 被 handle 计入\nattempts——此前至少一次投递下的正常迟到重投三次即被打进死信，与\"内容有毒\"共用一套判据。\n\n该修复随 1.0.0-rc.3 发布（同一本地旁路通道，见基础设施仓 G-12），本仓两后端 pin 到\nrc.3 后删除 ingest 里的「错误码 → 结果词」边界翻译：判定完全回到 SDK，本仓只留事务、\n可信回查与 apply。FactRejected 的 import 保留——回查逻辑仍在用。\n\n验证：typecheck 13/13；两后端 employment 真实 DB 验收各 9/9 在无翻译的情况下通过\n（含\"落后版本 STALE：投影停在较新的版本，不回滚\"这条）；check:platform-provenance 仍绿。\n\n边界不变：rc.3 与 rc.2 一样没有任何 CI 阶段门证据，可宣称\"依赖来源合规\"，\n不得宣称\"经过发布门禁验证\"。\n\nscripts/ 与 reports/ 的并发改动不在本提交内（另有会话在本仓工作）。\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-13T23:00:25-07:00"},"CompareURL":"luoanwu/digital-employee-os/compare/454681c0f8e6137d1c37b6b843b0694ffc4ef966...3c100f855828a6b046679818aafce7f1bbf3bfb8","Len":2}

TEXT

created_unix

INTEGER

Update row 29480 in action