"polish Charter 尝试做的第一件事 —— 从 main 启动 ./sentinel 来执行 §5 的 smoke —— 以两个不同的 panic 失败了。"

5 月 22 日，Sentinel adopter 以 RFC 形式提交了 Issue #199，正是这样开头。当 thread 在五条评论更新后收尾时，计数已经从两个增长到十个。polish Charter —— Etapa 2 的关闭 Charter，原本被规划为一份 WCAG 审计与 quickstart 验证的清单 —— 用六个小时做了另外一件事：捕获了一类潜伏回归，而之前八个 Charter 的所有 per-Charter 测试套件都没能抓住它，也不可能抓住它，因为它们的写法决定了这一点。

这篇文章是对那个早晨为何发生的重建，对底层那个反复出现的形状是什么的追问，以及在 PR #200 中所做的深思熟虑的决定：为反模式命名，但暂时不为它打造工具。这个循环对追读过前几篇 —— 关于涌现观察与链条演化 —— 的读者来说很熟悉：这是两周内第三个沿着同一弧线结晶的模式：在 N=1 中浮现 → 为元模式命名 → 在 N=2 验证之前，推迟跨项目工具化。

真正分量重的两个案例​

在 polish 会话浮现的十个 gap 中，八个或者是环境依赖腐烂（huma 升级在 *string 参数上引入了 panic；Go 1.22 收紧了 http.ServeMux 的 wildcard 语义），或者是 runbook 漂移（§boot 中缺失的 env vars、混淆了互斥模式的 smoke 配方、关于 fake provider 标准输出的声明而 fake 实际上从未写过任何东西）。每个都值得修。没有哪个改写了规则手册。

真正改写了规则手册的那两个不一样。它们共享一个形状。

US3 Preference Center，5 月 12 日交付。 当 Sentinel 发送邮件的 recipients 点击 footer 中类似 unsubscribe 的链接时，他们落在一个 JWT-in-path 的 URL 上，形如 /preferences/<token>。handler 是有意公共-按-合约的：JWT 就是 auth；不期望 Authorization header。handler 的 doc-comment 这样写着。集成测试用 humatest 写成，通过测试 adapter 直接挂载 handler 并确认：给定 path 中一个合法的 JWT，handler 返回正确的 HTML。CI 通过。feature 被交付到 main。

从未发生的事：任何在那个 handler 前面执行生产 middleware 链的事情。internal/core/middleware/auth.go 有一个 publicPrefixes 列表，列出绕过 Authorization 检查的路由前缀。/preferences/ 不在这个列表里。整整十天，每个点击 unsubscribe 链接的 recipient 都从 middleware 那里收到一个 401 missing authorization header，请求甚至没有触达那个本来知道不该期望 Authorization 的 handler。Preference Center 在测试中可达，在生产中不可达。

发送 pipeline 的 OTel 可观测性 instruments，同一周交付。 八个 metric instruments —— counters、histograms、gauges —— 在 internal/core/metrics/commshub.go 中声明，在启动时与 OpenTelemetry meter 注册。Charter 的 Constitution Check §IV 正式宣布 FR-039..042 可观测性门已满足：API 层是正确的，注册都通过了，dashboards 已经规划好。这八个 instruments 中有七个在整个 commshub 模块中拥有零个 .Add() / .Record() 调用位置。声明了，注册了，从未被调用。ops 在这些 series 之上构建的 dashboards 已经收了十天的零数据。polish Charter 的手动 smoke —— 启动一个 OTel Collector，生成几个 sends，grep collector 输出查找 FR-039..042 名称 —— 立即浮现了这一点。

两个案例都不奇特。两个都不是硬 bug。两个都是同一个机械错误的实例：一个 artifact 在一处被声明，而本应连线它的实现住在另一处，并且代码库或 CI 里没有任何东西在关联两者。

反模式想要的那个名字​

当同一个形状出现得足够多以至于值得一个名字时，名字就重要起来。在 #199 的第三条评论更新时，Sentinel 作者已经数出了同一个底层错误的四个子类：

那个一句话的统一者 —— 新治理文档以此开篇的那一句 —— 是：

每个被声明的 surface artifact 都至少有一个可从真实 request 触达的连线位置。

这个反模式的名字 —— 它在 dist/.straymark/00-governance/POLISH-CHARTER-PATTERN.md 中作为典范落地 —— 是声明了表层但未连线（Surface declaration without wiring）。那才是交付物。polish Charter 是发现工具，不是论点本身。

为什么集成测试会系统性地漏掉这些​

这一节值得展开，因为它塑造了这篇文章其余部分的形状。四个子类共有的失败模式是：标准集成测试 harness —— Go 中的 humatest.NewTestAdapter、TypeScript、Python、Rust 中的对应物 —— 直接通过测试 API 挂载 handler。被测的 handler 由 fixture 正确连线了。生产组合的那一步 —— 路由注册在那里与 middleware 链相遇，与 env-var 清单相遇，与嵌入资源表相遇 —— 才是坏掉的那一步。CI 的绿灯对它声明的内容是诚实的：handler 在正确的 request 下返回正确的响应。它对以下事情什么也没说：request 在生产中是否能触达 handler，以及 handler 所依赖的 artifact 是否曾经被连线到 runtime。

把这件事读成对 humatest 的批评是诱人的。它不是。humatest（以及它的等价物）正在做它被设计来做的事：让你以隔离方式、快速地、不需要立起整棵组合树就测试 handler 逻辑。那种隔离是一个 feature。隔离的代价就是我们刚刚命名的那个 —— 而代价只在隔离之外的某些事浮现出分歧时才变得可见。polish Charter 是浮现那种分歧最便宜的方法，因为它做了没有任何 test fixture 在做的事：它启动真实的 binary，对它执行真实的、已记录的 operator 配方。

这是新 pattern doc 那项承重的主张。不是说 polish Charter 出于美容原因而有价值。而是说它是唯一让生产组合在外部可读的规范（operator runbook）面前被 end-to-end 执行的地方。如果你把 polish Charter 当作美容清理，你也就把那种浮现能力当作美容。Sentinel 的数据论证了相反的方向。

决定：B′，不是 B​

RFC 提出了三个选项。PR #200 中的决定是它们都不照原样采纳 —— 称之为 B′。值得说出原因，因为结构性的决定比表面看上去更重要。

RFC 的 Option B 要求一个 pattern doc 放在 docs/patterns/ 之下。那个目录今天在 StrayMark 中并不存在，创建它会分裂项目的文档约定。已经住在正典里的经验模式 —— FOLLOW-UPS-BACKLOG-PATTERN.md、CHARTER-CHAIN-EVOLUTION.md、EMERGENT-OBSERVATION-DESIGN.md、SPECKIT-CHARTER-BRIDGE.md —— 都住在 dist/.straymark/00-governance/。它们共享一个 i18n 镜像基础设施（每个治理 doc 都有英文、西班牙文、简体中文的兄弟版本）。增加第三个文档 surface 会成倍放大 i18n 开销，并把项目的模式撒在两个家之间。把新 doc 留在 00-governance/ 内部以零边际成本复用了既有基础设施。

RFC 的 Option C 要求一个 straymark charter polish-checklist 或 straymark analyze declared-vs-wired 的 CLI helper。Sentinel 作者已经原型化了一个（CHARTERs 25/26/27，三个预备性 CI 守卫），并愿意把它种到 upstream。这里的决定是保守的：推迟。不是因为原型没有价值 —— 它有 —— 而是因为 Sentinel 是 N=1。那四个子类是一个 adopter、一个 stack 所浮现的。framework 必须预先考虑才能交付一个有用的跨项目 CLI 的第五、第六、第七个子类，目前还不存在，因为没有第二个 adopter 把它们推上来。我们走过这条路。FOLLOW-UPS-BACKLOG-PATTERN.md 作为 v0 在 fw-4.10.0 中交付，并在那里住了一个半月，等待第二个 adopter 在它毕业为 straymark followups 子命令之前完成验证。同一道闸门在这里适用。新 doc 的 ## Open questions 明确说了：「结晶为 straymark analyze declared-vs-wired CLI 子命令 …… 闸门：N=2 adopters。」

B′ 是落地的版本。 一个新的治理 pattern doc 放在典范位置，以三种语言。Charter 模板里的第七个 Format conventions 项目符号，当作者关闭一个 Etapa 或 SpecKit Polish 阶段时把他们指向它。QUICK-REFERENCE ## Patterns 表格里的一行。一个 fw-4.18.0 版本号 bump，附带在三十几份文档间的页脚级联。没有 CLI 子命令。没有新的 frontmatter 字段。没有 schema 变更。反模式有了名字；发现仪式有了一份文档；工具化在等。

反复重演的弧线​

三周前，follow-ups backlog 模式沿同一弧线结晶：一个 adopter 浮现了一个需求，模式在 v0 被命名，CLI helper 被推迟。两周前，链条演化的两个模式结晶：Pattern 1（pre-declare SpecKit refresh）和 Pattern 2（post-close audit-driven Batch N.4），由同一个 Sentinel adopter 浮现，在 fw-4.16.0 中被命名，并以 straymark charter refresh-suggest 作为软 helper 而非硬闸门。一周前，元模式 —— EMERGENT-OBSERVATION-DESIGN.md —— 编码了让上述所有观察首先成为可能的东西：形式化的交叉引用加上文化上的许可。这周，这个模式。

这是一个月里的四次结晶，全都来自同一个 adopter，全都遵循同一个形状：在 N=1 中浮现 → 为元模式命名 → 只在 N=2 之后才工具化。当一个模式以鲜明的方式浮现 —— 六小时里十个生产 gap 就是鲜明的 —— 的诱惑是跳过命名，直接去做工具。纪律恰好相反。名字承担了大部分工作。工具化在到来时，是被至少两个 adopter 所浮现的内容参数化的；建造在 N=1 之上时，它是对一个 stack 与一个团队失败模式的外推，并倾向于把那些选择固化成不通用的 framework 默认值。

这一轮迭代里有一个真正新的、值得标出来的东西。新 pattern doc 命名了一个 Sentinel 作者已经承诺要发表的可证伪预测：下一个 Etapa 的 polish Charter，在刚刚在 Sentinel CHARTERs 25/26/27 中落地的三个预备性 CI 守卫的对照下执行，应该浮现大约少 80% 的 gap。如果那个预测成立，把 Option C 从「open question」升级为「CLI 子命令」就获得了定量支撑。如果它失败 —— 如果下一个 polish Charter 仍然浮现十个 gap 但落在没被预料到的第五个子类里 —— 失败本身就是下一个数据点，并会在打造工具之前重塑规范。任何一种结果都有用。两种都还没被观察到。我们在等。

关于刻意没有做的事的一则说明​

Charter frontmatter 里没有 phase: polish 字段。没有 straymark charter polish-checklist <ID>。没有自动化 analyzer 在扫描 Go（或任何其他语言）代码中已声明但未连线的符号。pattern doc 把上述每一项都列为候选演化，明确以 N=2 或 Etapa-3 之后的回顾为闸门。在 fw-4.18.0 中它们一个都不存在。

这是有意的，而且值得公开说出来，因为对一个鲜明发现的自然反应是过度建造响应。每一项推迟都是用短期完备性换长期可移植性。一个 frontmatter 字段把 framework 锁定到下一个 adopter 可能不共享的词汇上。一个 CLI helper 把 framework 锁定到一个映射某个具体 stack 失败模式的 runtime 上。一个 analyzer 把 framework 锁定到扫描一种语言，而它的约定可能与下一个 adopter 的截然不同。任何这样的承诺都不应基于一个领域的信号来做，无论信号多干净。pattern doc 本身可以被修订；一个 CLI 子命令不能在不破坏 adopters 的情况下被收回。

如果你读到这里，我会建议你看什么​

如果你运营一个有基于 mock-adapter 的集成测试的代码库 —— 大多数代码库都是 —— 你可以做一项有用的内部练习，完全不需要采纳 StrayMark 的任何东西。挑你的团队最近交付的、同时具有（a）docs 一侧声明（env vars、OpenAPI specs、嵌入式 HTML、metric instruments）与（b）住在另一份文件里的连线位置的最新 feature。在一个干净的 shell 里启动 binary。把 runbook 中面向 operator 的配方端到端跑一遍。如果第一次就跑通了，你的代码库还没有这个模式所捕获的潜伏债务 —— 或者它有但你这次走运。如果跑不通，数一下 gap。这个数字就是你需要的校准，用来判断 polish-Charter-作为债务检测的仪式在你的项目里是否值得它的开销。

如果你已经采纳了 StrayMark 并且正在关闭一个用 humatest 风格 adapter 测试 handler 的 Etapa，新 pattern doc 已经为你 scoped 好四个子类检查。把 polish Charter 预算为 L，不是 XS 或 S。预期会有 emergent 的 follow-on Charter，而不是残余清理 scope creep。在 scoped 工作之前去读 POLISH-CHARTER-PATTERN.md，而不是在之后。

而如果你是 Go 之外某个 stack —— TypeScript、Python、Rust、Elixir —— 上的 adopter，那四个子类是与语言无关的，但具体的检查形态不是。在你的 stack 里浮现一个第五或第六子类正是模式要从 v0 毕业所需要的第二-adopter 信号。从「在你的项目里一个有趣的观察」到「在 StrayMark 正典中被命名」的路径与 #199 走过的是同一条：开一个 issue。开它的成本很低；让模式处于欠验证状态的成本是真实的。

StrayMark fw-4.18.0 —— Issue #199 · PR #200 · tag fw-4.18.0。Sentinel 锚点：AIDEC-2026-05-22-001 · CHARTERs 25/26/27 PR。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

"嗨，我们处理过 Issue #153 了吗？"

对话就这样开始了，今天，5 月 16 日，在上午。一个简短的、几乎只是例行确认的问题，准备开始做其他事情之前顺口一问。答案是没有 —— Issue #153 是故意保持开放的，等待第二个领域来验证这个机制，然后再将其固化（StrayMark 第 12 条原则：在正式纳入规范之前，需经过第二个领域的验证）。但这个问题打开了另一扇门，在那次对话结束时，我已经将一个在框架中默默运转了几个月的设计属性正式编入了文档 —— 这一切，都是由两天前发生的一件事所引出的。

这篇文章是对那段弧线的重建，因为它值得留存。不是因为结果 —— 一个新的规范文档、一条第 8 原则、一个已合并的 PR —— 而是因为它所揭示的机制。StrayMark 背后有一个人的项目：确保在智能体辅助开发中，负责所产出软件的工程师不会失去掌控。这件事暴露了一个推动这一方向的具体设计属性。

关于创作的一点说明：StrayMark 首先在我自己的项目上接受测试。Sentinel 就是其中之一 —— 私有项目，但它与 StrayMark 的交互记录在 StrayMark 仓库的公开 Issue 中，因此上下文是可链接的。我是这个框架的作者，也是第一个使用者。第 12 条原则要求我在宣布任何新机制为规范之前，等待第二个领域的验证；但第一个领域就是我自己，这篇文章毫不掩饰地承认这一点。

事件经过：一个智能体标记了没人要求它标记的事​

两天前，5 月 14 日，在 Sentinel 中，一个智能体主动提出了一个我没有要求的观察。它正准备帮我填写 CHARTER-18 —— 这是一个已经很长的链条中的一项具体工作 —— 在写下任何一行代码之前，它说了大意如下的话：

(从西班牙语原文翻译) 有一个问题。specs/002-commshub/plan.md 在 4 月 21 日被冻结。此后经历了七个连续的 Charter，在该链条的 AILOG 记录中，有十二项实证经验尚未反映到 plan 中，这些经验在实质上影响了 US5 的范围。如果我们在阅读这份过时的 plan 之后填写 CHARTER-18，那么在下一个审计周期中，关闭前将会原子式地修复各种偏差 —— 由于过时前提的继承，出现至少一个严重或高优先级发现的概率大约为 50%。

它还引用了具体的 AILOG ID，以及具体的代码引用。

没有人要求这个分析。没有配置任何触发器。没有任何 CLI 命令的目的是产生这样的输出。这个智能体是来帮我处理下一个任务的，而不是来审计项目状态的。但在为下一个任务做准备的过程中，它发现了 StrayMark 文档明确关联的两个来源之间存在偏差，并选择在继续之前将其标记出来。

当天下午我提交了 Issue #150 作为 RFC，在下午 5 点到深夜之间，手动 spec 刷新规范被讨论并落地到 fw-4.14.3。第二天，5 月 15 日，我提出了 Issue #156，将这次演练所揭示的两个模式上游化：预声明 SpecKit 刷新 和 收尾后的 Batch N.4 修正。到 5 月 16 日 凌晨，它们已在 fw-4.16.0 中以 CHARTER-CHAIN-EVOLUTION.md 的形式被正式纳入规范，附带专项遥测和 CLI 辅助命令（straymark charter refresh-suggest）。行为得到了复现，模式得到了固化，循环就此闭合。

但当我在 16 日同一天上午坐下来，以 Issue #153 开启对话 —— "这个我们处理过了吗？" —— 继而反问自己另一个问题 —— "等等，究竟是什么让那个观察成为可能的？" —— 我意识到这个循环只完成了一半。fw-4.16.0 中编入的是模式的应用。尚待编入的，是产生该模式的机制。

用技术语言说出的一个人的问题​

我在与生成这篇文章的智能体的对话中是这样表述的：

(从西班牙语原文翻译) 那个智能体的行为让我有些惊讶 —— 它注意到了已积累的知识，如果不加以应用，将在 Charter 18 的实现中造成问题。也就是说，这既不是我要求它分析的任务，也不是某个提示词触发器被激活的结果，我认为这要归功于 StrayMark 的文档。我想更深入地了解这是如何发生的，我认为这是积极的，这样我们就可以利用这次经验，将其钩入 StrayMark 的习惯性行为 —— 这个从智能体及其与生成的文档的关系中涌现出来的模式非常有趣。

我问的不是要实现一个功能。而是要理解一个机制，以便复现它。这个区别很重要。当你要求实现某个东西时，路径是清晰的：spec → 任务 → 代码。当你要求理解为什么某件事奏效时，路径则更为罕见：你必须诊断一个运转中的系统，识别是哪些部分使其运转，并将偶然的与结构性的分开。

当你在构建与 AI 智能体协作的工具时，这类问题有一种特别的紧迫性。因为如果奏效的是偶然，下一个智能体 —— 或者同一个智能体的下一个版本 —— 可能无法复现它。如果奏效的是结构，那么它就可以被刻意地保留下来。对于一个旨在让工程师掌控 AI 辅助开发的项目而言，这两者之间的差异，就是运气与设计之间的差异。

审计：StrayMark 的哪些部分让这个观察成为可能？​

我让一个智能体系统性地梳理 StrayMark 的文档，带着三个具体问题：

1. 哪些文档机制明确地将各来源相互关联？（前置元数据、规范章节、稳定 ID、跨来源的 CLI 命令。）
2. 文档在哪里给了智能体明确的许可，以标记超出所要求任务范围的事情？
3. 除了引发本次案例的那对来源之外，还存在哪些来源对，如果基础设施就位，可能产生类似的涌现观察？

报告以结构化形式返回，每个发现都附有文件:行号。重要的不是个别细节（带有 originating_charter: 的前置元数据、§Risk: R<N> 章节、稳定 ID 约定、charter drift 等命令），而是将它们放在一起审视时所涌现的模式。两个属性始终共存：

属性一：强制的结构化交叉引用。 每种文档类型都有必填字段和规范章节，在文档自身的结构中声明它所指向的其他文档。当智能体阅读一份 AILOG 时，它不必猜测它属于哪个 Charter —— originating_charter: 会告诉它。当它看到一个风险时，它不是一段自由散文中的观察 —— 而是规范的、可计数的章节中的一个 R<N> 条目。当 spec 指向 Charter 时，是正式的；当 Charter 指向 AILOG 时，也一样。这是一个智能体无需创造性工作就可以三角定位的显式关联图。

属性二：文化层面的许可，不设阻断式门控。 AGENT-RULES §6 告诉智能体："保持主动 —— 识别潜在风险，在明显时提出改进建议，就技术债务发出警报"。PRINCIPLES §2 告诉它："不隐藏相关信息"。而关键的是，AGENT-RULES §3 赋予它无需操作员预先批准就可以创建文档（AILOG、AIDEC、TDE）的自主权。操作员保留的是优先级排序权，而非创建权。智能体不必请求许可才能标记某件事：标记它是规则的执行，而非价值判断。

有趣的是，这两个属性单独存在都无法产生该行为。如果你只有正式的关联（属性一）而没有文化许可，你会拥有一个可查询的语料库，但没有智能体敢主动查询它。如果你只有文化许可（属性二）而没有结构，你会得到模糊的标记 —— "我觉得某个地方可能有问题" —— 操作员无法据此行动。

两者结合，产生了值得拥有自己名字的东西：智能体将*"我应该说点什么吗？"外化为"有没有一个规范章节可以容纳这件事？"*。如果答案是肯定的，标记就不再是一个情绪化的决定，而成为机械式的执行。标记的成本降低了，因为目的地 —— 规范章节 —— 已经存在。

为何这超越了 StrayMark 本身​

我们正处于 AI 智能体写代码之快如思维流转的时代，如何不失去对过程的掌控的问题是真实且紧迫的。这不是一个末日论的问题 —— 这是一个操作层面、工艺层面的问题，由正在构建软件、需要交付的人们提出。这件事的速度本身就是证明：从智能体的诊断到被正式纳入规范的元模式，不到 72 小时。这种速度是一种收益，但也正是为什么可见性机制如此重要。

业界今天的主流回应，是更严格的提示词、更多上下文中的规则、CI 中更多门控的某种变体。这些方法是有效的，但有一个值得命名的特征：它们将智能体变得更像一个在可验证流水线中执行命令的工人。这解决了可靠性问题，但代价是牺牲涌现观察。一个只做被命令之事的智能体，无论其推理能力多强、提示词多长，都不会去标记没人要求它标记的事情。

Sentinel 事件所展示的是一种不同的、互补的回应：构建文档装置，使重要的偏差在结构上可见，并赋予智能体文化层面的许可，让它无需请求批准就可以标记这些偏差。 这将涌现观察保留为系统的一个属性，而非取决于智能体有多强或提示词有多长的运气。

这种立场中有一种近乎道家的意味：我们不告诉智能体要寻找什么；我们构建一个让需要被看见的事物可见的环境。"可见的结构 + 命名的许可"这对组合完成了工作。套用一些同事的话，智能体成为了活文档与代码状态之间的诚实中间人。

这正是 StrayMark 背后的人的项目所追求的，即使它很少被这样言说：让 AI 辅助开发令人眩晕的变化，不将我们推入一个工程师失去对所构建内容之可见性的世界。可见性不是通过更多的官僚控制来保留的；而是通过设计智能体所工作的环境来保留的，使重要的事情自然可见。工程师不会成为无尽 Pull Request 的审阅者 —— 而会成为智能体所带来的、已结构化且已命名的观察的优先级排序者。

我们做了什么​

诊断清晰后，问题是如何将其钩入 StrayMark 的习惯性行为，同时又不扼杀其涌现特质。这个张力是真实的：每当你将一个自发行为变成义务，你就将其变成了另一种东西。硬性规则可以是健壮的，但也可能在不合时宜的情境中触发时产生智能体的抵触或虚假信号。

决定是保守的：命名元模式，而非强制要求其使用。

具体而言，在 PR #160 中，以 fw-4.17.0 发布：

• 一个新的规范文档 —— EMERGENT-OBSERVATION-DESIGN.md —— 阐明了该设计属性及其两个组件，以 Sentinel 的实证案例为锚点，并构建了一个实例金字塔：元模式在顶端，其下是所有已正式纳入规范的应用（链条演进的模式 1 和模式 2；Charter 漂移；后续事项积压漂移；TDE 对比 R<N> 的升级；外部审计检查点）。之前看似各自独立的模式，被揭示为同一底层原则的应用。这个可视化本身就值得：当你看到七件看似不同的事情，突然认出它们有着共同的形状，框架就在没有新增任何东西的情况下获得了内在的一致性。

• 一条新的第 8 原则 —— 跨来源不一致性浮现（Cross-Source Dissonance Surfacing） —— 在 PRINCIPLES.md 中。这是用五行字凝练的文化规则。智能体在进入项目时读到它，并递归地应用它。

• 扩展了 AGENT-RULES.md §6 "保持主动"，加入了值得关注的具体偏差示例：过时的 spec、未升级为 TDE 的累积 R<N>、被实现所矛盾的 ADR、跨越积压模式阈值的后续事项、收尾后出现的审计发现。这些不是义务；而是一个主动的智能体会注意到什么的示例。这个区别对于保留涌现特质很重要。

• 识别了四个开放轴作为空缺 —— 交叉引用基础设施部分存在但模式尚未命名的地方：MCARD ↔ 已部署的模型代码，SBOM ↔ 锁定文件，有效 ADR ↔ 矛盾的实现，Constitution Check ↔ 框架版本升级。每一个在固化之前都需要 N=1 的实证验证 —— 第 12 条原则适用。它们已被记录在 Issue #161 中作为跟踪 RFC，等待第二个领域来推动其中之一。

• 明确的反模式：元模式是如何失效的。如果一个新的文档类型附带可选的前置元数据关联，交叉引用就会出现盲点。如果一个规范章节被自由散文取代，可查询性就会消失。如果在 AILOG/AIDEC/TDE 的创建中引入阻断式门控，文化许可就会破裂。如果遥测演进时没有保留 r_n_plus_one_emergent_count 等信号，反馈回路就会断裂。这些反模式是廉价但有效的保护，可防止意外侵蚀：任何未来的变更提案都可以与这份清单对照，以检测它是否在退化元模式。

从诊断到合并以及发布的 fw-4.17.0，全程发生在同一天的上午 9 点到凌晨 4 点之间。十五小时。这正是这个博客所承认的那种节奏：你必须学会在这个时钟下运作，否则掌控就会溜走。

我从这个过程中学到的​

当我从回答*"不，Issue #153 还是开放的"*开始，有三件事是我没有预料到会学到的：

第一，编入元模式与编入模式是不同的。 元模式不增加义务；它增加了词汇和对底层属性的可见性。那个属性已经在做它的工作；所缺少的是给它一个名字，以便在框架未来的演进中保护它。阅读 EMERGENT-OBSERVATION-DESIGN.md 的人不会学到什么新的做法 —— 他们会学会认出已经存在的东西。这才是让人能够刻意保留它的前提。

第二，如果过度规范化，涌现属性就会消失。 在对话中有那么一刻，我选择不将模式 1 变成硬性义务（"智能体在声明 Charter-(N+1) 之前必须运行 refresh-suggest"），而是保留它作为建议，加上对元模式的命名。如果你来自*"更多控制 = 更多可靠性"*的世界，这个决定是反直觉的，但对于这类属性而言，它是正确的选择。智能体的主动性是脆弱的：一旦它成为强制要求，它就不再是主动性了。能够扩展的是文化引擎（"保持主动"）加上结构化关联，而非具体义务的清单。

第三，我们为智能体构建的文档装置同时也在教育我们人类自己。 当我看到散布在各个治理文档中的七个模式，认出它们是同一元模式的实例时，我理解了一些我之前不曾理解的关于 StrayMark 的东西 —— 而 StrayMark 是我花了几个月构建的。框架正在向其自己的作者揭示东西。这个属性 —— 结构化文档在被审计时会产生关于自身的洞见 —— 是智能体在标记偏差时所做之事的一个内部变体。是同一机制，应用于不同的尺度。

背后的人的项目​

我是认真的，当我说 StrayMark 有一个人的项目。我不是因为痴迷于前置元数据字段而在构建一个文档治理框架。我是因为有一种直觉 —— 越来越不像是臆测 —— 软件工程的下五年将会是智能体所提供的速度与工程师需要保持的可见性之间持续谈判的五年。如果这场谈判向智能体一侧倾斜，我们会进入一个代码被编写而没有人知道为什么的世界。如果它向官僚控制倾斜，我们会失去证明这个实验合理性的生产力收益。

这个平衡不是理论性的。它是用具体的决定构建的：在哪里放一个前置元数据字段，哪个章节应该是规范的而非自由的，何时给予智能体自主权、何时保留优先级排序权。每一个决定都使平衡向一个方向或另一个方向倾斜。而知道平衡是否正确的唯一方法，就是测试它 —— 并在它奏效时命名奏效之物，以便它能在框架的下一次变更中存活下来。

两天前的 CHARTER-18 事件，是一次测试。它奏效了。我今天写下的，是给它一个名字。下一次测试已经有了候选者：MCARD、SBOM、有效 ADR 对比实现、Constitution Check ↔ 框架升级。四个轴，如果我们填补基础设施空缺，元模式可以在其上复现。我会等待第二个领域在实证上推动其中之一，然后再将其固化。第 12 条原则 —— 在固化之前需经过第二个领域的验证 —— 仍然是护栏。

如果你正在阅读这篇文章，并且你与智能体一起开发软件，我邀请你用这两个问题审视你自己的文档装置：哪些来源是正式关联的，具有智能体无需创造性工作就可以三角定位的显式关联？ 以及 当智能体检测到偏差时，对没被要求的事情进行标记，其成本有多高？ 如果第一个问题的答案是"很少"，第二个的答案是"很高"，你可能正将涌现观察留在桌上。这不是世界末日 —— 但这恰恰是一个处于人类掌控下的 AI 辅助开发过程，与一个逐渐溜走的过程之间的区别所在。

StrayMark fw-4.17.0 — Issue #150 · #156 · #161 · PR #160 · tag fw-4.17.0

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 二十七小时，为它们命名​

PR #152 关闭了第 9 篇的故事，于 5 月 14 日 21:39 UTC 合并。它带来了 fw-4.14.3 以及手动 refresh 的三个已正典化的关卡。

PR #157 —— 本篇要讲述的那个 —— 于 5 月 16 日 00:31 UTC 合并，整整二十七小时之后。它带来了 fw-4.16.0 / cli-3.14.0，以及两个具名的元模式：

• Pattern 1 —— pre-declare SpecKit refresh。在链中声明下一个 Charter 之前，先刷新 spec。
• Pattern 2 —— post-close audit-driven Batch N.4。当外部审计在关闭后发现问题时，修正一个已关闭的 Charter，而无需开启新的 Charter。

第 9 篇记录了手动应用于 CHARTER-18 的纪律。本篇记录之后发生的事：两个具名模式、为它们命名的正典文档（CHARTER-CHAIN-EVOLUTION.md）、度量它们的遥测 schema、两个用于搭建脚手架的 CLI helper —— 以及作为整个编辑弧线的收尾，七十七分钟后，一个哲学层面的元模式将两者向上重新吸收。

这是本弧线的最后一篇。第 1 篇从前方打开的博客，在此从后方合拢。

2. Pattern 1 —— 声明前 refresh​

正典文档中的字面定义：

"一个专用的 refresh PR 在 Charter-N 关闭与 Charter-(N+1) 声明之间落地。它只触及 SpecKit 制件的非锁定章节（plan.md、data-model.md、contracts、quickstart.md、research.md）。"

这正是 Sentinel 在第 9 篇中为 CHARTER-18 手动执行的操作。第 9 篇与第 10 篇的区别在于性质：第 9 篇记录流程；第 10 篇记录其条件激活 —— 框架在何时向采用者推荐应用 Pattern 1。

激活标准是可量化的，文档毫不含糊地列出：

• 该模块在同一 spec 上已有 ≥ 3 个已关闭的 Charter。
• 遥测中 agent_quality.r_n_plus_one_emergent_count 字段最近 3 个 Charter 的滚动均值大于 6。
• 自上一个 branch point 以来，没有 refresh PR 落地。

> 6 的阈值并非随意为之。它是 Sentinel CHARTER-18 转化为规则的结果：CHARTER-15、16、17 期间涌现发现（Charter 执行过程中发现的、原计划未声明的风险）的平均值，正是触发"spec 累积了过多技术债"这一感觉的临界点。框架不要求采用者凭直觉判断，而是给出一个遥测数据可以与之比较的数字。

Pattern 1 应用后产出：

• research.md 中一张分类表，将先前 Charter 中的发现归入四类：可复用模式、代码缺口、纪律模式、经验修正。
• 若分类揭示了权衡取舍，则给出明确的操作决策（D1、D2 等）。
• 在下一个 Charter 的 §Context 中，以 id 引用已整合条目。
• 在接收 refresh 的 Charter 的 charter-telemetry.yaml 中，一个可选的 pre_declare_refresh: 遥测块。

支撑该模式的度量指标直接引自 Sentinel CHARTER-18，在 CHARTER-CHAIN-EVOLUTION.md 中字面引用：

"Sentinel CHARTER-18 是一条 7-Charter 链中第一个无需中途补救 Charter 便干净关闭的 Charter。estimation_drift_factor: 1.0，pre_work.items_discovered_during_planning: 0，overall_satisfaction: 5/5。"

单一领域，N=1。文档毫不掩饰地说明了这一点：该模式在 Sentinel 中得到了经验验证。等第二个领域的数据到来，再将其晶化至更高层级。

3. Pattern 2 —— 涌现时修正​

字面定义：

"修正提交搭载与原始 Charter 相同的 execute 分支（该分支仍可合并至 main；修正提交叠加在其上）。"

其思路是：当一个已关闭的 Charter 收到关闭后外部审计发现的 critical 或 high 问题时，框架不强制开启新的 Charter。操作者可以在 execute 分支仍可合并至 main 的时间窗口内，修正已关闭的 Charter。

理由，同样字面引自文档：

"开启一个新 Charter 将为约 6 小时的集中工程工作带来数周的治理开销。"

这种不对称 —— 数周治理对比六小时工程 —— 正是 Pattern 2 所要解决的。为五个关闭后发现开启新 Charter 意味着：声明新上下文、重复外部审计、生成新 AILOG、从头注册遥测。而代码层面的修正只需一个下午。Pattern 2 的回答是：不必如此。

激活标准，同样可量化：

• Critical/High 发现在关闭后、外部审计后出现。
• 这些发现使 Charter 的关闭标准实质上未被满足。
• 修复涉及文件少于 25 个。
• 不需要重新打开架构层面的问题（原始 Charter 视为已定论的设计决策）。

四个标准全部成立，Pattern 2 适用。任一不符，则必须开启新 Charter。

应用后产出：

• 与原始 Charter 相同的 execute 分支上的一个修正提交。
• 一个新的 AILOG（不修改原始 AILOG），包含 risk_level: high、review_required: true，以及一个指向原始 AILOG 的 amends: 字段。
• 原始 AILOG 中的 ## Historical correction (YYYY-MM-DD) 章节，向前指向新的 AILOG。这是存档性的：原始 AILOG 不被改写，而是被链接。
• charter-telemetry.yaml 中的 post_close_amendment: 遥测块。

支撑 Pattern 2 的经验指标，字面引用：

"Sentinel CHARTER-18 于 2026-05-15 关闭，审计报告于 2026-05-15 至 05-17 到达。五个发现（4 个来自 gpt-5.3-codex，1 个来自 gemini-2.5-pro）均为代码层面的修复 —— DI 接线、重试头部解析、多租户过滤器、超时默认值。Batch 7.4 修正在一个内聚的提交中（19 个文件，+2257/-106 行）关闭了全部五个发现。"

一次提交，19 个文件，两个审计模型汇聚于相似发现，五项修复。若开启新 Charter：声明、外部审计、关闭之间至少两周。替代方案：同一分支上的一次修正，六小时。

4. 组合，而非排斥​

文档中最有趣的部分 —— 我认为也是最能收尾整个弧线的部分 —— 是关于两个模式如何关联的章节。字面引用：

"收到 Pattern 1 的 Charter 更可能规避 Pattern 2，因为 refresh 吸收了执行前的风险，否则这些风险会以关闭后发现的形式浮现。但 CHARTER-18 两者都需要 —— refresh 处理了 spec 层面的漂移；修正处理了 refresh 触及不到的运行时层面的漂移。"

它们不是竞争性的模式，而是同一原则在周期不同时刻的应用。Pattern 1 吸收 spec 层面的漂移 —— 原始计划已不再准确描述的内容。Pattern 2 吸收运行时层面的漂移 —— 只有代码运行起来、外部审计员以全新视角审视、问题从代码本身涌现后才会暴露的内容。

Sentinel CHARTER-18 两者都需要。刷新后的 spec 消除了后续审计周期原本需要原子性修复的涌现发现；后续修正吸收了 refresh 无法预见的内容 —— DI 接线、重试头部解析、多租户过滤器、超时默认值。这些是计划无从得知的事情，只有在代码存在之后才会涌现。

框架通过命名两个模式并明确声明其组合关系，做了一件我想着重指出的事：它将纪律不是线性的这一事实记录在案。不存在单一的检查点；在每个 Charter 之前有一个（Pattern 1），之后也有一个（Pattern 2），同一个 Charter 中两者都可能是必要的。链在演化；模式也在演化。

5. Schema 与 helper​

fw-4.16.0 在遥测 schema 中新增了两个可选的子对象，位于 charter-telemetry.schema.v0.json v0.2 中：

pre_declare_refresh:
  enabled: boolean
  refresh_pr: string | null
  refresh_aidec: string | null
  reusable_patterns_integrated: integer  # ≥ 0
  code_gaps_integrated: integer
  discipline_patterns_integrated: integer
  empirical_corrections_integrated: integer
  operator_decisions_ratified: integer

post_close_amendment:
  applied: boolean
  trigger: external_audit | production_incident | deferred_implementation
  ailog_id: string
  findings_closed: integer
  files_modified: integer
  effort_hours: number

整数计数器，而非叙述性文字。这是有意为之的设计：遥测 schema 所捕获的，是智能体或操作者可以机械计数的内容。无法计数的 —— 问题有多深、修复有多巧妙 —— 存在于 AILOG 中，而非遥测里。Schema 度量工作的形态；文档承载工作的内容。

cli-3.14.0 新增了两个 helper，均不是变更器：

• straymark charter refresh-suggest <module> [--threshold N] —— 只读。它读取该模块最近三个已关闭 Charter 的遥测，计算 r_n_plus_one_emergent_count 的滚动均值，并给出建议：refresh-now、not-needed 或 insufficient-data。始终以 Exit 0 退出。它是信息性的，永远不是 CI 门控。

• straymark charter amend <CHARTER-ID> --trigger <kind> --ailog-title <title> [--findings-closed N] [--merge-into <PATH>] —— 脚手架。它创建一个包含正确字段的 AILOG stub（risk_level: high、review_required: true、指向原始 AILOG 的 amends:），在原始 AILOG 中添加 ## Historical correction 章节，并渲染 post_close_amendment: YAML 块。不触及 git。

让两个 helper 保持谦逊 —— 一个只推荐，另一个只准备 —— 与第 4 篇的 A1 决策一脉相承："CLI 编排，但不调用 API"。在此：CLI 建议，但不决定；搭建脚手架，但不变更。人类仍然是纪律发生的节点。框架只是把工具放在触手可及之处。

6. 七十七分钟后​

在弧线收尾之前，还有一件值得记录的事。PR #157 于 5 月 16 日 00:31 UTC 合并。PR #160 —— 第 1 篇的那个，EMERGENT-OBSERVATION-DESIGN.md，fw-4.17.0 —— 于同日 01:48 UTC 合并。七十七分钟后。

这七十七分钟里发生的事，是弧线的倒置收尾。第 1 篇所命名的哲学元模式 —— 由正式链接加上允许标记的文化许可所构成的涌现观察 —— 恰好在本篇的两个操作性元模式之后一小时十七分钟晶化。哲学元模式不先于纪律存在；它在纪律之后出现。它是对同一证据的升序解读。

CHARTER-CHAIN-EVOLUTION.md 在其 §Related 章节中明确记录了这一点：

"EMERGENT-OBSERVATION-DESIGN.md —— Pattern 1 与 Pattern 2 作为其应用的元模式（正式交叉引用 + 允许浮现的文化许可）。"

Pattern 1 是正式链接（遥测中的 r_n_plus_one_emergent_count、§Context 中按 id 的引用、分类的 AILOG）与文化许可（智能体发现 spec 与代码之间的漂移时应当标记的规则）的组合。Pattern 2 是类似的组合（带 amends: 的 AILOG、向前链接的 Historical correction 章节）与允许标记关闭后发现而非静默吸收的许可。两个模式都是第 1 篇从上方命名的同一文化+结构原则的应用。

这是一个我持续喜欢的结尾：以"智能体看见了没人要求它看见的东西"开篇的博客，以在时间上更早的这一篇收尾，说的是："这里是智能体因为框架为它们命了名而能够看清的两件事"。

7. 合拢弧线​

十篇文章。十一个故事片段（H-01 至 H-13，其中若干合并成篇）。一个编辑决策 —— 追溯发布 —— 由第 2 篇引入，此后九篇严格遵守。一项贯穿始终的双语承诺。

写这个博客过程中学到的一些东西，值得在收尾前记录下来：

1. 模式诞生于纪律。 这句话在第 9 篇中已经出现，但整个弧线都在印证它。本篇的元模式不是被设计出来的，而是被提炼出来的。每个记录的里程碑都先有操作性的故事，后有名字。

2. 节奏并不均匀。 从第一次提交（第 2 篇，1 月 27 日）到第一个有外部审计的有界单元（第 3 篇，4 月 25 日）之间隔了十九天。从手动应用纪律到正典化纪律（第 9 篇，5 月 14 日）之间只有五小时。从两个元模式到它们的哲学解读（第 10 篇与第 1 篇，5 月 16 日）之间只有七十七分钟。项目经历了每一种速度，博客将它们全部记录在案。

3. 框架对其采用者并非中立。 Sentinel 使得每个模式在晶化之前都能得到经验验证。博客不掩盖这一出处；它将其作为方法论前提加以强调。

4. 未被命名的，就不会被看见。 第 5 篇将其表述为结构性可见性；第 7 篇将其应用于横向技术债；第 8 篇将其指向语言异常值。这是整个弧线中最持久的规律性。作为技术制件存在是不够的。名字激活制件。

博客要讲述的弧线 —— 里程碑 H-01 至 H-13、项目的四个名字、六个 Plan、一等公民 Charter、外部审计周期、Issue #113、更名为 StrayMark、TDE、审计提示异常值、手动纪律，以及两个元模式 —— 在此合拢。剩余的明确技术债：H-14，straymark explore TUI（在第 8 篇中作为可见性工具横向出现），以及 PLAN-INVESTIGACION.md §1.43-55 列出的待处理候选里程碑 H-?-A 至 H-?-E。可能的未来第二批次。不作承诺。

最后一个观察，与第 1 篇对称。那篇以"智能体看见了没人要求它看见的东西"开篇。博客在十篇之后收尾所记录的，是这句话的另一半：智能体之所以能看见，是因为框架让它具备了看见的条件。第 1 篇的涌现观察是证明；本篇的具名模式是前提条件。智能体在弧线覆盖的四个月里浮现的每一件事，都因为某个先前的故事片段在原本空无一物之处放置了一个制件、一个触发器、一个正式链接、一个可见的表面而成为可能。

博客讲完了这个故事。框架继续前行。

锚点：Issue #156。PR #157 —— fw-4.16.0 / cli-3.14.0（合并于 2026-05-16 00:31 UTC）。正典文档：CHARTER-CHAIN-EVOLUTION.md。Schema：dist/.straymark/schemas/charter-telemetry.schema.v0.json v0.2。后继元模式：EMERGENT-OBSERVATION-DESIGN.md，fw-4.17.0（合并于 2026-05-16 01:48 UTC，77 分钟后）。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

—— StrayMark 博客 H-01 → H-13 弧线终结。

1. 直觉与标准之间的四个月​

2026 年 5 月 15 日，UTC 时间 19:05，PR #155 以 fw-4.15.0 / cli-3.13.2 的形式合入框架。它带来的是一个新文件，加入了 CLI 注入的指令列表：AGENTS.md，位于采用者仓库的根目录，与已有的文件并列（CLAUDE.md、GEMINI.md、.github/copilot-instructions.md、.cursorrules、.cursor/rules/straymark.md）。

这本来可以是一件微不足道的事，但恰好在四个月前的 2026 年 1 月 27 日，项目的第一份 AIDEC —— 第 2 篇文章中以"年份笔误"为切入点讲述的那份 —— 曾宣示：

"AI 智能体（Claude、Gemini、Copilot、Cursor）能同等流畅地处理任何语言的指令，因此翻译它们的配置文件不会带来功能上的收益。"

这句话写于项目初始提交六小时后，包含着框架此后不断付诸实践的一个直觉：智能体是同一个技术受众。配置文件（CLAUDE.md 等）保持英文（而人类文档被翻译成三种语言），原因在于"AI 智能体"这一受众并不从翻译中获益。若要把这个直觉彻底落地，所缺的只是给它一个单一的指向——而无需为每个不同厂商各复制一遍文件。

本文正是围绕这件事展开：AGENTS.md —— 一个于 2025 年 12 月捐赠给 Agentic AI Foundation 的开放标准 —— 如何在四个月后完成了第一份 AIDEC 于 1 月所开启的那个决策。

2. AGENTS.md 所解决的碎片化问题​

2024 年至 2026 年间，随着 AI 智能体 CLI 的大量涌现，每家厂商都另起炉灶，发明了自己的指令文件格式：

• Anthropic 随第一版 Claude Code 发布了 CLAUDE.md。
• Google 为 Gemini CLI 采用了 GEMINI.md。
• GitHub 为 Copilot CLI 确立了 .github/copilot-instructions.md。
• Cursor 以 .cursorrules 起步，后来迁移到 .cursor/rules/*.md。
• OpenAI 的 Codex CLI 使用另一套路径；Aider、Devin、Continue、Roo Code、Factory Droids、Sourcegraph Amp、Zed AI、Windsurf、Amazon Q 各有各的方式。

一个同时使用两三个 CLI 的 StrayMark 采用者，不得不维护两三份内容相同的副本，靠手工同步，祈祷它们不要彼此偏离。在 fw-4.14.x 之前，框架的 straymark init 命令承认了这种碎片化现实：它向最常见的五个特定于厂商的文件注入内容。但其余十到十五个 CLI 则被排除在外，采用者只能靠手工复制内容来处理它们。

2025 年底，生产智能体 CLI 的开源项目社区做出了碎片化代价高昂时常见的选择：就标准达成一致。AGENTS.md 置于仓库根目录，所有人都读取它。将其捐赠给 Agentic AI Foundation（Linux Foundation，2025 年 12 月）赋予了它机构层面的治理。规范刻意保持极简：一个 Markdown 文件，不强制任何模式，位置可预测。每个 CLI 如何处理这个文件是其自己的事；那个核心问题——"这个仓库的智能体配置在哪里？"——现在有了唯一的答案。

到 2026 年 5 月，读取 AGENTS.md 的 CLI 列表包括（直接引用 PR #155 正文）：

"Claude Code、OpenAI Codex CLI、Cursor、Aider、Devin、Sourcegraph Amp、Google Jules、Zed AI、Continue、Roo Code、Factory Droids、GitHub Copilot、Gemini CLI、Windsurf、Amazon Q 及其他。"

十五个 CLI。其中一些出于历史兼容性仍然同时读取各自特定于厂商的文件。但全部十五个都知道优先查找 AGENTS.md。

3. 采纳，而不消灭自己的格式​

fw-4.15.0 最有趣的决策不是采纳 AGENTS.md；一旦标准达到临界质量，那是必然之举。有趣的是如何采纳。PR 正文毫无含糊地表述了这一点：

"与 CLAUDE.md / GEMINI.md 并列：标记块指向 STRAYMARK.md，其下附有最小可行正文，供无法跟随相对链接的读者使用。"

三个关键词：并列、标记块、最小可行正文。

并列意味着 AGENTS.md 不替换特定于厂商的文件，而是共存。框架仍然注入 CLAUDE.md、GEMINI.md、.cursorrules 等文件。理由很务实：某些 CLI（尤其是旧版 Cursor）要求将完整内容内嵌，而非通过相对链接指向。保留兄弟文件维持了这种兼容性，无需每个采用者为自己特定的 CLI 单独费心。

标记块是框架在其他特定于厂商的文件中已使用的惯例：一个 HTML 注释块，夹在 <!-- straymark:begin --> 与 <!-- straymark:end --> 之间，将 STRAYMARK.md 指向为真实来源。每次 straymark update-framework 只替换标记之间的内容。采用者在标记之外写入的内容——例如项目专属指令——保持完整。框架尊重采用者的文件；它只治理自己的那一节。

最小可行正文是对不跟随相对链接的 CLI 的妥协。标记块之下，AGENTS.md 携带一段简短正文，包含要素：智能体身份、审查要求、提交前检查清单、监管前置元数据片段、NIST AI 600-1 风险分类、可观测性规则、命名规范。对于无法读取 STRAYMARK.md 的智能体而言，这已足以正常运作；但它不足以替代规范文档。这种不对称是刻意为之的：我们希望智能体主动去打开 STRAYMARK.md。

CLI 的防御性细节（cli/src/commands/remove.rs:13）封堵了操作层面的漏洞：AGENTS.md 被加入了 LEGACY_DIRECTIVE_TARGETS。如果采用者丢失了 .straymark/dist-manifest.yml 并运行 straymark remove，旧版回退逻辑也会清理 AGENTS.md，而不是留下孤立文件。这是枯燥的日常维护，但正是这种差别决定了一个框架能否彻底卸载，还是留下残骸。

4. 没有 ADR​

有一个缺席值得点名。采纳 AGENTS.md 的决策没有获得自己的 ADR。

这与第 6 篇文章中 StrayMark 品牌重塑形成刻意对比——那次有公开的 ADR-2026-05-08-001，包含三个评估过的替代方案和列举的后果。它也与第 12 篇文章中 Phase 2 的情形不同，那次有一份包含架构论证的详尽 CHANGELOG 条目。fw-4.15.0 的文档论证只有 PR 正文——一篇好的正文，论点清晰，但不是 ADR。

为什么？操作层面的答案：这个决策被认为是附加性的，而非结构性的。采纳一个与现有格式共存的开放标准，并不改变框架的模型，只是扩展了它。没有哪个被否定的替代方案需要正式论证：不采纳 AGENTS.md 意味着出于审美偏好将十五个 CLI 排除在外，而没有人持有这个论点。

但这里有一个值得记录的教训。博客已经见过这种模式——Phase 2 关闭了一个经验闭环，品牌重塑改变了身份，第 10 篇文章的元模式命名了已然存在的东西——每次那个问题*"这值得写一份 ADR 吗？"*的答案都不同。框架似乎在不明言的情况下采纳了这样一条操作规则：当决策关闭了代价高昂的替代方案、并留下了那些未被选择之方案的记录时，ADR 才是必要的。fw-4.15.0 并未关闭代价高昂的替代方案——它只是增加了一个层次。所以 PR 已经足够。

我在这里将其记录在案，因为值得承认：并非每项变更都值得一份 ADR，也并非每个 PR 都是历史文献。存档纪律有其自身的标准。

5. 智能体可见性的两个层次​

fw-4.15.0 发布十天前的 5 月 9 日，Issue #113 被关闭——第 5 篇文章将这段插曲记录为*"对智能体不可见的 Charter"*。当时，操作者与一个能力出众、专注认真的智能体合作了六小时，规范的入门装置已全部加载，但智能体从未提议使用 Charter。那篇文章的结论：结构性可见性是框架的责任，而非智能体的属性。

fw-4.15.0 涵盖了同一问题的另一面。

第 5 篇文章关注的是内部结构可见性：如何确保已在读取我们仓库的智能体发现框架的核心概念。PR #122（第 5 篇）的答案是在 Charter 作为概念出现的内部表面上做乘法：STRAYMARK.md §15、CLAUDE.md/GEMINI.md 指令、/straymark-* 技能、status 输出、模板、通往 SpecKit 的桥接。九个内部表面。

本文关注的是外部结构可见性：如何确保任何进入仓库的智能体——无论其厂商——都能找到框架的装置。fw-4.15.0 的答案是采纳社区选定的规范接入点。一个外部表面，被十五个厂商读取。

两个层次共享同一概念轴——一个技术制品只有在表面命名它时才对智能体存在——但各有不同的作用域。内部可见性保证智能体在读取 STRAYMARK.md 时看到 Charter。外部可见性保证智能体进入仓库时看到 STRAYMARK.md，无论是哪个 CLI 在编排它。缺少任何一个层次都是不完整的。

6. 运行 update-framework 时采用者的操作​

发布的操作部分，直接引用 CHANGELOG：

"straymark update-framework 会带来新模板并在项目根目录注入 AGENTS.md。注入遵循与所有其他指令目标相同的规则：若文件不存在则创建，后续运行时替换标记块；若文件已存在但没有 StrayMark 标记则安全追加（这在 2026 年非常普遍——许多采用者已经手工维护着自己的 AGENTS.md）。"

三种重要行为：

1. 若文件不存在，CLI 使用规范模板创建它。
2. 若文件已存在且带有 StrayMark 标记，CLI 只替换标记之间的内容。
3. 若文件已存在但没有标记——2026 年非常普遍，因为许多采用者已经在手工编写自己的 AGENTS.md——CLI 会在文件末尾追加其标记，不触碰采用者已写入的内容。

这与博客在第 3 和第 6 篇中记录的存档尊重原则相同：框架治理它自己的那一节，而非整个文件。如果采用者想在其 AGENTS.md 中编写项目专属指令——内部政策、命名规范、特定代码库的专属指令——这些指令在每次 update 时都保持完整。StrayMark 块存在于它那个小小的标记边界之内，更新也在那个边界之内进行。

CHANGELOG 说明以一条值得记录的小操作警告作结："如果你的 .gitignore 排除了 AGENTS.md，请在运行 update-framework 之前调整，以确保注入内容能进入版本控制。" 这是对框架自身无法解决的边界情况的坦诚——采用者选择忽略该文件是其主权，而非错误。

7. 结语​

我从这个过程中提炼出四点：

1. 直觉与落地之间四个月的周期，正是把一个闭环做好所需要的时间。 1 月的 AIDEC 携带着直觉——"智能体是同一个受众"。fw-4.15.0 用一个开放标准将其关闭。两者之间，框架在特定于厂商的原型上持续迭代，直到通用替代方案出现。早期的直觉是对的；时间线是生态系统成熟所必需的。

2. 采纳开放标准不需要放弃自己的格式。 AGENTS.md 与 CLAUDE.md、GEMINI.md、.cursorrules 共存。这个决策不是"一个替换其他"，而是"当它有所贡献时，一个加入其他"。框架获得了外部可见性，同时保留了对需要特定格式的 CLI 的兼容性。

3. 并非每项变更都值得一份 ADR。 StrayMark 品牌重塑关闭了代价高昂的替代方案，并留下了被舍弃方案的正式记录。fw-4.15.0 只是增加了一个通用层：任何 ADR 都不会丰富这个决策。存档纪律有其操作标准，而非教条。

4. 智能体的可见性在两个层次上运作。 内部层次（第 5 篇，fw-4.12.0）确保智能体在读取仓库时看到框架的概念。外部层次（fw-4.15.0）确保智能体无论由哪个 CLI 编排，都能从正确的门进入仓库。缺少其中任何一个，要么是有能力的智能体在沉默中读取，要么是迷失方向的智能体找不到入口。

参考锚点：PR #155 — fw-4.15.0 / cli-3.13.2（合并于 2026-05-15 19:05 UTC）。原始 AIDEC（第 2 篇）：.chronicle/07-ai-audit/decisions/AIDEC-2025-01-27-001-i18n-strategy.md（提交 7b7193e，含年份笔误的 ID）。注入模板：dist/dist-templates/directives/AGENTS.md。标准规范：agents.md —— 捐赠给 Agentic AI Foundation（Linux Foundation），2025 年 12 月。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 七十二小时内的两个动作​

2026 年 5 月 13 日，UTC 06:20，fw-4.13.4 合并。它填补了两个小的 i18n 覆盖缺口——ISO-25010 参考文档此前只有英文版，而 Charter 模板的简体中文版缺失。二十二个规范框架文件达到了结构上的 EN/ES/zh-CN 均衡。

65 小时后，5 月 15 日 UTC 00:14，PR #154 合并。它在 README 中添加了一枚徽章——CLA Assistant 的那枚，那个小小的可见方块，告诉访客这个仓库接受在贡献者许可协议下的贡献。CLA 政策此前已在 CONTRIBUTING.md 中存在了数月；唯一改变的是它现在在 README 中一眼可见。

本文覆盖这两个动作。分开看，它们都很小——一个完成了某项技术工作最后的 5%，另一个则将已有的内容公开发布。放在一起，它们是框架决定向外部展示自身的那一刻。一个开源项目停止对自己讲话、开始向任何想读的人讲话时所做的事情。

2. i18n 覆盖度最后的 5%​

fw-4.13.4 并非一个重大发布。PR #144 有 511 行新增内容，几乎全是翻译。但 PR 摘要说了一件值得记录的事：

"将治理文档在 EN + ES + zh-CN 上带到完整的 20/20/20 对等。"

20/20/20。dist/.straymark/00-governance/ 中的二十二个规范文件（数量后来增加；5 月时是二十个），全部在 i18n/es/ 和 i18n/zh-CN/ 中有其对应版本。完整对等，而非近似。

填补对等缺口的两个文件是具体的：

• ISO-25010-2023-REFERENCE.md——对框架原则中引用的国际软件质量标准的规范性参考。直到 fw-4.13.4，它只存在英文版。该发布添加了 i18n/es/ISO-25010-2023-REFERENCE.md 和 i18n/zh-CN/ISO-25010-2023-REFERENCE.md，各 150 行。
• charter-template.md 的 zh-CN 版。Charter 模板已经翻译成了西班牙语；简体中文版缺失，共 211 行。

这不是令人兴奋的工作。这是关闭一个框架的那一块。但它在两件事上很重要。第一：在该发布之前，克隆框架的中文使用者会发现只有英文版的核心模板，这与框架提供三语言版本的承诺相悖。第二：博客在第 8 篇文章中已经记录了框架的 i18n 覆盖度接近完整，仅剩两处小缺口作为已记录的债务。fw-4.13.4 偿清了这笔债务。一篇关于审计 prompt 异常值的文章中看似旁注的内容，最终成了一个独立发布，有其自己的 CHANGELOG 条目。

3. 哪些内容被翻译，哪些不被翻译​

PR #144 明确编入代码的一条操作规则值得记录，因为它是框架在 i18n 方面最清晰的规则：

"LLM 处理的资产（skills、工作流、schemas）保持纯英文；以人为主要受众的制品会被翻译。"

也就是说：AI 智能体读取的内容——skills、.claude/、.gemini/、.agent/ 中的工作流、dist/.straymark/schemas/ 中的 schemas、dist/.straymark/audit-prompts/ 中的 prompts——只以英文存在。人类阅读的内容——文档、原则、贡献指南、面向人类的模板文本——则翻译为三种语言。

这与第 13 篇文章记录为通用 AGENTS.md 知识源头的原则相同：智能体是单一的技术受众，不会从翻译中受益。此处值得记录的是，5 月时这条规则已作为操作标准写入 PR，而非作为直觉存在。技术提案引用它；审阅者用它来决定新文件是否进入 i18n/ 目录。

PR #144 中还有一个细节值得逐字记录：

"docs/contributors/TRANSLATION-GUIDE.md 的缺口是有意为之——其目标受众本就能读英文才能阅读该指南。"

翻译指南有意保留英文，因为其受众——将框架翻译为其他语言的贡献者——必然已能读英文。这是操作上的诚实：20/20/20 对等并非仓库每个文件都是 22/22/22。它是对翻译能增加用户价值的文件达到 20/20/20。总覆盖率与适用覆盖率的区别。

4. 那枚没有引入任何新事物的徽章​

PR #154 是 fw-4.13.4 的教学对立面。fw-4.13.4 关闭技术工作，PR #154 则发布已经存在的内容。其 12 行变更向 README 中添加了这些内容（英文、西班牙文和中文各一份）：

[![CLA assistant](https://cla-assistant.io/readme/badge/StrangeDaysTech/straymark)](https://cla-assistant.io/StrangeDaysTech/straymark)

一枚徽章。一张出现在 README 顶部、与其他项目徽章（许可证、版本、下载量）并排的小图片。视觉上平平无奇。

但这枚徽章不是装饰。它是一个信号。这个信号说了一件具体的事："这个仓库接受外部贡献，规则在这里"。任何打开 README 的访客都可以点击该徽章，来到 CLA Assistant——这个服务会自动在任何贡献者的第一个 pull request 上留言，要求他们签署贡献者许可协议。一次签署涵盖未来对该项目的所有贡献。

重要的是，CLA、CONTRIBUTING.md、完整的审阅政策，这一切在 PR #154 之前就已存在。它已编码、运行、生效。框架已经接受外部贡献——只是偶然来访的仓库访客必须打开 CONTRIBUTING.md 才能了解其运作方式。

PR #154 做了一个值得命名的区分：拥有政策和发布政策是两件不同的事。前者是内部纪律；后者是公开邀请。在 5 月 15 日之前，框架拥有该政策。从 5 月 15 日起，它将其公开发布。

这是一个编辑性变更，而非架构性变更。但一个开源项目决定在 README 顶部放上 CLA Assistant 徽章的那一天，就是它决定正式向第三方呈现自身为可采用项目的那一天。这是框架停止成为一个"一位开发者与其使用者（Sentinel）"的项目、成为一个接受拥有更多使用者、更多贡献者、更多双手的项目的时刻。

5. 当一个框架感到准备好被看见​

这两个里程碑放在一起读，记录了一个年轻框架生命中的特定时刻：它感到准备好被那些没有写过它的人看见的时刻。

fw-4.13.4 兑现了技术承诺。如果框架说它支持西班牙语-英语双语并实验性地支持简体中文，那么二十二个规范文件必须以三种语言全部存在。不是二十分之十九。不是二十一分之二十还有两个待处理。20/20/20。完整对等是当访客核验时让承诺可信的东西。

PR #154 兑现了社会承诺。如果框架说它接受外部贡献，README 中的 CLA 徽章就是行业标准的表达方式。没有徽章，开放性存在但需要自行发现；有了徽章，它就有了路标。访客的第一次点击就能找到路径。

值得命名这两个动作的不对称性。关闭技术工作最后的 5% 恰好需要那些成本——一个专项发布、两个翻译文件、一个 CHANGELOG 条目。发布一项已有政策只需要十二行 Markdown。便宜的那个有时是操作上最重要的姿态，因为它改变了外部世界对项目的感知，而没有改变项目本身的任何事情。

这是第 5 篇文章以结构性可见度记录的模式的"打开框架"版本：存在但没有命名的东西，对智能体来说不存在。这里是：存在但没有发布的东西，对外部使用者来说不存在。5 月的七十二小时，两个小里程碑——一个技术性的，一个编辑性的——框架跨越了*"它能工作，但只有写它的人知道"与"它能工作，任何人都能看见"*之间的界线。

6. 弧线的象征性收束​

有了这篇文章，博客覆盖了 RETOMAR-AQUI.md §5 在主 H-01 → H-13 弧线关闭后列出的第二批中最后待处理的里程碑。四个已识别的候选——H-?-C（validate + schemas）、H-?-A（通用 AGENTS.md）、H-?-B（完整 i18n 覆盖度）、H-?-E（CLA 徽章）——全部已覆盖：三个有各自的文章（第 12、13 篇和本篇），一个合并覆盖。

写第二批时，将四个里程碑放在一起回看，我学到的是：

• 第 2 阶段 / validate（第 12 篇）是结构性的：框架开始验证它一直在承诺的事情。
• TUI explore（第 11 篇）是关于可见度的：框架变得可导航。
• 通用 AGENTS.md（第 13 篇）是关于覆盖范围的：框架变得可被任何 CLI 发现。
• 完整 i18n 覆盖度 + CLA 徽章（本篇）是关于开放的：框架变得对外部访客可见。

每一个都覆盖了同一个想法的不同维度，而博客在早期文章中已经编码了这个想法：框架声称自己是什么，不足以让它成为那样；它必须在每一个某人——智能体、外部使用者、访客——可以构建项目模型的表面上存在。第二批的里程碑是第 5 篇文章以一个治理 Issue 命名的结构性可见度的成熟版本。

现在，在第 14 篇之后，队列中没有更多候选了。如果在今天到博客下一个会话激活之间出现新的框架里程碑，RETOMAR-AQUI 将再次被用作恢复点。如果没有出现，这篇文章就是真正的收束——完成博客着手覆盖的清单的收束。

7. 结语​

我从这个过程中得到的，用四个论断表达：

1. 总覆盖率在工作末尾代价很小，在开头代价很大。 最后的 5%——那两个中文文件——是一个专项发布。但它之所以只是轻微地可关闭，是因为其余 95% 已经完成。20/20/20 对等不是从一开始就有的；它被追求了数月，最终以一个小 PR 关闭。

2. 拥有政策和发布政策是两件不同的事。 框架的 CLA 在徽章之前就已存在了数月。十二行 Markdown 将一项内部政策变成了公开邀请。你放上徽章的那天，你没有发明任何东西；你宣告你准备好被找到了。

3. 什么内容被翻译的操作规则具有存档价值。 人类阅读的内容会被翻译；智能体阅读的内容以英文存在。这个区分，从一月份第一次 AIDEC 中直觉得出，在 5 月成为明确的审阅标准。每个新框架文件在选择目的地之前都要经过那个问题。

4. 框架何时变得可被第三方采用是一个决定，而非一种状态。 有一天，运营者决定框架可以被没有写它的人看见而不感到难堪。那一天以小动作具体化——完成翻译、发布徽章——这些动作不改变功能，但改变姿态。框架停止对自己讲话。

至此，博客关闭第二批。从项目史前史（第 2 篇，一月）开始追溯、以元模式（第 10 篇，五月）完成的弧线，现在也有了其推论：使框架可被采用的里程碑。十四篇文章，二十八个文件（十四篇西班牙语 + 十四篇英语），每种语言两万五千到两万六千字。正如第 10 篇结语所说：博客讲完了这个故事。框架继续前行。

锚点：PR #144 — fw-4.13.4（2026-05-13 06:20 UTC 合并，完整 i18n 覆盖度）。PR #154 — README 中的 CLA Assistant 徽章（2026-05-15 00:14 UTC 合并）。完整政策：CONTRIBUTING.md（仓库根目录 + docs/i18n/{es,zh-CN}/CONTRIBUTING.md 中的翻译版本）。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

——StrayMark 博客第二批结束。

1. 正确的问题​

Issue #150 于 5 月 14 日 16:59 UTC 开启，寻求的不是一个是/否的答案。操作员要求的是重新表述这个问题：

"bridge 文档真正需要回答的是如何做，而不是是否做：在多 Charter 执行期间，什么纪律能确保 spec 与代码保持同步，同时避免刷新步骤对已经交付的部分撒谎。"

这套纪律已经存在了。就在那时，它正在 Sentinel 中被手工应用于 CHARTER-18，操作员心里清楚任何一步走错都会埋掉前六个 Charter 的工作。缺少的——Issue 以令人不安的精确度所记录的——是名字。是时机。是未来的采用者无需经历自己摸索之痛就能遵循的规则。

这篇文章涵盖从那个 Issue 到将纪律规范化为上游治理的 PR 之间的五个小时、为规范化提供依据的 12 条实证经验，以及在模式存在之前就演练了该模式的具体操作事件——Sentinel 的 CHARTER-18。下一篇文章将介绍 27 小时后发生的事：名字。

2. 在同一个 plan 上跑七个 Charter​

一句话背景：Sentinel 执行 specs/002-commshub/plan.md——写于 2026 年 4 月 21 日 commit be29421——历经连续七个 Charter（CHARTER-07 至 CHARTER-17），整整一个日历月，一次都没有刷新 plan。

原始 plan 写得很好。它经过精心撰写，详细描述了四个用户故事（US1-US4），声明了数据模型，勾勒了契约。但这个 plan 是操作员在四月时对代码行为的一个快照式设想。执行过程中发现了 plan 无法预见的事情：

• 执行过程中出现的基础设施模式，并被证明是可复用的（core.processed_events 中的命名空间、withRLS 辅助函数、用于不变量执行的 PL/pgSQL 触发器）。
• plan 假设已解决的代码缺口（AnomalyDetector 半成品、缺失幂等性去重、Recipient.TenantID schema 缺口）。
• 在执行过程中逐渐固化的 Charter/审计模式（跨家族审计周期、HTTP 层测试覆盖缺口、带严格大于的游标分页）。

当需要为 US5 规划 CHARTER-18 时，plan 已经一个月没更新，而代码上面积累了一个月的实证经验。两者不同步。而 SPECKIT-CHARTER-BRIDGE.md——通常应该回答*"这里该怎么做？"的框架文档——对这种情况保持沉默。规则"在多 Charter 执行期间如何让 spec 与代码保持同步"*还不存在。

3. 十二条实证经验​

Issue #150 列举了在 plan 中未经反思而积累的十二条经验。这份按类型分组的原始表格值得保留在视野中：

执行期间发现或完善的四个基础设施模式。plan 未预见到的四个代码缺口。当场固化的四个 Charter/审计模式。十二条，在一个月内，全部真实。plan 没有它们。而下一个 Charter——CHARTER-18——将要读取 plan，仿佛它们不存在。

操作员在 Issue 中记录的估算是诚实的：

"由过时前提继承导致 ≥1 个关键/高危发现的估计概率：~50%。"

一句话，就是掷硬币。一半在过时 plan 上启动的 Charter 会以一个后续审计周期必须在关闭前原子性修复的关键发现结束。另一半只是侥幸逃脱。

4. 方案四：手工应用的纪律​

同一天，在这套纪律还没有名字之前，Sentinel 内部发生的事：操作员评估了五个具体方案，选择了第四个。Sentinel 的私有 AIDEC——AIDEC-2026-05-14-001-speckit-plan-scope-limited-us5-refresh.md——毫不掩饰地记录了这一分析。我在这里转述它，因为详细内容在私有仓库中，但推理结构才是关键所在：

• 方案一——"和以前一样读"。 保持 plan 过时状态，像前六次一样读取。代价：在后续审计周期中偿还债务，约 50% 的关键发现概率。
• 方案二——用 /speckit-plan 重新生成一切。 风险：覆盖关于 US1-US4 的断言，而真实代码并不满足这些断言；生成器不知道当前状态。
• 方案三——不受限制地在另一个 PR 中刷新。 与方案二相同的风险，加上评审摩擦。
• 方案四——范围限定刷新 + 3 个关卡。 选定方案。
• 方案五——推迟 CHARTER-18，先做重构 Charter。 日历成本高，相对方案四边际收益低。

第四个方案由三个具体机制组成：

第一机制——范围限定提示词。 带着明确限制性提示词运行 /speckit-plan：仅重新生成对应 US5 的第 7+8 阶段；将 US1-US4 逐字节保留原样，用智能体必须遵守的 <!-- LOCKED: prior US shipped --> 注释标记。没有这个明确限制，SpecKit 的重新生成是破坏性的：它重写整个 plan，覆盖真实代码已经与之矛盾的描述。

第二机制——关卡 (a)：对代码现实的验证。 一个临时脚本，约 30 行 bash + grep，将 data-model.md 中每个非 US5 实体与 db/migrations/*.sql 中的真实 schema 进行差异比较，并将 contracts/*.md 中每个非 US5 端点与 internal/modules/commshub/handler_*.go 中的实际处理程序签名进行比较。任何分歧都会阻止合并。脚本存在于 Sentinel 的仓库中；它不优雅，它是操作性的。框架后来规范化为关卡 (a) 的东西当时已经在那里了，以手工 bash 的形式。

第三机制——关卡 (b)：逐 hunk 细粒度评审。 逐文件、逐 hunk 评审 git diff，对锁定部分的任何变更都不接受，除非有理由说明。操作员在 AIDEC 的 R1 中明确记录了预期的摩擦：如果智能体重新生成的 hunk 比必要的多，人工评审者会感到疲惫，纪律就会崩溃。缓解措施：超过 50 行的 hunk 触发 P1 评审。

第四机制——关卡 (c)：两个 PR 拆分。 刷新是一个独立的 PR，针对当前代码进行评审。随后的 Charter 填充是另一个 PR，针对已经刷新的 plan 进行评审。不要混合两个评审——因为如果混合在一起，刷新的债务就会藏在新工作后面。

四个机制。手工应用，没有任何上游文档支持。一个单独的采用者（我），一个单独的会话，以及始终伴随着的感觉——在解决一个以前从未有人解决过的案例。

5. 结果​

CHARTER-18 当天就关闭了。Charter 遥测指标，逐字记录在关闭 YAML 中：

• estimation_drift_factor: 1.0 —— Charter 恰好在估计的小时范围内完成。
• pre_work.items_discovered_during_planning: 0 —— 规划过程中没有出现意外事项。
• overall_satisfaction: 5/5 —— 操作员在整个链条中最好的主观校准评分。

比指标更重要的是：CHARTER-18 是七个 Charter 链条中第一个在不需要中途修复 Charter 的情况下关闭的。前六个各自至少需要一次原子性事前关闭修复，以弥补声明与交付之间的分歧。CHARTER-18 没有。操作员的结语，直接引用自后来的 CHARTER-CHAIN-EVOLUTION.md：

"PR #76 的 SpecKit 刷新消除了大部分导致先前 Charter 漂移的歧义。不需要中途修复 Charter——research.md 中的 EC1..EC15 实证修正清单将本来是执行前风险的东西吸收为执行中意识。"

手工纪律奏效了。它不只是干净地关闭了 Charter；它改变了风险的性质。过去是执行前风险（在 Charter 执行期间发现分歧，原子性修复）的东西变成了规划前意识（EC1..EC15 清单在声明 Charter 之前列举实证修正）。风险没有被消除；它被移到了一个可以管理的时刻。

6. 四小时四十分钟​

时间线值得精确记录，因为这正是博客所要记录的：

• 5 月 14 日，16:59 UTC —— Issue #150 开启。十二条经验被列举，三个关卡被提出，概率分析被公开。
• 5 月 14 日，21:39 UTC —— PR #152 合并。fw-4.14.3 发布。*"多 Charter 执行期间的 spec 维护"*作为 SPECKIT-CHARTER-BRIDGE.md 的新章节添加，三个关卡被逐字规范化为框架治理。问题与上游答案之间相隔四小时四十分钟。

PR #152 作为治理文档记录的，正是私有 AIDEC 在几小时前手工应用的。三个关卡同名：对代码现实的验证（关卡 a）、逐 hunk 细粒度评审（关卡 b）、两个 PR 拆分（关卡 c）。另加四条何时刷新的启发式规则：同一 plan 上 ≥3 个已关闭 Charter、≥4 周 + ≥2 个 Charter、R<N>(new) 数量 > 6、目标 US 触及已完善的基础设施。另加一条明确说明为何不重新运行 /speckit-tasks 的注释（因为它会销毁 [X] 标记和构成历史追踪的 *CHARTER-NN:* <sha> 注解）。另加一条路线图注释，提到未来将机械化关卡 (a) 的 straymark spec-drift CLI。

四小时。毫不夸张地说，框架在操作员另一个窗口里还开着 git diff 的时候就写好了指导文档。纪律与其规范化几乎是同时发生的。这值得记录，因为它颠倒了学术治理机构通常假设的顺序：先理论，后实践。这里反过来了。先实践，在它还疼的时候。再理论，在疼痛还新鲜的时候。

7. 结语​

我从这个过程中得到的，用四个论点：

1. 模式源于纪律，而不是反过来。 fw-4.14.3 的三个关卡不是抽象设计的；它们是从一个具体的操作事件中提取的，在手工应用数小时后。当框架尊重顺序时，治理是后实证的。

2. 明确的概率就是纪律。 *"过时前提继承导致关键发现的概率约 50%"不是贝叶斯精确度；它是一个公开声明，迫使决策必须有理由支撑。没有这个数字，"我们应该刷新吗？"*的问题由直觉决定。有了它，就由风险算术决定。

3. 三十天内十二条经验是实际的节奏。 这不是可以用*"以后再读"*捕获的噪声。这是原始 plan 无法预见的实证密度，它摧毁了任何长期规划假设。智能体辅助开发的节奏就是如此。

4. 四小时不是记录；它是过程的属性。 当纪律已经在一个领域中被应用时，将其规范化到上游是执行，不是设计。正如我们在第 4 篇文章中关于外部审计周期所见（"一天内五个 PR"），以及第 6 篇文章中关于品牌重塑（"四十三分钟"）。框架没有发明这套纪律；它提取了它，并给它起了名字。

接下来，在下一篇文章中，是这个博客所要讲述的弧线的最后一个事件："模式 1 + 模式 2——链条演化"（H-12）。在 PR #152 之后 27 小时，三个治理关卡结晶为两个命名元模式——事前声明刷新和浮现即修正——附带遥测 schema 和 CLI 辅助工具。这是第 1 篇文章从前方打开的弧线的收尾。

锚点：Issue #150（5 月 14 日 16:59 UTC）。PR #152 —— fw-4.14.3（5 月 14 日 21:39 UTC）。规范化章节：SPECKIT-CHARTER-BRIDGE.md §"多 Charter 执行期间的 spec 维护"。CHARTER-18 指标报告于 CHARTER-CHAIN-EVOLUTION.md（fw-4.16.0）。私有来源依照 GUIA-EDITORIAL.md §7 转述：Sentinel 仓库中的 AIDEC-2026-05-14-001-speckit-plan-scope-limited-us5-refresh.md。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 从提交记录的一行说起​

这是本文的操作性开头。2026 年 5 月 12 日的提交 a8a1ac5 包含如下正文，第一句话是这样的：

"dist/.straymark/audit-prompts/ 下的统一 audit-prompt 模板，是框架中唯一一个正典内容以西班牙语存储的制品 —— 其他所有模板、skill、工作流和治理文档，都遵循"英语正典 + i18n/<lang>/ 覆盖层"的模式，由 cli/src/utils.rs:146 负责解析。"

就这一个文件。在几十个文件之中。它反着活。而且它就这样活了整整六个星期，没有人发现。

这篇文章刻意写得很短。它所记录的修复 —— PR #142、fw-4.13.3 与 cli-3.12.3，合并于 5 月 13 日 —— 并不是什么重大的叙事节点。这是一次维护性工作。但它记录了我在这门手艺中反复遇到的一个规律：异常值有其价值。它们通过对比，教你什么是规范。

2. 异常值从哪里来​

audit-prompt 并非生于框架之中。它最初是 Sentinel 的一个本地 skill —— sentinel/.claude/skills/plan-audit/ —— 诞生于第 3 篇文章所记录的六 Plan 实验期间，也就是四月。它是一个特定情境下的 skill，由操作者（我）以西班牙语编写，理由现在可以坦诚地列出来：这是一次私人实验，操作者说西班牙语，而且这个 skill 此后大概不会有人再读。我用自己的语言随手写了它，因为它只是为我而写。

当实验逐渐凝结成框架 —— 也就是第 4 篇文章所记录的从 fw-4.4.0 到 fw-4.9.0 的演进弧 —— 那个 skill 被移植到了正典路径 dist/.straymark/audit-prompts/audit-prompt.md。移植过程是机械的：复制文件，做够泛化处理使其不再引用 Sentinel 特定的组件，调整 Plan → Charter 的命名。没有做的一件事是：把它翻译成英语。这个文件就以它被编写时的语言进入了框架。没有人做出这个决定，西班牙语就这样成了那一个制品的正典版本。

框架的其余部分 —— 每一个模板、每一个 skill、正典治理文档 —— 自一月起就以英语编写，西班牙语和 zh-CN 作为 i18n/<lang>/ 下的覆盖层。audit-prompt 是那个沉默的例外，持续了六周，直到 5 月 12 日。

3. 如何被发现：目视检查​

发现它的不是智能体的涌现性观察。是操作者，靠眼睛发现的。CHANGELOG 条目毫无修辞地记录了这件事：

"在 Sentinel 审计 straymark explore 渲染效果时经验性地浮现出来：用户注意到 audit 周期模板是西班牙语，而其他所有模板和 skill 都是英语。"

straymark explore 是框架的 TUI —— 也就是第 14 篇文章将要介绍的交互式文档浏览器。它的价值在于把所有模板并排渲染在同一个视图中。而当所有模板并排显示，其中一个是另一种语言，就显而易见了。就是这样一个观察。

这个数据值得留下，因为它关乎博客的诚实。第 1 篇文章阐述了涌现性观察的模式 —— 智能体标记出没有人要求它标记的事情 —— 第 5 篇文章记录了因结构性可见性缺失而导致该模式不起作用时会发生什么。这个插曲两者都不是。这是一个更平常的观察：框架的一个新界面（TUI）把所有文件同时呈现在视图中，不一致性就变得像你整理书架时发现一本书脊朝内的书一样显眼。工具也能产生可见性。

4. 修复：一次提交里的三个动作​

PR #142 在同一次提交里做了三件事：

• dist/.straymark/audit-prompts/audit-prompt.md 以英语重写为正典版本。312 行。翻译时注意保留了原文的严重程度结构和校准示例。
• dist/.straymark/audit-prompts/i18n/es/audit-prompt.md 作为覆盖层创建。318 行。原本住在根目录的西班牙语内容，现在回到了它正确的位置。
• cli/src/commands/charter/audit.rs 接入 i18n 解析器。在此之前，该子命令硬编码了 dist/.straymark/audit-prompts/audit-prompt.md 路径，不查询采用者在 .straymark/config.yml 中的 language 字段。PR 合并后，它会读取项目配置并解析本地化路径 —— 如果采用者设置了 language: es，他们会得到西班牙语覆盖层；如果设置了 language: zh-CN，则回退到英语正典（audit-prompt 尚无 zh-CN 译文）；如果设置了 language: en 或未指定，则得到正典版本。

三个新测试覆盖了这三条路径。对英语用户（占多数）零功能变化。对西班牙语用户而言是一次改善：此前，他们收到西班牙语 prompt 是出于偶然（因为正典路径指向了西班牙语）；现在，他们收到西班牙语 prompt 是出于约定（因为解析器做出了决定）。

5. 顺带的一步​

在做语言切换的同时，操作者借机提取了一处从 Sentinel 起源时遗留下来的具体性。prompt 的 §Step 5 小节 —— 关于发现项的严重程度校准 —— 引用了四月实验中一个真实的案例："Etapa 12 Pub/Sub stub vs gochannel"。这是一个很有说明性的例子，但它特定于一个没有其他采用者会认识的 Sentinel 组件。

英语译文用一个供应商中立的表述替换了那个示例："声明的延期，而非缺陷 —— 一个 Charter 引入了一个薄适配层，计划在未来的 Charter 中替换"。那个想法 —— 一个存根，是声明的技术债，而非缺陷 —— 保留下来了。消失的是组件的名称。

这个动作很小，但与博客的原则一脉相承。当有机会在不损失教学性的情况下将框架从某个特定采用者身上解耦，就应该这样做。这与第 3 篇文章为六个 Plan 所记录的、第 4 篇文章为第一个 Charter 所记录的泛化操作如出一辙：经验性内容留在 Sentinel 内部；进入框架的是供应商中立的抽象。audit-prompt，在将近一年之后，终于完成了对这条规则的尊重。

6. 结语​

三个简短的论断：

1. 在一个有约定的框架中，单个文件违反约定，是遗留问题的迹象，而不是设计的迹象。 audit-prompt 是异常值，因为它诞生得更早，而当其他制品对齐的时候没有人迁移它。异常值积累来历。

2. 新工具产生可见性。 西班牙语到英语的切换，不是通过系统性地审查仓库来决定的。它是因为一个新的 TUI 把所有模板放在同一个屏幕上，不一致性变得显而易见，才被决定的。同样的道理适用于 grep、聚合视图、status 输出：每一个新界面都会暴露出曾经错位的东西。

3. 小范围的重新标注是去标识化的机会。 当你触碰一个文件来更改语言时，顺带提取出源自起源的采用者特异性，边际成本为零。博客之前记录过这个模式（Plan → Charter、DevTrail → StrayMark）；这是它的微缩版。框架一次一个文件地变得更加供应商中立。

下一篇文章，是一个已经在第 1 篇文章中擦肩而过、但值得独立处理的插曲："模式之前的手工纪律"（H-11）。在 Pattern 1 的链式演进机制存在之前，Sentinel 是如何处理 CHARTER-18 的 —— 那段经验性学习，后来在第 1 篇文章中被命名为元模式。

锚点：PR #142。发布版本：fw-4.13.3 / cli-3.12.3。关键提交：a8a1ac5。文件：dist/.straymark/audit-prompts/audit-prompt.md（英语正典）+ dist/.straymark/audit-prompts/i18n/es/audit-prompt.md（覆盖层）。CLI：cli/src/commands/charter/audit.rs 接入 i18n 解析器。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 十三个 Charter，零个 TDE​

Issue #128 以一个令人不安的不对称开局：

"Sentinel 采用者（主要，fw-4.12.0）在 13 个已关闭的 Charter 中创建了零个 TDE，尽管有 ≥7 处横向债务通过并行机制流转。"

十三个已关闭的 Charter。至少七处可辨认的横向债务——继承自前序 Charter，跨越模块，在会话之间持续存在。零个 TDE。如果这是某个陌生操作者的数据，或许还说得过去。但操作者是我，采用者就是这个在实践中验证框架本身的项目。如果 Sentinel——整个框架被最激进使用的仓库——在十三次尝试中一次都没有产生 TDE，那一定是哪里出了问题。

出问题的不是债务本身——债务通过其他渠道被捕获了（AILOG 内部的 R<N>（新增，不在 Charter 内），以及 follow-ups-backlog.md 中的条目）。出问题的是，框架中没有任何准则说明"这一具体内容值得创建 TDE，而不是 R<N>"。文档类型存在，操作触发器不存在。

本文记录的是 2026 年 5 月 11 日至 12 日这段经历：如何诊断出缺失的触发器，如何用四条规范标准（fw-4.13.0）填补这个缺口，以及修复问题的 PR 链如何在此过程中留下了一堂关于 "stacked PR" 的操作课，并最终被写入项目的 CLAUDE.md。这是框架在同一弧线中修复了两件不同的事的第一篇博客记录，而其中第二件是无意为之的。

2. 类型存在，触发器不存在​

TDE——Technical Debt Entry（技术债务条目）——自一月份的初始提交以来就存在于框架中（Post 2 记录了这一点：它是 v1.0.0 README 中八种原始类型列表中的一员）。模板在，分类法字段在，06-evolution/technical-debt/ 文件夹也在。

缺少的是在规范装置的某个地方写一句话，说*"现在创建一个 TDE"*。Issue #128 毫不留情地指出了这一点：

"阅读面向采用者的文档（AGENT-RULES.md、DOCUMENTATION-POLICY.md、QUICK-REFERENCE.md、CLAUDE.md 自主规则），没有任何明确的触发器说明'现在创建 TDE'。AILOG（随时创建）、AIDEC（考虑替代方案时）、ETH（高风险 PII）、ADR（架构决策）都有触发语言，但 TDE 只是被列为'智能体可以识别'。"

"智能体可以识别。" 如果你有心的话就识别吧。进入仓库的智能体读到这句话，耸耸肩，转向 AILOG 和 AIDEC——那两个明确告诉它何时动作。这个缺陷与 Issue #113（Post 5）中的一个如出一辙：制品技术上存在，但规范界面没有给智能体激活它所需的动词。这个案例与 #113 不同之处在于后果。Charter 的情况是看不见就不用新流程。TDE 的情况则更糟：横向债务确实在被捕获——但是碎片化的，没有整合视图，没有跨制品的优先级排序，没有供人类审阅者排序的 assigned_to 或 priority 字段。

Issue 列举后果时措辞直白，因为它详细说明了所有没有发生的事：

"在文档层面没有可查询的'所有待处理技术债务'视图。每个条目没有 影响 × 努力 优先级矩阵。没有向人类审阅者暴露 assigned_to / priority 字段。真正跨越多个 Charter 的架构债务（例如，跨模块的范围授权缺口遗留）被碎片化到每个 Charter 的 R 编号中，而不是合并到一个 TDE 里。"

十三个 Charter 的债务被碎片化为每个 Charter 的 R<N>。从仓库操作者的角度来看：没有整合列表，没有一项被明确标注为继承而来，没有任何债务可以在项目层面进行优先级排序。一切都在仓库里。但没有一样放在仓库为那些从外部进来阅读的人类所构建的地方。

3. 债务的四条判定标准​

PR #129（fw-4.13.0，在 Issue 提出整整十三小时后于 5 月 11 日 19:38 UTC 合并）用 AGENT-RULES.md §3 中的新章节——"TDE 与 R<N>（新增，不在 Charter 内）"——填补了这一缺口。四条标准，原文如下：

操作规则：如果一项债务满足四条标准中的至少一条，它就是一个 TDE。如果一条都不满足，它就留在它出现的那个 Charter 内作为 R<N>。

四条标准各有其逻辑。继承性（1）捕获跨时间持续存在的债务，审阅者希望按来源分组，而不是按 Charter 分组。多模块或多 Charter（2）捕获存在于制品之间而非存在于某一制品内部的债务。独立 Charter（3）承认某些债务足够大，值得拥有自己的周期，因此不适合作为事前声明的风险。人类优先级排序（4）承认自主性的边界：有些决定智能体可以标记但无法解决，这些决定值得有一份文件供人类排队处理。

同一个 PR 还在 TDE 模板的元数据中增加了新字段——promoted_from_followup: FU-NNN | null——以及 FOLLOW-UPS-BACKLOG-PATTERN.md 中关于如何将后续跟进条目晋升为 TDE 的章节。晋升有两种形式，均有字面记录：现有条目的晋升（已在列表上数周的后续跟进条目成熟为 TDE），以及创建时的追溯晋升（创建 TDE 时，承认它源自先前的后续跟进条目并加以标注）。元数据字段完整了追溯链：现在任何 TDE 都可以指回产生它的后续跟进条目（如果有的话）。

4. Sentinel 的三个 TDE——实证循环闭合​

Issue #128 不是靠论证关闭的，而是靠证据。同一天，Sentinel——那个在十三个 Charter 中一个 TDE 都没有产生的同一采用者——创建了三个：

• 一个关于 RequireScope 架构缺口的 TDE，继承性跨越模块。标准 1 + 2 + 3。
• 一个关于 HTTP 层缺失测试覆盖的 TDE，债务跨特性 Charter 持续存在。标准 1 + 4。
• 一个关于审查早于 Charter 格式 v3 的遗留 AILOG的 TDE，这个问题需要自己的周期。标准 1 + 3。

数小时内三份文档。速度不是关键，关键在于每一份都适用了至少一条标准，且没有任何一份落入灰色地带。标准作为明确的启发式规则发挥了作用——操作者不必自我纠结某项内容是 TDE 还是 R<N>。Issue 在上午开启的实证循环在当天下午以三份文档宣告闭合。

PR #136（fw-4.13.1，次日合并）根据同一实践经验对两条标准进行了细化。继承性（1）被明确拆分为严格继承与模式传播，因为 Sentinel 的三个 TDE 之一清晰地展示了第二种情形：债务并非字面上被继承，而是在遵循相同程序时相同模式再度出现。多模块（2）被重新表述为"多个模块或 Charter 执行边界"，因为三个 TDE 中的另一个属于治理轨迹型（跨越会话边界，而非跨越代码模块）。这些标准在三个真实案例上经过演练后，只经历了一轮精化。框架再次验证了第 12 条原则：没有任何模式在第二个领域验证之前会结晶成型。

5. Stacked PR 的教训​

这里文章故意转了个弯。关闭 Issue #128 的 PR 链 #129 → #131 → #133 留下了一个附带的操作教训——不关于 TDE，而是关于如何不应该叠加分支。这一教训被字面记录在公开仓库 CLAUDE.md（第 181-220 行）的 "Stacked PRs——避免，或使用合并提交" 章节中。

它是怎么出问题的​

PR #131（cli-3.12.1，验证器修复——它曾拒绝 TDE 上的 status: identified）以 base = #129 打开，因为 #131 需要 #129 的代码才能编译其测试。然后 #129 以压缩合并的方式并入 main。当前的 CLAUDE.md 用值得完整引用的精确措辞描述了这一情形：

"当你把 PR B 叠加在 PR A 的分支上（B 的 base 是 A 的 head，而非 main），而 A 以压缩合并并入 main 时，B 的内容就会被搁置：

— A 的压缩合并在 main 上创建了一个新提交，其内容等同于 A，但 SHA 与 A 原始提交不同。

— B 的分支仍然指向 A 的原始提交，而这些提交在 main 上已没有后代。

— 当 B 被合并时，GitHub 将其合并到 A 的分支（其声明的 base），而不是 main。'合并到 main'从未发生——即使 GitHub UI 显示 B 为 MERGED。"

在 #129/#131 周期中实际产生的结果：GitHub 的 UI 显示 #131 已合并，验证器测试表面上进入了 main，但内容从未到达。PR #133 是后来不得不开启的程序性同步 PR，以将内容送达目的地。诊断耗时：约三小时。理解后的恢复操作耗时：五分钟。

如何预防​

CLAUDE.md 记录了两种策略，一种保守，一种务实：

"1. 顺序，而非叠加。等待 PR A 合并到 main，然后将 B 变基到 main 上，以 base = main 作为独立 PR 开启 B。较慢但万无一失。

2. 如果必须叠加，对父分支使用合并提交（而非压缩）。合并提交保留了共享历史，因此后续将叠加 PR 合并到 main 可以顺畅解决。用更嘈杂的 git log 换取 stacked-PR 的安全性。"

Sentinel 和 StrayMark 默认使用压缩合并。这个选择有助于保持 git log 整洁，每个特性一个决策，每个 PR 一个提交。但代价恰恰在这里：与 "stacked PR" 不兼容。CLAUDE.md 现在所编纂的规则是诚实的：要么不叠加，要么付出提交历史的代价才能叠加。没有第三个选项不会破坏某些东西。

如何恢复（如果已经发生）​

CLAUDE.md 的恢复部分是该文档中操作性最强的内容。四个步骤：

"1. git checkout -b chore/sync-<B-content>-to-main main

2. git cherry-pick <B 的合并提交 SHA> ——应该是干净的，因为 B 触及的文件在 A 的冲突区域之外（这正是当初可以叠加的原因）。

3. 推送，以 base = main, head = chore/sync-... 开启 PR。cherry-pick 在 main 上产生新提交，因此不会有冲突。

4. 如果内容已在 B（原始 PR）中经过审查，分支保护可能需要 --admin 合并——同步 PR 纯属程序性操作。"

最后一步在编辑上很重要：明确说明 --admin 合并仅授权用于此类程序性 PR——即内容已在原始 PR 中经过审查的情形。这是项目"内容经人类审查"规则的唯一例外。

之所以值得将这一教训记录为 TDE 文章的一个子章节——而非独立文章——是因为两者有一个共同特征：都是框架现在明确命名的横向流程债务。一个是代码债务（TDE 作为新类型），另一个是工作流债务（"stacked PR" 作为已记录的反模式）。两者同源：是真实的操作摩擦触发了文档的诞生。

6. 这段经历在仓库中留下了什么​

不到二十四小时内四个 PR，三条已记录的教训：

• PR #129（fw-4.13.0，5 月 11 日 19:38 UTC）——TDE 激活触发器。四条标准 + AGENT-RULES.md §3 新章节 + FU → TDE 路径。
• PR #131（cli-3.12.1，5 月 11 日 19:39 UTC）——验证器接受 TDE 上的 status: identified。没有这个修复，在新触发器下创建的第一个 TDE 会通不过验证。
• PR #134（5 月 12 日 04:54 UTC）——"stacked PR" 教训记录在 CLAUDE.md 中。它没有修改框架代码，而是修改了仓库的操作规则。
• PR #136（fw-4.13.1，5 月 12 日 04:54 UTC）——基于 Sentinel 三个真实案例对 TDE 触发器进行细化。

关于这段时间线，我最想强调的是：CLAUDE.md（PR #134）在关闭 Issue #128 的同一弧线中被更新了。"stacked PR" 的教训没有等到被遗忘。如果框架的纪律是"每一次重大变化都留下有据可查的痕迹"，这同样适用于操作摩擦，而不仅仅是设计。框架的存在，部分正是为了让昂贵的教训不会消散。

7. 结语​

从这个过程中得出的四点结论：

1. 没有触发器的文档类型是不可见的类型。 与 Issue #113 一样，智能体进入仓库时看不到的东西对它来说就不存在。TDE 从一月份起就在技术上存在，但直到四条标准出现在 AGENT-RULES.md §3 中才开始被使用。没有激活动词的结构只是装饰。

2. 横向债务值得拥有自己的类型。 将债务碎片化为每个 Charter 的 R<N> 会破坏治理系统最重要的属性：整合视图。四条标准，满足任意一条即可，守住了"这是 Charter 的风险"与"这是项目的债务"之间的界线。

3. 操作教训也要文档化。 PR #134 在教训浮现的同一天更新了项目的 CLAUDE.md。这不是存档偏执，而是同一规则应用于流程：如果今天这个摩擦耗费了你三小时，就在今天写下这一教训。

4. 框架从特性和反模式两个方向生长。 这段经历留下了一个新类型（TDE 作为操作实体）以及一个已记录的反模式（"stacked PR" 与压缩合并不兼容）。两者都是框架的素材，即使只有一个显示为版本号的变更。

下一篇文章是一段简短但具有结构性意义的经历："西班牙语审计提示词是那个离群值"（H-10）。一个 i18n 惯例细节，揭示了哪种语言一直是规范语言——以及为什么修复它在无意间改变了框架对翻译的理解方式。

锚点：Issue #128。PR #129 · #131 · #134 · #136。版本发布：fw-4.13.0 / cli-3.12.1 / fw-4.13.1。"Stacked PR" 教训已编入仓库 CLAUDE.md 第 181-220 行。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 拥有 schema 与针对 schema 进行验证，并非同一回事​

straymark validate 自 2026 年 3 月 25 日起就已存在 —— PR #27，CLI Phase 1 第一段弧线的组成部分。那时它所做的事情很小：验证 .straymark/ 中的文档具有有效的 Markdown 语法、可解析的 frontmatter，以及正确类型的最小字段集。它有用，但称不上执行。

2026 年 5 月 11 日，随着 fw-4.6.0 / cli-3.7.0 发布，改变的是别的东西：CLI 路线图的 Phase 2 关闭了七个 PR 组成的完整弧线（#73 到 #79），并将它们整合进一个 PR（#80）。CHANGELOG 直白地说明了这一点：

"自重新定位以来第一个承载功能的发布……Propuesta/devtrail-cli-roadmap.md 的 Phase 2 以 7 个 bisect-safe PR（#73–#79）落地，在此处汇总供审阅者参考。本次发布关闭了 Sentinel 实验打开的实证循环：Charter 关闭时的遥测、Charter 关闭时的漂移检测，以及针对 review_required: true 文档的正典批准信号。"

对于这篇文章而言，重要的不是七个 PR 作为各自里程碑的意义；而是其中三个触及 validate 命令和 schema 的 PR。3 月份的"我检查这看起来像一份文档"，到 5 月变成了"我检查这是否满足该类型的正典 schema，在你要求的模式下，附带具体的运行结果"。

2. 从手工 bash 到命令 flag​

这次变化中最显眼的部分很小：--staged flag。

在 Phase 2 之前，采用者在提交前验证文档的推荐方式是一个叫做 pre-commit-docs.sh 的 bash 脚本。它位于 dist/.straymark/scripts/，共有 464 行。它做了合理的事情：读取 git diff --cached --name-only，过滤 .straymark/ 中的文件，用 awk 解析它们的 frontmatter，检查字段。它能用。而且它是 464 行 bash，每个采用者都必须相信它执行了正确的事情、用正确的版本、用正确的 YAML 解析器。

3 月 28 日的一个 PR（commit d9ea874）用一个 flag 替换了这 464 行：

straymark validate --staged

同样地读取暂存文件，同样地按 .straymark/ 过滤，同样地进行验证。区别在于：今天所有这些都住在二进制文件内的 Rust 中，而不是磁盘上的 bash 里。采用者不必维护脚本；脚本不会在版本之间产生偏差；行为在 Linux、macOS 和 Windows 上完全一致。框架不再要求采用者信任一个松散的脚本，而是给了他们一个带有版本化二进制文件隐含承诺的命令。

这与第 6 篇文章记录的归档纪律模式相同（保留 git 历史而非重写），或第 4 篇文章记录的决策 A1 模式（无需调用 API 的编排）：从"操作者手动执行 X，存在偏差风险"转变为"框架将 X 正典化为一个声明式命令"。--staged 不是一个异域功能；它是被扫除的手工债务。

3. 三个 v0 schema​

Phase 2 也整合了位于 dist/.straymark/schemas/ 的三个 schema：

每个 schema 在其根部都带有一个 $comment 字段。charter.schema.v0.json 中的那个字面上写道：

"EXPERIMENTAL v0。从 Sentinel /plan-audit 结晶而来（6 个周期，格式 v1 → v2 → v3）。在第二个领域（前端、ML 流水线或基础设施即代码）验证之前，不会稳定至 v1.0。"

charter-telemetry.schema.v0.json 中的类似：

"EXPERIMENTAL v0。源自 Sentinel 中的 5 个 PLAN-NN.telemetry.yaml 文件（一个项目，Go 后端）—— 与 charter.schema.v0.json 相同的 N=1 领域警告。在第二个领域验证之前，不会稳定至 v1.0。"

audit-output.schema.v0.json 中的同理：

"EXPERIMENTAL v0.x。CLI 路线图的 Phase 3。从在 Sentinel 中实证验证的双重审计模式结晶而来。"

三者共享一个明确声明：不经过第二个领域，不进行结晶。这是框架原则 #12，不是以治理文档中的独立段落形式出现，而是直接写在 JSON Schema 内部，在任何标准验证器都会读取、任何 schema 浏览工具都会向用户呈现的字段中。框架不隐藏其 schema 的临时性质；它把这一点放在任何人都无法错过的地方。

这比看起来更重要。schema 生态系统（JSON Schema、OpenAPI、Avro）的惯常做法是发布 v1，然后随着变化升版。用 $comment 标注 v0 并声明"这是实验性的，直到第二个领域验证它"，是从一开始就承认第一次结晶并非最终结论。schema 本身是诚实的。

4. 命令的三种模式​

straymark validate 不再是一个只有单一流程的命令。Phase 2 之后，它拥有三种运行模式，每种模式都与生命周期中的一个时刻相耦合：

• all 模式（默认） —— 不带 flag 的 straymark validate。递归遍历 .straymark/，解析每个 .md 文件，尝试解析其类型（AILOG、AIDEC、ADR、ETH、REQ、TES、INC、TDE、MCARD、SBOM、SEC、DPIA、Charter），应用相应的 schema，并逐文件报告违规。这是完整审计模式。适用于 CI，适用于检查新的仓库，适用于采用者想衡量积累了多少形式债务的场景。

• --staged 模式 —— straymark validate --staged。替代 bash 的那个。仅验证 git diff --cached --name-only 报告为已暂存且位于 .straymark/ 内的文件。它的自然归宿是 .git/hooks/pre-commit，自 fw-4.6.0 起，straymark init --hooks 会自动安装它。这是运行门控模式 —— 防止损坏文档进入 main 的那个。

• --check-pending-reviews 模式 —— straymark validate --check-pending-reviews。三者中最微妙的，也是值得更多篇幅介绍的那个。

在 Phase 2 之前，智能体在 frontmatter 中标记为 review_required: true 的文档（低置信度的 AIDEC、高风险的 AILOG 等）会等待人工批准。但没有正典的方式来发出该批准信号。操作者阅读文档，在心里批准，继续前进。没有结构性的批准痕迹。这正是 Issue #67。

--check-pending-reviews 关闭了这个漏洞。该命令遍历所有带有 review_required: true 的文档，列出它们的 confidence、risk_level、作者（人类或智能体）以及日期。批准是一个将 review_required: true → review_required: false 的提交，提交信息中带有人类联合署名 —— 而 validate --check-pending-reviews 就会停止列出该文档。批准是一个正典信号，而非与自己的口头约定。

这是关闭智能体循环的部分。框架允许智能体在没有事先人工批准的情况下创建文档（第 1 篇，属性 #2："无阻断控制的文化许可"）；但在适当时候将其标记为待审；现在有了一个命令来列出待处理项，没有逃生舱口。没有审计文档会无声地丢失。

5. Phase 2 关闭实证循环​

完整的 CHANGELOG 句子值得保留，因为它凝练了本次发布的意义：

"本次发布关闭了 Sentinel 实验打开的实证循环：Charter 关闭时的遥测、Charter 关闭时的漂移检测，以及针对 review_required: true 文档的正典批准信号（解决 issue #67）。"

三个部分，关闭了一段始于六 Plan 实验（第 3 篇）的弧线：

1. Charter 关闭时的遥测 —— Sentinel 在实验中手工填写的 YAML 块，成为了可验证的 charter-telemetry.schema.v0.json。
2. Charter 关闭时的漂移检测 —— 145 行的 bash 脚本（check-plan-drift.sh）成为了 straymark charter drift 子命令，集成进验证流程。
3. 正典批准信号 —— 操作者在心里完成的事情，变成了一个具有结构性后果的命令：--check-pending-reviews。

这是博客中反复出现的模式：每次框架将 Sentinel 手工实践的内容结晶成命令，都是在实证验证该实践有效之后才进行的。这次的不同之处在于，验证该结晶的命令是包的一部分。Phase 2 之前，Sentinel 有模板、声明了 schema，以及文档遵循 schema 的隐含承诺。Phase 2 之后，有了一个检查的命令。这不是能力上的变化；这是保证上的变化。

6. 原则 #12，转化为 schema​

这篇文章的哲学部分 —— 也是我最想留存记录的部分 —— 是这样的：

三个 v0 schema 的 $comment 编码了框架自 4 月以来一直以散文形式声明的一个原则。第 4 篇将其命名为："schema 被有意标记为 v0 而非 v1，因为框架的原则 #12 规定，没有第二个领域的验证，schema 不会结晶。" 第 7 篇将其应用于 TDE 设计："框架再次验证了原则 #12：没有第二个领域，schema 不会结晶。" 第 10 篇将其应用于模式 1 和模式 2："文档毫不简化地说明：该模式在 Sentinel 中得到了实证验证。等待第二个领域，再进行更高层次的结晶。"

Phase 2 做了不同的事情。它不是声明原则；它把原则写进 schema 本身，写在任何 schema 消费者都会读到的地方。 $comment 不是营销语言；它是协议。任何 JSON Schema 2020-12 验证器都会暴露它；任何解析 schema 的 IDE 都会显示它。这是框架第一次将其形式化的临时性质本身也进行形式化。

如果要用一句话来总结：框架验证它所拥有的，知道它所拥有的是临时的，并将这一点以书面形式写在验证发生的地方。验证临时性是纪律。过早结晶并验证结晶物是神学。

7. 结语​

我从这个过程中得出的四条结论：

1. 拥有 schema 与针对 schema 进行验证，并非同一回事。 第一步是声明性的；第二步是运行性的。Phase 2 做的是第二步，而非第一步。两种框架模式之间的差异 —— "我有承诺" 与 "我有检查承诺的命令" —— 决定了采用者是否能信任所声明的内容。

2. "手工 bash → 命令 flag"的模式是结构性的。 --staged 不是一个孤立的功能。它是 Phase 2 版本的同一模式 —— 第 4 篇为外部审计周期记录了它，第 10 篇为 Charter 演化 CLI 辅助工具记录了它：冗长的命令式 → 可读的声明式 → 版本化。每次框架用一个 flag 扫除一个 bash 脚本，它就提升了一层保证。

3. --check-pending-reviews 关闭了智能体的循环。 第 1 篇命名为无需预先批准的文化许可，在这里得到完成：智能体可以创建，但标记为待审的文档不会丢失 —— 命令会列出它们，直到人类通过明确的提交批准它们为止。没有这个信号，第 1 篇的文化许可就会是疏忽。

4. 声明的临时性 > 过早的形式化。 v0 schema 的 $comment 将原则 #12 变成协议，而非教条。任何消费 schema 的工具都知道该形式化是临时的。这是一个年轻框架所能拥有的最强结构性诚实：验证你所拥有的，而不假装你所拥有的是最终定论。

锚点：PR #27 —— 原始 validate 版本（2026 年 3 月）。Phase 2：PR #73 至 #79 + PR #80 —— fw-4.6.0 / cli-3.7.0（合并于 2026-05-11）。Schemas：dist/.straymark/schemas/{charter,charter-telemetry,audit-output}.schema.v0.json。Issue #67 —— --check-pending-reviews 的起源。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 六小时看不见，五分钟看见了​

Issue #113 开头有这样一句话，事后回看显得既显而易见、又来之不易：

"检测耗时：约 6 小时的会话工作；从未被自主发现。一旦用户提示后解决耗时：约 5 分钟。"

六小时，一个能力强、专注的智能体，加载了框架完整的入门资料 —— STRAYMARK.md、项目章程、CLAUDE.md 清单、可用的 /straymark-* 技能、开始时运行了 /straymark-status —— 却在整整六小时里，从未主动建议使用 Charter。当我直接要求时，五分钟内流程就被纳入了。这种不对称不在于能力，而在于可见性。

这篇文章记录一段简短、具体的事件：Issue #113，于 2026 年 5 月 7 日开启，距 Charter 在框架中正式成为一等实体（fw-4.4.0，5 月 2 日）仅三天。它是本博客第一篇文章的天然对应。那篇文章命名了一切就位时涌现的属性；这篇文章记录了当一个结构性组件存在、但不在智能体首先读取的表面上时会发生什么。

2. 意外的实验​

这个设置并非刻意设计成实验。它是一个真实项目：用 Rust 从零开始构建的 CLI+TUI 套件，处于第一个 v0.1 版本。智能体是 Claude Opus 4.7，拥有 1M token 的上下文窗口，足以将整个仓库保留在上下文中而无需分页。流程是规范的 SpecKit 流程：/speckit-specify、/speckit-plan、/speckit-tasks，而在任务与实现之间，拆分为 Charter 的想法本应浮现 —— 理论上如此。

Issue 以近乎冷静的精确措辞表述如下：

"一个能力强、专注的智能体，遵循规范的项目入门资料（DEVTRAIL.md、项目章程、CLAUDE.md 清单、可用的 /devtrail-* 技能、/devtrail-status），在 plan/tasks 生成过程中，未能自主识别 Charter 作为工作流概念，尽管该项目明显符合其使用场景（多会话实现、多阶段任务、审计价值）。"

(该 Issue 仍使用 DEVTRAIL.md，因为按照时间线，更名为 StrayMark 的工作几乎是并行合并的。混合命名是日历上的残留，而非疏忽。)

该项目满足 Charter 作为正确单元的每一个条件：多会话实现、多个阶段、审计价值。智能体做了一切正确的事 —— 阅读了章程、运行了 status、识别了可用技能、生成了合理的 SpecKit 计划 —— 却始终没有关联到 Charter。仿佛这个概念根本不存在。对于智能体来说，在它对仓库的模型中，确实不存在。

关于这个 Issue，事后最令人不安的是：智能体并非因能力不足而失败。它失败，是因为框架在无意间构建了一张地图，而其中没有标注 Charter 的位置。

3. 九个差距汇聚为一​

当操作者（我）开启 Issue 并着手审计问题原因时，问题并非一个，而是九个。而所有这些都是同一个缺陷的不同版本：

九个失败，一个单一缺陷：Charter 以技术制品的形式存在（有效的 schema、可运行的命令、从 Sentinel 移植的模板），但在智能体入门时构建项目心智模型的任何位置，都没有被命名。

智能体读取 STRAYMARK.md 和章程来理解项目是什么。如果 Charter 不出现，它就不存在。智能体查看可用技能。如果没有 /straymark-charter-new，它就不存在。智能体运行 /straymark-status 来了解仓库中存在哪类文件。如果输出中没有提及 Charter，它们就不存在。智能体在入门过程中经过的每一个表面都重复着同样的沉默。而这些沉默的累积说服了智能体：这个概念不属于这个项目。

4. 为何这个事件超越了 Issue 本身​

值得在此停下来，因为这正是 fw-4.17.0 元模式 —— 涌现观察模式 —— 需要先发生才能被表述出来的事件。

#113 之后一周，在 EMERGENT-OBSERVATION-DESIGN.md 中，框架命名了两个属性，其组合能让智能体主动发现没有人要求它发现的事物：制品之间的正式链接（前置数据中的 originating_charter、originating_ailog、originating_spec），以及标记来源之间不一致的文化许可。这两个属性组合后，产生了智能体读取 AILOG、统计 R<N>(new, not in Charter) 条目、并在无人要求的情况下标记差异的效果。

但这一表述有一个前提条件：智能体在进入仓库时能看到 Charter。如果 Charter 不在可见表面上，制品之间任何正式链接都无法组合成涌现观察 —— 因为这个组合的其中一个项对智能体来说不存在。

Issue #113 是从反面记录这一前提条件的事件。fw-4.17.0 在该模式存在时命名了它；fw-4.12.0（五天前）填补了妨碍它存在的差距。没有 Issue #113 及其修正，这个元模式就没有立足之处。框架无法发现它看不见的，它也看不见表面没有命名的。

5. 回应：倍增表面​

PR #122（fw-4.12.0，5 月 9 日）以一个单一的操作策略关闭了九个差距：在智能体构建项目模型的每一个位置命名 Charter。PR 的数字是诚实的：+1211 行，−92 行，36 个文件被修改，几乎全是文档和模板。没有代码重构。有的是可见性的重新分配。

主要变更，按组归类：

• 在规范文档中（STRAYMARK.md）：新增专门介绍 Charter 作为概念的章节（§15），以及在列出文档类型但缺少 Charter 的 §6/9/10/11/13 表格中新增了相应行。
• 在智能体指令中（CLAUDE.md、GEMINI.md、copilot-instructions.md）：添加了明确的触发器，教导智能体何时建议使用 Charter，而不仅仅是在被要求时才创建。
• 在技能中：新增 /straymark-charter-new（Claude、Gemini、通用版本）。更新 /straymark-status 以列出活跃的 Charter。
• 在 CLI 中：向 straymark status 输出添加了 Charters 块，使运行该命令的智能体能在初始信号中看到它。
• 在模板中：移至专用子目录 dist/.straymark/templates/charter/，不再与其他模板混放。
• 新文档：SPECKIT-CHARTER-BRIDGE.md（171 行，EN/ES/zh-CN）。明确建立了 SpecKit 的 plan.md 与 StrayMark 的 Charter 之间的桥梁 —— SpecKit 功能产生一个或多个 Charter 的四个标准、三种不适用的情形、四个粒度启发式规则，以及 originating_spec ↔ originating_charter ↔ originating_ailog 前置数据链接。

SPECKIT-CHARTER-BRIDGE.md 的结语毫无隐喻地记录了引发整个变更的案例：

"引用了经验背景（issue #113）：Greenfield Rust CLI/TUI 套件，Claude Opus 4.7 通过规范入口点入门。Charter 最终被采用（2 个 Charter：基础 + MVP），但仅在用户明确提示后 —— 确认差距是系统性的，而非会话特有的。本文档消除了这一差距。"

差距是系统性的，而非会话特有的。 这句话是这个 Issue 的操作性教训。不是某天一个分心的智能体；是框架在智能体查看的每一个地方都没有向它讲述 Charter。

6. 关于结构性可见性的所学​

教训，以散文而非表格的形式书写：

在框架中创建一个制品，与使其对在该框架仓库中工作的智能体可见，并不是同一件事。它们是两个步骤。第一步 —— schema、命令、模板、示例 —— 是可见的步骤：它出现在 CHANGELOG 中，随版本发布，出现在 git log 里。第二步 —— 将制品锚定在智能体进入仓库时的每一个表面上 —— 是不可见的：第二步中没有任何内容本身作为功能出现；它是交叉引用、清单中的行、输出中的条目、文档中的章节。但第二步决定了第一步对智能体来说是否存在。

框架治理的是从制品创建所在的会话之外读取仓库的智能体。每个进入仓库的智能体都从头构建其心智模型，读取规范文档、可用技能、status 输出。如果制品在那里没有被命名，它就不存在于模型中。而没有该制品的模型不会建议使用它，不会审计其缺失，不会标记相关的不一致。如果仓库的表面在入门时没有给智能体正确的名词，智能体的技术能力就无关紧要了。

这就是我现在内部所称的结构性可见性。它不是智能体的属性。它是仓库的属性，进而是框架的责任：每当它将一个新概念具体化时，必须倍增命名该概念的表面。单一表面 —— schema、命令、模板 —— 是不够的。至少有九个，而它们正是 Issue #113 中的那九个。

7. 结语​

从这一过程中得到的收获，以四点陈述：

1. 作为制品存在与对智能体可见不是同一件事。 Charter 有 schema、命令、模板、示例 —— 却依然不可见。两种状态之间的差距，就是 Issue #113 的九个表面。

2. 六小时与五分钟。 一个能力强的智能体可以花数小时未能检测到某件事，而一旦被命名，整合只需数分钟。这种不对称不是在诊断智能体，而是在诊断仓库。

3. 结构性可见性是框架的责任。 当框架将一个概念具体化时，不以创建它的命令为终点。终点是该概念被命名在智能体构建仓库模型的每一个表面上：规范文档、指令、技能、status、模板、与其他框架的桥梁。

4. 没有结构性可见性，就没有涌现观察。 后来让智能体能够发现来源之间不一致的属性 —— 正式链接 + 文化许可 —— 作为前提条件，需要制品从入门的第一刻起就是可见的。Issue #113 记录了当这一前提条件缺失时会发生什么。

接下来，在下一篇文章中：一个与此相邻的事件 —— 更名为 StrayMark（H-08）。Issue #113 的解决与从 DevTrail 更名为 StrayMark 处于同一时间弧内，它们共享一件值得命名的事情 —— 一个框架向其智能体和其采用者清晰声明自身身份的责任。

锚点：Issue #113（开启于 2026-05-07）。PR #122 —— fw-4.12.0（合并于 2026-05-09）。PR 生成的文档：SPECKIT-CHARTER-BRIDGE.md。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 这次改名并非在寻找概念​

ADR 2026-05-08-001 以一句话开篇，对于读过本博客第 2 篇的人来说，这句话显得有些突兀：

"此决策的动因是对商标的法律确定性，而非产品战略或用户反馈。"

1 月份的三次改名（Chronicle → Monimen → DevTrail）是一场仓促的概念探寻。每一次都确认了一种关于产品本质的直觉，却没有任何一次写过 ADR——提交信息是当时存在的全部文档依据。

5 月份的第四次改名性质截然不同。它不是源于寻找概念，而是来自一次商标冲突调查——于 5 月初通过 Claude.ai 网页会话委托进行——调查结果揭示了 "随着项目获得使用者，商标归属存在法律不确定性"。1 月份项目尚无任何使用者，改名可以即兴而为。到了 5 月，项目已有一位使用者（Sentinel）、286 次 crate 下载、两个未解决的 Issue，以及一份公开承诺结构化治理的宣言。再度即兴更名的门槛已经越过。

本文涵盖三件事：5 月 8 日做出的有纪律的决策；翌日四十三分钟内五个 PR 的操作弧线；以及两天后浮现的残余问题。在这一切之下，还有一个更微妙的区分：当品牌迁移纯粹停留在表面时，与当它在无意间也改变了身份认同时，两者有何不同。

2. 第一次有纪律的改名​

5 月 8 日的新意在于形式。这一次：

• 有前期调查。 不是先决定改名再找理由，而是先发现冲突，再由此推出决策。
• 有公开的 ADR。 明确考量了三个备选方案：保留"DevTrail"并接受商标风险；采用遗留名称与新名称并行的混合品牌策略；以 StrayMark 为名、以"新项目"身份重置到 v0.1.0。三者均以明确论据驳回。
• 有时间成本测算。 ADR 本身这样量化代价："改名窗口随时间收窄——每增加一位使用者，日后更改的成本就增加一分……法律风险占主导地位。现在行动，只有一位自有使用者，在实质上比日后被迫行动要廉价得多。"

测算之所以重要，在于其结构性意义。若品牌迁移再推迟两个月——等到第二位、第三位使用者出现——迁移成本将成倍增长。每个使用者的仓库都需要执行 mv .devtrail .straymark，更新 CLAUDE.md/AGENT.md，重新生成流水线。而只有一位使用者（操作者本人）时，成本是可控且可逆的。ADR 所说的 "现在行动在实质上更廉价" 正是如此：这次品牌迁移是一次最小化未来技术债务的操作，而非一项市场营销决策。

这里与第 2 篇文章之间存在一个无意的呼应。那篇以 "大概不会再有另一次品牌迁移了" 收尾。这篇写于 5 月，知道它发生了。承诺与追认的区别在于：第四次改名不同于前三次，它是由外部环境所迫——商标冲突——任何操作者都无法预见，且以 1 月份所没有的纪律加以应对。

3. In scope，out of scope——ADR 的精妙之处​

这篇文章后续所有内容的骨架，正是 ADR 中区分哪些内容需要改名、哪些内容需要保留的那一节。原文引用如下：

"In scope（项目的'活跃状态'）：源代码中的所有标识符、Cargo 元数据、真实来源路径、30 个技能/工作流文件、公开文档、CI 工作流、GitHub 仓库名称。"

"Out of scope（不可变历史，逐字保留）：所有提交、提交信息和 git 历史；本 ADR 之前发布的所有标签；之前发布的所有版本标题和正文；所有先前的 CHANGELOG.md 章节。"

这一区分是整个品牌迁移的骨架。活跃的内容——路径、命令、URL、发布资产、README——一次性完成改名。历史性的内容——git log、devtrail-cli@3.10.0 标签、先前的 CHANGELOG 章节、已关闭的 Issue——按原样保留。项目不向后改写自己的历史。

这与第 3 篇文章为 Plan → Charter 改名所记录的档案纪律如出一辙，现在被应用于全框架范围的操作性品牌迁移。以表格呈现更为直观：

版本连续性是最显而易见的证明。下一个版本不是 0.1.0 或 1.0.0，而是 fw-4.11.0 和 cli-3.11.0。版本号无需任何比喻地宣告：这个项目依然是同一个项目。

4. 五个 PR，四十三分钟​

5 月 9 日，UTC 时间 06:05 至 06:48 之间，五个 PR 依次合并：

顺序是刻意为之，由外而内：先是法律依据（ADR），再是内部代码，然后是使用者所见（文档），接着是分发（CI），最后是既成事实（发布）。这一序列具有档案意义：六个月后有人按时间顺序回顾 git log，会先看到决策，再看到实施。因果关系就活在仓库里。

有一处值得特别记录，它打乱了原有计划。ADR 原本设想了九个独立的 PR（每个逻辑层一个）。实际执行时，CLI 测试依赖于硬编码路径——include_str!("../../dist/.devtrail/...")——在不同步更新测试的情况下修改路径，会让 CI 变红。计划压缩为五个，是因为各层在技术上耦合，而非因为概念纪律失败。PR #115 的备注毫不掩饰地记录了这一点："合并是被紧耦合强制的：测试通过 include_str! 使用 dist/.devtrail/ 路径。"

四十三分钟内完成了一次触及约两百六十个文件的品牌迁移。这样的速度之所以可能，是因为 ADR 在触碰代码之前已关闭了每一个决策。框架原则第 6 条——"当提案写得足够清晰时，实施就是执行，而非设计"——再次得到验证，与第 4 篇文章中外部审计循环的案例如出一辙。

5. 为何 StrayMark 改变的不只是名字​

到目前为止，ADR 的立场是明确的：品牌迁移停留在表面，概念身份得以保留。但有一个细节值得指出。

PR #120——在主弧线结束数小时后合并，同样是 5 月 9 日——在 README 中新增了"Why StrayMark?"一节。这不是代码，而是一份宣言。它说出了项目此前任何文档都未曾明确阐述的内容：

"代码不过是一场心智博弈留下的化石痕迹。真正的工程发生在决策的混沌之中，发生在经过测算的冒险之中，发生在那些你选择不走的路径之中。传统上，所有这些人类足迹都被当作项目历史中的 stray marks（意外涂抹的痕迹）而丢弃。在 Strange Days Tech，我们相信那些痕迹才是信号，而非噪音。"

从这份宣言的视角来看，名字的选择并非随意。那些 stray marks——不规则的痕迹、大多数项目丢弃的意外轨迹——正是框架着力呈现的内容：AIDEC、AILOG、TDE、Charter。在任何传统项目中都可被视为可丢弃噪音的东西，在这个项目中是审计的原材料。这个名字以 DevTrail 从未做到的方式，将产品论点具象化在了其中。DevTrail 是一条中性的路径；StrayMark 是一种主张。

宣言以三行话收尾，后来成为编辑意义上的操作性 tagline：

"Capture the noise. Weave the signal. Humanize the machine."

这里有品牌迁移的一个小小的有趣张力。ADR 说只有表面改变了；同一天的宣言则表明，身份认同也被阐明了——或许是第一次清晰地阐明。这并不矛盾：操作性品牌迁移的时机被用来写下项目中早已存在、却尚未被命名的东西。身份没有改变，它变得可读了。

6. 留下的未竟之事​

即便有公开的 ADR 和有纪律的操作弧线，"完成" 依然是一个近似值。

品牌迁移两天后，当 Sentinel 正在准备其下一轮外部审计时，智能体发现了三类残余问题。这段时间线——在 CHANGELOG.md 中以内联勘误的形式诚实记录——值得公开呈现：

• PR #137（5 月 11 日，22:55）——孤立的技能目录。品牌迁移改写了每个 SKILL.md 内部的 name: 字段，但未重命名三个平台的技能目录（.gemini/skills/devtrail-*、.claude/skills/devtrail-*、.agent/workflows/devtrail-*.md）。三十个孤立产物：名称已新，路径仍旧。Gemini CLI 在启动时报告了十条冲突警告。
• PR #138（5 月 11 日，23:32）——遗留 Charter 路径。三个框架产物在 fw-4.12.0 已将规范路径迁移至 .straymark/charters/ 之后，仍引用 docs/charters/。最糟糕的是：pre-pr.sh 钩子以 [ ! -d docs/charters ] 作为门控条件，导致任何 4.12.0 之后的使用者都会静默 exit 0。这个漂移检查已安装七个月，却一直是空操作。
• PR #139（5 月 12 日，12:02）——安装脚本失效。install.sh 和 install.ps1 仍指向 REPO=StrangeDaysTech/devtrail、BINARY=devtrail、资产名 devtrail-cli-v*。README 已完成品牌迁移并指向新 URL。结果：任何用户从 5 月 9 日起复制 README 命令，运行安装脚本时都会遭遇 GitHub 404。产品在生产环境中宕机了七十二小时。
• PR #140（5 月 12 日，16:49）——微小残余。.gitignore 第一行仍写着 # DevTrail - .gitignore。另外在内部开发模式中新增了 Aparador/ 条目。

教训不在于纪律不足，而在于纪律不能阻止残余——它让残余变得可发现、可记录、可在公开内联勘误中修复。前三次改名（1 月份）大概也有同等程度的残余；我们从未整理它们，因为那时还没有文档记录的习惯。第四次品牌迁移整理了它们。这是项目第一次在公开仓库和 CHANGELOG 本身中承认，操作者没有在第一遍就发现所有问题。

最令人不安的细节——安装脚本宕机七十二小时——是我最想记录的。如果彼时不是一位独自使用的采用者（操作者本人），而是一个团队，那个窗口期将真实地伤害用户。现在行动，只有一位自有使用者，在实质上更廉价，ADR 如此说。这句话买到的正是：有权在七十二小时内犯错，而不伤及任何人。

7. 结语​

从这一过程中，我得出四点结论：

1. 并非所有改名都属于同一类型。 1 月份的三次是在寻找概念；5 月份的那次是在抵御项目未来的法律债务。只有 5 月份的那次能够借助公开 ADR 来完成，因为只有它诞生于外部证据，而非内部直觉。

2. 表面与身份的区分属于文档，而非修辞。 ADR 本身宣告了哪些内容被改名、哪些内容被保留。那份清单——路径是的、git log 否；版本标题是的、先前标签否——是品牌迁移的骨架。没有这份明确的清单，"品牌迁移" 可以意味着任何你想要的东西。

3. 身份可以在不改变的情况下变得可读。 "Why StrayMark?" 宣言没有发明项目原本是什么；它第一次清晰地将其阐明。操作性品牌迁移被用来写下那些已经在代码中存在、却尚未进入 README 的内容。身份没有被重写——它被发布了。

4. 纪律不能阻止残余；它让残余变得可发现。 两天后的四个勘误 PR 不是品牌迁移的失败；它们是证据，证明这次品牌迁移足够诚实，承认了漏网之鱼。1 月份的三次改名大概也有同等情况；它们从未被记录。

下一篇文章，将涉及一个与最后这点直接相关的情节：TDE 作为命名横切面技术债务的机制（H-09）。这是框架用来阐明如何暴露债务的第一个真实案例——并且留下了一个关于 PR 堆叠的惨痛教训，等到谈及那里时，值得专门用一段来讲述。

参考锚点：ADR 2026-05-08-001。核心弧线：PR #114 · #115 · #116 · #117 · #118。宣言：PR #120。残余修复：PR #137 · #138 · #139 · #140。版本：fw-4.11.0 / cli-3.11.0。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

1. 当纪律开始变成仪式​

4 月末，Sentinel 以一种写出来略显狼狈的感受关闭了当月第四个 Charter：外部审计是有效的——Copilot 9.25，Gemini 9.5，漂移脚本零误报——但每次关闭都要我手动打开三个文件，把三段 prompt 复制进三个不同的窗口，等待回复，再把三份标定 YAML 粘回遥测文件，然后逐一核对哈希值以确认匹配。每个 Charter 在两小时正式工作之外还要 40 分钟的复制粘贴。纪律在起作用；仪式却变成了问题。

5 月 3 日撰写的 audit-skills-design.md 提案毫不掩饰地点明了这一点：

"如果每次关闭时操作员都必须在文件间手动搬运数据，吞吐量将会崩溃，纪律也将从有益的摩擦变成纯粹的仪式。凡是可以可逆地自动化的，都应当自动化；文档保留用于事后人工审计。"

本文涵盖三天——从 2026 年 5 月 2 日到 6 日——期间两条并行主线同时收尾。其一：Charter 从手工实践变成了 CLI 的一等实体。其二：外部审计周期从使用临时 prompt 的手工仪式变成了一条正式命令（背后有一个反直觉的架构决策，值得单独成节）。

2. Sentinel 已经在做的，与 StrayMark 尚未拥有的​

5 月 3 日的提案用一句话点明了当时的状况，措辞算不上优雅，却精准：

"Sentinel 有这些技能，StrayMark 没有。"

Sentinel 已有的：sentinel/.claude/skills/plan-audit/ 和 plan-audit-review/——本地技能，能生成 prompt，收到回复后自动标定，并合并到遥测文件中。它们可用，已经过六个周期的验证。但它们耦合了 Sentinel 特有的路径（docs/plans/、internal/modules/、go vet）以及 "Plan" 词汇——而这个词汇在一周前刚刚被重命名为 Charter。

StrayMark 尚未拥有的：没有任何等价物。截至 4 月，框架只有文档 + 技能 + 带 init、update、remove 的 CLI。在 Sentinel 中称为 Plan 的单元——预先声明、事后审计的有界工作单元——作为 CLI 工件并不存在，只以实践的形式存在。

fw-4.4.0（5 月 2 日）以及 fw-4.7 → 4.9（5 月 3-5 日）的演进弧线，几乎是逐字地将 Sentinel 的手工做法移植成任何框架使用者都可以调用的通用命令。从 cli-roadmap.md 摘抄的迁移对照表直白地说明了来源：

fw-4.4.0 的 CHANGELOG 直白表述："将 Charter 模式固化——预先声明、事后验证的有界可审计工作单元——该模式源自 Sentinel 六周期 /plan-audit 实验。" 固化才是关键。4 月还是配了 bash 脚本的定制做法，5 月已是带可验证 schema 的正式命令。

3. 成为"一等实体"意味着什么​

PR #65（fw-4.4.0 / cli-3.6.0，5 月 2 日）做了三件具体的事：

• 创建 straymark charter new 命令。自动递增编号（NN-slug.md），预填来源（若源自已有 AILOG 则填 originating_ailogs；若源自 SpecKit plan.md 则填 originating_spec），并支持 --type X|S|M|L 标志以在第一时间确定规模。
• 引入 charter-template.md，移植自 Sentinel 的 TEMPLATE.md v3。模板内嵌了 4 月实验逐周期固化的六项规范：本地/生产检查分离、以时间而非故事点计量投入、结构化子章节、R<N> 风险记录、通过 AILOG 的合并后协调进行闭环、以及自动核查清单漂移。
• 随附 dist/.straymark/schemas/charter.schema.v0.json——schema 刻意标注为 v0 而非 v1，因为框架原则 #12 规定：未经第二个领域验证的 schema 不得固化。Sentinel 是一个领域，第二个尚缺。

PR #68（5 月 3 日）看似动作小，却举足轻重：原子 Charter 关闭模式，格式 v4。在 Sentinel 中，"若 AILOG 记录了偏差，则在合并后更新 Plan 文档" 这一步骤在 TEMPLATE 中仅作为备注存在，没有系统性触发机制。实践中，每当声明内容与交付结果存在偏差，操作员（我本人）要靠记忆来协调文档——而记忆会失效。偏差会在仓库中停留数天乃至数周，直到下一个周期才被发现。格式 v4 将协调变成关闭的强制步骤，而非边注。

PR #69（同日）解决了一个摩擦细节：手动编号。此前需要自行判断下一个 Charter 是 11 还是 12；现在 straymark charter new 读取目录并提议下一个编号。纯粹的用户体验改进。但这类摩擦累积到二十个 Charter 时，决定的是框架被使用还是被抛弃。

三个 PR 在同一个周日和周一的提交潮中发布。这种节奏是刻意为之：一旦模式固化，用户体验细节必须一起关闭，而不是分散在几个 bump 中，让使用者拿到半成品流程。

4. 一天三个版本​

随后的 fw-4.7.0、fw-4.8.0、fw-4.9.0 是外部审计周期的连续版本。audit-skills-rollout.md 提案如实记录了这一节奏：

"第一阶段在 1 个日历日内完成（2026 年 5 月 3 日连续 5 个 PR），远快于 1.5-2 周的重点估算。吞吐量来自 audit-skills-design.md 中决策已提前固化（D1/D2/D3），以及带有明确优雅降级的 arborist 启发式——实施期间无待定决策。这为原则 #6 提供了额外的操作验证：提案写得好，实施就是执行，而非设计。"

具体的外部审计周期由三条链式命令组成：

1. straymark charter audit prepare <CHARTER-NN> ——从已关闭的 Charter、其关联的 AILOG 以及被修改文件的 diff 生成规范审计 prompt。输出：audit/<CHARTER-NN>/{copilot,gemini,claude}.prompt.md 中的三个 .prompt.md 文件。
2. （人工将这些 prompt 带到所选审计工具，收到回复后粘贴回来。）
3. straymark charter audit collect <CHARTER-NN> ——接收回复，对照审计 schema 逐一验证，将标定值合并进 Charter 的遥测文件，并输出审计员之间收敛（或发散）的摘要。

提案中的决策 D1 是整个体系的基础：

"技能通过 Bash(straymark charter audit *) 委托给正式实现。模板只存放在 dist/.straymark/audit-prompts/ 中。技能与 CLI 之间零漂移可能。"

prompt 只有一个存放位置，流程只有一个实现，技能（Claude、Cursor）通过 Bash 调用它。这是朴素的模式——CLI 是唯一来源——却避免了任何拥有两个接口（技能 + CLI）的框架最终都会出现的顽疾：技能和 CLI 因各自独立更新而说出不同的话。

5. 为什么 CLI 只做编排而不调用 API​

这是 5 月最奇特的决策，也是我花费最多精力作出的决策。它在 cli-roadmap.md §0 中被字面记录为 "架构决策 A1"：

"A1（第三阶段）：仅编排，v0 中不含 HTTP API 客户端。路线图 §5.4 原本建议'v0 支持 OpenAI/Google/Anthropic'并处理 API 密钥。实际实现是：CLI 准备 prompt，对照 schema 验证输出，并与遥测集成——但不调用 API。操作员手动将 prompt 粘贴到所选审计工具。"

其理由，同样字面呈现：

"实现 3 个 HTTP 客户端需要 1-2 周加上 API 变更时的持续维护（对于实验性 v0 而言过于超前）；人在回路的模式与 Sentinel 的 /plan-audit 一致；符合原则 #10（'不是 LLM 网关'）；在设计上关闭了 RFC #82。HTTP 客户端推迟到 v1，届时真实使用者以数据证明其必要性。"

三个论点，各有分量。

第一个是务实层面的。 三个 HTTP 客户端——OpenAI、Anthropic、Google——需要一到两周的实现工作，加上每当三方之一有所变更时的持续维护。对于一条手工形式在 Sentinel 中已有经验验证的命令来说，这是荒谬的成本。这是为一个没有任何使用者提出的问题而做的工程。

第二个关乎延续性。 Sentinel 在 4 月验证的，恰恰是人在回路模式：操作员手动将 prompt 粘贴进 Copilot/Gemini/Claude，阅读回复，再粘回来。那个诞生了整条演进弧线的六个 Plan 实验从未调用过 API。如果 CLI 现在自行调用 API，就是用一个未经验证的模式取代一个已经验证的模式，毫无经验依据。

第三个关乎身份。 StrayMark 不是 LLM 网关。框架原则 #10 明确说明了这一点。LangChain、LiteLLM、LiteLLM Proxy、OpenRouter，以及各类包装器——有数十个产品是这个定位——它们对自身所做的事情是有用的。StrayMark 做的是另一件事：它围绕使用这些模型所完成的工作构建纪律，无论是哪个模型。CLI 是否调用 API 改变的是框架是什么；保持仅编排的定位，使身份保持清晰。

这段话中我最在意的部分："HTTP 客户端推迟到 v1，届时真实使用者以数据证明其必要性。" 这个决策不是被教条关闭的，而是被设置在一个证据门槛之后延后处理的。如果六个月后某个使用者证明人在回路流程破坏了他们的吞吐量，HTTP 客户端就会落地。在那之前，手动将 prompt 粘贴到另一个窗口所需的四十秒摩擦，与维护三个活跃 SDK 的成本相比，微不足道。

6. 框架决定不自动化什么​

值得用同一决策的另一面来收尾。audit-skills-design.md 提案写道：

"凡是可以可逆地自动化的，都应当自动化；文档保留用于事后人工审计。"

前半句解释了 5 月的三个版本：prompt 自动生成，标定值自动合并，漂移自动检测。后半句——"文档保留用于事后人工审计"——解释了哪些内容是刻意保留为手工的。

框架不自动化的内容：

• 操作员在关闭 Charter 前阅读 AILOG。 straymark charter audit prepare 命令会生成 prompt，但操作员必须自行打开 AILOG 并阅读。如果我们将这一步自动化——由智能体来阅读、总结、决策——就会失去那个使 Charter 存在有意义的人类判断时刻。
• 接受或拒绝外部审计的决策。 CLI 将标定值合并进遥测文件，但不对其采取行动。如果某位审计员给 Charter 打了 4 分，Charter 不会自动重新开启：操作员决定是重新开启、提出异议，还是声明其为可接受的已知债务。这个决策就是纪律；将其自动化会摧毁纪律。
• 调用模型。 如上所述：操作员复制 prompt 的暂停时刻，正是他们决定使用哪个模型、调整哪段 prompt、判断问题措辞是否合理的时刻。那个暂停是功能，不是缺陷。

贯穿三者的标准只有一个：自动化可逆的、机械的；将需要判断的保留为手工。四十秒的复制粘贴并不算多，如果换来的是让判断留在人手中。

7. 结语​

我从这个过程中得到的四点结论：

1. 经验验证有效的实践无需重新发明即可被正式化。 Sentinel 在 4 月完成了验证工作；5 月只是将其移植进框架。固化是迁移，不是从零设计。

2. 提案写得好，实施就是执行。 一天三个版本只有在所有决策都在触碰代码之前关闭的情况下才有可能。原则 #6 的表述更为平实，但这就是它的含义。

3. 并非所有可以自动化的都应该自动化。 决策 A1——CLI 做编排但不调用 API——是一个哲学决策的技术表达：人在回路不是需要消除的遗留做法，而是支撑纪律的功能特性。

4. 框架的身份由它做什么和它不做什么共同定义。 "不是 LLM 网关" 是框架原则 #10 中少数几句值得逐字记住的话之一。StrayMark 之所以把自己做的事情做好，恰恰是因为有许多事情它拒绝去做。

下一篇文章：与本博客起点直接相连的方法论事件——Issue #113：智能体看不见的 Charter——框架在此发现，创建命令和 schema 还不够，如果仓库的接触面不能向智能体表达自身。这是本文的自然对立面：这里我们谈的是什么被正式化了；那里我们谈的是什么没有被看见。

锚点：PR #65 · #68 · #69（Charter 一等实体）。提案 audit-skills-design.md · audit-skills-rollout.md · audit-cli-flow.md · cli-roadmap.md（决策 A1 §0）。版本 fw-4.4.0 → fw-4.9.0。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

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，四种不同规模：三个 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 的明确设计目标是打破该论题，而非捍卫它。文档第一行写道：

"本文档将用数据检验这一论题。它不是为了捍卫它，而是试图打破它。目标是：一位不认同该论题的读者，只需阅读本文，就能判断现有证据是支持、修正还是反驳它。"

将论题的六个假设与证据对照后，最终结论如下：

三个假设完全验证，两个部分验证，一个无证据，零个被反驳。关于非二元审批的假设未经测试，因为 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 更像是带有架构骨架的 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. 结语​

从这个过程中，我提炼出四点：

1. 实验的设计目标是打破，而非确认。 "它不是为了捍卫，而是试图打破" —— 这字面上就是验证论题的文档的职责定义。任何值得尊重的技术博客都必须能承受这种框架。

2. 六个设计中的 Plan，四天内执行了五个。 那个未能执行的（规模最大，包含七个功能的路线图）偶然间成为了工作单元能承载多大规模的第一条证据。今天的 Charter 是通过合约约定有边界的；在 4 月，边界是偶然形成的。

3. 格式在实验内部自我演进：从习惯，到模板，到脚本。 五个 Plan 产生了三个版本的格式。v1 → v2 → v3 的曲线，是任何有效标准化的曲线——只是被压缩了。

4. 更名源于务实，而非营销。历史保存源于原则。 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）的协助下撰写；内容的全部责任由人类作者承担。

1. 两周后揭露异常值的工具​

本博客 Post 8 记录了一个具体事件：发现了框架中唯一一个正典语言为西班牙语的文件。操作者并非通过系统性检查找到它；而是在审计准备过程中运行了 straymark explore --lang es，在视觉上注意到有一个模板相对其他文件是反向书写的。那篇文章中有这样一句话：

"框架的一个新界面（TUI）将所有文件同时呈现，不一致之处变得显而易见——就像整理书架时，突然发现有一本书脊背朝外。"

本文介绍的就是这个工具。straymark explore 这个 TUI 几乎在它所揭露的发现之前三周就已诞生——于 2026 年 4 月 25 日随 cli-3.4.0 发布——并在此后四个版本中逐步完善，所有版本均在 48 小时内完成。这不是一篇关于代码的文章。它是关于一件具体工具的文章，印证了博客此前已命名的一个论点：新工具会在无意之间制造出可见性。

2. 为什么在 Markdown 框架里构建 TUI​

到 2026 年 4 月下旬，框架已经拥有约五十个受治理的 Markdown 文件——PRINCIPLES.md、AGENT-RULES.md、DOCUMENTATION-POLICY.md、QUICK-REFERENCE.md、SPECKIT-CHARTER-BRIDGE.md，加上 dist/.straymark/templates/ 中的模板、审计提示，以及每个文件的三语版本（i18n/es/、i18n/zh-CN/）。它们都在磁盘上，都可以用 find 和 cat 浏览，完全可访问。

但同时，也完全不可见。对于第一次克隆框架的使用者，第一个问题不是"规则 N 在哪里？"，而是"这里有什么？"。递归 ls 无法回答这个问题——它只会让人不知所措。grep 需要知道要搜索什么。编辑器一次只打开一个文件。框架已经达到了这样的规模：它自身的表面已经变得不透明。

straymark explore 正是为了解决这个问题而诞生的：一个可导航界面，能在三秒内回答"这里有什么？"。它不是 IDE，不是 Read-the-Docs 式系统，也不是静态网站。它是一个 TUI——终端用户界面——运行在使用者的仓库上，对框架的正典文件建立索引，按类别分组展示，并在终端内使用带颜色的 Markdown 查看器让你阅读文件。

构建 TUI 而非 Web 应用的决定，与博客此前论述的两点相符。第一，Post 4 的原则 #10——"StrayMark 不是 LLM 网关"——可以推广为"StrayMark 不是任何已经做了某件事的东西"。我们不与 MkDocs 或 Material for MkDocs 竞争。第二，同一 Post 4 中的 A1 决策：纯编排。TUI 不需要服务器，不需要构建步骤，不需要网络连接：它运行在框架已经存在的使用者仓库上。这是能解决问题的最朴素的一块拼图。

3. cli-3.4.0 落地的内容​

4 月 25 日的 PR #57，以 cli-3.4.0 合并，做了三件具体的事：

• 引入了 straymark explore 命令。当终端宽度达到 100 列或以上时，采用双面板布局：左侧导航（30%），右侧文档（70%）。较窄的终端折叠为单面板。底部状态栏显示相关快捷键。
• 将框架的正典文件索引为可导航的层级结构：治理文档（AGENT-RULES.md、DOCUMENTATION-POLICY.md 等）、模板（dist/.straymark/templates/）、审计提示，以及使用者目录（docs/charters/、.straymark/07-ai-audit/ 等）。每个节点可用 Enter 展开。
• 接入了 i18n 解析器。--lang <code> 选项允许运行 straymark explore --lang es，并在翻译存在时获取西班牙语的所有治理文档。若无翻译，则静默回退到正典英文。提交的字面描述：

"通过 explore TUI 贯通 language 配置和新的 --lang 标志，当翻译存在时从 i18n/<lang>/ 提供框架治理文档，否则静默回退到英文。"

i18n 解析器部分比 TUI 本身更重要。在 cli-3.4.0 之前，辅助函数 resolve_localized_path 仅由 straymark new 使用（用于解析应以何种语言将模板注入使用者）。PR #57 将其提取到 cli/src/utils.rs:146 作为共享辅助函数，使得**i18n/<lang>/ 覆盖层解析方式的单一定义**同时支撑 new 命令和 explore 命令。对使用者而言，行为保持可预期：如果你将某个模板翻译到 i18n/es/，TUI 展示它的方式与生成时使用它的方式一致。没有意外。

Markdown 渲染使用 pulldown-cmark 作为解析器，ratatui 组件负责绘制。语法着色、带边框的代码块、圆角边框的表格、按层级缩进的标题。不炫目，但可读性好。

4. 三十六小时内的四次精炼​

4 月 25 日至 27 日之间发生的事，正是 Post 9 几个月后命名为流程属性的东西：当提案写得清晰，实现就是执行。四个 PR，在 36 小时内完成，将 TUI 从"能用"带到"做完"：

这段弧线的速度重复了同一模式。Post 6 中记录的 fw-4.11.0 的五个 PR（品牌更名为 StrayMark）在四十三分钟内完成。Post 4 中记录的三个审计周期版本在一天内完成。TUI 的曲线类似：设计在 PR #57 中已确定，而精炼则是在操作者开始频繁使用该命令并注意到摩擦点时出现的。

值得记录的轶事是 cli-3.5.2：它移除的 l 和 h 键是 vim 别名——操作者在编辑器中靠肌肉记忆使用它们。但当大写 L 语言切换器几小时前落地时，小写 l 和大写 L 共享同一物理键，视觉上的过渡令人困惑。修复方法是移除未记录的别名：完整字母拼写（j/k/g/G）保留；复制功能的缩写消失。这是一个小的 UX 细节，说明 TUI 决策是针对真实使用调整的，而非 UX 理论。

5. TUI 两周后揭露的内容​

此处，文章从另一端接续了 Post 8 的线索。cli-3.4.0 给框架增加的不仅仅是一个导航命令；它是一个同时可视化的界面。也就是说：在 TUI 出现之前，框架的文件存在，但只能逐一阅读。有了 TUI 之后，它们可以被一次性看到，分组、标记，以相同的呈现模式。

这改变了操作者能注意到的事情。

5 月 12 日，cli-3.4.0 合并两周半后，操作者在外部审计周期前运行了 straymark explore --lang es。他们打开了"审计提示"组，发现了一件存在已久的事：根目录下的 audit-prompt.md 是用西班牙语写的，而其他所有正典框架文件都以英文作为根目录版本，以 i18n/es/ 覆盖层作为西班牙语版本。一个文件，相对于约定是反向的。

这个细节不是通过系统性审查发现的。它是通过视觉对比发现的。这正是 Post 8 第 3 节编纂为论点的内容：

"新工具制造可见性。"

TUI 没有造成这个异常值——它自第一次将 Sentinel 技能 plan-audit 移植到正典框架的提交以来就存在（Post 3 对此有记录）。TUI 也没有寻找异常值；它不是一个不一致性检测工具。它所做的只是把每个文件放在同一屏幕上，以相同的呈现模式，让人眼注意到从一开始就存在的东西。值得记录的结论是结构性的：任何超过五十个正典文件的框架都需要一个同时可视化的界面，不是因为这个界面本身在教学上重要，而是因为没有它，仓库的某些规律性就变得无法观察。

6. 值得记录的细小技术决策​

三个值得记录的 TUI 设计细节，均与博客已命名的框架原则相符：

特性标志 tui。 CLI 的 Cargo.toml 将 TUI 声明为可选依赖（ratatui + crossterm + pulldown-cmark 置于默认启用的 tui 标志之后）。只需要 init、update、validate 的使用者可以通过 cargo build --no-default-features 构建不含 TUI 的二进制文件。这关闭了一个在框架中反复出现的子架构决策：默认给使用者提供价值，但当 TUI 对其流程毫无意义时，让他们可以选择更轻量的二进制文件。

文档懒加载。 DocIndex 维护一个 HashMap<PathBuf, Document>，它在每个节点被打开时才填充，而非在启动时。对于拥有一百个治理文件的仓库，这意味着 straymark explore 在 200ms 内启动，只在操作者按下 Enter 时才读取磁盘。这个决策在技术上微不足道；真正不微不足道的是它是有意识做出的。TUI 不与 IDE 竞争；它与 cat 竞争。它必须感觉同样即时。

超链接的历史栈。 当一个框架文档提及另一个（例如 AGENT-RULES.md §3 引用 DOCUMENTATION-POLICY.md §6），TUI 允许你通过点击跳转到被引用的文档，并用 Esc 返回。内部有一个导航栈，可以恢复之前文档的滚动位置。这一功能将阅读框架从"我打开一个文件，关闭它，再打开另一个"变成了"我在文档之间跟随一场对话而不失去线索"。框架今天所拥有的交叉引用数量——原则、智能体规则、模式、模板之间——使这种导航在结构上重要，而不只是装饰性的。

7. 结语​

从这个过程中，我得出了四个结论：

1. 超过一定规模的框架需要一个同时可视化的界面。 这不是人体工学问题；这是仓库某些规律性得以被观察的条件。Post 8 记录了后果；本文记录了工具。

2. TUI 不会造成发现；它使发现成为可能。 审计提示异常值自上一年 5 月就已存在。4 月唯一改变的是，一个屏幕出现了，在那里它可以与同类文件一起被看到。工具对内容没有意见；它改变的是人眼能注意到规律性的条件。

3. 当设计清晰时，实现是小时，而非冲刺。 三十六小时内的五个 PR——语言感知、实时切换器、OS 检测、面板 i18n、快捷键清理——之所以可能，是因为设计在 PR #57 中已关闭。这与 Post 4、6 和 9 是同一模式。

4. 最有趣的技术决策可以是一个编译时标志。 tui 特性标志明确声明 TUI 是可选的，框架在没有它的情况下仍然可以工作，使用者可以自行决定。这种架构上的谦逊，是一个假设使用者工作方式的 CLI 与一个在能发挥作用的地方提供自身的 CLI 之间的区别。

本文使本博客覆盖了第一批留为明确技术债的 H-14 里程碑。PLAN-INVESTIGACION.md §1.43-55 中记录的其余候选里程碑——AGENTS.md 通用注入、完整 EN/ES/zh-CN i18n 覆盖、straymark validate 作为正式层、CLA 助手——仍可作为未来批次的主题。没有承诺的节奏，但已记录在案。

锚点：PR #57 — cli-3.4.0（语言感知 explore，2026 年 4 月 25 日）。PR #60 · #61 · #62 · #63 — 精炼版本 cli-3.5.0 至 cli-3.5.2（2026 年 4 月 25-26 日）。代码：cli/src/tui/（15 个文件）。使用者文档：docs/adopters/CLI-REFERENCE.md §straymark explore。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。

编者按：这是本博客第一篇以追溯方式发布的文章。frontmatter 中的 date 对应的是文章所叙述的时间弧线中的某一时刻，而非实际撰写当天。整个博客都以这种方式构建——从后往前，从触发我提笔的那个事件开始（emergent-observation-design，2026 年 5 月 16 日）。假装情况不是这样，对任何人都没有帮助。

1. 第二天​

2026 年 1 月 28 日 17:29（中部时间），这条 commit 落入了仓库：

chore: rebrand Chronicle to Monimen

仅仅一天。确切地说，是项目初始 commit 后的二十九小时。框架刚刚存在，就已经在改名了。

我用过去时态来叙述，但这件事发生在三个月前。而在三个月前，又经历了两次改名之后，它依然还不叫 StrayMark。这个今天以面向 AI 辅助软件开发的文档治理框架自居的项目，有着一段简短、凌乱的早期历史，值得在继续前行之前把它说清楚。

2. 五个事件，四个月​

三天内三次改名。然后是长达一个月的停顿。然后是捆绑 Rust CLI 的组织品牌迁移。再然后又是两个月的停顿。最后是 StrayMark，这次有一份公开的 ADR 作为决策的锚点。

有一个细节值得注意：2026 年 1 月 28 日的 commit（Chronicle → Monimen）没有标注 BREAKING CHANGE；而 1 月 29 日的那次（Monimen → DevTrail）标注了。commit 正文写道："BREAKING CHANGE: Complete rebrand from Monimen to DevTrail"。差别虽小，却说明问题：第二次改名显得更具决定性。它确实如此——坚持了整整两个月。

3. 不曾移动的东西​

这是我最感兴趣的一节。项目在四个月内四次改名；理念却纹丝未动。

初始 commit 的 README —— 也就是项目还叫 Enigmora Chronicle Framework 时仓库里的那份 —— 以这行字开头：

Documentation Governance for AI-Assisted Software Development

这也是今天 StrayMark README 的第一行。四个名字，一句标语。

稍往下，同一份 v1.0.0 README 在一个引用块中明确陈述了项目的核心主张：

"No significant change without a documented trace."

这句话今天是框架的第一原则。它存在于 PRINCIPLES.md §1 — Total Traceability 中。翻译成西班牙语时措辞略有调整，但主张的分量完整保留：没有文档记录的重大变更，就不应发生。

v1.0.0 README 列出的八种文档类型 —— REQ、ADR、TES、INC、TDE、AILOG、AIDEC、ETH —— 全部留存至今。后来新增了一些（MCARD、SBOM、SEC、DPIA），但没有一个取代了原有的类型。一月份的分类体系经受住了时间的考验。

名字动了四次；理念没有动。 那四个月里改变的不是内容，而是贴在它上面的标签。

4. 年份打错的 AIDEC​

有一个小细节，我总是会回想起来。

项目的第一份结构化文档 —— 第一份 AIDEC，即框架自身分类体系中用于记录借助智能体协助所做决策的文档 —— 是 AIDEC-2025-01-27-001-i18n-strategy.md。它存在于 commit 7b7193e，添加于 2026 年 1 月 27 日 18:01，也就是初始 commit 后六小时。

ID 写的是 2025。commit 日期是 2026。

正是这份确立了 [TYPE]-[YYYY-MM-DD]-[NNN] 标识符规范的文档，在自己的年份上打了个错字。框架从不完美中起步，没有人及时修正它。任何克隆仓库后仔细查看这个 ID 的人都会注意到 —— 同时也会看到引入它的 commit 日期是正确的。这是我掌握的最好证据，证明审计纪律是后来才会养成的东西，并不会随仓库一起交付。

但比这个错字更有意思的，是那份 AIDEC 做出的决策。2026 年 1 月，José 借助 Claude Opus 4.5 的帮助提出了这个问题：如何对一个为人类而存在、但配置文件由智能体读取的框架进行国际化？该 AIDEC 的论证部分给出了答案：

"AI agents (Claude, Gemini, Copilot, Cursor) process instructions equally well in any language, so translating their config files provides no functional benefit."

那份文档做出的决策 —— 翻译人类阅读的内容（文档、模板），保留智能体读取的内容（CLAUDE.md、GEMINI.md、.cursorrules）为英文 —— 是一个早期直觉：框架有两类截然不同的受众。这个博客本身今天也印证了这一直觉：面向阅读的人类提供中西双语，而编排智能体的技能和提示词则仅保留英文。三个月后，这仍然是正确的选择。

5. CLI 的诞生，以及那个缺失的版本号​

5a. 项目成为软件的那一天​

2026 年 3 月 1 日 19:05，commit c7e9026 落入仓库：

"feat: rebrand to Strange Days Tech, add CLI scaffolder, restructure repo"

在那天之前，这个项目只是文字。是模板、技能、治理规则，以及一堆 Markdown —— 依赖操作者（我本人）手工将其复制到想要使用它的仓库中。有一个叫 copy-devtrail.sh 的 bash 脚本。那是个玩具。

那次 3 月 1 日的 commit 引入了 cli/Cargo.toml 和 cli/src/main.rs。第一个 CLI 叫做 devtrail-cli，版本 2.0.0，有三个命令：

enum Commands {
    Init { path: String },
    Update,
    Remove { full: bool },
}

init、update、remove。三个操作。其余的都是后来的事：status、repair、validate、new、compliance、metrics、analyze、audit、explore。但最初的三个依然还在，几乎原封未动。

那次 commit 的意义不在于那三个命令，而在于：从那天起，这个项目不再是一堆存活于自身仓库里的文档，而成为了一个可以安装到其他仓库中的可执行工具。"文档治理项目" 与 "带工具链的框架" 之间的边界，在那个三月的周日被跨越了。这比之前任何一次改名都更为重要。

那天也是项目迁移 GitHub 账号的日子：从 enigmora/devtrail 到 StrangeDaysTech/devtrail。组织在同一个 commit 里将自身从 Enigmora 改名为 Strange Days Tech S.A.S.，同时也发布了 CLI。两个层面的身份认同同步迁移：产品的（Monimen 到 DevTrail）发生在一月；公司的，发生在三月。两个不同层次的身份，按照各自的节拍移动。

（一个对存档准确性重要的补充说明：智能体联合署名 —— 出现在 commit 中的 Co-Authored-By: Claude Opus X.Y 行 —— 并不始于三月。2026 年 1 月 27 日的初始 commit 就已经由 Claude Opus 4.5 联署。AI 联合署名的透明化是从第一行代码起就确立的规则。3 月 1 日改变的不是这个实践，而是规模：CLI 是联合署名第一次产出可执行代码，而非文档。）

5b. 那个缺失的版本号​

框架版本编号有一个细节，直接看 git tag 就能一目了然：

fw-2.0.0
fw-2.1.0
fw-4.0.0
fw-4.1.0
...

没有 fw-3.x.x。项目刻意从 2 跳到了 4。

这个跳跃对应的是 commit 21e03b2，日期为 2026 年 3 月 27 日，其正文如此描述这次变更：

"Reposition DevTrail from 'documentation helper' to 'ISO 42001-aligned AI governance platform' across all user-facing docs. Lead with regulatory urgency (EU AI Act Aug 2026) and compliance value proposition."

在三月之前，DevTrail 将自己定位为一个文档辅助工具；从那次 commit 起，它将自己定位为一个符合 ISO 42001 的 AI 治理平台。版本号的跳跃（2 → 4，跳过 3）标志着这一主张转变的幅度。这是一个有意识的选择：仅仅一个大版本的跃升，不足以体现这种差异。

而这正是早期历史开始从回顾的角度产生意义的地方。那个自一月起就存在于仓库中的直觉 —— 一个健壮、规范、可对齐标准的记录体系的构想 —— 直到三月才被明确命名。我们将在下一节谈到第二个名字时，更清楚地看到这一点。

6. 关于那些名字​

四次改名中，三次没有 ADR。理由只存活在 commit 信息里，有时甚至连那里也找不到：commit chore: rebrand Chronicle to Monimen 没有说明为什么是 Monimen；紧接着的那条 chore: rebrand Monimen to DevTrail 也没有说明为什么是 DevTrail。将 ADR 作为有纪律的制品的实践，是后来才形成的；在一月，名字随着一个 commit 而改变，理由则随着产生它的那场对话一同消散。

但部分词源学是可以追溯的。

• Chronicle（1 月 27 日）。历史记录。航海日志。这个名字不言自明：你用一部chronicle（编年史）所做的事，就是按顺序写下发生了什么，以便日后查阅。没有 ADR，但这个词自带含义。

• Monimen（1 月 28 日）。这是唯一一个我确实记得其直觉、且值得讲述的名字。Monimen 来自对 Monumento（纪念碑）的文字游戏。驱动这个建议的类比是：彼时已经隐约感知到的那些规范 —— AIDEC、AILOG，以及可对齐于新兴 ISO 42001 治理体系的一切 —— 代表着某种坚实而持久的东西。纪念碑是为了长存而竖立的；是一个社群中不可移动的参照点。这正是框架想要成为的。截短的后缀 —— Monimen 而非 Monument —— 是赋予这个词更敏捷、更具软件气质的尝试，少一些大理石的厚重感。它只存活了二十五小时。但那个直觉没有消亡：三月将被明确命名为符合 ISO 42001 的 AI 治理平台的东西，正是那同一冲动的成熟版本。Monimen 是一个有着正确主张、却说错了语言的名字。

• DevTrail（1 月 29 日）。开发者的足迹。比 Monimen 少了些庄重，多了些具体。那个 commit 标注了 BREAKING CHANGE —— 从五月的视角来看，颇具讽刺意味：前三次改名中最具决定性的那次，恰恰是在三个半月后被替换的那次。

• StrayMark（5 月 8-9 日）。那个标记，那个留下的痕迹。但这次品牌迁移值得单独成文：已经有了一份公开的 ADR（2026-05-08-001）、五个核心 PR 的弧线（#114-#118），以及 README 中的一份*"为什么叫 StrayMark？"*宣言，值得另行论述。在此，我只是将它作为那次终于有了文档纪律支撑的品牌迁移，画上句号。

重点不在词源本身，而在于：每个名字都印证了一种关于这个产品是什么的独特直觉——日志（Chronicle）、规范支柱（Monimen）、开发者足迹（DevTrail）、残留痕迹（StrayMark）。四个名字是对这个概念的四种假设。当概念稳定下来，搜索才会终止 —— 而只有到那时，名字才能安定下来。

7. 结语​

我从这个过程中得出的结论，凝炼为四点：

1. 我们不是在寻找名字，而是在寻找概念。 四次改名是探索的证据，而非优柔寡断的证据。概念在名字的轮替中不断清晰。

2. 四次改名中，三次没有 ADR。 将 ADR 作为有纪律的制品的实践是后来才形成的。一月时还没有这个习惯。这不是债务 —— 这是对节奏的诚实。治理习惯是想要记录已然发生之事的产物，而非启动的前提。

3. 这个项目在 2026 年 3 月 1 日成为了软件。在此之前，它只是文字。 Rust CLI 是那道边界。任何关于 StrayMark 作为框架的讨论，都必须承认那次 commit 之前和之后的区别。

4. 大概不会再有下一次改名了。 但这个博客不作此承诺。这个项目对自身的可变性保持诚实，做出相反的承诺将背叛第一篇文章的第一个主张。

当我两周前开始写这个博客时，并没有打算回溯早期历史。本意是谈 Charter、谈 emergent observation、谈框架今天实际在做的事情。但这个博客本身就是一个追溯性的行为 —— 它的存在，是因为某件事让我足够惊讶，以至于我开始动笔。而一旦我决定从后往前写，抵达一月就成了必然。抵达三天内的三次改名。抵达年份打错的 AIDEC。抵达 Monimen。

下一篇：框架的第一个真正的方法论实验 —— Sentinel 的六个 Plan，以及 Plan 被重命名为 Charter 的那一天。那才是这个博客本来要讲述的故事真正开始的地方。

锚点：commit 7c58b6d · 0b772bc · 25ab7a4 · 7b7193e · c7e9026 · 21e03b2。原始 README：git show v1.0.0:README.md。

本文档在生成式 AI 工具（Claude 4.7）的协助下撰写；内容的全部责任由人类作者承担。