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":"9a8b716a056597786b9fcbc8fd57bff6c5b44722","Message":"docs(回灌): 订正 U-40——「gitSha 为空」不成立，字段叫 sourceSha 且有值，落点随之改向\n\nU-40 原文称 registry 上的 @juhai/client-fact@1.0.0-rc.3 其 provenance.json 为 gitSha:\"\" 空字符串，\n据此把落点定为「平台侧必须带真实 gitSha，本地旁路发布也不得留空」。一手实测推翻该前提：\n\n在真源仓 npm 作用域下 npm pack 拉取架上 tarball 读其 provenance.json，client-fact 与 contracts 的\nrc.3 两份一字不差，且都带 \"sourceSha\": \"036a308f27acf35a46f068c96fea7723ef74d05e\"。\n字段名是 sourceSha 不是 gitSha，且有真实值——提交号一直在包里。照原落点做，平台会去补一个已经存在的字段。\n\n本条结论仍成立、病因换了：不是「平台没写」，是两侧键名对不上，且基座判据根本没读产物的\nprovenance.json——复核 数字员工OS/digital-employee-os/scripts/check-platform-dependency-provenance.mjs，\n其中 gitSha / sourceSha 的命中全部属于它自己报告的 provenance，没有一处读依赖产物。\n\n落点改为两条：① 平台侧把 sourceSha 这个字段名写进对外契约（发布物 schema / 接入套件文档），\n使消费者不必靠猜；旁路车另缺 tag（tag:null，与 CL-5「一次发布 = 一个 tag = 一组同版本包」不符），该项仍欠。\n② 基座侧把判据从「解析来源」扩到「内容出处」，只需读包内 sourceSha 与期望提交比对，不必等平台改任何东西。\n\n状态 🔴 → 🟡：不再与 U-39 同一阻塞，两侧都可立即动工，不受 G-12 计费阻塞；仅 tag:null 仍挂在旁路车上。\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-18T16:05:19-07:00"},{"Sha1":"63850ac3b7b1a51d74aac689837fdf7ed58905bb","Message":"docs(回灌): U-39 补 contracts 同版本不同内容的新实例——落差由一个提交扩大到一整轮硬化\n\n@juhai/contracts@1.0.0-rc.3 与 client-fact 同属 2026-09-13 那趟本地旁路车。实查架上包：其\nprovenance.json 自证 sourceSha=036a308，而仓内同版本源码已含 2026-09-18 九个契约包域\n（public-file / IM / 跨域流程 / 通知 / 数据分析 / 成本容量 / 统一体验 / 注册中心 / 配置与功能开关）\n的失败关闭硬化。消费者 exact pin 1.0.0-rc.3 拿到的是硬化前代码；./domain/* 是公开子路径导出，\n失败一侧行为已变。U-39 的「同版本不同内容」因此不是 client-fact 一例。\n\n不另开 U 号：本实例由基础设施自查发现、没有上层对接方，不符合本台账 §0「只有业务应用的开发轮次\n触发回灌」的驱动方口径，故并入 U-39 状态格，不新设真源。\n\n证据取自一手产物：在仓内 npm 作用域下 npm pack 拉取架上 tarball，读其 provenance.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-18T16:03:44-07:00"},{"Sha1":"fad563310502477427181b6cbe2b48af4aebb668","Message":"docs(计划): 登记四份过期证据回绑与一次撤回 @ 772b253\n\nrelease-manifest / sbom / naming / fork-readiness 四份在干净检出内重跑回绑，结论逐项\n对照无劣化；sbom 的 ref 更新后它描述的才是当前登记的镜像。check:evidence 由\n36 新鲜 / 5 过期 变为 40 新鲜 / 1 过期 / 0 error，仅剩 image-smoke（须 Secret 到位后\n由 CI 插一步冒烟，带复核期 2026-10-31）。\n\n另记一次撤回：module-imports 那次回绑是多余的——并行会话提交门禁改动时已连报告一起\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-18T15:47:52-07:00"},{"Sha1":"80eced637aa8796ffec9c266cde6d6567e4fdb49","Message":"docs(计划): 登记注册中心就绪闸门补判与干净检出回绑 @ 94366bc / de532d4\n\n并更正上一行登记：注册中心 9ac9914 已被 7f82399 的合并整体放弃，上一行现在只对\n统一体验 caefbf6 成立。远端那版的摘要归一化比本地那版的「一律拒」更好，本轮采纳\n其口径；只补它仍缺的四条就绪闸门真值判定，并把零覆盖的 snapshot-upgrade-review.ts\n接进夹具门禁。\n\n回绑改走 #34-A 立的干净检出路径：主工作区 4 小时没出现干净树。附带记下一条坑——\n检出必须落在工作区内，否则 workspaceRelative 套件会以 unavailable 让门禁 exit 1。\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-18T12:26:45-07:00"},{"Sha1":"1d2416ab6482cf2ad8f2e4c311c62545daebfd16","Message":"docs(计划): 登记统一体验与注册中心两个契约包入参硬化 @ caefbf6 / 9ac9914\n\n两域各有一条同形缺陷（闸门用真值判断，\"false\" 一律放行——统一体验是 G3 本身与\n权限 / Scope 判定，注册中心是四条就绪闸门）与各自的崩溃面；注册中心另有 blockedBy\n传字符串时 .length 是字符数、摘要正则带 i 导致同一制品两个身份两处。修的都是同一\n文件里正确写法本来就在的那种。顺带补两块零门禁覆盖：统一体验持闸的两个公开函数、\n注册中心整份 393 行的升级复核。九个契约包域至此全部补强，套件合计 188 例 0 失败。\n\n另回写一条技术教训：独立索引提交后必须 git reset -- \u003c路径\u003e 把共享索引刷回 HEAD，\n否则并行会话下一次从索引提交会把已提交的改动带回去（2026-09-18 已实际发生一次）。\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-18T07:53:53-07:00"}],"HeadCommit":{"Sha1":"9a8b716a056597786b9fcbc8fd57bff6c5b44722","Message":"docs(回灌): 订正 U-40——「gitSha 为空」不成立，字段叫 sourceSha 且有值，落点随之改向\n\nU-40 原文称 registry 上的 @juhai/client-fact@1.0.0-rc.3 其 provenance.json 为 gitSha:\"\" 空字符串，\n据此把落点定为「平台侧必须带真实 gitSha，本地旁路发布也不得留空」。一手实测推翻该前提：\n\n在真源仓 npm 作用域下 npm pack 拉取架上 tarball 读其 provenance.json，client-fact 与 contracts 的\nrc.3 两份一字不差，且都带 \"sourceSha\": \"036a308f27acf35a46f068c96fea7723ef74d05e\"。\n字段名是 sourceSha 不是 gitSha，且有真实值——提交号一直在包里。照原落点做，平台会去补一个已经存在的字段。\n\n本条结论仍成立、病因换了：不是「平台没写」，是两侧键名对不上，且基座判据根本没读产物的\nprovenance.json——复核 数字员工OS/digital-employee-os/scripts/check-platform-dependency-provenance.mjs，\n其中 gitSha / sourceSha 的命中全部属于它自己报告的 provenance，没有一处读依赖产物。\n\n落点改为两条：① 平台侧把 sourceSha 这个字段名写进对外契约（发布物 schema / 接入套件文档），\n使消费者不必靠猜；旁路车另缺 tag（tag:null，与 CL-5「一次发布 = 一个 tag = 一组同版本包」不符），该项仍欠。\n② 基座侧把判据从「解析来源」扩到「内容出处」，只需读包内 sourceSha 与期望提交比对，不必等平台改任何东西。\n\n状态 🔴 → 🟡：不再与 U-39 同一阻塞，两侧都可立即动工，不受 G-12 计费阻塞；仅 tag:null 仍挂在旁路车上。\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-18T16:05:19-07:00"},"CompareURL":"luoanwu/platform-governance/compare/a7075e40e9aed8fbe69edb7fb7f0ebc05e477214...9a8b716a056597786b9fcbc8fd57bff6c5b44722","Len":6}

TEXT

created_unix

INTEGER

Update row 31174 in action