同步主线CI门禁修复

合入最新主线Repository checks修复

保持完美像素损坏结果对账变更

docs/project-memory/shared-memory/decision-log.md

@@ -1,5 +1,12 @@
 # 决策记录
 
+## 2026-08-12 Repository checks 采用 CI 与本地共用的单一门禁入口
+
+- 背景：master run 1037 的 Backend/Frontend 已通过，但 `Repository checks` 因 3 个 `simple-import-sort/imports` 错误失败。原 pre-commit 只运行 Prettier，Prettier 不处理 ESLint import 排序；推送前又未运行完整仓库 lint，因此本地与 CI 的覆盖范围长期存在漂移。
+- 决策：`npm run check:repository-ci` 成为 Repository checks 唯一仓库入口，统一执行 lint、生产构建、内容检查和基线到候选提交的空白差异检查；Gitea workflow 与 master pre-push 只调用该入口。pre-push 必须验证待推 master SHA 是当前 `HEAD` 且已跟踪工作树干净，无法确认候选内容时失败关闭；feature 分支不运行该重门禁。
+- 提交门禁：lint-staged 对 staged JS/TS 先运行按 ESLint 配置过滤 ignored 文件的 autofix wrapper，再运行 Prettier。回归测试覆盖 import 排序、部分暂存恢复、ignored 文件、feature push 跳过、master push 参数绑定，以及 workflow/hook 共用入口。
+- 权威边界：本地 hook 可被 `--no-verify` 绕过，不能从制度上保证 master 永远不红。服务端根治要求禁止日常直接 push master，统一走 PR，并要求当前 head 的 Repository/Frontend/Backend/Native 四项检查全部成功后合并；紧急白名单只能最小化保留。
+
 ## 2026-08-12 Agent 失败原因使用稳定分类贯穿 Runtime 与正式展示面
 
 - 背景：Codex app-server 的 failed turn 已携带 `turn.error.codexErrorInfo`，但适配器曾丢弃该字段并写固定失败句；Runtime、事件 `publicText`、最近任务、game-chat 阶段记录和多个 Agent 卡片又各自用固定文案覆盖已有安全原因。自主构建 final-reply 已形成确定性完成文案时还对任意错误 fallback 成成功，导致鉴权、额度、上下文、策略、sandbox、配置或网络失败可能被伪装为完成。

docs/project-memory/shared-memory/development-workflow.md

@@ -611,13 +611,15 @@ npm run check:server-rs-ddd
 - 页面交互 smoke
 - 移动端视口检查
 
-### 提交前 TypeScript 自动格式化
+### 提交与 master 推送前自动门禁
 
-仓库级 Git `pre-commit` hook 通过 `lint-staged`，只对当前已暂存的 `*.ts`、`*.tsx` 文件运行 Prettier 自动格式化，并把格式化结果更新到本次提交的暂存区；未暂存的其他文件不进入格式化范围。格式化或暂存恢复失败时提交会中止，应先处理失败原因并重新检查 staged diff，不能等 CI 再暴露格式问题。
+仓库级 Git `pre-commit` hook 通过 `lint-staged`，只对当前已暂存的 `*.js`、`*.mjs`、`*.cjs`、`*.ts`、`*.tsx` 文件依次运行 ESLint autofix 和 Prettier，并把修复结果更新到本次提交的暂存区；ESLint wrapper 会按仓库配置过滤 ignored 文件，避免 ignored warning 与 `--max-warnings 0` 组合造成误阻塞。未暂存的其他文件不进入处理范围，修复或暂存恢复失败时提交会中止，应先处理失败原因并重新检查 staged diff，不能等 CI 再暴露 import 排序或格式问题。
 
-部分暂存同一 TS / TSX 文件时，`lint-staged` 会临时隐藏该文件未暂存的改动，以暂存快照执行格式化，随后恢复未暂存内容。因此提交前后都应分别检查 `git diff --cached` 和 `git diff`，确认格式化后的暂存内容属于本次提交，未暂存工作没有被误带入；若恢复产生冲突，先人工整理暂存边界再重新提交。
+部分暂存同一 JS / TS 文件时，`lint-staged` 会临时隐藏该文件未暂存的改动，以暂存快照执行修复和格式化，随后恢复未暂存内容。因此提交前后都应分别检查 `git diff --cached` 和 `git diff`，确认修复后的暂存内容属于本次提交，未暂存工作没有被误带入；若恢复产生冲突，先人工整理暂存边界再重新提交。
 
-`git commit --no-verify` 会绕过该 hook，只允许在已明确原因的紧急场景使用。绕过时仍须对本次暂存的 TS / TSX 文件手动执行等价的 Prettier 格式化、重新暂存并核对 staged diff；`--no-verify` 不代表可以跳过格式化或其他提交门禁。
+`Repository checks` 的唯一仓库入口是 `npm run check:repository-ci`，依次运行 `npm run lint`、生产构建、内容检查和基线到候选提交的空白差异检查。Gitea `Repository checks` job 和本地 master `pre-push` 必须共同调用该入口，禁止各自复制或删减子命令；本地 hook 还会确认待推 master SHA 等于当前 `HEAD` 且已跟踪工作树干净，无法确认时失败关闭。普通 feature 分支 push 不运行这条重门禁，进入 master 前仍以 PR required checks 为权威。
+
+`git commit --no-verify` 和 `git push --no-verify` 都会绕过本地 hook，只允许在已明确原因的紧急场景使用；绕过不代表可以跳过等价门禁。真正阻止红提交进入 master 依赖 Gitea 分支保护：禁止日常直接 push，统一经 PR，并要求 `Repository checks`、`Frontend tests`、`Backend tests`、`Native shell tests` 四个当前 head context 全部成功后合并。本地 hook 只负责提前反馈，不能替代服务端分支保护。
 
 前端原则：