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":"5b7a1c033ef290f7fa48f58bf0eae5eaa38150aa","Message":"docs(框架): FR-6 提交框架 Owner——在送达入口 README 登记待受理\n\nFR-6 的正文 2026-09-18 已写入 基础设施仓框架变更请求-2026-09-12.md（48c5a9c），\n但那份文档本身不是送达入口：框架 Owner 是从 工程基础框架/README.md 的变更请求\n条目看待办的（FR-1 / FR-4 / FR-5 与另两份平台治理的请求都是这么送达并受理的）。\n此前只写了正文没更新入口，等于没提。\n\nREADME 该条更新为：FR-1 已落地 0.19.0、FR-4 / FR-5 已落地 0.20.0、**FR-6 新提\n待受理**、FR-2 / FR-3 仍未受理，并就地摘出 FR-6 的请求与依据：\n\ncheck:docs-truth 的四级证据新鲜度须按「该级别是否已接线」判定。起因是基础设施仓\n同步到 0.22.0 时实测，新增的制品部署 / 生产运维两级依赖 apps/api-nestjs/Dockerfile，\n而那份里有 COPY packages/kernel/package.json——该仓按 DEC-010 / DEC-031 只 exact\npin 已发布的 @juhai/kernel，仓内不存在 packages/kernel，构建必然失败，这道门禁\n在该仓只能恒红。恒红门禁不携带信息，正是 0.22.0 自己要治的失效模式的反面。\n\n请求对应 pnpm 脚本存在则断言照旧、不存在则 SKIPPED，不接受占位报告；接线了却让\n报告陈旧的仓仍照旧判红。影响面是框架仓单点改动加一条负向用例。基础设施仓已本地\n修正并在改动处注释指向 FR-6，受理后删除该段回到框架原文。\n\n未触碰框架仓 base-framework（其工作区有 12 项他人在途改动）。\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-17T23:57:57-07:00"}],"HeadCommit":{"Sha1":"5b7a1c033ef290f7fa48f58bf0eae5eaa38150aa","Message":"docs(框架): FR-6 提交框架 Owner——在送达入口 README 登记待受理\n\nFR-6 的正文 2026-09-18 已写入 基础设施仓框架变更请求-2026-09-12.md（48c5a9c），\n但那份文档本身不是送达入口：框架 Owner 是从 工程基础框架/README.md 的变更请求\n条目看待办的（FR-1 / FR-4 / FR-5 与另两份平台治理的请求都是这么送达并受理的）。\n此前只写了正文没更新入口，等于没提。\n\nREADME 该条更新为：FR-1 已落地 0.19.0、FR-4 / FR-5 已落地 0.20.0、**FR-6 新提\n待受理**、FR-2 / FR-3 仍未受理，并就地摘出 FR-6 的请求与依据：\n\ncheck:docs-truth 的四级证据新鲜度须按「该级别是否已接线」判定。起因是基础设施仓\n同步到 0.22.0 时实测，新增的制品部署 / 生产运维两级依赖 apps/api-nestjs/Dockerfile，\n而那份里有 COPY packages/kernel/package.json——该仓按 DEC-010 / DEC-031 只 exact\npin 已发布的 @juhai/kernel，仓内不存在 packages/kernel，构建必然失败，这道门禁\n在该仓只能恒红。恒红门禁不携带信息，正是 0.22.0 自己要治的失效模式的反面。\n\n请求对应 pnpm 脚本存在则断言照旧、不存在则 SKIPPED，不接受占位报告；接线了却让\n报告陈旧的仓仍照旧判红。影响面是框架仓单点改动加一条负向用例。基础设施仓已本地\n修正并在改动处注释指向 FR-6，受理后删除该段回到框架原文。\n\n未触碰框架仓 base-framework（其工作区有 12 项他人在途改动）。\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-17T23:57:57-07:00"},"CompareURL":"luoanwu/platform-governance/compare/e393d2db524e2c16a517866d412b1d039c01640a...5b7a1c033ef290f7fa48f58bf0eae5eaa38150aa","Len":1}

TEXT

created_unix

INTEGER

Update row 30853 in action