为一个论题设计的六个 Plan（以及更名为 Charter 的那天）
纸面上六个 Plan，实际跑了五个 —— Sentinel 在 4 月 25 日至 28 日之间的第一次系统性实验。正是这一轮把一个手工的模式变成了 Charter，即框架中有边界的工作单元。
1. 一个说明了很多事情的脚注
在 2026 年 4 月 30 日撰写的 charter-telemetry.md 提案中，文档顶部有一条术语说明：
"本文档所称'Charter'，在 Sentinel 实验中（PLAN-01..06）称为'Plan'。以下引用的实证数据沿用这些历史 Plan 的原始名称；架构形态和前瞻性示例则使用新的正式名称'Charter'。"
这是一条技术性脚注，平实无华。但它精确记录了制品更名的那个瞬间——更有意思的是，它记录了一项存档决策，本博客同样遵守这一决策：当时被称为 Plan 的，在原始记录中依然叫 Plan。向后改写名称，会伪造溯源记录。
这篇文章涉及五天内发生的两件事：框架的首次系统性实验——Sentinel 的六个 Plan，在 4 月 25 日至 28 日之间执行——以及紧随其后、在 4 月 30 日发生的更名。这并非两件独立的事，一件导致了另一件。
2. 纸面六个 Plan，实际五个
本次实验设计了六个 Plan（PLAN-01 至 PLAN-06），实际执行了五个。PLAN-04 从未运行：它停留在一份包含七项延期功能的目录清单状态，罗列了我们想做但测试周期无法覆盖的事项。如实说明这一点是应有的诚实，因为验证该论题的文档（thesis-validation.md）在其汇总表中公开记录了这一情况：
| Plan | 规模 | 内容 | 格式 |
|---|---|---|---|
| PLAN-01 | XS | 治理文档部署 | v1 |
| PLAN-02 | S | 管理端点（gcp-resource） | v1 |
| PLAN-03 | XS | 合约版本升级 | v1 |
| PLAN-05 | M | 按服务配置异常阈值 | v2 |
| PLAN-06 | XS | 手动重算基准线 | v3 |
| (PLAN-04 目录) | — | 7 项延期功能的路线图，未执行 | — |
五个 Plan，四种不同规模：三个 XS、一个 S、一个 M。领域刻意选取异构——运维部署、两个管理端点、合约升级、带配置逻辑的后端功能。这不是合成基准测试，而是 Sentinel 在 4 月 25 日至 28 日之间的真实代码，被划分为有边界的工作单元，以三个模型（Copilot、Gemini、Claude）作为外部审计方，逐一审计。
第六个 Plan 未能执行，这件事有两层意义。显而易见的一层是：实验超出了时间预算。更耐人寻味的是：PLAN-04 是这批 Plan 中唯一规模较大的——七个累积功能，没有自然边界。偏偏这个 Plan 没能跑完，已经在暗示这种格式能承载的规模上限。小型 Plan 可以；路线图式的 Plan 不行。这个经验后来被正式确立，无需任何人专门写明：StrayMark 的 Charter 今天是*"有边界的工作单元，耗时数小时到数天，对应一个分支"*，而非季度路线图。
3. 实验在自身迭代中演进
五个已执行的 Plan 产生了三种不同的格式。这不是随意为之，而是因为每个周期都暴露了上一个格式未能捕捉到的内容。
-
v1 —— 前三个 Plan（
01、02、03）沿用原始格式执行。在审计 AILOG 中识别出五个反复出现的模式，但没有一个被正式化为模板。它们以习惯的形式存在，而非合约。 -
v2 —— 针对 PLAN-05，将这五个模式固化进
TEMPLATE.md，并在 README 中添加了"格式约定"章节。仅限文档层面：尚无可执行的内容。假设是：如果格式明确，外部审计方的判断会更趋于一致。AILOG-020 直言不讳："内部沿用已久但无名可循的模式，对外部审计方而言是不可见的。正式命名，能把实践变成公开的信号。" -
v3 —— 针对 PLAN-06，新增了一个模式（自动清单漂移检测），并且这次引入了可执行工具：
scripts/check-plan-drift.sh，约 145 行 bash 脚本，用于验证实际交付内容是否与 Plan 中的声明相符。格式第一次从纯文本转变为带有验证器的形态。
我想指出的是这条曲线的形态。v1 捕捉了潜在实践，v2 为其命名，v3 编写了检查它的程序。这正是任何有效标准化的完整弧线——只不过压缩进了五个 Plan，而非五年。
这也是某个事物最早的具体证据——两个月后，它会在 CHARTER-CHAIN-EVOLUTION.md 中被明确命名为模式 1（pre-declare refresh）和模式 2（amend-on-emergence）。在那里作为元模式被正式确立的内容，最初在 4 月，只是一个无名的习惯。
4. 最有力的证据：外部审计方的收敛
论题中最关键的假设是："结构化记录能减少失效模式，当外部审计方介入时，这种减少是可观测的。" 验证方式：将每个 Plan 的产出——修改的文件、AILOG、TEMPLATE 下的 Plan 文档——提交给三位未参与开发的审计方（Copilot、Gemini，以及 Claude 的批判性分析），比较汇总评分。
thesis-validation.md 报告的 PLAN-05 数据（第一个使用 v2 格式的 Plan，也是唯一一个 M 规模的 Plan）十分清晰：
"5 个周期中最佳的综合审计方校准度（Copilot 9.25，Gemini 9.5）。累积假设已验证：TEMPLATE v2 + 丰富的 AILOG 减少了外部审计的歧义面。"
两个异构模型，不同的指令，在这批 Plan 中规模最大的 Plan 上收敛于 9.3/10——不是最小的那个。这是信号，不是噪声。在 v3 的 check-plan-drift.sh 运行时，这一结果得到了复现：
"PLAN-05（含已知漂移）：脚本报告 3 个遗漏文件：
evaluator_test.go（F4）、repository.go（F1/R6）、statuscenter/service.go（F5）—— 正好是 Copilot+Gemini 在审计中捕获的 3 处漂移。零误报。"
自动化脚本与两位外部审计方在哪些 Plan 文件未完成这件事上完全一致。这不是在论证脚本有多智能——它不过是 bash 加 grep，再简单不过。这是在论证 Plan 格式一旦正式化，就能让任何检查方（人类、智能体、脚本）看到相同的内容。结构化规范不需要智能就能被审计：它需要的是清晰。
5. 实验未能证明的事
这一节是我最希望留存在记录中的，因为它考验博客是否愿意诚实。
thesis-validation.md 的明确设计目标是打破该论题，而非捍卫它。文档第一行写道：
"本文档将用数据检验这一论题。它不是为了捍卫它，而是试图打破它。目标是：一位不认同该论题的读者，只需阅读本文，就能判断现有证据是支持、修正还是反驳它。"
将论题的六个假设与证据对照后，最终结论如下：
| # | 假设 | 结论 |
|---|---|---|
| 1 | Vibe coding 无法规模化 | 部分验证*（无对照组）* |
| 2 | 结构化记录减少失效模式 | 已验证 |
| 3 | 合规性作为无额外工作的副产品 | 已验证*（待真实人工审计方测试）* |
| 4 | 审批很少是非此即彼的 | 无证据——待多参与方项目验证 |
| 5 | Stage 比 commit 更适合作为可追溯单元 | 已验证 |
| 6 | 就地签署优于事后重建 | 部分验证*（未测试加密签署）* |
三个假设完全验证，两个部分验证，一个无证据，零个被反驳。关于非二元审批的假设未经测试，因为 Sentinel 是单一所有者项目；要得出结论，需要一个有多位签署方的真实团队。加密签署——Sigstore、哈希链、仅追加日志的技术保证——未经演练，因为没有 Plan 涉及流程的那个部分。这在文档中作为明确的空白保留，而非含糊其辞的断言。
实验未能证明的事，比它证明了的更重要。如果我们发布六个绿灯，而非五个诚实的结论，这个博客就成了营销材料。避免这种情况的方式，是直言不讳：这里有我们没有证据的假设，单一操作者项目无法生成这些证据。其他人会生成；框架将随着这些数据的积累而成熟。
6. 为什么 Plan 变成了 Charter
4 月 30 日的更名不是营销行为。原因字面上写在 WHAT-IS-A-CHARTER.md 中：
"GitHub SpecKit 已经用'plan'这个词（
/speckit.plan、plan.md）指代另一种制品，这一名称冲突在同时使用两套流程的采用者文档中造成了摩擦。"
SpecKit 已经有了 plan.md，StrayMark 也有。在同时使用两者的采用者文档中，相邻段落里的 plan 指代着不同的东西。更名是为了消除这一冲突。
但在这个务实动机背后，有一个值得点明的细节。这两种制品确实不同，且区别是结构性的：
SpecKit plan.md | StrayMark Charter | |
|---|---|---|
| 粒度 | 完整功能（数周，多个用户故事） | 有边界的工作单元（数小时到数天，一个分支） |
| 主要内容 | 技术栈、依赖、项目结构、constitution 检查门 | 待修改的具体文件、验证命令、R<N> 风险 |
| 验证方式 | Constitution Check（事前门控） | 漂移检查 + 外部审计（事后门控） |
| 优化目标 | 前置清晰度 | 事后可追溯性 |
SpecKit 所称的 plan 更像是带有架构骨架的 ADR。StrayMark 所称的 Charter 更像是带有合约验证和审计锚点的任务卡片。它们是互补制品，而非竞争关系；SPECKIT-CHARTER-BRIDGE.md 在 5 月对此做了明确说明。但在讨论互补性之前，名称冲突必须先得到解决。
我认为值得重点强调的是这一伴随决策：Sentinel 的历史记录——AILOG、遥测数据、check-plan-drift.sh、sentinel/docs/plans/ 文件夹——保留了 Plan 这个名称。WHAT-IS-A-CHARTER.md 本身这样论述：
"Sentinel 的历史记录（Plan 01–06、
sentinel/docs/plans/、sentinel/scripts/check-plan-drift.sh、AILOG 与 YAML 遥测数据PLAN-NN.telemetry.yaml）保留原始名称——它们是特定时刻的实证记录，改写历史会伪造这份记录。"
改写历史会伪造记录。 对我而言，这句话才是这次更名的真正核心。框架存在的目的是保存溯源记录，而非改写它。当制品更名时，变化是前瞻性的：从 4 月 30 日起，新创建的是 Charter。旧的、实验期间的那些，仍然是 Plan。这种不一致是刻意为之的，而这种不一致本身就是证据。
4 月 30 日更名的另一个伴侣——遥测提案——在同一天出现，事后看来原因显而易见：如果这个涌现出来的模式值得一个新名称，它也值得结构化的度量。charter-telemetry.schema.v0.json 架构，包含投入时间、检测到的漂移、规模、领域等字段，是今天用于机器化度量的工具，而 Sentinel 在 4 月时还在用手写 YAML 进行度量。Plan 被更名为 Charter 的同一天，我们决定开始计数 Charter。
7. 结语
从这个过程中，我提炼出四点：
-
实验的设计目标是打破，而非确认。 "它不是为了捍卫，而是试图打破" —— 这字面上就是验证论题的文档的职责定义。任何值得尊重的技术博客都必须能承受这种框架。
-
六个设计中的 Plan，四天内执行了五个。 那个未能执行的（规模最大，包含七个功能的路线图）偶然间成为了工作单元能承载多大规模的第一条证据。今天的 Charter 是通过合约约定有边界的；在 4 月，边界是偶然形成的。
-
格式在实验内部自我演进：从习惯，到模板，到脚本。 五个 Plan 产生了三个版本的格式。v1 → v2 → v3 的曲线，是任何有效标准化的曲线——只是被压缩了。
-
更名源于务实，而非营销。历史保存源于原则。 Plan 在 Sentinel 中依然叫 Plan，因为当时它就叫那个名字。Charter 从 4 月 30 日起开始使用。框架不改写自己的存档——这正是它值得追溯的原因。
下一篇将介绍两个相近的里程碑，它们将全新的能力定性地编码为正式规范——Charter 作为一等实体（PR #65，fw-4.4.0）和外部多模型审计周期（audit-skills-design、audit-cli-flow，发布版本 fw-4.7 → fw-4.9）。那就是 Sentinel 实验成为 CLI 功能的地方。
参考锚点：提案 thesis-validation.md 与 charter-telemetry.md（均为 2026-04-30）。Charter 的规范定义：WHAT-IS-A-CHARTER.md。运行时架构：dist/.straymark/schemas/charter-telemetry.schema.v0.json。
本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。