动机（Why）

目标项目方向 F1 连续 4 个 PR（#4~#7） 换来的 CNB 坑点——已由 PR-E 落到 skills/cicd-pipeline/SKILL.md 作为"使用指引层"——进一步升级为 docs/workshop-share.md §四 的第 9 种治理模式 M9，让这条经验对外可分享。

关闭目标项目 CHECKPOINT §五 的 T-Q3-03 待办。

分层定位（关键——本 PR 不是"搬家"是"升维"）：

前者讲"怎么用"，后者讲"为什么要这样用"——同一知识在不同层有不同价值，关键是各有受众。

变更清单（What）

2 个 commits · 2 文件 / +148/-3 行

• commit 1 docs(share) fff4a7b：workshop-share.md M9 新增（1 文件 / +70/-2）
• commit 2 docs(meta) 27252f4：CHECKPOINT §四 轮次 15-b 档案（1 文件 / +78/-1）

改动 1：§一 TL;DR 表扩展 8 行 → 9 行

  | **M8** | 机制化 + 机器化克制 | SOP 要定触发条件，但别一上来就加时限阻塞 | #38 |
+ | **M9** | CI 平台坑点实证清单 | 文档不一定对；把本项目踩过的坑原样交给下一个项目 | 目标项目 #4~#7 + 源仓库 PR-E |

同步更新：

• 宣称的 PR 累计 15 PR → 23 PR（反映 Q2 + Q3 真实状态）
• 反直觉认识新增一条：M9 的生存价值

改动 2：§四 "八种模式" → "九种模式" + M9 完整子节（约 55 行）

起因：4 PR 演化实证表

4 条核心发现（官方文档未说明）：

1. services:[docker] 强制忽略 image: 字段
2. services:[docker] 不注入 CLI 也不设 DOCKER_HOST
3. Stage 耗时是识别"静默跳过"的关键信号
4. default-build-env 实际内容：Java ✅ / Maven ✅ / Docker CLI ❌

"把坑点作为资产"的对比表：

4 条关键约束（派生自 M2 + M4）：

• 【必须】每条坑点配实证锚点（env 输出 / PR SN / stage 耗时）
• 【必须】与 CHECKPOINT 某轮次直接关联
• 【推荐】每次新 CI 平台接入都开独立子节（GitHub Actions / GitLab CI / 云厂商 CI）
• 【推荐】坑点失效时标注"历史坑点（修复于 ）"，保留认知传承不删除

3 条反模式：

• ❌ "我们换脚本绕过了但没记录 bug"
• ❌ "那是平台方的问题不是我们的问题"
• ❌ 写在 commit message 里（git log 不是知识库）

与 M8 的关系：

M8 说"不急着机器化强制"——M9 说"经验一定要机制化存档"。两者不矛盾：

• M8 针对机制本身的强制度克制
• M9 针对已验证的知识必须收编

合成一句话：对已发生的坑要收编（M9），对未验证的假说才克制（M8）——按证据强度采取不同机制化力度。

改动 3：CHECKPOINT §四 轮次 15-b 档案（新增 78 行）

• 分层定位对比表（使用指引层 vs 治理模式层）
• 规则自举第 6 次实证表（3 阻 + 3 放）
• §七 指标变化子表
• 4 条本轮学到的东西
• T-Q3-03 闭环标记

验证证据（How verified）

本地 9/9 CI stages 全绿 + 0 lint

规则自举第 6 次实证——连续 3 次放行：

6 次 = 3 阻塞 + 3 放行——连续 3 次放行合规修改。本次放行原因值得注意：docs/ 天然在 scope（rules/ + governance/）之外，守门员根本不扫描。这不是"守门员识别能力"，而是 scope 划分本身的健康度——健康的 scope 让"输出向"（docs/）和"约束向"（rules/ / governance/）天然隔离。

关键指标变化

影响面（Impact）

"使用指引层" vs "治理模式层"的分层设计（新发现）

本 PR 不是简单"搬家"——同一坑点同时存在于 skills/ 和 docs/，但受众和粒度不同：

• skills/cicd-pipeline/SKILL.md CNB 坑点 = 具体知识，给本项目 scaffold 使用者
• docs/workshop-share.md §M9 CI 平台坑点实证清单 = 元知识，给其他团队 Leader

这种分层设计应成为未来 workshop-share 扩展的通用范式——每种治理模式可能都有两层对应（实例层 + 模式层）。

workshop-share 作为活文档

之前 PR #39 尾声是 Q2 周期的总结，宣称"15 PR 8 种模式"。本 PR 首次让 workshop-share 跨周期扩展（Q2 收尾 + Q3 新 M9），证明它是"活的知识载体"——Q3 周期继续产生新模式（如 T-Q3-06 候选），workshop-share 应持续扩展。

scope 健康度首次被显式指认

抽象化守门员 scope = rules/ + governance/，天然不扫 docs/ 和 skills/。这曾是隐性设计决策，本 PR 档案里首次显式指认为治理成果——健康 scope 让"输出向"与"约束向"天然隔离，让 docs/workshop-share.md 这种对外分享内容可以自由写日期/案例/具体项目名，不被守门员误伤。

关闭的待办

• ✅ T-Q3-03：对外分享新模式"CI 平台坑点实证清单"（→ 实际成为 M9）

不动的事

• T-Q3-04 前端 E2E（业务向，规模大）
• T-Q3-05 观察（被动，无需主动做）
• T-Q3-06 元向（"家族化演化"作为第 16 种模式——留待新家族成员出现后再做，避免过度工程）

本 PR 与 PR-F 的互补

两者合成 Q3 周期开始的完整图景——向内升级规则 + 向外分享知识。

Refs

• 父事件：目标项目 anta-newproject-demo PR #4~#7 四 PR 演化链
• 关联：
  • 源仓库 PR-E（#44）—— skills/cicd-pipeline/SKILL.md 坑点条目（使用指引层）
  • CHECKPOINT §四 轮次 15-b（跨层升级档案）
  • docs/workshop-share.md §四 M9（本 PR 产出）
  • meta-principles.md §原则 4（抽象化——把具体坑点升级为模式是抽象层级跃迁）
  • meta-principles.md §原则 5（契约——M9 作为跨团队契约）
• 下游：
  • T-Q3-06：workshop-share 第 16 种模式"反模式的家族化演化"（待新家族成员）
  • 未来 CI 平台接入（GitHub Actions / 云厂商）时按 M9 范式新开独立子节