6 篇博文 含有标签「charters」

一次本应是美容清理的 polish Charter，在六个小时内浮现了十个生产 gap —— 其中两个已经交付到 main 并且整整十天从未真正工作过。反模式获得了名字，模式作为 fw-4.18.0 被写入文档，而 CLI helper 被有意推迟。

二十七小时后，这套手工纪律被命名为两个模式：模式 1 —— pre-declare SpecKit refresh；模式 2 —— post-close audit-driven Batch N.4。正典文档、遥测 schema、CLI helper —— 再过一小时，一个把两者向上重新吸收的元模式出现了。

Sentinel 在一个已经一个月没有刷新的 plan 上连续跑了七个 Charter，靠手工执行 CHARTER-18，心里清楚任何一步走错都会埋掉前六个 Charter 的工作。五个小时之内，把这套手工纪律写进了上游治理 —— 当时还没给这个模式起名字。

六个小时的工作会话，使用一个能力强的智能体，加载了框架的全部入门资料 —— 一次都没有主动建议使用 Charter。直接被问到时五分钟内就能套用。这不对称的不是能力，是可见性。

每个 Charter 在两小时工作之上还要 40 分钟的复制粘贴。纪律在起作用；仪式却变成了问题。Charter 如何成为 CLI 的一等实体，以及那一条把审计编排留给框架、把 prompt 评估交给任何第三方的架构决策。

纸面上六个 Plan，实际跑了五个 —— Sentinel 在 4 月 25 日至 28 日之间的第一次系统性实验。正是这一轮把一个手工的模式变成了 Charter，即框架中有边界的工作单元。