记录分支保护现状：不把 Project CI 配成合并必需检查

复核后确认本仓库不把 Project CI 的 context 配成 master 分支保护的合并必需检查，合并前由人工
确认最近一次结果。据此把文档里"必须设为合并必需检查 / 需补 6 个新 context"的强制口径改成
与现状一致，避免下次有人照着一个不执行的待办去逐个勾选 context：

- 开发运维文档：说明当前不配 required context（代价是门禁红了不会自动阻止合并），把 11 个
  context 清单降级为"将来若要启用时的清单"，并保留"不能残留已不再上报的旧 job 名，否则 PR
  会永远停在等待该检查"这一条；master 交付口径里"当前 head 的七个 required context 全绿"
  改为"最近一次 Project CI 全绿"。
- shared-memory/decision-log：AGC 壳分片那条的"影响范围"不再把它列为待补 context 的待办。
- shared-memory/pitfalls：置顶条目新增"分支保护口径"，并把旧条目里"要补齐两个新 AGC
  context"改成"确认没有残留旧 job 名"。
- .craft 的 gitea-ci-triage 技能同步为"改 job 集合或 job 名不需要同步分支保护"。

验证：prettier、check:encoding、check:doc-index 通过。

Co-authored-by: DotCraft <273930855+dotcraft-ai@users.noreply.github.com>

docs/project-memory/shared-memory/pitfalls.md

@@ -8,6 +8,7 @@
 - **反面实验（run 2102，勿重做）**：起先把 4 片放进**同一个 job** 内的 4 个进程并行，结果门禁步骤跑满 18 分钟仍未结束，比整套串行的 507 秒还慢——同一容器内这几片共享 `HOME`、target 目录与固定临时路径，会互相拖慢。因此 `--shard-index` 是 CI 的唯一入口；不带 `--shard-index` 的「单命令内多片并行」只留给本地全量自测。
 - **易错点**：① 分片规则必须自校验「片并集等于 `--list` 全集且互斥」，否则改分片方式会静默漏跑门禁；② 每片要拿独立 `TMPDIR`，`tempfile::tempdir()` 默认落在它下面（测试里的硬编码 `/tmp/...` 多是「必须拒绝」的负向断言，不是真实读写）；③ 不要给分片 job 装 `npm ci`——AGC 壳 Rust 门禁与 `agent-run` smoke 只用 cargo 与 node 内建模块，那些 `npm ci` 正是达标 7 分钟的主要障碍；④ 片 job 只需预热 AGC 壳自己的 manifest（其 `Cargo.lock` 的 path 依赖已覆盖 `platform-llm` / `platform-agent` / `agent-runtime-core` / `shared-contracts`），`server-rs` 那份预热属于 crate 级 job；⑤ 分片后 `--test-threads=1` 不再出现在 workflow 里，但它是分片运行器的片内参数，别再往 workflow 里补整套串行命令。
 - **不要做的事**：不要退回「整套 `--test-threads=1`」（507 秒长尾回来了），不要放开成整套并行（同进程内后台锁与异步终态会再互相干扰），也不要在单个 job 内多进程并行多个片（实测比串行还慢）。
+- **分支保护口径**（2026-09-14 复核）：本仓库不把 Project CI 的 context 配成 `master` 分支保护的合并必需检查，合并前由人工确认最近一次结果；因此 job 拆分或改名不需要同步分支保护设置，代价是门禁红了不会自动阻止合并。
 - **关联**：`apps/ai-game-creator-shell/scripts/run-rust-shell-test-shards.mjs`、`.gitea/workflows/project-ci.yml`、`scripts/check-native-shells.mjs`（`agc-rust-shard-1..4` / `agc-rust-smoke` / `agc-rust-crates` 分组）、`package.json`。
 
 ## 2026-09-14 根门禁的 `[check:native-shells] <label>` 是别处按字面量校验的契约
@@ -23,7 +24,7 @@
 - **现象**：把 `Native shell tests` 拆成客户端三个 job 后，如果只跑 `npm run check:native-shells:release`，静态契约和壳运行时门禁都不会执行；如果只跑 `--groups=contract`，`desktop-release-binary-artifact` 又会因为缺少 `build/native/desktop/` 产物而失败。
 - **原因**：分组是执行范围，不是"额外检查"。`desktop-release-binary-artifact` 断言依赖同 job 内的 `desktop-shell-stage-release-binary` 步骤，所以它归 `release` 组，不能放进 `contract`；反过来，任何"只跑一组"的命令都不能被当成完整门禁。
 - **处理**：分组与 job 的对应关系固定为 `contract`+`shells`+`release` → `Native shell tests`，`agc-web` → `AI game creator shell web tests`，`agc-rust-shard-1..4` → `AI game creator shell Rust shard 1/4 .. 4/4`，`agc-rust-smoke` → `AI game creator shell Rust smoke`，`agc-rust-crates` → `AI game creator shell Rust crates`；`scripts/project-ci-workflow.test.ts` 校验"每个分组恰好被一个 job 调用一次"和"CI 不再调用全量 `npm run check:native-shells`"，新增分组必须同步门禁脚本、根脚本与 workflow 三处。
-- **易错点**：① 拆 job 后 Gitea `master` 分支保护的 required context 要补齐两个新 AGC context，只改 workflow 不改分支保护会让新门禁在合并前不生效；② 每个 job 只预热自己会构建的 Cargo 依赖，`agent-run:smoke` 因为会 spawn `cargo` 必须留在 `agc-rust` 所在 job；③ 本地全量 `npm run check:native-shells` 仍会串行跑完所有分组，用它作为本地完整门禁，不要用单组脚本冒充。
+- **易错点**：① 拆 job / 改 job 名后要确认分支保护里没有残留已不再上报的旧 job 名（本仓库现在不配 required context，只需人工确认 CI 结果，见置顶条目的「分支保护口径」）；② 每个 job 只预热自己会构建的 Cargo 依赖，`agent-run:smoke` 因为会 spawn `cargo` 必须与 AGC 壳的依赖预热同 job；③ 本地全量 `npm run check:native-shells` 仍会串行跑完所有分组，用它作为本地完整门禁，不要用单组脚本冒充。
 - **关联**：`.gitea/workflows/project-ci.yml`、`scripts/check-native-shells.mjs`、`scripts/project-ci-workflow.test.ts`、`.gitea` 分支保护设置。
 
 ## 2026-09-14 `check:native-shells` 的调用链扫描在 Windows 上恒假