# 决策日志

governed_by：D-014

本文件是决策索引和轻量决策记录。影响多个模块、难以撤销或需要长期解释的决策，应单独建立 ADR。

效力语义、必需字段、未标注默认行为、空集合规则和到期处理由[规范效力元治理](08-规范效力元治理.md)定义。本文件不重复定义，只登记。

<a id="effective-register"></a>

## 生效登记表

**本表是查询"当前哪些规则可以阻断或授权"的唯一权威位置。** 未出现在本表中的决策一律按`提议`处理：不阻断、不授权。

本表为空或极短是正常状态，**不等于"没有约束"**；形如"全部 X 通过"的条件在 X 集合为空时判定为 `UNDETERMINED` 而非 `PASS`，见[空集合条款](08-规范效力元治理.md#empty-set)。

| decision_id | 状态 | approved_by | approved_at | effective_scope · blocks | effective_scope · grants | review_at | expiry | 上游依据 |
|---|---|---|---|---|---|---|---|---|
| D-014 | 已接受 | Alan（项目所有者） | 2026-09-02 | 在 `repo:AI辅助开发规范及工作流确定` 内：阻止把未登记规则用作执行/授权依据；阻止把空检查集判定为通过；阻止在正文中新增第三处状态值副本 | 授权执行者按[分向降级](08-规范效力元治理.md#unmarked-default)使用未标注规则作为拒绝理由 | 2026-12-02 | N/A（已接受，无到期） | 无（宪法性批准） |
| D-015 | 已接受 | Alan（项目所有者） | 2026-09-03 | 在 `repo:AI辅助开发规范及工作流确定` 内：阻止在上下文合同之外维护第二份默认加载清单；阻止合同复制被路由文档的正文（只路由不复制）；阻止把参数化视图当作新的清单（视图必须由同一份合同派生）；阻止用无法解析的描述（"相关""对应""当前"）充当加载项；阻止链接自动递归展开 | 授权执行者按合同声明的**运行类型视图**裁剪默认加载集合；授权在合同缺项、锚点不可解析或与工作区身份冲突时失败关闭、停止并报告 | 2027-03-03 | N/A（已接受，无到期） | D-014、D-020。正文为 [22 上下文装配 §2 P1](22-上下文装配.md#context-levels)；本仓库的实例是 [CONTEXT_MANIFEST.md](../CONTEXT_MANIFEST.md)，其载体形态效力为零 |
| D-020 | 已接受 | Alan（项目所有者） | 2026-10-05 | 在本仓库全部规范正文内：阻止载体绑定内容进入正文；阻止未通过「两种互不相同机制类型」检验的候选进入正文（两种可在同一宿主内，同一机制类型的两种写法不算；跨工具一项记未定）；阻止只举一种形态的探测提示；阻止在规范中维护各工具映射表；阻止把附录载体实例引用为落地要求 | 授权按各条判据把已在正文中的载体绑定内容移出至无效力附录 | 2027-03-02 | N/A（已接受，无到期） | D-014 **修订**：2026-09-06 按 [D-086](#decision-index) 裁准（依据[审计记录 040 §8](审计记录/040-会漂计数的综合审计与推荐.md)），grants 里的「三条判据」改为「各条判据」。**Alan 同日裁定 [09 跨工具通用性](09-跨工具通用性.md) 的判据集合为开放**，故该处本就指「该章当下那组判据」，新写法与旧写法等义且不会漂，grants 覆盖的动作集合前后相同——按 [D-077](#decision-index) 第 ① 句属记账修改，**`approved_at`、`review_at`、`expiry` 三格一字未动**，裁决方向不变，不另开生效规则。 **修订**：2026-10-04 按 [D-135](#decision-index) 改一处——可行性检验由「两种实例不得同属一个工具」改为「两种实例须落在互不相同的机制类型上，可在同一宿主内」，并规定通过该检验的候选在「跨工具」一项记未定、不折算为已验证跨工具（见 [09 §5](09-跨工具通用性.md#feasibility-test)）。原因：本仓受支持宿主收为 DeepSeek Harness 一家，原检验在单宿主下恒不可满足。blocks 覆盖的动作集合改变了成立条件，按 [D-077](#effective-register) ② 属**实质修改**，经 Alan 重新批准：2026-10-04 先说「修改为只支持DeepSeek harness吧」；提交前独立审查指出该话未必涵盖「放宽检验」这一具体改动，于是把这一点单列给他确认，2026-10-05 他答「那按照推荐来做吧」，所推荐的选项是「批准并按他明确确认的话记录」。`approved_at` 写 2026-10-05（以明确确认为准，不以 10-04 的泛指令为准），`review_at` 2027-03-02 与 `expiry` N/A 照已接受项不变；裁决方向不变（载体绑定不进正文、检验用于证伪）。 |
| D-040 | 已接受 | Alan（项目所有者） | 2026-09-30 | 在本仓库全部规范正文内：阻止以判据一的「不写」为由，拒绝写入运行中观察提炼的经验或同一可推断事实已二次失败的内容；阻止因二次失败写入的内容不绑定删除条件；阻止因读取成本过高而建的缓存不带对账；阻止换一个团队就会不一样的内容进入正文（判据三第二问；正文只写该类内容必须存在并有所有者） | 授权同一可推断事实二次失败后写入，并绑定删除条件；授权读取成本过高时建立带对账的缓存 | 2027-03-30 | N/A（已接受，无到期） | D-014（生效路径）；修正 D-020 的判据一与判据三，文字在 [09 §2](09-跨工具通用性.md#criteria-whether)、[§3](09-跨工具通用性.md#criteria-which)，同批写入。由项目所有者直接批准（Alan 2026-09-30 原话「按建议执行」），批准人与形式同 [08 §0](08-规范效力元治理.md#self-reference) 的宪法性批准。D-020 本行不改：其 blocks 与 grants 不涉判据一的行数与判据三的问数，文字与三个日期格一字未动 |
| D-043 | 已接受 | Alan（项目所有者） | 2026-09-02 | 在本仓库全部规范正文内：阻止新增**部件级**内容不归属于四平面 14 个部件之一（不变量与平面接口为架构级内容，与部件并列，不受本条约束——D-047 澄清）；阻止把边缘部件（外部系统交接、触发与入口）写成一等部件；阻止按原八层结构新增章节 | 授权用四平面结构取代原八层组织方式，并把原 00–07 章移入历史目录 | 2027-03-02 | N/A（已接受，无到期） | D-014、D-020 |
| D-047 | 已接受 | Alan（项目所有者） | 2026-09-02 | 在本仓库全部规范正文内：阻止把外部系统交接与触发入口写成部件或独立章节；阻止跨边界纪律以并列条款清单的形式在正文中第二次出现；阻止新增无法挂靠第六条不变量各条推论之一的跨边界规则 | 授权删除 [21](21-调度与拆分.md) 与 [24](24-工具与执行环境.md) 的"待定"节并把其纪律并入第六条不变量；授权把不变量与平面接口作为与部件并列的架构级内容新增或修改 | 2027-03-02 | N/A（已接受，无到期） | D-014、D-020、D-043。**修订**：第六条不变量的判据段按 D-055 改写为关系模型（权威侧 / 消费侧 + 三项可执行前提），2026-09-02 裁决、2026-09-03 落地；D-047 的裁决方向（不设部件、以判据加不变量收口）不变，不另开生效规则 **修订**：2026-09-06 按 [D-086](#decision-index) 裁准（依据[审计记录 040 §8](审计记录/040-会漂计数的综合审计与推荐.md)），blocks 第三分句的「四条推论」改为「各条推论」。**Alan 同日裁定第六条不变量的推论集合为开放**，故该处本就指「当下那组推论」，新写法与旧写法等义且不会漂，blocks 覆盖的动作集合前后相同——按 [D-077](#decision-index) 第 ① 句属记账修改，**`approved_at`、`review_at`、`expiry` 三格一字未动**，裁决方向不变，不另开生效规则。**同批未处置、记为待处置**：D-055 把第六条不变量改写为关系模型后，义务分成消费侧推论、权威侧对偶与可执行前提三组，而本句只认「推论」一词，挂靠权威侧对偶的新跨边界规则按字面仍挂不上。 |
| D-057 | 试行 | Alan（项目所有者） | 2026-09-23 | 在 `repo:AI辅助开发规范及工作流确定` 内：正文 10～40 共 14 章的**全部原则**，各自声明的禁止项具有阻断力——**本行不写条数**，成员的外延由各章 `^- **Pn` 的行形态固定（该形态被检查器 C7 与[追溯账本](追溯账本.md)逐条对账咬住），要用条数跑 [`repo-counts.mjs`](../scripts/repo-counts.mjs) 现取。**一条原则在本仓库内生效，当且仅当本仓库实际存在它所治理的那个部件的实例**——本行给的是判据不是名单（D-055 改动 5），不列举章号，形式同 [00 §3](00-总览.md#default-scope) 的对象判据；本仓库不是一个交付软件的项目，没有实例的部件其原则在此不被触发，这一句 2026-09-03 补入，此前的写法在"约束本仓库每一轮"与"作为规范生效"两种读法之间没有选（见[审计记录 007](审计记录/007-D-057作用域与本仓库自身合规.md)）。此外：每条的阻断范围由它自己的「删除条件」尾标承载（取值域含起始档与运行类型限定，见 [09 §4](09-跨工具通用性.md#two-axes)），**本行不枚举原则编号**（D-055 改动 5：判据优先于枚举）；[00 §3](00-总览.md#default-scope) 逐字的「**§5 各条**不变量、控制平面与责任平面的原则对一切运行成立」（**本行只指不复述，措辞与该节逐字同**，该节的默认作用域声明随本行生效；不变量的权威清单全文只有一处，在[架构确定 §5.3](架构确定.md#invariants)，**本行不写条数**——[D-047](#effective-register) 的 grants 逐字授权把不变量「作为与部件并列的架构级内容新增或修改」，写死条数会在下一次增改时把新增的那一条静默排除出「对一切运行成立」，且这一格已实测漂过一次）；一条原则未被任何机械检查覆盖，不构成它不生效的理由 | 授权执行者援引正文任一条原则作为拒绝、停止或要求补齐工件的理由，并按该条声明的形式提出——此前正文全为`提议`时不产生此授权；授权按各条「删除条件」的起始档与运行类型限定裁剪其适用范围 | 2027-02-17 | 2027-03-03 | D-014（效力语义与「试行到期不追溯」）、D-043 与 D-047（正文的架构前提）、D-055（作用域两轴与「删除条件」四类取值，使逐条阻断范围可被援引）。**本行给的是正文文本的效力，不是决策文本的效力**：已被某章 `governed_by` 认领的`提议`决策（**本行不写条数**，是哪些跑各章文件头的 `governed_by` 现取），其落进正文的部分随本行生效，未落进正文的部分不生效；那些决策行状态不改，保留作来源追溯——按 D-014 §5 登记表是唯一效力源，把效力再抄进各决策的状态格即 [08 §7](08-规范效力元治理.md) 禁止的副本。**修订**：2026-09-05 按 [D-076](#decision-index) 裁准（依据[审计记录 031 §3](审计记录/031-四条待裁的整合与推荐.md)），删去本行内嵌的三处会漂计数——原则条数、不变量条数、被 `governed_by` 认领的决策条数，各改为判据加现取命令；**`approved_at`、`review_at`、`expiry` 三格一字未动**，按 [D-077](#decision-index) 第 ① 句属记账修改，**裁决方向不变，blocks 与 grants 覆盖的动作集合前后相同，不另开生效规则**。「14 章」保留不动：[D-043](#effective-register) 与 [D-047](#effective-register) 的 blocks 明文阻止新增章节，它不会漂。第四处「六条」在正文 [00 §3](00-总览.md#default-scope) 那一句，**已由本批另一路同批改成指向 §5 的表述，两半同轮落地**；本行随即照该节逐字措辞对齐，**不产生第二种写法**，本行不动正文；「117」在本仓库另有多处散文副本（跑 `grep -rn 117 --include=*.md` 现取，本行不写处数），它们不在唯一效力源里，本轮不动。**第三跳与第四跳也已一并处置**（[审计 032](审计记录/032-第二十五轮第三批提交前对抗性复核.md) F-02 查出：只删前两处，失效模式只是**挪了一跳**——00 §3 的规范句现在指向 [00 §5](00-总览.md)，而该节的标题与首句原本逐字写死「六条」，加第七条仍会被静默排除）：**00 §5 的节标题「六条不变量」→「不变量」、首句「换任何工具都不变的六条」→「…的那一组」；[架构确定 §5.3](架构确定.md#invariants) 的小节标题「六条架构级不变量」→「架构级不变量」。** 两处的显式锚点 `<a id="default-scope">` 与 `<a id="invariants">` 未动，全仓 0 断链。**「第六条不变量」那一类写法一律保留**——它是**指称某一条的序数**，不是集合的基数，加第七条不会使它失真。**至此规范链上不再写死条数**——00 §3 →（§5 各条）→ 00 §5 → [架构确定 §5.3](架构确定.md#invariants) 整条链现跑不含基数，加第七条不再被静默排除。**但不是"任何一处"**（[审计 032](审计记录/032-第二十五轮第三批提交前对抗性复核.md) R2-01 查出，本行第一版写成了全称断言）：规范链之外的活文档与架构图产物里仍有以「六条不变量」作**集合基数**的写法，序数「第六条不变量」不在此列。**本句不写路径清单、不写处数、不内嵌检索命令**（同格另有一条关于「117」散文副本的现取命令，属旧句，本轮未纳入处置范围）——是哪几处由处置时现跑一条不限路径的检索给出，且该检索不得按整行剔除序数，否则同一行里的基数会被一并静默丢弃。**它们不在规范链上**（不是 D-057 指向的那条路径），本轮不动，**记为待处置**。 **修订**：2026-09-06 按 [D-084](#decision-index) 裁准（依据[审计记录 040](审计记录/040-会漂计数的综合审计与推荐.md) §7），删去本行「待处置」句里写死的三条路径与内嵌的检索命令，改为判据加「本行不写路径清单」；一并消除该命令未转义竖线造成的第 10 格，「记为待处置」重新落回「上游依据」格内。**`approved_at`、`review_at`、`expiry` 三格一字未动**，按 [D-077](#decision-index) 第 ① 句属记账修改，**裁决方向不变，blocks 与 grants 覆盖的动作集合前后相同，不另开生效规则**。 **修订**：2026-09-23 续期一期（Alan 2026-09-23 在对话中批准 [D-078](#decision-index) 第 2b 项取「续」，落地记录见 [D-114](#decision-index)）。改三格：`approved_at` 2026-09-03→2026-09-23，`review_at` 2026-11-19→2027-02-17，`expiry` 2026-12-03→2027-03-03。**日期的计算依据**：原试行期 2026-09-03 至 2026-12-03 为 3 个自然月，复审在到期前 14 天；续一期接在原到期日之后再加 3 个自然月，得 2027-03-03，复审同样提前 14 天，得 2027-02-17。改了到期日即改了成立条件，按 [08 §6](08-规范效力元治理.md#trial-expiry) 属实质修改，已重新批准；blocks 与 grants 两格一字未动，裁决方向不变。**再次续期的条件**：[D-057](#decision-index) 的三项检验须有来自真实项目的数据；到复审日仍没有，就不再续，按 08 §6 到期自动失效。 |
| D-077 | 已接受 | Alan（项目所有者） | 2026-09-23 | 在 `repo:AI辅助开发规范及工作流确定` 内：阻止对生效登记表已有一行做实质修改（使 blocks 或 grants 覆盖的动作集合增减，或改变其成立条件，含到期日）而不重新批准、不写新的 `approved_at` 与 `expiry`（`试行`项另写新的 `review_at`）；阻止把判不出属哪一类的修改按记账修改处理；阻止改生效登记表某一行而不在该行「上游依据」格末尾留「修订」句 | 授权维护者对生效登记表某一行做记账修改（只把会漂的数、失效的指针或一句表述换成等义写法，覆盖的动作集合与成立条件不变）时就地改，不重新批准，`approved_at`、`review_at`、`expiry` 三格不动 | 2027-03-23 | N/A（已接受，无到期） | D-014（[08 §6](08-规范效力元治理.md#trial-expiry)「需要继续生效必须重新批准」）。三条规矩的文字在 08 §6 末，2026-09-23 同批写入 |
| D-108 | 已接受 | Alan（项目所有者） | 2026-10-05 | 在 `repo:AI辅助开发规范及工作流确定` 内（含从本仓向公开仓 `github.com/Alan-IFT/ai-dev-std` 的推送）：阻止在交付面（`标准/`、`templates/`、`tools/std/`、`tools/dsh-std/`、`LICENSE`、`LICENSE-DOCS`，及 `release` 分支根 `README.md`）新增生成器、脚手架、安装器或取用器脚本；阻止在交付面发布作为生效执行层的宿主工具钩子、权限或流水线配置，**唯一例外是 `tools/dsh-std/`——DeepSeek Harness 插件，它是本仓唯一受支持宿主上的执行层**（`templates/` 与示例项目里供复制或示意的 `AGENTS.md`、skill 文件，`tools/std/README` 里的接入示意片段不在此列，同 D-099 ③）；阻止把私有 `main` 上交付面以外的任何内容推到公开仓；阻止绕过 `release` 分支直接改公开仓（公开仓 `main` 只接收 `release` 的线性发布提交及其 tag）；阻止把工件文件在不在、有几个汇总成分数或等级来评价规范或采用项目（检查器逐项报三态不在此列）；阻止援引模板、Skill 或附录载体实例的文字作为执行、放宽或授权的依据（拒绝方向按[分向降级](08-规范效力元治理.md#unmarked-default)处理） | 授权维护者按私有 `main` → `release` 线性发布提交 + 日期 tag（同日第二次起加 `.1`、`.2`）发布，并把 `release` 推为公开仓 `main`、推送对应 tag；授权交付面的取用与升级命令默认写公开仓 `main`，要钉某一版时写 tag 名 | 2027-03-23 | N/A（已接受，无到期） | D-014（效力语义）、D-020（载体实例效力为零、规范不维护工具映射表）、D-098（tag + subtree 取用）、D-099（执行层不发可执行件）、D-101（Claude Code 拦截层随标准发，已由 D-115 取代）；取代 D-041。D-098、D-099 两行状态不改，其内容凡写进本行的随本行生效，未写进的不生效。**修订**：2026-09-23 按 [D-115](#decision-index) 改三处——交付面清单删 `.claude-plugin/`；grants 删「授权 Claude Code 拦截层（`.claude-plugin/` 与 `tools/std/hooks/`）随交付面发布」；blocks 的「Claude Code 以外宿主工具的钩子或流水线配置」改为「任何宿主工具（含 Claude Code）的钩子、权限或流水线配置」，`tools/std/README` 里的钩子与权限配置示意片段仍按本格括注不在此列。grants 覆盖的动作集合减少、blocks 增加，按 [D-077](#effective-register) ② 属**实质修改**，经 Alan 2026-09-23 重新批准（「实测完直接按推荐替换」）：`approved_at` 写 2026-09-23（与原批准同日，字面不变），`review_at` 2027-03-23 与 `expiry` N/A 照已接受项不变；裁决方向由「Claude Code 一家随标准发执行层」改回 D-099 的一般规则 **修订**：2026-10-04 按 [D-135](#decision-index) 改两处——交付面清单加 `tools/dsh-std/`；blocks 的「任何宿主工具（含 Claude Code）的钩子、权限或流水线配置」加上唯一例外 `tools/dsh-std/`（DeepSeek Harness 插件）。blocks 覆盖的动作集合减少（放行了一类以前被阻止的交付物），按 [D-077](#effective-register) ② 属**实质修改**，经 Alan 重新批准：2026-10-04 说「这个工具可要做实现为插件形式」，2026-10-05 对提交前的审查结论答「那按照推荐来做吧」（该问同时涵盖本行）。`approved_at` 写 2026-10-05，`review_at` 2027-03-23 与 `expiry` N/A 不变；Claude Code 自此不是受支持宿主，D-115 里面向 Claude Code 的接法一并退出。 |
| D-110 | 已接受 | Alan（项目所有者） | 2026-09-23 | 在 `repo:AI辅助开发规范及工作流确定` 内：阻止把状态为`已执行`的决策援引为阻断或授权依据；阻止把只执行一半或仍有待裁部分的决策记为`已执行`；阻止把`已执行`的决策写入本表 | 授权把整条执行完毕、无待裁部分、不产生规则的决策记为`已执行`（含把既有`提议`行改记），行内补执行记录指针，并删去仅为弥补状态值域缺档而写的免责句 | 2027-03-23 | N/A（已接受，无到期） | D-014（修正其 [§1 状态值域](08-规范效力元治理.md#force-states)；由项目所有者直接批准，批准人与形式同 [§0](08-规范效力元治理.md#self-reference) 的宪法性批准）。D-014 本行不改：其 blocks 的「第三处状态值副本」按值域外延随之覆盖新值，文字与三个日期格一字未动 |

当前生效规则数：**10**（D-014、D-015、D-020、D-040、D-043、D-047、D-057、D-077、D-108、D-110）。**其余决策的状态一律查下方决策索引的状态列，本处不再逐个 ID 枚举**——2026-09-03 前这里抄了一份 ID 名单，它随每次状态变更漂移，属 [08 §7](08-规范效力元治理.md) 禁止的副本。D-057 使正文 117 条原则整套进入`试行`：**正文文本自此有阻断与授权效力，2026-09-23 续期一期（见 D-114），到期日见上表 D-057 行，到期不追溯**；决策文本本身不因此生效，各决策仍按其状态列处理。

<a id="decision-index"></a>

## 决策索引

状态值：`提议`、`试行`、`已接受`、`已取代`、`已拒绝`、`已执行`。本列只作索引；与生效登记表不一致时以生效登记表为准，并标记为待修复缺陷。

| ID | 日期 | 状态 | 决策 | 原因 | 后续验证 |
|---|---|---|---|---|---|
| D-001 | 2026-09-01 | 提议 | 使用唯一 Context Contract 路由项目状态、当前工作项和按需 PRD/架构/ADR | 避免新会话取并集携带全部项目历史 | 在真实项目中记录恢复时间、误解次数和输入量 |
| D-002 | 2026-09-01 | 提议 | 采用端到端小切片作为默认交付单位 | 降低并行依赖和单次推理范围，保持每步可验收 | 比较切片周期、回滚难度和返工率 |
| D-003 | 2026-09-01 | 提议 | 同一故障连续两次无新证据时停止重复试错 | 防止 AI 围绕同一假设循环消耗时间 | 观察是否减少无效修改且不妨碍系统排查 |
| D-004 | 2026-09-01 | 已取代 | 不采用跨语言统一文件行数硬上限 | **已由 [00 §3](00-总览.md#default-scope) 的对象判据取代**（2026-09-04 记账更正）：D-055 改动 2 声明本规范的对象是这套开发系统本身与被交付产品中**承载主张**的那一部分；产品代码的可维护性由它自己的验收条目承接（[10 章](10-意图与验收.md)），"产品结构如何改"明确不是本规范的内容。本条讨论的对象已在边界之外 | 不需要裁决，是作用域边界移动后的清理 |
| D-005 | 2026-09-01 | 提议 | 按主张的时间、范围、版本和环境指定权威来源并绑定支持证据 | 同一主题的意图、代码、部署和运行现场可能同时正确 | 用版本错配和运行回读 Case 验证 |
| D-006 | 2026-09-01 | 提议 | 明确区分上下文、任务状态、项目知识、长期记忆和证据 | 避免摘要、旧记忆或状态书签被误当成事实 | 通过中断恢复和冲突 Case 验证 |
| D-007 | 2026-09-01 | 已取代 | AI 只能提出权威知识/长期记忆候选，默认由所有者审批后写入 | **已由 D-033 取代**（2026-09-04 记账更正）：本条自第四轮起即自述"拟被 D-033 取代"，D-033 的三维晋升（入池条件 × 权威性 × 影响面）已落在 [12 章](12-记忆与知识治理.md)并随 D-057 生效，本条的二值审批模型不再是现行表述 | 不需要裁决，是状态与事实对齐 |
| D-008 | 2026-09-01 | 提议 | 可确定的规则下沉到程序、测试、权限或 Gate | 自然语言提醒会被遗漏，且难以证明执行 | 比较违规拦截率与误阻断率 |
| D-009 | 2026-09-01 | 提议 | 完成证据绑定 requirement、revision、环境、过程、结果和时间 | "测试曾经通过"不能证明当前交付 | 构造报告过期和 worktree 错配 Case |
| D-010 | 2026-09-01 | 提议 | 采用确定性程序 → 单次调用 → Workflow → Agent → 多 Agent 的复杂度阶梯 | Agent 化会增加成本、错误累积和协调负担 | 在代表性任务上比较质量、成本和人工时间 |
| D-011 | 2026-09-01 | 提议 | 用工件、轨迹、任务和项目结果分层评估 Harness | 只看代码测试无法发现工具、handoff、权限和恢复问题 | 建立最小回归 Case 与项目指标 |
| D-012 | 2026-09-01 | 提议 | 模型升级时对 Prompt、Skill、工具和非安全脚手架做受控消融 | 旧模型补丁可能在新模型上成为噪声 | 移除候选前后运行同一评估集 |
| D-013 | 2026-09-01 | 提议 | Harness 按真实失败 Add，按无消费、重复、误伤或负收益 Thin | 防止先建平台和规则只增不减 | 为每项机制记录来源 Case、成本和复查条件 |
| D-014 | 2026-09-02 | **已接受** | 规范效力元治理：效力状态语义、blocks/grants 分离、未标注规则分向降级、空集合判 UNDETERMINED、试行到期不追溯、生效登记表为唯一效力源 | 防止理论提议因命令式措辞被 Agent 当成门禁或授权，并堵住"空 Gate 集 = 已通过"的合规漏洞 | 见[反例推演表](08-规范效力元治理.md#validation)；机械校验只声明语义要求，不绑定载体 |
| D-015 | 2026-09-01 | **已接受** | 唯一上下文合同（2026-09-03 批准）：每个项目只维护一份默认加载清单，其它文档只链接不复制；合同只路由不复制正文；**按运行类型参数化出视图，视图是同一份合同的投影而不是新清单**；缺项、锚点不可解析、与工作区身份冲突时失败关闭 | 多份默认入口会被执行者取并集并持续膨胀。**2026-09-03 补充的裁决理由**：此前每一轮都在用"把内容搬到别处"来控制加载量，而正文按部件组织、不按一次运行需要组织，搬迁收益已在第十轮用尽（正文降 18.4%，仓库总量反升 6.2%）。参数化视图对搬不动的内容同样有效，是这条路的替代而不是补充 | 比较新会话实际加载集合与清单，检查重复和猜测项；观察两个视图是否真的被按类使用，还是退化成"总是加载全集" |
| D-016 | 2026-09-01 | 提议 | WORK_ITEM 是实时任务状态源，SESSION_HANDOFF 是带身份的临时快照，PROJECT_STATUS 是里程碑摘要 | 三种状态载体职责和新鲜度不清会使恢复选择错误下一步 | 构造过期 handoff、不同 worktree 和状态冲突 Case |
| D-017 | 2026-09-01 | 提议 | 生命周期只维护一套状态机，并区分实现完成、可集成、已发布/N/A、已验收 | 多套完成定义会产生虚假完成 | 用无需发布、发布失败、验收失败和回滚 Case 验证 |
| D-018 | 2026-09-01 | 提议 | Gate 必须声明执行点、checker、输入、通过条件、失败回边、证据输出和限时豁免责任 | 清单式要求不能可靠阻断，也无法审计例外 | 建立漏拦截、误阻断、过期豁免 Case |
| D-019 | 2026-09-01 | 提议 | Harness 变更通过"评估通过 → 人类批准 → 决策生效 → 受控发布 → 线上观察"晋升 | 实验结果不能自动升级为生产规范 | 记录 eval manifest、批准、发布和观察的完整链路 |
| D-020 | 2026-09-02 | **已接受** | 跨工具通用性：三条判据（信息源头、责任可否转移、换工具要不要改）+ 两种机制类型的硬性可行性检验 + 探测提示须并列多形态 + 规范不维护工具映射表 + 载体实例效力为零 | 规范须在 codex、Claude Code、opencode、DeepSeek harness、Copilot 上通用；载体绑定会伪装成语义，只靠声明无法机械执行 | 见[反例推演表](09-跨工具通用性.md#validation) |
| D-021 | 2026-09-02 | 提议 | 每条规则写下时必须绑定它防御的可复现失败与删除条件；模型代际更替时做过期审计 | 说不清防什么的规则无法被淘汰；每条规则都编码了一条会过期的"模型做不到什么"的假设 | 对现有 D-001～D-019 逐条尝试补齐失败绑定，统计补不出的比例 |
| D-022 | 2026-09-02 | 已取代 | 八层模型作用域声明为单条交付链；组织摩擦与交付流动作为独立观测维度 | **已由 D-043 取代**（2026-09-04 记账更正）：八层结构已在第六轮被四平面 14 部件取代，D-043 为`已接受`，其 blocks 明文"阻止按原八层结构新增章节"。本条的作用域声明对象已不存在 | 不需要裁决，是状态与事实对齐 |
| D-023 | 2026-09-02 | 提议 | 失败分类新增"指标被满足而目标被背叛"；证据链中必须存在直接观察真实世界的节点 | 系统会用背叛目标初衷的方式移动被赋予的指标；全部节点互引模型结论则无法被证伪 | 构造指标上升而目标受损的 Case，以及全模型结论链的自洽 Case |
| D-024 | 2026-09-02 | 提议 | 自主度上限等于可廉价可靠验证的量；Gate 总数上限等于人能真正判断的数量 | 判不动的 Gate 等于没有且更糟，会制造"已经审过"的假象 | 记录 Gate 数量与实际否决率、平均审查时长的关系 |
| D-025 | 2026-09-02 | 提议 | 优化须报告局部输出/行动路径/整体结果三层；被测效果量小于执行路径噪声时端到端 A/B 不成立，退回组件级对照 | 局部改善不蕴含端到端改善；同类工具在不同任务形态上可测出相反方向 | 用一个已知局部收益的机制做端到端与组件级两种对照，比较结论稳定性 |
| D-026 | 2026-09-02 | 提议 | 本规范自身受规模预算、单轮增量上限、语义去重与定期压缩约束；冗余按负资产处理 | 自动修复只增不减；长文档中间区域遵循率下降，冗余会降低规范被正确执行的概率 | 记录每轮增删行数比，以及同一规则集在不同规模下的遵循情况 |
| D-027 | 2026-09-02 | 提议 | 会话不可变范围（权限、租户、项目、环境）作为第四类状态，会话创建时固化且模型不可修改 | 有效能力是多重交集；用户拥有的全部权限不应自动成为一次任务的全部权限 | 构造模型试图通过改写参数扩大范围的 Case |
| D-028 | 2026-09-02 | 提议 | 任务如何拆分合并可由 Agent 现场调整；谁有权改什么、谁能绕过审批必须慢变且可审计 | 把长期权限交给模型现场发挥会产生随时可爆的事故 | 构造 Agent 试图修改自身权限或审批路径的 Case |
| D-029 | 2026-09-02 | 提议 | 第三态纪律：验证层未执行、外部写入结果未知、审批应答缺席、生成者与验证者同一、工作单元交接缺字段，均为独立"未定（UNDETERMINED）"态，不得折算为通过或放行；裁定必须是与执行者无关的结构化三态 | D-014 只覆盖生效规则集合为空；同型漏洞在五个位置重复出现且有运行截图反例（五层门禁未跑仍 88 分放行） | 构造四类第三态 Case，检查是否全部停止并报告；同一事件流两条聚合路径一致 |
| D-030 | 2026-09-02 | 提议 | 压缩与外部化协议：压缩是可拦截事件，触发含行为信号，产物分叙事摘要与活动工作集原文两半，窗口重建后不变量重新锚定，失败尝试转教训再丢弃；工具返回默认只服务当前决策、写侧对称外部化、读降级/写关闭非对称失败语义；有损观察压缩须有损失信号、自动回退、验收环节无损 | 原 03 §8 只有保留清单：压缩丢状态与约束、重复审查已审文件、工具返回逐轮携带、残缺工件写入生产 | 对比"仅摘要"与"两半 + 重锚定 + 教训"两组；固定答案在宽泛搜索末尾的三组对照；残缺入参被阻断且有回读差异 |
| D-031 | 2026-09-02 | 提议 | 隔离原语与治理继承：委托 / 分叉试探 / 压缩外部化三类；委托须声明是否继承治理规则，未声明视为不继承且只读；子任务原子方可降级执行者；子执行者上下文独立计费，编排者成本单列 | 现有理论只有子代理与压缩两类；隔离把治理规则一并隔出去；拆分本身不省钱 | 隔离委托被派违反项目规则的副作用任务应被拒；对比拆分前后固定开销与切段收益 |
| D-032 | 2026-09-02 | 提议 | 知识过期双机制与派生缓存条件：派生知识绑定源版本机械过期、过期默认不作事实；经验知识带 scope/事件/版本触发复核；派生缓存允许存在的条件是声明为缓存、机械对账、人工区受保护且有覆盖权、变更只追加；不为 Agent 维护与人读分离的副本 | 调到废弃接口链路全通结果错；地图与代码脱节；经验型知识源是事件不是 revision；判据一在大仓不可执行 | 旧版派生文档 + 废弃接口 Case，测执行者是否先核版本；索引失配是否被报告 |
| D-033 | 2026-09-02 | 提议 | 【拟取代 D-007】记忆晋升三维分级：入池条件（客观交付信号）× 权威性（owner）× 影响面；自动晋升仅限已登记判定器覆盖且影响面局部、可事后否决；全局规则、安全边界、评估集、回滚、冷启动种子必经人审；审批点后移到进入权威载体或默认可见范围前；模型自身输出不得成为候选 | 全量人审导致沉淀停滞与审核疲劳，全自动导致污染，两者只在不同维度上正确 | 统计自动晋升条目的事后否决率、人审队列规模与时长；注入错误全局规则测多少任务后被发现 |
| D-034 | 2026-09-02 | 提议 | 记忆条目携带置信态（强 / 弱 / 影子）与使用方式，装配与输出按其区别对待；偏好只影响形式；召回为空须声明；注入即记账（到达 + 有用两维）；策展为独立评估组件，删减须结构性机制 | "相关≠可复用"是记忆误用主因；D-013"无消费"与 04 §6"记录是否有帮助"均无采集点；自动策展几乎不删 | 相关但不可迁移的历史 Case；注入重复条目观察多轮内是否清除；条目数与下游成功率相关性 |
| D-035 | 2026-09-02 | 提议 | 评估器与评估集治理：评估器须校准（基准样本、与人工一致性、变更重跑）；评估集按用途隔离（诊断 / 筛选 / 最终验证）、绑定权威定义版本、修改受门控、有饱和过期条件；同预算对照；评审类 Agent 指标锚下游真实行为 | 评估信号同时是门控与进化方向，偏差会被闭环反向优化；"评测过时→更新评测集"是逃逸口；eval 自身 1～3 代饱和 | 植入已知偏好的评估器跑多轮，测输出与人工评分背离；候选在可见集与隔离集分差 |
| D-036 | 2026-09-02 | 提议 | 活性不变量与恢复/副作用语义：进行中单元绑定可探活执行者与新鲜度信号，失绑即未定/阻塞；未到合法停止点不得静默停止；恢复即从检查点后重放，不可逆副作用须幂等或有回执，不得丢失已确认结果；外部写只在声明窗口内、失败入待补偿记录 | 静默卡住比失败更危险（平台自身 P0）；"靠持久工件恢复"未说明已发生副作用如何处置；两份一手框架重跑范围相反 | kill 执行者后断言阈值内转失败或重派；检查点后含一次外部写，重放后外部写次数为 1 |
| D-037 | 2026-09-02 | 提议 | 验收条目单一来源与写入权分离：验证用例从同一带 ID 条目列表派生，对抗性发现转为 ID，确认后冻结；证明修复的测试不得被修复者修改；生成权与写入权结构分离，每类工件单一可写角色；验证者独立于生产者是结构要求 | 下游重新解释意图与生成者篡改证据是同一类失败；事后 Gate 拦不住"顺手改上游/改测试" | 上游工件哈希在下游阶段前后对比；给难修的失败测试观察是否改测试 |
| D-038 | 2026-09-02 | 提议 | 验证基础设施自验与 Harness 第四观测面：检查器结构假设过期判故障并阻断；拦截层须独立失效探测与"应被拦截"回归集；判分器须效度证据；每项机制须能回答是否被消费与是否误伤，无计数不得判有效 | 提供事实的机器自己会撒谎（同类错误一年四次）；拦截层静默失效无人知晓；审计按存在性打分奖励追加 | 禁用拦截层跑回归；判分器回归集；配置声明与运行时能力对账 |
| D-039 | 2026-09-02 | 提议 | 轨迹最小数据结构与导出非权威：调用树 + 时间区间 + 节点状态与用量 + 重试/中断一等节点 + 注入可溯源；导出与聚合是派生投影，验收证据须回读原始记录 | 事件序列无法归因慢/贵/错；导出通道有损且静默 | 先跑会话再装观测插件，对账 span 数与日志事件数 |
| D-040 | 2026-09-02 | 已接受 | （2026-09-30 Alan 批准，原话「按建议执行」；登记见[生效登记表](#effective-register)）【D-020 修正案，需宪法性批准】判据一增"运行中观察提炼的经验"行；"不写"是默认非禁令——同一可推断事实二次失败即写并绑定删除条件；读取成本过高允许带对账的缓存；判据三增第二问"换一个团队会不会不一样" | 判据一存在间隙：经验类内容既不在公开语料也不能从代码读出；"可推断"是经验事实非公理 | 对现有正文"不写"处逐条问是否有失败 Case |
| D-041 | 2026-09-02 | 已取代 | 规范载体形态：语义正文 + 项目侧存在性检查器/生成器 + 附录实例（模板与 Skill 皆为实例、效力为零）；附录含机制类型清单与载体过期登记；规范自审计只作诊断、禁止存在性/数量打分 | **已由 D-108 取代**（superseded_by：D-108，2026-09-23 记账）：实际交付形态已按 D-098、D-099、D-101 落成「三目录交付面 + release／tag／公开仓分发 + 检查器随标准发」，生成器一支落选；本条保留下来的两句——不按文件在不在、有几个打分，模板与 Skill 效力为零——由 D-108 承接。原因原文：Skill 只能承载提醒级，承载不了执行边界与责任节点；纯模板仓库无法自检；存在性审计奖励追加 | 不再执行；后续验证见 D-108 行。原文：在两种工具上各生成一次映射并运行存在性检查 |
| D-042 | 2026-09-02 | 提议 | 规范自身的引用与证据纪律：证据等级三态（实测 / 具名转述 / 说明性示例）、概念出处与数字出处分列、口径标签随行、材料内容级去重；效力元信息不进模型常驻指令 | 本轮至少五次观察到转述升格（虚构示例→真实案例、二手数字→一手、预估→既成事实），且已进入本规范前三轮记录 | 对来源矩阵每个 V1 数字抽样回溯一手，统计标签不符率 |
| D-043 | 2026-09-02 | **已接受** | 系统架构为四个平面（知识 / 执行 / 控制 / 责任）加一条交付线，共 14 个部件；正文按部件重组，每部件一章；人单列为责任平面而非控制平面的一部分 | 52 个来源的统计显示“被提得最多的部件”与“最不能缺、最常出事的部件”不是同一批；原八层并列无主次，范式阶梯是历史叙事而非架构；人在不可省略投票中以 21 票居首且责任不可转移 | 见[架构确定](架构确定.md)的统计、候选比较与裁决；后续以真实项目检验四平面是否覆盖全部新增内容 |
| D-044 | 2026-09-02 | 已取代 | 修复施加在原则层而非样例层 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-045 | 2026-09-02 | 已取代 | 人的更正与更正的理由分开处理 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-046 | 2026-09-02 | 已拒绝 | **不采纳。**（2026-09-30 Alan 裁决，原话「按建议执行」）**理由**：前置的评估集本仓库不存在（[审计记录 013](审计记录/013-图工程换骨架-正方.md) §6.1 第 7 条「本仓库没有评估集」），并行评估、以评估结果切换这一步无处兑现；能落地的部分——模型代际更替时在隔离环境里以全删对照建立最小基线——已由 [33 §2 P8](33-评估与演进.md) 承载。**重开条件**：本仓库有了评估集之后单独再提。以下为原提议。能力上移时以重建替代叠加：执行者能力发生代际变化时先问"从零开始会怎么做"；重建版本在共享同一知识源的隔离工作副本中构建，与现版本并行接受同一组评估集，切换以评估结果为准 | 结构随模型能力变化而失配时，继续加约束会让约束越多越不生效（一手来源两例：架构漂移与半年内架构全变） | 在一次模型代际升级上实际走一遍并行验证，比较重建版与叠加版的评估结果与规则总量 |
| D-047 | 2026-09-02 | **已接受** | 边缘部件不设部件：以一条"外部"判据（权威记录源不由本项目治理 ‖ 已发生的事不能单方面撤销）加第六条架构级不变量「边界外不由我们控制」（读只引用不复制 / 写限阶段窗口且幂等留回执、结果未知即未定 / 可用性不保证分必需与推荐两档 / 唤醒不等于授权）替代之，落到 11、21、24 三处一行标注；并澄清不变量与平面接口为架构级内容 | 两者是同一事实的两个方向（那一侧不归我们管），其全部纪律都是约束的形状而非部件的形状；四条推论各自收紧一条已有规则，无新语义 | 出现被反复绕过的跨边界纪律，或出现无法由判据推出的跨边界纪律，即回到"升为一等部件"（见[架构确定 §6](架构确定.md#edge-components)证伪信号） |
| D-048 | 2026-09-02 | 已取代 | 第六条不变量补两条推论，把边界建模成双向 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-049 | 2026-09-02 | 已取代 | 不可逆动作的粒度与授权参数 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-050 | 2026-09-02 | 已取代 | 触发源的退场纪律归 33 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-051 | 2026-09-02 | 已取代 | 非交付运行是一类合法运行 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-052 | 2026-09-02 | 已取代 | 接手与考古场景的合法降级路径 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-053 | 2026-09-02 | 已取代 | 权威重建程序 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-054 | 2026-09-02 | 已取代 | 统计性与抽样验证的裁定语义 | **由 D-055 取代**，逐条去向见[归档件 A0⁗](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E5%8E%86%E5%8F%B2/%E5%BE%85%E5%86%B3%E7%AD%96%E6%B8%85%E5%8D%95.md#a0-round8)与[审计记录 003](审计记录/003-综合审计.md) | — |
| D-055 | 2026-09-03 | 提议 | 本轮综合审计的统一处置，六个改动：① 第六条不变量改写为关系模型（每次跨边界有权威侧与消费侧，四条推论在两端各落一次，判定同时登记可重读 / 有可比对版本 / 单写入者三项可执行前提）；② 在 00 §3 声明本套正文的默认作用域两轴——对象（本开发系统本身，含所依赖的外部机制，以及被交付产品中承载主张的那一部分，判据是"读它是为了回答一条主张"）与运行类型（产出类型：交付 / 事实；起点状态：从头 / 接手），21 的"起点"扩为"起点与类型"；③ 裁定与状态记录的通用形式是"结论 + 其成立条件"，不新增第四态；④ 40 的授权模型补动作粒度、反向方案与具名位置空缺三项，风险接受记录的两栏前移为准入条件；⑤ 09 加"判据优先于枚举与样例"与"规则引用的对象须能指出载体、归属与失效条件"；⑥「删除条件」取值域扩为 `{具体失效条件 \| 起始档 \| 运行类型限定 \| 写不出（仅责任结构型）}`，作用域由每条原则自己的该字段承载而不由任何一处列举原则编号 | 121 项待处理项（实质 113 项）聚成 5 个根因；照旧逐条落地十条候选估计新增约 45 行、原则 +5 且无配套删除，而本方案覆盖同一批发现，新增 0 个部件、0 个章节、0 条原则编号 | 本条取代 D-044、D-045、D-048、D-049、D-050、D-051、D-052、D-053、D-054 共 9 条候选（均已改记`已取代`）。验证：再走一次接手型与事实型切片，检验是否还会同时命中互相矛盾的要求；统计新写下的原则里"删除条件"取"写不出"的比例是否下降。论证见[003 综合审计](审计记录/003-综合审计.md)，落地见[执行记录·条文层](审计记录/003-综合审计/执行记录-条文层.md) |
| D-056 | 2026-09-03 | 已执行 | **归档更正，不是规则，不进生效登记表**：三样证据材料——各章「它解决什么问题」、§5 的源章节与主题综合映射、每条原则的「强度」尾标——此前误置于正文，现归入[追溯账本](追溯账本.md)，与架构确定、来源与证据矩阵同族。正文由五节变四节（最小职责与接口（含未决）／原则／L0–L3／追溯指针）。移出不删除，正文与账本合起来与迁移前逐字等价。**本条不产生任何判据**：证据材料不在正文是既有结构，不需要新判据支持；一次运行要不要加载账本由 D-015 的合同视图回答 | 这三样在正文里占 19.6%，而查一条规则必须穿过它们。落地后正文 71,022 → 57,939 字符（−18.4%）。**一度用"运行类型"论证它、并提出与 D-020 判据三合并，均已作废**：判据三的输出是改写句子而不是搬运文件，归档不归它管 | 检查器 C7 机械对账（正文每条原则在账本中有且只有一条记录，已做反例测试）。**待观测**：仓库总量反升 6.2%，说明移位不降体量——下一轮若仍以降体量为目标只能删除。 执行记录：提交 `c1793e7`。 |
| D-057 | 2026-09-03 | 试行 | **正文 10～40 共 14 章的 117 条原则整套以`试行`进入生效登记表**，期限至 2026-12-03，复审 2026-11-19（2026-09-23 续期一期，新的复审与到期日见[生效登记表](#effective-register) D-057 行，见 [D-114](#decision-index)）。阻断范围不逐条枚举，由每条自己的「删除条件」尾标承载；[00 §3](00-总览.md#default-scope) 的默认作用域声明随之生效。**给的是正文文本的效力，不是决策文本的效力**——各决策状态不改，登记表仍是唯一效力源 | 十四轮下来 56 条决策里 42 条卡在`提议`、**0 条用过 D-014 定义的`试行`**：`已接受`要求确定性、`提议`没有执行点，于是这个三态系统实际上按两态在跑，缺掉的正是 42 条各自需要的中间态。而这 42 条里 **35 条的内容早已写成正文**（按各章 `governed_by` 统计），开着的从来不是"该怎么写"而是"写好的这套算不算生效"——所以这是**一次裁决取代 42 次**，不是 42 个问题。同期实测：正文 117 条原则在[失败 Case 清单](失败Case清单.md)里拦住 0 条，原因不是写得差而是`提议`没有执行点，**在有效力之前这 117 条永远不会产生验证数据** | 一个`试行`期内检验三件事：① 有没有任何一条原则真的拦住过东西（对账[失败 Case 清单](失败Case清单.md)的"当时被拦住了吗"列；**截至本行写下的 2026-09-03**，此前该列的"是"全部来自机械检查器——**这一句此后已被推翻，见本格末尾的「修订」**）；② 31 章的 Gate 原则会不会因「最低 Gate 集合」仍未决而大量产出未定，以及那些未定是否可读；③ 有没有原则因有了效力而暴露出互相矛盾。**到期不追溯**：若这套正文站不住，它自己失效，不需要走废止流程。<br><br>**修订（2026-09-05）**：给检验① 括号里那句加了时点限定。原文不带时点，即是一句现在时的断言，**而它今天不成立**——[036 §1.1](审计记录/036-三条待裁的独立复验.md) 独立重算（先按行内代码掩码再切列，避开 [C-040](失败Case清单.md) 那行单元格里的竖线）：喂本行入库那一笔 `f280edf`（2026-09-03）的历史版本，该列的"是"确实全部是程序；而现文里 [C-038](失败Case清单.md)（入库 `e89a8f1`，2026-09-04）与 [C-045](失败Case清单.md)（入库 `addbffd`，2026-09-05）两条是**非机械拦住**，两条的「本该防住它的规则」列都指 [30 §2 P5](30-验证与测试.md)。**本行不抄该列的条数**——要数跑 [036 §1.1](审计记录/036-三条待裁的独立复验.md) 给出的那段掩码切列脚本现取；`repo_counts.py` 印的这一列有已登记未处置的裸切缺陷（[C-042](失败Case清单.md)），照抄它会抄到一个错数。[033](审计记录/033-待裁D-078-试行到期.md) 称这是三项检验在试行期内产出的、可机械复算的**唯一**一条真实变化，[036](审计记录/036-三条待裁的独立复验.md) 复核属实，并指出**更正的方向是给"续期"一侧递论据**。**按 [D-077](#decision-index) 第 ① 句判为记账修改**：改的是`后续验证`列里一句对既往事实的描述，不增减 blocks 或 grants 覆盖的动作集合、也不改变其成立条件，故[生效登记表](#effective-register)里 D-057 那一行的 `approved_at`、`review_at`、`expiry` **三格一字未动**，登记行整行未动。**两件须写明的**：① **D-077 三句的对象逐字是「改「生效登记表」某一行」，而这句话不在登记行里，在决策索引这一行的`后续验证`列——严格说 D-077 管不到本处**；此处仍按它的判据判，是从严不是从宽（它第 ② 句要求"判不出属哪一类的按实质修改办"，而本处判得出）。留痕位置也随之改：决策索引表没有「上游依据」格，本句写在`后续验证`格末尾。② 本次改动使 [022](审计记录/022-执行前审计-价值与顺序路.md)／[026](审计记录/026-待裁D-073-试点判据与观测窗.md)／[033](审计记录/033-待裁D-078-试行到期.md) 三处对本格的**整段**逐字引用成为对"修订前版本"的引用；它们是带日期的审计快照，本轮不改，**但此后不得再把那三处当作本格现文的逐字引处**（[C-044](失败Case清单.md) 记的正是"援引一句不在原处的话"这个病）。被推翻的那半句本身逐字保留在括号内，故按该子串检索仍可命中。<br><br>**数据来源（2026-09-24）**：已有真实项目数据：[审计记录 052](审计记录/052-L3验证冲刺-NFBY.md) §5（检验①②③）。只作指针，不作复审结论；是否满足[生效登记表](#effective-register) D-057 行的再续条件由复审判。本句只加在本格末尾，登记行整行未动。 |
| D-058 | 2026-09-03 | 已拒绝 | **三项均不需要新规则**（2026-09-04 Alan 裁决）。原提案是给接手场景补三处路径。**① 权威冲突能不能降级——已有明文，拒绝新增**：[08 §8](08-规范效力元治理.md#conflicts) 第 1 条写着"两条生效规则在同一 scope 内给出相反判定时，失败关闭：停止并报告，不由执行者挑选"，即按设计不许降级；主张冲突一侧由 [11 §2 P1/P2](11-项目知识.md) 与 [00 §3](00-总览.md#default-scope) 承载（登记冲突、声明各载体范围与版本、冲突未消除前逐载体绑定证据）。**② 22 章接手路径写在字段外——归类有误，拒绝改动**：[22 §2 P2](22-上下文装配.md) 那句"任务对象本身是历史时第三层正是当前所需"**不是作用域声明**，而是判据本身的说明；[09 §4](09-跨工具通用性.md#two-axes) 管的是"这条在什么范围内不适用"，而 P2 在接手运行中完全适用、只是判出不同结果。Case C-014 据此更正归类。**③ 合同事实型视图的边界——接受，已执行**：[上下文合同](../CONTEXT_MANIFEST.md)第 7 项写明处置冲突、判断效力或判断内容归属时 08 与 09 一并计入"目标章"；事实型运行的问题来源由请求者在起点给定。这是载体澄清，不产生新规则，故本条整体记`已拒绝`而非部分接受 | **四问四中：答案已在正文里，问题是找不到。**第十二轮把 08 §8 的失败关闭读成"缺降级路径"，第十四轮把一句判据说明归类成作用域缺陷——而写并维护这些条文的是同一方。117 条分布在 14 章，作者本人定位不到应答条款：**这是可发现性问题，不是完备性问题**，而"每次推理看什么"正是 [22 章](22-上下文装配.md)存在的理由。第 ③ 项的改动同时就是这个共同成因的处置 | 第十二轮没读到 08 §8 的直接原因是视图没纳入元治理两章，已修；下一次事实型运行可检验它是否真的把人带到那里 |
| D-059 | 2026-09-03 | 已拒绝 | **不改 [33 §2 P9](33-评估与演进.md)**（2026-09-04 Alan 裁决）。原提案是处理"持续零消费"不可判定：甲取未定、乙补留痕机制。**两者都不需要**——"持续零消费"是一个**缺成立条件的结论**，按 [30 §2 P1](30-验证与测试.md)"任何一态都是结论 + 其成立条件的一对，缺成立条件即记未定"已判未定；未定则不得据以删除。在 P9 里再写一遍是同一条规则的第二处副本 | 30 章与 33 章现都随 [D-057](#effective-register) 生效，这条链是通的，无需新增条文。乙案（补留痕机制）另有实测反证：27 条 Case 里 5 条出自检查器自身，本仓库加机制一直在产出新缺陷 | 取此裁法的代价是 Thin 只剩"绑定 Case 不再复现"一条路；当前无处兑现——117 条里 105 条没绑任何 Case，Thin 本来就没有候选 |
| D-060 | 2026-09-03 | 已拒绝 | **不允许。**（2026-09-23 Alan 裁决，「全按推荐」）AI 评定低风险后由团队自批，不采纳；[40 §2 P7](40-人的检查点与授权.md)「完成判定与风险接受不下放」维持原样。**理由**：本仓与在册采用项目都没有 AI 风险评定的实测数据（评定与人工复核的对照），「评定可信」这个下放前提没有证据；P7 的删除条件是「写不出」（责任结构型）；错误授权的代价高于多问一次人（[08 §3](08-规范效力元治理.md#unmarked-default) 的不对称）。**重开条件**：有了风险评定的实测数据之后再议。以下为原提议。**PSR 型自批是否可接受**：AI 评定低风险后由团队自批，不上升到具名授权人。默认裁决为"允许，条件是评定规则为慢变可审计的角色图变更 + 风险加权抽样 + 观察期"；备选是禁止（代价：拒绝一个一手实践）| 原待决策清单 A0″ 第 11 项的三件事之一，另两件已各自结案（认知覆盖声明已降级出正文、机制类型清单入附录），只有这一件仍开着且**从来没有自己的决策编号**——它是[40 §1](40-人的检查点与授权.md)「未决」里明写"待责任人裁定"的那条 | 它改的是[40 §2 P7](40-人的检查点与授权.md)「完成判定与风险接受不下放」的边界，而该条删除条件为"写不出"（责任结构型） |
| D-061 | 2026-09-03 | 已拒绝 | **不单独复核，并入 [D-057](#effective-register) 于 2027-02-17 的复审。**（2026-09-30 Alan 裁决，原话「按建议执行」）**理由**：六组边界已随 D-057 进入`试行`，D-057 登记行已设 `review_at` 2027-02-17，届时复审即覆盖这六组；单独再开一轮是重复劳动。D-057 登记行不改（按 [D-077](#effective-register)，对登记行的实质修改须重新批准），去向只记在本行。以下为原提议。**复核第六轮就地裁定的六组跨章边界**（原 A0‴ 第 3 项）：三态语义、验证基线、屏障与重试预算、确定性下沉、结构性删减、成本口径 | 第六轮正文重组时这六组是就地裁的，未单独立决策；此后十轮无人复核。它们现在随 D-057 进入`试行`，**即以未经复核的形态取得了阻断力** | 逐组给出"当时怎么裁的、依据是哪几个来源、现在还成立吗" |
| D-062 | 2026-09-03 | 提议 | **工程闸门四问**（原待决策清单 B 组四项，此前无编号）：① 所有项目不可省略的最低 Gate 集合是什么、如何按 Web / 移动端 / 后端 / 数据项目增配；② 大文件与复杂度用硬失败、警告，还是只在评审中判；③ 安全扫描、依赖审计、密钥扫描哪些是最低强制项；④ CI 失败时是否禁止 AI 继续新增功能，直至主线恢复健康 | 第 ① 项是 [31 §1](31-守卫与权限边界.md)「未决」明写的仍待定项，**且它为空导致一切"全部 Gate 通过"按 D-014 空集合条款判未定**——31 章随 D-057 进入`试行`后，这个空集合开始有实际后果。第 ②③④ 项是它的项目侧增配 | 本仓库没有 Gate 实例（按 [D-057](#effective-register) 的作用域判据 31 章的原则在此不被触发），**这四问只能在一个真实产品项目上答** |
| D-063 | 2026-09-05 | 已执行 | **已裁（2026-09-23 Alan 批准）：不以图工程作规范骨架。**[D-043](#effective-register) 的 blocks 已挡住在 14 部件之外另立骨架、按新结构加章节，不需要另做改动，本条改记`已执行`；执行记录：D-043 登记行。以下为原提议。**不以图工程作为规范骨架**；降为方法层来源，语义按各条分散吸收（提议原文见[输入材料 005 §5](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E8%BE%93%E5%85%A5%E6%9D%90%E6%96%99/005-%E7%AC%AC%E4%BA%94%E8%BD%AE%E5%9B%BE%E5%B7%A5%E7%A8%8B%E6%9D%90%E6%96%99%E7%BB%BC%E5%90%88%E8%AE%B0%E5%BD%95.md)的候选决策表） | 依据来自[审计 015](审计记录/015-图工程三原则综合审计.md) 的三方案裁定矩阵：换骨架那一栏「可指认的删除项」填的是**指认不出**，正文字符净变化**未定**（净减为零、净增下界大于零），且这条骨架就是[架构确定](架构确定.md) §3 用同一份 52 源证据裁掉的候选 C。**015 那个「≥555 处账本改动」不得引用**——[016](审计记录/016-第二十四轮提交前对抗性复核.md) F-08 查出其中 178 处是正文互引、自身加总有误 | **证伪信号逐字照 005 §5**：出现厂商官方文档/标准文件采用该分类法 → 重判；出现无法归属 14 部件的新增内容 → D-043 证伪信号。**方向已于 2026-09-23 裁定**（005 §7 第 1 件）。另：综述正文 §6.1「图工程的局限」与 §11.2 两节本轮未读到（WebFetch 稳定截断在 §4.4），读到后作本条的复核输入 |
| D-064 | 2026-09-05 | 已执行 | **C-1 阻断点盘点已执行完毕；出口是事实不是规则，不进生效登记表。** 判据开工前写下（[33 §2 P4](33-评估与演进.md)「先写成功与失败标准，再运行」）：按 [31 §2 P1](31-守卫与权限边界.md) 的四级，逐一归档本仓库现存的每一个阻断点，判据是“动作空间被该通道穷尽”，出口是一份带成立条件的事实（[00 §3](00-总览.md#default-scope) 事实型运行的出口定义）。**结论三条**（照抄[审计 023 §2](审计记录/023-执行清单-冻结版.md)；两条 `ls` 命令见该节，本轮现跑两者皆为 0）：① **本仓库零启用的 git 钩子、零版本化 CI**；② **按 31-P1 的四级，本仓库的「约束」级与「警告」级都是空集**——唯一实际运行的阻断是人工调用的两个脚本（`check_normative_force.py`、`linkcheck.py`），它们不在任何自动通道上，按“动作空间被该通道穷尽”的判据**连“警告”级都不成立，因为绕过它们不需要任何动作**；③ **[015](审计记录/015-图工程三原则综合审计.md) §2.4 预写判据的后半句“而对检查器可得”不成立**（021、022 各自独立查到）。**成立条件**：以上三条只对本仓库当前工作副本成立，且只覆盖“版本化的自动通道”；执行者本地私有的钩子不可见，**这一格记未定，不折算** | 005 §5 给本条的证伪是「出口若产出的是变更而非事实，即违反 00 §3，作废重跑」——本次出口是事实，正文 0 行改动，未产生任何变更。**本条不产生任何判据，也不进生效登记表**：事实不是规则。 | 两条命令可复跑，下一轮复跑必然得到同样的值或一个真实变化——**本批十五项里它是唯一一项其产出在结构上不可能漂移的**（021 的判定）。**本条顺带回答了 [D-057](#effective-register) 检验① 的一半**：正文整套原则在[失败 Case 清单](失败Case清单.md)里拦住 0 条，此前归因于「`提议`没有执行点」；现在多一条实测的共同成因——**本仓库根本没有任何自动执行点，无论条文是`提议`还是`试行`**。发现另记 [C-041](失败Case清单.md)；能把「警告」级从空集变成非空的那一行配置另立 D-074 待裁。 执行记录：提交 `a282e31`。 |
| D-065 | 2026-09-05 | 已拒绝 | **B 的三条改判据本轮一条不落。** B-2（30-P5 加「验证者的默认判决是否定」）与 B-3（21-P5 上限型加「达到上限时创建失败而非仅告警」）**砍**；B-1（31-P1 通道穷尽）**推后**，不是被否 | **B-2 与 [30 §2 P1](30-验证与测试.md)「未定不得折算」相撞**：把默认判决设成“否定”，是把“尚未证明通过”折算成“失败”，而正文给的默认是「未定」，其四种子原因第一种就是「未执行」（020、021 各自独立查到）。**B-3 被 [21 §2 P5](21-调度与拆分.md) 的标题句逐字命中**：「**三类停机条件并存，任一触发即转阻塞并升级**」——“转阻塞”不是“告警”，上限型正是三类之一；残余差别（“创建失败”＝某编排器抛错）是载体绑定，按 [D-020](#effective-register) 判据三不进正文。**B-1**：015 自己写着须在 C-1 之后，C-1 已随 D-064 跑完，但 B-1 的措辞依赖试点结果，而试点（D-068）的判据本身未定 | B-1 是顺序问题，待 D-073 裁出判据、试点跑过之后重提。**须一并记住 015 写下的自指**：B-1 自己是条文，按它自己的判据落在“提醒”级——而 D-064 实测本仓库对条文一侧没有任何必经路径，**单独的 B-1 是又一条无执行点的条文** |
| D-066 | 2026-09-05 | 已拒绝 | **记忆治理的五项新增本轮一条不落条文。** 第 10 项（来源标记必填）**已有明文，砍**；第 8 项（双时间轴四时间戳）与第 12 项（Thin 第三信号）**降档，砍**；第 11 项（控制流不得来自记忆内容）**不落条文，改作一条冲突交 Alan 裁**（另立 D-072）。**整体记`已拒绝`而非部分接受**，照 [D-058](#decision-index) 的先例 | **第 10 项**（020）：[12 §2 P4](12-记忆与知识治理.md) 逐字「**来源只取人的自述或可定位的观察，模型自己的产出不进候选**，只进本次运行的证据与轨迹」，其删除条件逐字「**来源判不出时记未定并按弱置信登记，不得硬塞进最近一类**」；“某来源声称 X ≠ X”是 [32 §2 P1](32-证据与追踪.md)「五个概念不可互换」的直接推论——入池闸门与身份保全两侧都已有明文。**第 8 项**（020）：可降档；且它自带的可删项自标须经审议，按「未定不折算」不计入已得的可删项。**第 12 项**（020）：前提就错了——落地包 02 写 Thin 信号是两条，[33 §2 P9](33-评估与演进.md) 现读是七条，其中「维护与上下文成本超过收益」逐字覆盖“被反复加载却从不被遵守”；往枚举里追加第八项正是 [09 §10](09-跨工具通用性.md#validation) 反例表要挡的。**第 11 项**（020）：与 [12 §2 P5](12-记忆与知识治理.md) 逐字「**强可驱动执行**，弱只提示风险，影子只助发现与背景召回、不得单独作为执行依据」**相反**——正文的立场是分档驱动，不是一律不驱动；落地包 02 §7 汇总表把本项的“对应现有条文”记为 `—`，**它没有核到 P5** | 第 11 项**不是“新增 vs 已有”的问题，是两条主张冲突**——按 [08 §8](08-规范效力元治理.md#conflicts) 第 1 条「两条生效规则在同一 scope 内给出相反判定时，失败关闭：停止并报告，不由执行者挑选」，本条不由执行者挑选，见 D-072。005 §7 第 2 件原把第 10、11 两项一起列为“是否接受一次纯增量”待裁；**第 10 项现已由“已有明文”关闭，只余第 11 项** |
| D-067 | 2026-09-05 | 已拒绝 | **上下文装配 R1/R2/R3 三档判据不进正文**，形态留在[落地包 01](图工程落地包/01-上下文管理落地设计.md)。正文 0 改动 | **三档结构与 [23 §2 P3](23-方法库.md) 逐字一一对应**（020 判「逐字在 23 §2 P3」）。该条逐字：「**只写模型和工具拿不到的内容。**公开语料里的不写；代码、配置与运行环境里可直接读取的不写；只有来自人的头脑与组织结构的内容必须写。“不写”是默认而不是禁令：同一条可推断的事实第二次导致失败时可以写下来，但须绑定删除条件」——R1 手写永久＝只有来自人的头脑与组织结构的内容；R2 可图算＝代码配置与运行环境里可直接读取的不写；R3 待图化＝第二次导致失败时可写、须绑删除条件，**连“绑删除条件”都同字**。区别只在作用域（那条管方法库，R1/R2/R3 管上下文合同），按仓库优先级最多是「加一句作用域」档；**[D-020](#effective-register) 另挡一道**——合同是载体，载体实例效力为零（021 独立查到，与 020 的路径不同） | 005 §5 原给的证伪是「机器半上线后手写半没缩短 → 判据失效」；本轮不落条文，因而不触发该检验。**若将来真要落，先答的是“加不加那一句作用域”，不是三档判据本身** |
| D-068 | 2026-09-05 | 已拒绝 | **不跑。**（2026-09-23 Alan 裁决，「全按推荐」）类型头试点不做。**理由**：[D-073](#decision-index) 写死的开工条件是「[D-074](#decision-index) 裁开」，而 D-074 已拒绝挂执行点，条件不会满足；D-073 已定的判据留档，不作废。**重开条件**：D-074 被重新裁开。以下为原提议。**关系型类型头试点本轮不跑，且判据本身未定。** 原提议是在 30 或 31 章择一就地改写作试点，[019](审计记录/019-四件待裁事项的选项与推荐.md) 待裁三推荐 30 章 | 三条拦阻，任一件都足以拦下它（022 查出）：① **`C-1 → 试点` 的依赖不成立**——C-1 产出的是「阻断点按约束力分级的名册」，试点判据要的是「缺陷报出史」，两者不对口；019 给的顺序理由只论证了“条文改动会污染试点”，**一个字没论证这个箭头**。② **判据里的“此前”这个基准谁都没给**：按字面“任何东西”，[016](审计记录/016-第二十四轮提交前对抗性复核.md) 与 [018](审计记录/018-第二十五轮提交前对抗性复核.md) 报出的那批全部出局、试点必败；按上下文“现有机械检查器”，试点必胜——**同一句判据两种读法相反裁定，按 [30 §2 P1](30-验证与测试.md) 记未定**，这是裁定问题，C-1 修不了。③ **就地改写 30 章可能重置 [D-057](#effective-register) 对 30 章的观测窗**，而 30 章是这扇窗里产出数据最多的一章；019 与 015 全文都没提过这个问题 | **判据未定就不能开工**——[33 §2 P4](33-评估与演进.md)「先写成功与失败标准，再运行」，[C-024](失败Case清单.md) 记七轮全没写。“此前”基准的定义与观测窗风险一并交 Alan 裁，见 D-073。005 §5 原给的证伪「导不出一条此前没被报出的真缺陷 → 当场作废」**正是那句读法未定的判据本身**，因此它现在不能充当检验。**2026-09-24 修订**：重开条件「D-074 被重新裁开」已由 [D-120](#decision-index) 满足；是否开跑待裁，本行状态不动。**2026-09-25 修订**：2026-09-25 Alan：暂不开跑，待 Gate 简化落地后再议（落地见 [D-122](#decision-index)）；本行状态不动。 |
| D-069 | 2026-09-05 | 已拒绝 | **只剩前半，且不做。** 删 [25 §2 P3](25-执行者与模型.md)：**本轮不删，改记为发现**，会漂计数那一侧另立 [D-076](#decision-index) 待裁。**后半（强度表）已从本条移出到 [D-075](#decision-index)**——它换一种形态后可做，且已执行，与本条的裁决方向相反，合在一行会让状态列失真（C4 当场拦下过一次「部分执行」这个不存在的状态值） | **前半**（021 查出，主 Agent 复算确认）：删一条原则会让全仓多处 `117` 字面量过期，**其中一处在[生效登记表](#effective-register) 的 D-057 行内**——按 [D-014](#effective-register) 生效登记表是唯一效力源，改它的文本不是记账动作。**命中处数跑 023 §1.4 给的 grep 现取，本行不抄条数**（该数本身会漂，正是发现 [C-039](失败Case清单.md) 的内容）。**后半：015 写的形态（删掉这批行）确被 C7 挡住**——C7 把追溯账本各章段内的强度表行与正文原则行逐一对账，miss / extra / dup 任一非空即报缺陷，删行即等条数 miss；且[追溯账本](追溯账本.md) §1 逐字声明「**本文与正文之间只有一条硬约束：每条原则在本文中有且只有一条强度记录，编号与正文一致**」。**但 [021 §5.2](审计记录/021-执行前审计-删减路.md) 给的第二种形态不碰这两道约束**：保留 `| Pn |` 行形状、只压空值列、在 §1 声明默认值——C7 的正则逐字 `^\|\s*(P\d+)\s*\|` **只认行首形状、不读值列**。**已执行，两项自检 PASS，净减跑 `wc -c` 现取（字节与字符两个口径差一个量级，引用时必须写明单位）** | **[015](审计记录/015-图工程三原则综合审计.md) 把这处删除记作「可指认的删除项｜有一处，且可复算」，B 与 C 两栏填的都是这同一处、A 栏填“指认不出”——三个方案的账都建立在它上面，而它写的那一种形态不成立。** 主 Agent 第一版据此把整项砍掉，**这一步也是错的**（[审计 024](审计记录/024-第二十五轮第二批提交前对抗性复核.md) F-03）：021 同段给了可行形态，被漏掉了。 发现另记 [C-040](失败Case清单.md)。**（此处第二版残留过一句「要做需先改 C7 与账本硬约束」，与本行依据栏已判它可做相矛盾，2026-09-05 按[审计 024](审计记录/024-第二十五轮第二批提交前对抗性复核.md) R2-02 删除；那句只对 015 写的那种形态成立，正确的带限定表述在 [C-040](失败Case清单.md)。）** 005 §5 给前半的检验「25-P3 须确认 31-P7 是否真的全包含」**本轮未做，记未定** |
| D-070 | 2026-09-05 | 已拒绝 | **不为 `docs/图工程落地包/` 另立一条“登记为载体实例、效力为零”的决策** | **五份文件的第 1 行逐字已写**「**效力为零：本目录是载体实例，不是正文。**」（`01`～`05` 各自首行，现跑可验）。005 §5 自己给的证伪命令 `grep -rn '图工程落地包' docs/[1234][0-9]-*.md docs/0[89]-*.md` **本轮现跑返回空**——正文十四章与元治理两章无一处引用落地包，不违 [D-020](#effective-register)「阻止把附录载体实例引用为落地要求」 | 证伪命令可复跑：返回非空即违 D-020，届时重开本条。**该命令自带的限制照抄 005 §5**：`check_normative_force.py` 的 C1–C10 无一项能查这件事，不要指望它 |
| D-071 | 2026-09-05 | 已拒绝 | **不立“对齐 12207:2026 / SLSA v1.2 / 42001:2023 三份标准的空缺登记”** | **它唯一的动作是“不许说话”**（005 §5 原文：本条在拿到三份标准正文之前不得宣布任何对齐结论），**是无执行点条文**；而三份标准的正文在付费墙内，本轮取不回来——**取不回来就写不出对照**，那份“哪几条本规范已有、哪几条缺、哪几条不适用”的三档计数无从产出 | 005 §5 给的检验是「逐份取回其条款目录，与正文 14 章逐条比对」。**复活条件是拿到三份标准正文或其公开条款目录**；在此之前任何对齐结论**按未定处理，不折算**。**与最高原则的关系须写明**：Alan 逐字的最高原则第一句是“以行业标准规范推荐”，而本轮三路没有一路能取回标准正文，**本规范与真标准的距离这一格记未定** |
| D-072 | 2026-09-05 | 已拒绝 | **不是真冲突；三个出口一个不取，正文 0 改动**（2026-09-05 Alan 裁决，依据[审计记录 031 §3](审计记录/031-四条待裁的整合与推荐.md)）。原问的是 D-066 第 11 项（控制流不得来自记忆内容）与 [12 §2 P5](12-记忆与知识治理.md#memory-retrieval) 的冲突如何处置；**答案是它根本不构成 [08 §8](08-规范效力元治理.md#conflicts) 第 1 条意义上的冲突**，见原因栏的程序层与实体层两重理由。取的是「关档 ＋ 落地包账面更正」这一路——它是四个选项里**唯一自带删除**的一个（把"无可删项"那一格消掉），且堵住复发。**配套的[落地包 02](图工程落地包/02-记忆管理落地设计.md) §4.3 与 §7 汇总表第 11 行已由本批另一路同批更正**（该文件首行自声明效力为零，此处只是账面对齐，不产生任何效力） | **程序层：要件不成立，冲突处置不触发。** [08 §8](08-规范效力元治理.md#conflicts) 第 1 条逐字「**两条生效规则**在同一 scope 内给出相反判定时，失败关闭：停止并报告，不由执行者挑选」——要件是"两条**生效规则**"。而拟加条文在效力为零的[落地包 02](图工程落地包/02-记忆管理落地设计.md) 里，本条自己记`提议`，[08 §1](08-规范效力元治理.md#force-states) 那张状态表里`提议`一行的「可阻断」与「可授权」两栏逐字都是"否"。**故按 [08 §1](08-规范效力元治理.md#force-states) 与 [08 §3](08-规范效力元治理.md#unmarked-default) 处置，不按 §8**——**这不是改节号**：[030](审计记录/030-四条待裁的独立复验.md) 复验查明节号与引文都对，改的是"哪一条适用"。**实体层：两者 scope 不重叠。** [12 §2 P5](12-记忆与知识治理.md#memory-retrieval) 的 scope 由三处自证锁定——主语是"条目"、「防的失败」逐字「把"相关"当"可复用"驱动错误流程」、「删除条件」逐字「模型判断"是否同一问题、是否可迁移"的精度」——即**内容可复用性分级**；[31 章](31-守卫与权限边界.md)的 scope 由章头逐字「定义什么不许做、能力有多大」与 [31 §2 P6](31-守卫与权限边界.md) 的维度枚举锁定——即**能力面与禁止项**。字面撞车只发生在提案越出它自己声明的落点的那两句上。**另记提案自身一处缺陷**：它引的 CaMeL 原文逐字带 `untrusted` 限定词（"the untrusted data retrieved by the LLM can never impact the program flow"），**提案正文把这个词丢了**，泛化成"L2/L3 的内容"；而置信态「**由来源节点与验证证据决定**」这句**逐字在[术语表](术语表.md)，不在 12-P5 的正文里**（归属照 [025](审计记录/025-待裁D-072-记忆与控制流.md) 的原始引处，不上移），它正是同形状的按信任分流——**12-P5 比提案更贴近提案自己引的那句** | **记`已拒绝`而非部分接受**，照 [D-058](#decision-index) 与 [D-066](#decision-index) 的先例：三个出口一个不取，且 [D-014](08-规范效力元治理.md) 的状态值域里没有"部分接受"这一档——上一轮检查器 C4 当场拦下过的是「**部分执行**」这个同类的不存在值（见 [D-069](#decision-index)），本行只借其先例、不改写它拦的是哪一个。**反向的失败仍被三条独立关死**：[31 §2 P6](31-守卫与权限边界.md)、[31 §2 P8](31-守卫与权限边界.md)、[12 §2 P3](12-记忆与知识治理.md#memory-retrieval)——一条记忆条目要成为权限依据须同时穿过三条；**正向的缺失不产生失败，只产生保守**（[017](审计记录/017-Alan图工程综合的正文对照.md) 对同型缺口的判定，本条照搬其口径）。**重开条件**：出现一条实测的"记忆内容 → 控制流"绕道，本判定即被证伪，回到"31 章新增一条"那一路——**但届时先要过 [D-079](#decision-index)**（新增一条原则是否自动随 [D-057](#effective-register) 生效）。**可复跑**：`grep -n untrusted docs/图工程落地包/02-记忆管理落地设计.md` 现取那个被丢掉的限定词 |
| D-073 | 2026-09-05 | 提议 | **两问都裁了；试点本轮仍不跑**（2026-09-05 Alan 裁决，依据[审计记录 031 §3](审计记录/031-四条待裁的整合与推荐.md)）。**第一问，"此前"取「本仓库已版本化的书面记录」**，裁决原文逐字采 [026 §1.3](审计记录/026-待裁D-073-试点判据与观测窗.md) 的丁：「判定面为 `git ls-files` 覆盖的全部 `.md` 文件的当前内容与历史内容，不含未提交的工作副本、不含会话记录、不含任何人的口头或自述。一条候选缺陷若能在该面内被逐字回查到已被书面报出，即判为"此前已报出"，不计入试点产出；判不出是否为同一条的，记未定，不折算进"报出了"。」（判定面大小现跑 `git ls-files "*.md"` 取行数，**本行不写数**。）**第二问，观测窗不会重置。** 试点（[D-068](#decision-index)）本轮仍不跑，**重开条件写死为「[D-074](#decision-index) 裁开」**——而 D-074 已于同日裁为不挂，故本条现处于「判据已定、开工条件未满足」。**状态记`提议`，不是待裁，也不记`已执行`**（[D-110](#decision-index)）：两问要到试点开跑时才被适用，现无执行可记；两问的答案都是对既有条文的读法，不产生新规则、不进生效登记表；记`已接受`会触发检查器 C4（索引称生效、登记表无此行） | **第一问选丁的三条不作弊理由**（逐条可独立驳，照 [026 §1.3](审计记录/026-待裁D-073-试点判据与观测窗.md)）：① **它是所有可判定候选里对试点最不利的**——[019](审计记录/019-四件待裁事项的选项与推荐.md) 指名的那批"现成材料"在丁下一条不剩；② **它不是为本案新造的口径，是本仓库正在用的那把尺子原样搬过来**——逐字就是[失败 Case 清单](失败Case清单.md) §1 的 A 档定义「从 git 历史或当前文件即可独立复算，不依赖任何人的叙述」，[C-034](失败Case清单.md) 与 [C-041](失败Case清单.md) 的降档都是按它做的；③ **两个结局都可达**，且灰区永远倒向未定，这是丁的反作弊闩。**被否的三种**：全称"任何东西"**不是必败而是判不出**（[022](审计记录/022-执行前审计-价值与顺序路.md) 这里判错了，026 更正）；"现有机械检查器"是让试点必胜的作弊读法；"已进 Case 清单"把一个已被登记为不可判定的谓词放在承重位置（[失败 Case 清单](失败Case清单.md)的读数八逐字「而"算不算一次"的判据从没定义过」）。**第二问的依据**：本轮现跑，[D-057](#effective-register) 的生效登记行里"观测窗"与"重置"两词**各 0 次**（复跑：取出该行后数这两个词），是审议侧造的词；而 [08 §6](08-规范效力元治理.md#trial-expiry) 逐字「需要继续生效必须**重新批准并写入新的 approved_at 与 expiry**」，全仓无第二条改这两格的路径。**真代价是混样不是清零**，暴露面只有 [30 §2 P1](30-验证与测试.md) 与 [30 §2 P5](30-验证与测试.md) 两条 | **另记一条比基准更致命的，且它不因本裁定消失**：这个判据**没有对照臂**——[33 §2 P4](33-评估与演进.md) 逐字要求登记「**基线、候选、结果工件、限制与回退方式**」，而试点的"候选"是类型头、「**基线**」这一格是空的，成败都归因不到类型头上（[026 §1.5](审计记录/026-待裁D-073-试点判据与观测窗.md) 查出，此前无人写下）。另：二值判据本身撞 [30 §2 P1](30-验证与测试.md)「聚合分数不得把未定折算为部分通过」——不允许"部分成功"是对的，**缺的不是一档，是成立条件**。**重开时按选项乙跑**：干跑，只对 [026](审计记录/026-待裁D-073-试点判据与观测窗.md) §2.4 划出的那批零数据原则计分（**条数照该节现取，本行不抄**），正文 0 改动；选项甲（就地改写 30 章）已被否，理由是净增八处无可删项且混样。**本条不产生规则，不进生效登记表。****两处记未定，不折算**：① [026](审计记录/026-待裁D-073-试点判据与观测窗.md) 另建议"D-074 若裁不开则 D-068 改记`已拒绝`"，而[审计记录 031](审计记录/031-四条待裁的整合与推荐.md) 采纳的是"重开条件写死为 D-074 裁开"、未把 D-068 列进最小动作集——**两者对 D-068 的处置不同，本轮不代裁，[D-068](#decision-index) 状态不动**；② [031 §4](审计记录/031-四条待裁的整合与推荐.md) 记着那份"有实例的章"名单是从失败 Case 清单派生的**代理指标**，它与 [D-057](#effective-register) 说的"部件实例"是否同一判据，**本轮判不出** |
| D-074 | 2026-09-05 | 已取代 | **不挂。**（2026-09-05 Alan 裁决，依据[审计记录 031 §3](审计记录/031-四条待裁的整合与推荐.md)）pre-commit 不挂，pre-push ＋ 版本化钩子目录那一路也不走。**同时做的是另一件事**：对抗性复核 +1 分句（要求对抗者把两项自检与所用命令的原始输出连同退出码附进复核记录，不得转述），**已由本批另一路加进[仓库工作须知](附录-载体实例/仓库工作须知.md) §5 第 4 条"给对抗者的话"，成为其中第 ③ 条**。**那一句买到的只是 [31 §2 P9](31-守卫与权限边界.md) 要的他证性（判定不由产出方自报），不改变 [31 §2 P1](31-守卫与权限边界.md) 的级**——本仓库的「约束」级与「警告」级**仍是空集**，它**不使「警告」级非空**；引用它时不得暗示相反（[C-041](失败Case清单.md)） | **已由 [D-120](#decision-index) 取代**（superseded_by：D-120，2026-09-24）：Alan 2026-09-24 裁「选A」，重开本条、本仓挂提交闸门，本条写明的三项欠账（31-P4 合同、P9 失效探测、P10 豁免留痕）已按 D-120 落实。以下为原记录。 **理由必须换，不是"价值为零"。** [030](审计记录/030-四条待裁的独立复验.md) 用四条独立理由加一条现场证据证伪了 [027](审计记录/027-待裁D-074-执行点.md) 的那个推论：历史是被待评估机制自己筛过的（[仓库工作须知](附录-载体实例/仓库工作须知.md) §2 逐字「两项自检（每次改完都要跑，都要 PASS）」，重放量到的是人工执行率 100% 下的**边际**值）；仓库已登记的两条真阳性 [C-008](失败Case清单.md)、[C-010](失败Case清单.md) 在提交前就被修掉，**任何按提交树做的重放都结构上看不见它们**；n=21 的零事件按三法则上界与"每七笔漏一条"完全相容；[D-065](#decision-index) 刚砍掉 B-2 的理由正是"把尚未证明通过折算成失败"，而 027 的判据是同一个折算的镜像。**正确的记法是「价值未定，成立条件"人工执行率不下降"；而代价确定且已知」。** 代价逐条：① **历史真阳 0、假阳 2**——两次都挡在本仓库自定的"拆四笔提交"纪律上；② **挂上即造出本仓库第一个 Gate 实例**，[31 章](31-守卫与权限边界.md)十条原则随即按 [D-057](#effective-register) 的作用域判据生效，**立刻欠 [31 §2 P4](31-守卫与权限边界.md) 的整份 Gate 合同 ＋ [31 §2 P9](31-守卫与权限边界.md) 的失效探测 ＋ [31 §2 P10](31-守卫与权限边界.md) 的豁免留痕**——"一行配置"这个标价不成立；③ 脚本文件头自己逐字写着「**这是 checker，不是 Gate。把它接成阻断需要单独的 Gate 决策（D-018）**」，而 [D-018](#decision-index) 至今仍是`提议`；④ **收益命题两次不成立**——「动作空间被该通道穷尽」这句判据**不在 [31 章](31-守卫与权限边界.md)正文里**（现跑 `grep -c 动作空间 docs/31-*.md` 得 0），它出自 [015 §2.3](审计记录/015-图工程三原则综合审计.md) 的 B-1 拟增文本、状态`提议`；按 B-1 原文钩子也有绕过路径（`--no-verify`），按 31-P1 正文两种读法只有一种支持"挂上就是警告级"。**一处记账更正**：[027](审计记录/027-待裁D-074-执行点.md) §2.4 与 [031 §3](审计记录/031-四条待裁的整合与推荐.md) 都把 P4 的合同写成"十二项"，**本轮按 `；` 切分 31-P4「至少声明」那一句现跑得 11 项**（027 自己那段括号里列出的也只有 11 个）——**故本行不写项数，只写"整份合同"**，要数照 31-P4 原句现取 | **人侧排除的处理，两半都要写。** Alan 2026-09-02 那句"先不要考虑 hooks 等需要写代码的东西"，按 [D-042](#decision-index) 的证据三态仍记**具名转述**（本仓库内无第二处书证），不作实测引用。**它的表层理由（"要写代码"）已经过期**——今天确实只差一行配置；**但它挡住的实质风险今天证据更足**：那一行配置会当场拉出一整份 Gate 合同、一套独立于钩子自身的失效探测、一套 `--no-verify` 的豁免留痕制度，而这三样在本仓库都还不存在。**这一条诚实说清，不替他改主意。** **代价不掩饰**：两级保持空集。**此处原写「[D-057](#effective-register) 检验① 到 2026-12-03 到期时读数仍将是"拦住 0 条"」，2026-09-05 更正——那句不成立**：那个 0 只在"自动通道拦住的条数"这个读法下成立（[D-064](#decision-index) 量的正是这一个），而检验① 原文给的口径是对账[失败 Case 清单](失败Case清单.md)的"当时被拦住了吗"列，**按那个口径现跑就已经不是 0**——其中两条是非机械拦住、且都在 D-057 生效之后入库（[036 §1.1](审计记录/036-三条待裁的独立复验.md)；条数与命令见该节与 [D-057](#decision-index) 那一行的「修订」，本行不抄）。**成立的表述是**：本条裁"不挂"不改变「约束」级与「警告」级仍为空集这一事实，**因此它不为检验① 贡献任何"自动执行点拦住的"读数**；至于检验① 按对账口径的读数到期时会是多少，本条既不决定、也不预告。**但从此不得再把这个读数归因于"条文写得不好"**——成因是"本仓库没有任何自动执行点"（[D-064](#decision-index) 实测、[C-041](失败Case清单.md)）。**重开条件**：Alan 另行裁开；或出现一条 pre-commit 能拦住而人工执行确实漏掉的真实缺陷（那将直接证伪"价值未定"里的成立条件）。**一件从本条移出的**：2026-12-04 起 C3 报 [D-057](#effective-register) 过期、退出码 1——**那是 D-057 那一行自己的缺陷，与挂不挂钩子无关**，027 把它记进"选项二三的缺点"是记账错位（030 查明），现移出另立 [D-078](#decision-index) |
| D-075 | 2026-09-05 | 已执行 | **归档更正，不是规则，不进生效登记表**：[追溯账本](追溯账本.md)各章「各条原则的证据强度」表的**值列压空**，在 §1 声明「空即取默认值『一手多来源』」，只逐条留出例外。**行一条不删**——保留 `| Pn |` 的行形状。**2026-09-05 已执行完毕**，两项自检 PASS | 形态出自 [021 §5.2](审计记录/021-执行前审计-删减路.md)。它成立的关键是 C7 的正则逐字为 `^\|\s*(P\d+)\s*\|`——**只认行首形状、不读值列**，因此既不产生 miss，也不触碰[追溯账本](追溯账本.md) §1 自声明的那条硬约束，不需要改检查器。[015](审计记录/015-图工程三原则综合审计.md) 与 [D-069](#decision-index) 写的是另一种形态（删掉整行），那一种确被 C7 挡住——**两种形态的成立条件不同，015 没有区分，主 Agent 第一版据此把整项砍掉也是错的**（见 [C-040](失败Case清单.md)、[审计 024](审计记录/024-第二十五轮第二批提交前对抗性复核.md) F-03） | **失效探测（可复跑，本条自带）**：压空之后，默认行与被误清的例外行同形，肉眼分不出——这个盲区是本条的动作**新造**的，按 [31 §2 P9](31-守卫与权限边界.md) 新机制须自带探测。判据一行：`grep -c '^| P[0-9]* |  |$' docs/追溯账本.md`（空值行）与 `grep -cE '^\| P[0-9]+ \| .+ \|$' docs/追溯账本.md`（非空值行；**原写 `grep -oP '^\| P\d+ \| \K.+(?= \|$)' docs/追溯账本.md | wc -l`，2026-09-11 改**：`-P`/`\K` 是从审计 024 Q2-02 那句原稿转抄进本行时引入，原稿本就是 `-E`；不支持 `-P` 的 locale 下 grep 报错退出、管道把退出码吞成 0，归零会被读成账本缺陷。改用 `-E` 并去掉管道，零命中 rc=1、文件缺失 rc=2 可见；行形状判据同形，两 locale 读数相同，数不抄），**非空值行数须等于 [追溯账本](追溯账本.md) §1 声明的例外条数**；对不上即为待修复缺陷。**C7 只认行形状、不读值列，因此它查不出这一类**。净减跑 `wc -c`（字节）与 `len()`（字符）现取，**两个口径差一个量级，引用时必须写明单位**，本行不抄。 执行记录：提交 `a282e31`。 |
| D-076 | 2026-09-05 | 已执行 | **已执行完毕；本条不产生规则，不进生效登记表。**（2026-09-05 Alan 裁准，依据[审计记录 031 §3](审计记录/031-四条待裁的整合与推荐.md)）原问的是[生效登记表](#effective-register) D-057 行里内嵌的会漂计数要不要删；**裁准选 A（删数），并按 [031 §0.2](审计记录/031-四条待裁的整合与推荐.md) 把「六条不变量」提到「117」之前**。**本轮实际执行三处，都在 D-057 那一行内**：① 原则条数「117」→ 改为"全部原则"＋`^- **Pn` 行形态判据＋要数跑 [`repo_counts.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/docs/%E9%99%84%E5%BD%95-%E8%BD%BD%E4%BD%93%E5%AE%9E%E4%BE%8B/repo_counts.py) 现取；② 不变量条数「六条」→ 改为逐字引 [00 §3](00-总览.md#default-scope)，权威清单指向[架构确定 §5.3](架构确定.md#invariants)；③ 被 `governed_by` 认领的决策数「35 条」→ 改为跑各章文件头的 `governed_by` 现取。**第四处在正文 [00 §3](00-总览.md#default-scope)，由本批另一路同批完成。****另有第五、第六处系提交前复核当场追加**（[审计 032](审计记录/032-第二十五轮第三批提交前对抗性复核.md) F-02）：[00 §5](00-总览.md) 的节标题与首句、[架构确定 §5.3](架构确定.md#invariants) 的小节标题——不改它们，00 §3 的规范句就绑在一处写死「六条」的节上，失效模式只是挪了一跳而不是解除。**六处同轮落地。****三个日期格（`approved_at`、`review_at`、`expiry`）一字未动**，依据是 [D-077](#decision-index) 第 ① 句：本次改动不增减 blocks 或 grants 覆盖的动作集合，属记账修改 | 「117」是**描述性规模说明，删了零损失**——依据是登记行自己的两句自述（逐字「本行给的是判据不是名单」与「本行不枚举原则编号」），grants 授权的对象逐字是"正文**任一条**原则"，外延由各章 `^- **Pn` 的行形态固定并被检查器 C7 咬住。**但真正该先删的是「六条」**（[031 §0.2](审计记录/031-四条待裁的整合与推荐.md) 五条判据同向）：它是**真·范围界定**，不像「117」那样在同一格里两次自弃枚举，**没有任何判据兜底**；漂它的动作**被 [D-047](#effective-register) 的 grants 逐字授权**（把不变量「作为与部件并列的架构级内容新增或修改」），**加第七条即当场出错**；**且它已实测漂过一次**——[D-047 决策记录](#d-047)逐字记着「§5.3 原本就有**五条**不变量」，而 [C-039](失败Case清单.md) 自认"117 会漂"本轮没有实测支持。**一处援引更正**：[08 §7](08-规范效力元治理.md#annotation) 那句计数判据的作用域逐字是「同一个计数或状态**在正文中**只允许有一处权威位置」——**它管不到登记表**，[C-039](失败Case清单.md) 与本条此前援引过宽，须修 | **改后凭什么仍确定**（这是本次改动的最高优先级检验——[D-014](#effective-register) 说登记表是唯一效力源，**效力范围模糊比数字过期严重**）：**三处删掉的都是基数，不是外延。** 原则的外延由各章 `^- **Pn` 的行形态给出，且被检查器 C7 与[追溯账本](追溯账本.md)逐条对账咬住；不变量的外延由[架构确定 §5.3](架构确定.md#invariants) 那份"全文只有一处"的权威清单给出；被认领决策的外延由各章文件头的 `governed_by` 给出。**三处外延各有一个唯一的、可现跑枚举的权威位置**，删的只是它们的计数快照，因此 blocks 与 grants 覆盖的动作集合前后逐字相同，效力范围仍确定。**后果**：25-P3 的删除不再被这一处挡住，[D-069](#decision-index) 可重开。**副作用一件，另立处置**：删掉「117」让"新增一条原则是否自动随 D-057 生效"这个歧义浮出水面——**它今天已经存在，删数不制造它，但删数之后必须回答**，见 [D-079](#decision-index)。 执行记录：提交 `19deaf6`。 |
| D-077 | 2026-09-05 | **已接受** | **2026-09-23 Alan 批准，三句写进 [08 §6](08-规范效力元治理.md#trial-expiry)，登记见[生效登记表](#effective-register)。****改「生效登记表」某一行的规矩，三句。** ① **记账修改**：改动不改变该行 blocks 或 grants 覆盖的动作集合、也不改变其成立条件，只是把一个会漂的数、一处已失效的指针或一句表述换成等义且不会漂的写法——**可就地改，`approved_at`、`review_at`、`expiry` 三格不动**。② **实质修改**：改动使 blocks 或 grants 覆盖的动作集合发生增减，或改变其成立条件——按 [08 §6](08-规范效力元治理.md#trial-expiry) 逐字「**需要继续生效必须重新批准并写入新的 approved_at 与 expiry**」，**须重新批准并写新的 `approved_at` 与 `expiry`**（`试行`项一并写新的 `review_at`）。**判不出属哪一类的按实质修改办**——[08 §3](08-规范效力元治理.md#unmarked-default) 的非对称默认，错误阻断的代价是多问一次人。③ **留痕**：两类都在该行「上游依据」格末尾写一句 `**修订**：…`，写明改了哪几处、哪天裁、裁决方向变没变；形态照 [D-047](#effective-register) 那一行的现成样例。 | **现状不是空白，也不是完备。已有明文三处**：[33 §2 P6](33-评估与演进.md) 的晋升链末端逐字「保留、**修改**或回退」，其「删除条件」逐字「链上的『人类批准』一步不可省，实验结果不能自动升格为生产规范」；[33 §2 P3](33-评估与演进.md) 逐字「**它的修改是受门控的人工变更**」；[40 §2 P5](40-人的检查点与授权.md) 要求授权是带参数的结构化决定、确认入参与执行入参一致，[40 §2 P6](40-人的检查点与授权.md) 逐字「两者的变更都是**慢变、可审计的授权变更**，并附风险加权的抽样复核」。**缺三件**：实质修改与记账修改之间没有判据；改后 `approved_at` 与两个到期日怎么处理没有规定；登记表没有修订字段，C1–C10 也看不见任何修改。**而惯例已经成形并被行使过一次**：`git log -L 24,24 -- docs/决策日志.md` 本轮现跑只有两个提交——`f280edf` 建行，`474fa18`（第十六轮）就地收窄了在效力中的 blocks 格（补入一条作用域判据）、**三个日期格一字未动**、Alan 裁。**缺的只是把它写下来。**（判定出自[审计 028](审计记录/028-待裁D-076-效力源里的会漂计数.md)，[031 §3](审计记录/031-四条待裁的整合与推荐.md) 采纳） | **以下到「本轮不登记」是 2026-09-05 登记前的记录，2026-09-23 已登记。** 本条不产生效力，也不进生效登记表。 按 [08 §3](08-规范效力元治理.md#unmarked-default) 的分向降级，`提议`可作拒绝理由、不可作授权理由——**所以 2026-09-05 那次改动的授权不来自本条**，来自 Alan 对[审计 031](审计记录/031-四条待裁的整合与推荐.md) 全部推荐的批准，即 [33 §2 P6](33-评估与演进.md) 逐字要求的「人类批准」那一步。要让本条自己产生授权，须另走 [D-014](08-规范效力元治理.md) 的生效路径并登记，本轮不登记。**可复跑**：`git log -L 24,24 -- docs/决策日志.md` 现取该行的全部修改史，逐次核对有没有留下「修订」句。**已知盲区，记未定不折算**：C1–C10 无一项能判一次改动属哪一类，也查不出「修订」句在不在，本条因此只有人能执行；另一处未定是本条自己——判据由改动的一方写下、也由同一方适用，按 [30 §2 P1](30-验证与测试.md) 的子原因「生成者与验证者同一」记未定。**证伪信号**：出现一次按本判据判为记账修改、事后发现它实际改变了 blocks 或 grants 覆盖范围的改动，即回来收窄第 ① 句。 |
| D-078 | 2026-09-05 | 已执行 | **两半都已了结：2a 于 2026-09-05 执行，2b 于 2026-09-23 裁定续期。**原标题：拆成两半，技术处置（2a）已执行完毕，实质决定（2b）登记为待办、本轮不代裁。（2026-09-05 Alan 批准 [037 §2a](审计记录/037-三条待裁的整合与推荐.md) 的推荐——出路⑤「改 C3 为报告而不失败」，加出路④ 的"满足形态"那半句）**2a 已执行，执行与验收记录见 [038](审计记录/038-D-078技术处置的执行与验收.md)**：[`check_normative_force.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/docs/%E9%99%84%E5%BD%95-%E8%BD%BD%E4%BD%93%E5%AE%9E%E4%BE%8B/check_normative_force.py) 的 C3 现分两支——「`expiry` 不可解析」**一支不动，仍记不合规、仍进 FAIL、退出码 1**；「已到期」一支改为**到期通告**，在 PASS／FAIL 之上单起一节印出，**不计入不合规项、不影响退出码**。[仓库工作须知](附录-载体实例/仓库工作须知.md) §2 同轮写死满足形态，逐字「**其余项无报出 ＋ 决策日志有处置留痕**」，两半都要；该节同时写明**没处置本身不是 FAIL 是待办**，且 **C1～C10 没有任何一条判得了这一格**。**原缺陷的精确形状**（[C-043](失败Case清单.md)）：一个退出码同时承载"你写错了"与"日历翻页需要人决定"两类消息，而纪律只认第一类。**2b 已于 2026-09-23 裁：[D-057](#effective-register) 续期一期**（Alan 在对话中「全按推荐」），再次续期以三项检验有真实项目数据为条件；两半都已了结，本条改记`已执行`。执行记录：2a 见 [038](审计记录/038-D-078技术处置的执行与验收.md)，2b 见 D-057 登记行末的「修订」句与 [D-114](#decision-index) | **2a 的日期探针与验收照 [038 §4](审计记录/038-D-078技术处置的执行与验收.md)／§5 的原始输出记，不转述**：新脚本 **12-02 与 12-03 无通告、PASS、退出码 0**；**12-04 与 12-05 有到期通告、PASS、退出码 0**；对照旧脚本 **12-04 为 FAIL、退出码 1**（旧脚本 12-03 仍 PASS、退出码 0）。**反例两向都跑过**：`expiry` 写成非日期时，今天与 12-04 **都仍 FAIL、退出码 1**——写错的值不会被新开的通告通道吞掉。九类缺陷注入镜像上，**除 C3 外报出集合改动前后逐项相同**（含顺序、路径、行号、报文全文）；12-04 之后仍有新缺陷时**灯照样红、退出码照样 1**，只是「FAIL N 项」里的 N 不再被那条日历事实垫高。改动后两项自检 PASS、0 误伤。**为什么取⑤ 不取④**：④（只改纪律措辞）之下退出码恒为 1、灯恒红，而**恒红与恒绿一样不携带信息**；且 [036 §1.3](审计记录/036-三条待裁的独立复验.md) 查出 ④ 还漏了 §2 标题里「都要 PASS」五个字，不改那五个字纪律字面仍不可满足。**「⑤ 是 [C-006](失败Case清单.md) 的镜像」这条否决理由不成立**（[036 §1.4](审计记录/036-三条待裁的独立复验.md) 实测）：C-006 的承重属性逐字是"恒不匹配、永远通过""PASS 看起来是真的"，即**察觉不到**；而 ⑤ 每次都把到期事实印在 PASS 上面一行，**看得见**。**一处诚实的保留**：⑤ 改的是脚本，与 Alan 2026-09-02"先不要碰需要写代码的东西"有张力，[037 §2a](审计记录/037-三条待裁的整合与推荐.md) 已把这一点写在保留栏，本次是他明批的 | **2026-09-23 已裁：取下文出路①（重新批准续期一期）**，新日期与计算依据见 [D-057](#effective-register) 登记行的「修订」句。以下是裁前的记录。**2b 是实质决定，只有 Alan 能裁，须在复审日 `2026-11-19` 裁：[D-057](#effective-register) 续还是不续。本轮不代裁。**两条出路，代价照 [037 §2b](审计记录/037-三条待裁的整合与推荐.md)：**① 重新批准**（写新的 `approved_at` 与 `expiry`，`试行`项一并写新的 `review_at`）——按 [D-077](#decision-index) 第 ② 句属**实质修改**，须走 [33 §2 P6](33-评估与演进.md) 逐字要求的「人类批准」那一步；改动量 1 行 3 格、可逆，**但 [33 §2 P6](33-评估与演进.md) 那条晋升链要的"评估通过"这一格填不出**（见下三项检验）。**② 让它按 [08 §6](08-规范效力元治理.md#trial-expiry) 自动失效、正文整套退回`提议`**——语义自动发生，**但记账那一半仍是实质修改**：[036](审计记录/036-三条待裁的独立复验.md) 实测只删登记行会 FAIL（C4 与 C9 各报），**须改 3 处**；另有散文副本会静默过期（哪几处、共几处照该文现取，本行不抄）。可逆，但复原要再走一次①。**到期时三项检验的状态，照 [037 §2b](审计记录/037-三条待裁的整合与推荐.md) 的表逐条记，不折算**：**① 部分可答、关键谓词未定**——现跑"是"里有非机械的两条且都在 D-057 生效之后，但那两条的拦截由效力为零的载体纪律执行、只自述依据 [30 §2 P5](30-验证与测试.md)，「算不算原则拦住」无判据，按 [30 §2 P1](30-验证与测试.md) 记未定；**② 答不出**——本仓库无 Gate 实例（[D-062](#decision-index) 逐字「只能在一个真实产品项目上答」、[D-074](#decision-index) 裁不挂），读数是空集，按 [08 §4](08-规范效力元治理.md#empty-set) 判 **UNDETERMINED**，**不得读成"没问题"**；**③ 未定**——检验③ 原文的因果限定是「**因有了效力而**暴露」，而候选那两处都是审计读文本读出来的，**全仓无执行点、无原则被适用过**。**[033](审计记录/033-待裁D-078-试行到期.md) 说的"检验③ 答得出且有两个正例"已被 [036 §1.2](审计记录/036-三条待裁的独立复验.md) 否掉：文本属实，归类不成立**（那是两条不同规则各自的作用域标注，套到任一对象上得不出相反判定，按 [08 §8](08-规范效力元治理.md#conflicts) 第 1 条都不成立）。**本行原写的「到 2026-12-03 为止 D-057 检验① 的读数仍将是"拦住 0 条"」同批更正**，理由与 [D-074](#decision-index) 那一行的同句一致，见该行；**"到期时会不会有新数据"这一格仍记未定**，但成立条件换了——不是"读数一定还是 0"，而是"本仓库无自动执行点，检验① 的关键谓词与检验② 的空集到期时大概率仍未定"。**另一件本轮查出、本轮不修的**：12-04 之后报头的「生效规则：N」与 C9 的对账仍把 D-057 算作生效，另立 [D-082](#decision-index) |
| D-079 | 2026-09-05 | 已拒绝 | **已有明文，不新增；正文 0 改动、生效登记表 0 改动。**（2026-09-05 Alan 裁决，依据[审计记录 037 §3](审计记录/037-三条待裁的整合与推荐.md)）原问的是"一条新写进正文的原则是否自动随 [D-057](#effective-register) 生效"。**[08 §3](08-规范效力元治理.md#unmarked-default) 的分向降级已经答了，而且是双向的**：授权方向答"不允许"，**阻断方向答"允许"**——依据是 [D-014](#effective-register) 的 grants 格逐字「授权执行者按[分向降级](08-规范效力元治理.md#unmarked-default)使用未标注规则作为拒绝理由」；而 08 §3 末句逐字「本条不要求为仓库中每一句现存文字补标注。未标注即按上表处理。」**即：任何一句命令式语句都已可援引作拒绝理由，`- **Pn` 这个前缀不多买一分**；在授权方向上，无论前缀写不写，未标注规则一律不得用作执行动作、跳过检查、放宽条件或自我授权的理由（08 §3 那张表逐字）。**档位「已被覆盖」** | **三个实测是复验实测，不是转述**（[036 §2.1](审计记录/036-三条待裁的独立复验.md) 独立复现，[037 §3](审计记录/037-三条待裁的整合与推荐.md) 采纳；本行只记结论与形态，注入命令见那两节）：① 只往正文加一行 `- **P11 …` 而不动[追溯账本](追溯账本.md) → 检查器 **C7 报**「正文有账本无：['P11']」、**退出码 1**；② 再往账本对应章段补一条 `P11` 的表行（值列留空）→ **两项自检双双 PASS、退出码 0**，总代价两行，**无需任何批准**；③ 最省形态**连「删除条件」尾标都不用写** → 同样 PASS、退出码 0，C1～C10 无一条查该字段。**结论：C7 是对账不是闸门。**[追溯账本](追溯账本.md) §1 逐字「本文与正文之间只有一条硬约束：每条原则在本文中有且只有一条强度记录，编号与正文一致」——它**预设增删可发生**，且该文件自声明效力为零。**这个歧义不是删「117」制造的**（[D-076](#decision-index)）：原写法同样没说第 118 条算不算，只是那个数让人误以为成员集被枚举锁死。**另三个出口为什么不取**（照 [037 §3](审计记录/037-三条待裁的整合与推荐.md)）：② 在 D-057 行加一句作用域（"随本行生效的是 09-03 冻结的那一批"）——**范围反而更模糊**，冻结快照正是 [D-076](#decision-index) 刚删掉的那一类；按 [D-077](#decision-index) 第 ② 句属实质修改、须 Alan 重批三个日期格；且无可删项。③ 靠 C7 当闸门——**已被上述实测证伪**。④ 加一条 C11——需新增名册，而 [C-027](失败Case清单.md) 记的正是同一个病（逐字「这是同一个病的第六次」）；且 checker 不是 Gate，仍无可删项 | **重开条件写死：出现第一个自动执行点即重开。**（本仓库现为 0 启用钩子、0 版本化 CI——[D-064](#decision-index) 实测、[C-041](失败Case清单.md)；一旦有一条通道自动跑起来，"写下即取得阻断力"就从纸面变成机制，本条当场重开。）**两项差额未被本裁定消除，照实记，不折算**：**① 义务差**——[08 §1](08-规范效力元治理.md#force-states) 状态表里`试行`一行对执行者的含义逐字是「在 effective_scope 内执行，每次执行须记录结果供复查」，那是**义务**；而 08 §3 给未标注规则的只是"可以拿它拒绝"的**许可**。两者不等价：新写下的原则落在许可一侧，不落在义务一侧。**② 裁剪差**——08 §3 那张表把「放宽条件」逐字列在**不允许**的使用方向里，因此一条**不在**生效集内的原则，反而更难被就地裁掉或收窄（要裁它得援引它，而援引方向受限）。**两项都记未定，既不作本裁定的支持，也不作反对。****另一处不消除的**：[036 §2.3](审计记录/036-三条待裁的独立复验.md) 查出的 `governed_by` 与生效登记表两份答案，另立 [D-081](#decision-index)——它坐实本条原来的忧虑：没有任何章头承载 D-057 的效力，成员判据只剩行形态，中间无任何逐章关口。**可复跑**：跑 `grep -c "^- \*\*P" docs/[1234][0-9]-*.md` 逐章现取原则行数，与上一次取值比对即知集合是否变过 |
| D-080 | 2026-09-05 | 已拒绝 | **B-1 作废，记`已拒绝`；理由是「已被覆盖」，不是「价值为零」。**（2026-09-05 Alan 裁决，依据[审计记录 037 §4](审计记录/037-三条待裁的整合与推荐.md)）照 [D-074](#decision-index) 的先例，两者不是一回事。B-1 指 [015 §2.3](审计记录/015-图工程三原则综合审计.md) 拟给 [31 §2 P1](31-守卫与权限边界.md) 补的那个前提，逐字「"自动进入必经路径"以**动作空间被该通道穷尽**为前提；存在一条绕过该通道的写入路径时，本级不成立」。**正文 0 字改动。****本条此前记的"把 B-1 那条依赖边从 [D-073](#decision-index) 改挂 [D-074](#decision-index)"不撤销**，[D-065](#decision-index) 那一行的状态与裁决方向仍不动；本条只是把那条边连同 B-1 一起结案 | **一、加 B-1 之后本仓库一条判定都不变**（[035](审计记录/035-待裁D-080-B1判据的去留.md) 推演，[036 §3.1](审计记录/036-三条待裁的独立复验.md) 独立复算）：[31 §2 P1](31-守卫与权限边界.md) 现有正文的判定**卡在"自动"两个字就结束，走不到"必经"**。逐类推演：正文原则（"只写在指令里的是提醒"→ **提醒→提醒**）；两个人工调用的脚本（"写成程序但要执行者想起来运行的是工具"→ **工具→工具**，"必经"这个词根本没被读到）；钩子与 CI（**0 个**，无对象）。唯一会变的是假想的 pre-commit，而 [D-074](#decision-index) 已裁不建。**正文原则的条数不在此抄**，跑 `grep -c "^- \*\*P" docs/[1234][0-9]-*.md` 现取。**二、三处覆盖，逐条写明**：① 「**必经**」这两个字本身就承载"无绕过路径"；② 「**跳过必须可见**」逐字已在 31-P1（该句逐字「警告必须留下被下游必然消费的痕迹，跳过必须可见。」），承载留痕——**故"改写后落"那个选项净买零**；③ 逐机制的判定归 [31 §2 P4](31-守卫与权限边界.md) 的 Gate 合同。**三、两处给 B-1 的公道话，必须写**：① [027](审计记录/027-待裁D-074-执行点.md) 用 `--no-verify` 作的反驳**成立但不可推广**——受保护分支加必需状态检查这两例**在窄读下满足** B-1，**后半记未定**（[036 §3.3](审计记录/036-三条待裁的独立复验.md)：按 035 自己采信的宽读，改分支保护设置、推别的分支都是绕过路径，两例同样不满足）。② B-1 **过得了 [D-020](#effective-register) 的两种机制类型检验**（"权限与隔离配置"与"运行时拦截"，两种实例不同属一个工具），**不能拿 D-020 挡它**；它过不了的是 [09 §5](09-跨工具通用性.md#feasibility-test) 里那句判据——逐字「**规则引用的每个对象须能指出载体、归属与失效条件。** 指不出的名词不得作为规则的对象：要么就地给出它的载体与去向，要么从正文删除，不得靠上下文让读者自行推测。」，而「动作空间」指不出载体、归属与失效条件。（035 称它为"第二段"，[036 §3.4](审计记录/036-三条待裁的独立复验.md) 核明它是该节**最后**一段，不影响判定，此处照核后的说法写） | **顺带记一条，与本裁定同批**：[023 §2](审计记录/023-执行清单-冻结版.md)／[D-064](#decision-index)／[C-041](失败Case清单.md) 那处对 B-1 的援引是**空转**——两个脚本按 31-P1 在"自动"两个字上就落"工具"级，B-1 那句前提根本没被用到，**删掉半句结论一字不变**。**这与 [029](审计记录/029-四条待裁的跨条归并.md)／[031](审计记录/031-四条待裁的整合与推荐.md) 的"单向应用"提法不一致**（029 讲的是援引实践上的不对称：同一句判据拿来否掉一边、不拿来量另一边）；[035](审计记录/035-待裁D-080-B1判据的去留.md) 照实写了两者并存、不去改它们的记录，[036 §3.2](审计记录/036-三条待裁的独立复验.md) 确认 **035 更准**（在两个脚本那一侧那条判据根本没做功，谈不上"被应用"）。**两处记录都保留，不互相改写。****[C-044](失败Case清单.md) 的复发条件随本条关闭**：B-1 不再是一条悬着的待落条文，也就不再有"把一句拟增文本当现行判据援引"的对象。**重开条件**：[D-074](#decision-index) 被另行裁开（真挂上一个自动执行点）时，B-1 随该条一并重开——届时"必经"才第一次有对象。**本条不产生规则，不进生效登记表** |
| D-081 | 2026-09-05 | 已执行 | **已处置（2026-09-23 Alan 批准）：[08 §5](08-规范效力元治理.md#effective-register) 加一句「章头 `governed_by` 只作来源追溯，不作效力声明；一条规则能否阻断或授权，只查登记表」。**不动 [D-057](#effective-register) 登记行，不产生新的阻断或授权，故记`已执行`；执行记录见 [D-114](#decision-index)。以下为登记时的原文。**待裁／待处置：`governed_by` 标注与生效登记表对"某章由谁治理"给出两份不同答案，而 C1 与 C6 都报不出。**（发现出自 [036 §2.3](审计记录/036-三条待裁的独立复验.md)，[037 §3](审计记录/037-三条待裁的整合与推荐.md) 要求另立；下列三个数是本轮自己跑的，不是转述）现跑 `grep -n governed_by docs/[1234][0-9]-*.md` 得 **14 行**，正文 14 章各一行；其中**指向 [D-057](#effective-register) 的有 0 行**；[31 章](31-守卫与权限边界.md)那一行逐字是 `governed_by：D-008、D-018、D-024、D-027、D-028、D-029`，**六个 ID 与生效登记表成员的交集为空**；把 14 行里的 ID 全部去重后共 **38 个**，**其中在登记表内的只有 3 个**（`D-015`、`D-020`、`D-047`，分布在 11／21／22／24 四章；**本行第一版写作「11／21／22／24／33 等章」，33 章的交集其实为空**，[审计 039](审计记录/039-第二十五轮第四批提交前对抗性复核.md) F-01 查出，同源于 [C-046](失败Case清单.md) 把空集章数写成 9、实为 10）。**按标注载体读，31 章由六条没有效力的决策治理；按唯一效力源读，31 章由 D-057 治理。** | **这不是效力冲突，本行不把它算作 [D-057](#effective-register) 检验③ 的正例**（[036 §2.3](审计记录/036-三条待裁的独立复验.md) 的判读，本行照采）：[08 §3](08-规范效力元治理.md#unmarked-default) 给的是"可以拿它拒绝"的许可，D-057 给的是阻断力加拒绝方向的授权，**两者同向**，不构成 [08 §8](08-规范效力元治理.md#conflicts) 第 1 条要的"相反判定"。**真正的问题是两条并行的效力归属路径给出不同答案**：[08 §7](08-规范效力元治理.md#annotation) 的表把「规范文档章节头」定为写 `governed_by：D-0xx`（只写 ID）的载体，[08 §5](08-规范效力元治理.md#effective-register) 把生效登记表定为唯一效力源；而 08 §5 只把**状态值副本**判为过期注释，`governed_by` 是 ID 列表、不是状态值，**不在那句的字面射程内**——这批章头因此既不是被明文作废的注释，也不指向任何生效决策。**没有任何检查能报它**：C1 只查 `governed_by` 引用的 ID 在决策索引里存不存在（六条都在），C6 只查文档有没有声明 `governed_by`（都声明了），**「指向的全是无效力决策」落在 C1～C10 的检查面之外。****两处后果**：① 它使 [08 §3](08-规范效力元治理.md#unmarked-default) **结构上分不出新旧**——§3 的触发条件里没有"这一行是什么时候写的"这个维度；② 它坐实 [D-079](#decision-index) 原来的忧虑——既然没有任何章头承载 D-057 的效力，「成员的外延由各章 `^- **Pn` 的行形态固定」就是**唯一**的成员判据，中间没有任何逐章关口 | **本行只登记，不代裁处置方式。** 可想到的方向都动效力源或动载体（例：14 章章头一并写上 D-057；或在 [08 §5](08-规范效力元治理.md#effective-register) 把 `governed_by` 明文降为"只作来源追溯、不作效力声明"；或加一条检查判"章头 ID 无一在登记表内"），**按 [D-077](#decision-index) 第 ② 句，凡改 [D-057](#effective-register) 那一行 blocks 覆盖范围的都属实质修改，须 Alan 重新批准并写新的 `approved_at` 与 `expiry`**；执行者不得自行开工。**可复跑（三条，与决策格里的三个数一一对应）**：跑 `grep -n governed_by docs/[1234][0-9]-*.md` 数行数；在同一份输出里数含 `D-057` 的行；把该输出里的全部 ID 去重后与生效登记表成员求交。**本条不产生规则，不进生效登记表。****一处记未定，不折算**：这处脱节有没有实际造成过一次错误援引，**本轮查不出**——全仓无执行点、无原则被适用过（同 [D-078](#decision-index) 检验③ 那一格），按 [30 §2 P1](30-验证与测试.md) 记未定 |
| D-082 | 2026-09-05 | 已执行 | **已修（2026-09-23）**：C3 循环收集已到期 ID；生效集合只算一处并排除它们，报头与 C9 共用；报头另列「已到期」；C9 的散文数恰好多出已到期条数时归入到期通告、不进 FAIL（同 [D-078](#decision-index) 2a「日历事实不把灯变红」）。执行记录：本批提交，定位用 `git log -S'expired_ids' -- docs/附录-载体实例/check_normative_force.py`；修复前后实测见 [D-114](#decision-index)。以下为登记时的原文。**待处置，本轮不修：2026-12-04 之后，检查器报头的「生效规则：N」与 C9 的对账仍把 [D-057](#effective-register) 算作生效，而 [08 §6](08-规范效力元治理.md#trial-expiry) 说它此刻已自动退回`提议`。**[038 §7](审计记录/038-D-078技术处置的执行与验收.md) 第二处的实测：12-04 的输出里，同一屏上方印着到期通告，下方报头逐字仍把 D-057 列进生效规则；C9 拿散文里的那个数去对生效登记表实算的数，两边一致、不报。**到期通告是全仓唯一说出这件事的地方，没有任何检查去调和这两者。** | **不是本次技术处置引入的**（[038 §7](审计记录/038-D-078技术处置的执行与验收.md) 查明）：旧脚本在 12-04 的报头逐字相同，出路④ 与出路⑤ 在这一格上完全一样。**根因是生效登记表是唯一效力源，而没有任何一条检查在读它时应用 [08 §6](08-规范效力元治理.md#trial-expiry) 的时间语义**——"生效规则"的判定里只有状态值，没有时间条件。[037 §2a](审计记录/037-三条待裁的整合与推荐.md) 记出路⑤ 的缺时写的是"它把一个真实的不一致状态判成 PASS"，**没有点出这个不一致会以"报头计数与 C9 都读错"的形态具体呈现**。**本轮不修的两条理由**：① 修它要在"生效规则"的算法里加时间条件，那会同时改动 C2、C4、C9 三处的输入，**远超最小改动**；② 它触及 [D-078](#decision-index) 的 2b（D-057 到期续不续）**尚未裁定**的那半边——裁续期则这个不一致根本不会发生，裁失效则要改的是登记行本身而不只是脚本。照 [038 §7](审计记录/038-D-078技术处置的执行与验收.md) 取的处置（该文引 [C-023](失败Case清单.md) 的先例）：**先记着，等同型 Case 再攒一条再判** | **可复跑**：把 [`check_normative_force.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/docs/%E9%99%84%E5%BD%95-%E8%BD%BD%E4%BD%93%E5%AE%9E%E4%BE%8B/check_normative_force.py) 复制到会话临时目录、把取今天的那一行换成 `2026-12-04` 再跑，看报头是否仍把 D-057 列进生效规则；**仓库里的脚本不要动**，注入前先断言待替换串唯一（做法照 [038 §5](审计记录/038-D-078技术处置的执行与验收.md)）。**触发处置的时点**：[D-078](#decision-index) 的 2b 在复审日 `2026-11-19` 裁出之后——裁续期则本条自动消失（不再有到期条目），裁失效则与"只删登记行须改 3 处"合并处置。**本条不产生规则，不进生效登记表。****一处记未定，不折算**：这个读错今天没有任何消费者（无自动通道，也无"按报头做决定"的书面记录），**它的实际危害本轮判不出**，按 [30 §2 P1](30-验证与测试.md) 记未定 |
| D-083 | 2026-09-06 | 已执行 | **归档更正，不是规则，不进生效登记表**：依据[审计记录 040 §3 P-03](审计记录/040-会漂计数的综合审计与推荐.md)，删去 [00 总览](00-总览.md) §9 中概述生效登记表的那一分句（原写正文整套进入某状态、到期日与"正文文本自此有阻断与授权效力"）。该节首段逐字已写「本文不复制那张表也不概述它」，由它承担指路。**2026-09-06 已执行完毕。** | 立论**不是**"这个数会漂"——现跑正文原则数与该处所写一致，未漂；是 [08 §7](08-规范效力元治理.md) 的副本条款与该节首段的自我禁止。该处全行只有一个指向上下文合同的链接，**没有指向生效登记表的链接**，故 08 §7「要么引用它」的豁免口不占；也未声明为与源机械对账的缓存，第二个豁免口同样不占。这个位置此前已有两次同型复发：[C-022](失败Case清单.md) 逐字记「00 §9 里一句系动词形态的整体效力声明挂了四轮它一次没报」；而在修它的同一次提交里，C5 又当场报出同处的解释性引文再抄了一遍状态值（[审计记录 006](审计记录/006-正文整套进入试行.md)）。 | 删后读者要答"正文现在有没有阻断力、什么时候到期"须多跳一次，落点是该节首段已有的指针与生效登记表下方的散文，**指针与落点均已存在，无需新建**。两项自检须 PASS。**本条不产生规则，授权来自 Alan 2026-09-06 的裁准，不来自本条。** 执行记录：提交 `d71c633`。 |
| D-084 | 2026-09-06 | 已执行 | **记账修改，不是规则，不进生效登记表**：[D-057](#effective-register) 依据[审计记录 040 §3 P-05 与 §7.6](审计记录/040-会漂计数的综合审计与推荐.md)，生效登记行「上游依据」格里的「待处置」句，删去写死的三条路径与内嵌检索命令，改为判据加「本行不写路径清单」，并写明检索不得按整行剔除序数。**2026-09-06 已执行完毕，三个日期格一字未动。** | 三个缺陷一次删除同时关掉：一，路径清单漏了 [上下文合同](../CONTEXT_MANIFEST.md)；二，原命令按**整行**剔除序数，一行里既有序数又有基数时基数被整行静默丢弃（2026-09-06 实测存在过这样一行，随后该行自身被改掉；**本句不断言当前有无实例**——形态缺陷不因当下有无实例而消失，且判定时须区分基数的使用与对旧写法的引述，机械检索替代不了这一步）；三，命令里的竖线未转义，使该行供出 10 格而表头只有 9 列，「记为待处置」落在无列名的第 10 格，GFM 渲染与本仓库检查器的 `dict(zip(...))` 都读不到它。第三条缺陷由 `19deaf6` 引入，那一次做的几项防护一项也没咬住它，**本行不写项数**。 | 按 [D-077](#decision-index) 第 ① 句判为记账修改：不触碰 blocks 或 grants 覆盖的动作集合，也不改成立条件——该句自身逐字写着「它们不在规范链上」。**已知的判据风险**：外延由「三条路径」放宽为「规范链之外」，严格说是等价放宽而非等义；按 D-077 兜底句判不出属哪一类应按实质修改办，**此处由 Alan 2026-09-06 裁定按第 ① 句办**。**时机条件未满足，照实留痕**：审计 040 P-05 原写「与 P-06 同一次处理，不单独动生效行」，而 Alan 本轮只裁准了两条待裁方案，P-06 那批仍待裁——故本行是单独改的，P-06 落地时「记为待处置」这句还须再改一次。**新增一步 D-076 那次漏掉的验收：改后现数该行格数，须与表头列数相等**——改前 11 个竖线／10 格，改后须为 10 个竖线／9 格。两项自检须 PASS。 执行记录：提交 `d71c633`。 |
| D-085 | 2026-09-06 | 已执行 | **载体层机械修复，不是规则，不进生效登记表**：依据[审计记录 040 §8](审计记录/040-会漂计数的综合审计与推荐.md)，① 修 [`repo_counts.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/docs/%E9%99%84%E5%BD%95-%E8%BD%BD%E4%BD%93%E5%AE%9E%E4%BE%8B/repo_counts.py) 读失败 Case 表时的裸切列缺陷——改为用 `mask_code` 定位竖线、按位置切原行，取值仍取原文；② 删去本文件决策索引表中间的一个空行。**2026-09-06 已执行完毕。** | ① 该脚本此前印出不存在的等级档，成因是含行内代码带竖线的那一行被裸切成十余段（[C-042](失败Case清单.md) 第二段已登记、未处置）。**承重判定更正**：审计 040 原判它承重，理由取自 C-042 **第一段**（名单与绑定正则缺陷，已另修），属承重转移；按三条判据现跑——无检查器对账、不划定任何成员集、错数只在三份审计记录里被原样粘贴而无散文消费——**不承重**。仍修的理由是：每被粘贴一次就污染一份冻结记录，已污染两份，而改动面经实测有界（全表只有一行的裸切与掩码切结果不同）。② 空行使 GFM 就地断表，表后三十余行掉出表格渲染成段落，而检查器跳空行照样解析全表——**同一张表的机器视图与人视图给出两个答案，两项自检都 PASS**。 | ① 验收基准事前登记在 [C-041](失败Case清单.md) 那一格（用掩码口径现跑的「被拦住了吗」四个数），改后脚本印出的四个数须与它逐字相同；各等级档之和须等于 Case 总条数；「已绑定原则」与「已被证明有实例的章」两项须逐字不变，若变须逐条说明。② 改后本文件决策索引表内不得再有空行；本轮新增与改动过的行不得引入多余格。**本条不断言全表格数已对齐**——现跑该表另有四行（D-055、D-056、D-069、D-075）按本仓库检查器的裸切口径多出格数，属存量、非本轮引入，**记为待处置**。**成因不止一种**：D-056 是未转义竖线；而 D-055 的竖线已逐个转义、`pandoc -f gfm` 渲染恰为六格，它多出格数只因 `check_normative_force.py` 的切列不认 markdown 转义——**这一条是检查器缺陷，不是文本缺陷**。两项自检须 PASS、退出码 0。**本条不产生规则，授权来自 Alan 2026-09-06 的裁准，不来自本条。** 执行记录：提交 `5b4622b`。 |
| D-086 | 2026-09-06 | 已执行 | **记账修改，不是规则，不进生效登记表**：依据[审计记录 040 §8](审计记录/040-会漂计数的综合审计与推荐.md)，把两处写在效力格里的集合基数改为不写死条数的写法——[D-047](#effective-register) blocks 的「四条推论」与 [D-020](#effective-register) grants 的「三条判据」，各改为「各条」。措辞取自 [00 总览](00-总览.md) §3 已有的「§5 各条」，不造第二种写法。**2026-09-06 已执行完毕，两行的三个日期格一字未动。** | 两处同型：集合基数长在效力格上、外延无行形态判据、零检查器覆盖（现跑 `grep -n -e 不变量 -e 推论 docs/附录-载体实例/*.py` 无输出），而使其失真的动作被授权——D-047 自己的 grants 逐字授权「把不变量与平面接口作为与部件并列的架构级内容新增或修改」。**D-076 曾用这条授权论证过一次「不许写死不变量条数」，却没回头看 D-047 自己那一格。** 09 章增设判据四时，据它做的移出动作按字面亦不在 D-020 grants 的授权内（欠授权方向）。 | **归类依据 Alan 2026-09-06 的裁决**：两个集合为开放，故新旧写法等义、覆盖的动作集合前后相同，按 [D-077](#decision-index) 第 ① 句办；**若集合被裁为封闭，本条须改按第 ② 句重新批准**。改后两行的竖线数须仍等于生效登记表表头的竖线数；blocks 与 grants 两格除该四字外须逐字未变（其余各格 sha256 须相同）。两项自检须 PASS、退出码 0。**一处记未定，不折算**：D-047 blocks 的作用域逐字是「在本仓库全部规范正文内」，而推论住在[架构确定](架构确定.md) §5.3，**该文件算不算「规范正文」两个脚本给相反答案**——`repo_counts.py` 的正文集不含它，`check_normative_force.py` 的 `GOVERNED_GLOBS` 含它。**同批未处置、2026-09-23 补执行**：[09 跨工具通用性](09-跨工具通用性.md) 正文原逐字写「本文给出三条可逐句套用的判据和一条硬性检验」——效力格这一跳已不写死条数，但它指向的那一章自己还写着，增设判据四时该章当场出错。这与 D-076 处置「六条」时「只改一跳只是挪了一跳」同型；09 章是已接受决策正文，2026-09-23 Alan 批准（「批准 D-086，改成各条判据」），该句改为「本文给出可逐句套用的各条判据和一条硬性检验」。**本条不产生规则，授权来自 Alan 2026-09-06 的裁准与 2026-09-23 的批准，不来自本条。** 执行记录：提交 `5b4622b`（两处效力格）、09 章一处与本行改记同一提交（`git log -S'可逐句套用的各条判据' -- docs/09-跨工具通用性.md` 可取）。 |
| D-087 | 2026-09-07 | 已执行 | **已裁（2026-09-23 Alan「全按推荐」）：首个真实项目按[审计记录 045](审计记录/045-L3技术选型-ClaudeCode宿主.md)（Claude Code 作宿主）开工。**这一选择此前已由 [D-101](#decision-index)（Claude Code 拦截层随标准发布）事实落地，本条改记`已执行`；执行记录：D-101 及其发布号 `2026-09-22`。045 §7 验证冲刺未跑，属后续验证，不是待裁。冲刺范围 Alan 2026-09-23 裁：只跑 ● 类 17 条，B-257 收尾后启动，计划见 [052](审计记录/052-L3验证冲刺-NFBY.md)。**修订（2026-09-24）**：冲刺已执行，读数见 [052](审计记录/052-L3验证冲刺-NFBY.md) §4，对 045 设计的落点见 [045 §12](审计记录/045-L3技术选型-ClaudeCode宿主.md)；上句「未跑」是 2026-09-23 裁时的状态。以下为裁前的原文。**技术选型基线（待裁）：本规范首个真实项目的载体选型以[审计记录 041](审计记录/041-技术选型的综合审计与推荐.md) §6 的 L1 起点为基线**——通用层只押五宿主齐全的载体——[09 §5](09-跨工具通用性.md#feasibility-test) 七类里的外部状态存储（文件加 git）、检查器（宿主外）、人工检查点三类，加上「条件加载规则」类下唯一五宿主齐全的实现（Agent Skills 目录）；宿主绑定层只对 Claude Code 与 dsh 给确定推荐；L1 零服务、零编排引擎、零图或向量或记忆库；L2 起唯一新增的服务是已有的 PostgreSQL（持久执行、记忆检索、遥测落库三件事先落到它上面）。**本条不产生规则，不进生效登记表；全部具名工具只存在于 041 与附录（[09 §7](09-跨工具通用性.md#no-mapping-table)），正文 0 改动、生效登记表 0 改动** **修订（2026-09-07 同日）**：Alan 裁定「直接做 L3，避免一遍遍推倒重来；宿主选 dsh」——041 §6 的 L1 起点**不再作基线**，改为[审计记录 043](审计记录/043-L3技术选型-DSH宿主.md)：栈按 L3 一次选定（三个信任域、零新服务），自主度按 043 §6 的六个开关逐个放开，每个开关挂一个判定器；开工前先跑 043 §7 的验证冲刺（条数照该节现取）。**本条状态仍`提议`**：待 Alan 对 043 §4 的逐部件选型与 §7 的冲刺方案裁准。 **修订二（2026-09-07 同日，第二次口径变化）**：Alan 提出「dsh 现在还不稳定，是否用 Claude Code 能实现 L3 需求」——据此新增[审计记录 045](审计记录/045-L3技术选型-ClaudeCode宿主.md)：**栈、三个信任域、零新服务、043 §6 的六个开关全部沿用不变，只重写宿主绑定层那一张接触面表**（这正是 043 §5 写下的设计意图「换宿主时只重写这一张表」，045 是它的第一次兑现）。045 判 Claude Code 能承担 L3 宿主：堵掉 043 §5 的洞一（沙箱原生做出口域名白名单）与洞三（结构化最终裁定有原生标志），新开一个洞（有损压缩的损失信号无原生载体，退回 041 §6 L3 行早已规定的自建路径）；开工前的验证冲刺改照 045 §7（条数照该节现取）。**本条裁的东西没变**——仍是「第一个真实项目按哪份材料开工」，只是候选由一份变为两份（043 与 045），由 Alan 择一；两份的证据等级不对等（043 全部为厂商文档，045 含一手实测），045 §0 已声明该不对称本身不构成选型理由。 | 依据 Alan 2026-09-04 的优先级（行业标准 > 少就是多 > 好设计）与 2026-09-07 的四项答复（L1 为起点、主宿主 Claude Code + dsh、落成 041 + 本条、不写代码）。六名子 Agent 互不读对方报告的调研在四件事上各自同向（编排与状态买文件与 git 的账、代码图谱最低形态是文本文件、记忆最低形态是文件、上下文唯一清单只能靠纪律）；主 Agent 八处抽查七处属实、一处引文经[审计记录 042](审计记录/042-第二十八轮提交前对抗性复核.md)查出为抽查工具改写并已更正；三份报告对同一份官方页面给出三个不同的钩子事件条数，故 041 不写该数。**（裁前）状态记`提议`是真待裁**（与 [D-110](#decision-index) 所定的`已执行`不同）：裁的是"第一个真实项目按哪份材料开工"，不是"正文多了一条" | （裁前原文）先跑 043 §7 的验证冲刺，各条记 通过／失败／未定，不折算；结果直接改 043 §7 的对应格，不改本条。冲刺过后再在一个真实项目上按[落地包 04](图工程落地包/04-接入与验收清单.md) 的 S0～S6 跑一次，记录 043 §4 判为已定的载体里有几项实测不成立。**到期无真实项目即本条无验证数据，与 [D-057](#effective-register) 检验①同一困境**，不折算 |
| D-088 | 2026-09-10 | 已执行 | **标准目录的口径合并，不是规则，不进生效登记表**：「采用项目把标准版本记在哪」原有两种口径——`标准/01-项目管理标准.md` §3.1、§4.7、§8 与 `标准/README.md` 认 `governance/STANDARD_VERSION` 文件，工具契约认 `project.yaml` 的 `standard_version` 字段。**已裁定：认文件、删字段。** 本轮落地四件：① 示例项目三处同值删到一处——`governance/STANDARD_VERSION` 保留，`governance/project.yaml` 与 `README.md` 文档树那两处只留指针、不抄值；② 本仓库补建 `governance/STANDARD_VERSION`（值、`adopted_at`、`last_evaluated_upgrade`，裁剪登记只指向 project.yaml）；③ 本仓库 `governance/project.yaml` 删掉 `standard_version` 字段，顶部改为一行指针注释；④ 01 §3.2 职责卡 `project.yaml` 那行的两格同改。**不升修订号，仍属 `2026-09-10`。** | 合并方向由消费者数与承载面定，不由职责卡的权威域定（后者是选择性执法：同一把尺会把 layout、budgets、tailoring、derived 一起判出局）：文件有两个现存消费者（示例 `AGENTS.md` 的指向、01 §4.7 的验收判据「STANDARD_VERSION 与差异记录一致」），字段零个；文件是超集（带采用日期与上次升级评估），把超集并进子集要新造 YAML 结构。三处同值即 G2 与 N2 的副本形态，且现有检查器查不出来（无后缀文件与 YAML 不算文档，`1.0` 也不匹配数值正则）——**收益是样板不再自打脸，不是多了一道防线**。职责卡那格的失效探测原写「命令跑不通」，而本仓库 `project.yaml` 根本没有 commands 块，该探测对本仓库**恒真通过**——一道永远绿的假守卫；只扩权威域会当场制造新缺口，故两格必须同一次改。不升号：修订号在 §8 与 `标准/README.md` 里的语义是给已采用项目的升级信号，会把采用方推进 §4.7 整套升级流程；本轮不新增任何一条采用方要满足的要求。 | **采用方要做的只有一件，且是可选清理**：删掉自己 `governance/project.yaml` 里的 `standard_version` 一行。**「零义务变化」不成立，照实留痕**：它仍是一个动作；缓解是该字段零消费者，留着不产生任何后果，故不升号不使任何判断失真。**另一半不可省**：加一条读 `governance/STANDARD_VERSION` 的检查（存在、非空、读得出值与采用日期）并把读到的值写进每份报告的证据行，**不得与工具侧任何常量比对**（工具仓 0 个标签，没有可比制品，比了就是编）；不带它，删字段在机器可读性上是净损失。本仓库新建的这份 `STANDARD_VERSION` 会成为一条**诚实的未定**（它的值指不到任何可获取的制品），不是一条新的通过。**本条不产生规则，授权来自本轮已批准的裁决，不来自本条。** 执行记录：提交 `256dd59`。 |
| D-089 | 2026-09-11 | 已执行 | **已裁（2026-09-23 Alan「全按推荐」）：本仓用 `标准/01` 约束自己，范围由 [`governance/project.yaml`](../governance/project.yaml) 的裁剪表达。**本仓已有 `project.yaml` 与 `exceptions.md`，`check_all` 退出 0。这是对已发生的采用的记录，不另产生阻断或授权，不进生效登记表；`标准/01` 在本仓的效力仍按 [08 §3](08-规范效力元治理.md#unmarked-default) 分向降级（可作拒绝理由，不作授权理由）。此前「沿用实际惯例」的临时默认随之结束：未经 `project.yaml` 裁剪或例外登记排除的要求（含 §5.1 提交格式）今后适用，历史提交不追溯；发布步骤的版本号提交今后改用 `chore(release): …` 格式。执行记录：`7d0ae95`（本仓先采用）、`d553fa0`、`eecb5ac`（自检清零）。以下为裁前的原文。**`标准/01` 对本仓库自身的适用关系（待裁）——§5.1 提交格式的矛盾只是它的第一个实例。** 前置的那一格：[`标准/01`](../标准/01-项目管理标准.md) `:23` 逐字「本文是候选实现，在本仓库效力为零」，[`标准/README`](../标准/README.md)「本目录效力为零，不阻断或授权本仓库决策」，[仓库工作须知 §5](附录-载体实例/仓库工作须知.md) 把本仓的开轮／收轮／提交纪律只绑到 `docs/` 正文（经 [D-057](#effective-register)），全仓无一句「本仓自愿按 `标准/` 自我约束」；**而 `b4ebb5c` 提交体里至少两处把 `标准/01` 当依据援引**（逐字「单文件提交按 01 §5.1「一个提交一件事」」、「不改任何机器的 core.autocrlf：系统设置在 01 §5.5 边界外」），**又在 `b4ebb5c` 与 `b9e3571` 里把 §5.1 当矛盾挂起两次**（逐字「§5.1 提交格式矛盾另行处理，不在本批」）——援引与挂起都预设 §5.1 有约束力，一起与上述三处零效力声明冲突；且提交信息不在任何检索面上，本条是那两处「另行处理」的落点。**第二个实例**：[01 §4.2](../标准/01-项目管理标准.md#session-protocol) 第 4 条与 §4.7 的候选区机制在本仓从未运行（[M-08](../标准/参考资料/M-08-规则的增补与打薄信号.md) 自记无运行数据），本轮登记时把"没有候选区"当理由引用了。**待裁的问题**：本仓库是否、以及在哪个范围内以 `标准/01` 约束自己。三个方向及代价：① **不约束**——§5.1 对本仓不生效，矛盾不存在，提交体今后不再援引 `标准/` 作依据（否则重演）；② **整体自愿约束**——现跑 `git rev-list --count -E --grep='^[a-z]+(\([^)]+\))?: ' HEAD` 得 0，全部 59 条历史永久不合规，scope／type 在本仓无定义、无验收 ID 体系；③ **按条声明**（改 §5.1 加作用域，或在本仓侧列出自愿遵守的条）——开一条新的作用域轴，与 [D-057](#effective-register) 的实例判据成两套口径，改 §5.1 还要判升不升修订号（[D-088](#decision-index) 已裁修订号是给采用方的升级信号）。**裁定前的默认（Alan 2026-09-11 已裁）：沿用实际惯例**——主题一句中文＋正文「已观察失败／做了什么／明确不做／验收」，§5.1 一字不改、不升号、59 条不作缺陷。**本条不产生规则，不进生效登记表。** | 归口决策日志而非断点节或 §5.1 就地改：[断点节](../标准/覆盖与采用检查.md#research-breakpoints)现三条两条是「外部材料没读到」、一条是仓内未落地台账，无一是"标准文本与产地实践矛盾"，且无状态列、无日期；就地改 §5.1 与「作待裁」冲突且 §5.1 无锚点；不登记则两处「另行处理」永久悬空（提交信息不可改、不可检索）。与 [D-088](#decision-index) 同型（`标准/` 内的口径问题进本表）、与 [D-087](#decision-index) 同态（状态记`提议`是真待裁）。[审计记录 007](审计记录/007-D-057作用域与本仓库自身合规.md) 是"本仓是否受自己写的文本约束"这一问在 `docs/` 侧的先例，那次的答案是给 scope 补判据不是补名单；本条是同一问在 `标准/` 侧第一次被写下 | **可复跑**：`git rev-list --count -E --grep='^[a-z]+(\([^)]+\))?: ' HEAD` 现取 0；`git rev-list --count --grep='另行处理' HEAD` 现取 2；`git rev-list --count HEAD` 现取 59。**实际取的是整体约束、靠裁剪表收窄**（接近上面的 ②，但按 `project.yaml` 裁剪与例外登记收窄范围，历史提交不追溯）：自愿声明即 `project.yaml` 文件头与其裁剪表，§5.1 一字不改、不升号。裁前原写——**裁定后**：取 ① 则本行改`已拒绝`并在[仓库工作须知](附录-载体实例/仓库工作须知.md)加一句「提交体不援引 `标准/`」；取 ② 或 ③ 才动 §5.1 或另立自愿声明，届时再判修订号。**积压风险**：明写「待 Alan 裁准」的先例 n=1（[D-087](#decision-index)），本表`提议`总数跑脚本现取，不足以判本条会否积压，不折算 |
| D-090 | 2026-09-11 | 已拒绝 | **委托授权缺口：本轮不立规，记为沉淀候选，重开条件写死**（Alan 2026-09-11 裁「记沉淀候选，不立规」；状态值取`已拒绝`与 [D-079](#decision-index) 同一用法——不走「立规」这条路、重开条件明写）。**缺口的形状（四处逐字，互不衔接）**：① [`标准/01` §5.5](../标准/01-项目管理标准.md#controlled-actions) 受控清单只列「启动**权限更宽或免审批的**嵌套执行者、子会话或委托」，等权或收窄的子执行者不在清单，同节「未列动作按实际后果判断」的三判据（超出用户授权／破坏难以恢复的数据或状态／向外部产生承诺）对「占用人的注意力与工作区」皆不落；② [`标准/03` §9.1](../标准/03-Agent信息获取与上下文管理.md) 逐字「能否创建或调用子执行者、提供哪些数据与工具，仍由当前宿主和用户授权决定」，执行点指到 [01 §6.1](../标准/01-项目管理标准.md#writer-roles)「授权标记：只有人侧通道」——覆盖面比 §5.5 宽（管全部委托），判据留空（外包给"宿主和用户授权"，而 01 `:489` 已写常规可逆动作由任务授权覆盖，两句拼起来可读成"派发已被任务授权覆盖"）；③ [31 §2 P7](31-守卫与权限边界.md)「被委托者的权限严格是委托者的子集」——子集成立即可派，不问数量；④ [40 §2 P2](40-人的检查点与授权.md)「并行自主流的数量上限等于人能认真审查的数量」——无触发器，「并行自主流」[术语表](术语表.md)无定义，未接到授权侧。**本轮实例**：本仓 2026-09-10～11 的运行在会话内派出多名子执行者，无一逐次询问用户；数量与名单**仓库零书证**（只在会话记录），本行不写数；实例无可指认损害，且派发本身是项目所有者设计的多席流程的一部分——**这是缺口不是失败**，不立 Case（构造型 Case 要求确定的触发条件，此处取不到）。**正文 0 改动、`标准/` 0 改动、生效登记表 0 改动。** | 不立规的三条理由：**行业标准**——[33 §2 P6](33-评估与演进.md) 晋升链以「观察到失败 → 可复现 Case」为起点，此处无失败事件，起点不成立；**少就是多**——三处已有条文（§5.5、03 §9.1、31 P7）把「更宽」「子集」「人侧授权」各说了一半，再加一条是第四处口径，不是收口；**好设计**——项目所有者已在 `b9e3571` 那批裁过同族的 01 §4.4 前置判据「三轮判据未收敛，等有真实并行记录再立」，本条与之共用同一触发。**不并入 D-089**：共同点只是都涉 `标准/01`；D-089 待裁、本条已裁，可核性分两档，按[失败Case清单 §1](失败Case清单.md)「必须分开写」 | **重开条件（任一命中即重开）**：① 本仓或采用项目出现第一份真实并行记录（委托合同或 `expected / received / missing` 汇合报告，03 §9.2／§9.4 形态）；② 一次派发命中 §5.5「未列动作」三判据之一；③ 01 §4.4 前置判据重立时，本条与它同一批答「派发要不要过人侧通道」。**重开时先答**：03 §9.1 的「由用户授权决定」与 §5.5 的清单谁是权威、40 P2 的上限归哪个检查点计量。**可复跑**：`grep -c '权限更宽或免审批' 标准/01-项目管理标准.md` 现取 1、`grep -c '由当前宿主和用户授权决定' 标准/03-Agent信息获取与上下文管理.md` 现取 1、`grep -c 并行自主流 docs/术语表.md` 现取 0——三数任一变化即本条前提变了 |
| D-091 | 2026-09-11 | 已拒绝 | **`标准/参考资料/README.md`「主要落点」列不补格、不改口径、不加检查：记沉淀候选，重开条件写死**（触发：M-17 行只列 §4.7，而 [M-17](../标准/参考资料/M-17-存量模块审计的形态.md) 卡末逐字「本篇改 01 §4.7（新增一行 + 补一段 + 债务闭环句内改写）、§4.8（与 §4.1 的重复判据合并）」；状态值取`已拒绝`与 [D-090](#decision-index) 同一用法——不走「修副本」这条路）。**已核的形状（HEAD `6697a7c` 时点）**：① 该列是各卡「逐篇闭环」节的手写投影，全部 8 张表表头逐字均为「主要落点」，[`README.md`](../标准/参考资料/README.md) `:5` 逐字「本文只做索引。卡片中可回到具体落点」，每行已链回各卡——[11 §2 P2](11-项目知识.md#claim-model)「存在副本时声明主从或至少互链」两项皆已满足；② 同形的「卡说改了、格里没有」在 85 行索引行里（`grep -cE '^\| [A-Z]+-[0-9]+ \|' 标准/参考资料/README.md` 现取 85）另有（下列为本轮已核出的，不写处数：核法是取各卡「逐篇闭环」内「本篇」自报句的 § 集合减去该行格内的 § 集合，只覆盖「格 ⊂ 卡」一个方向，故是下界不是全集）：A-06 少 §2.2、C-08 少 §10.1、C-11 少 §13（卡逐字「本篇只改 03 §6 末条与 §13 一行的括注」）、C-13 少 §3.2（同句还动了 §3.1；C-13 与 M-17 同为「合并」形态但方向相反——M-17 是 §4.8 被合并走、C-13 是合并进 §3.2，故不套用 ③）、O-15 少 §8，各与 M-17 行同在提交 `d7e411b` 写下时即如此，不是后来漂移；另有 14 行的卡根本没有「逐篇闭环」节（`grep -L '^## 逐篇闭环' 标准/参考资料/[A-Z]-*.md` 现列出这 14 张：M-01、A-01～A-04、C-01～C-04、O-01～O-05），这 14 行无权威可对，整表对账对不到它们；③ §4.8 在索引里**并非无人认领**：M-05 行 `:53` 逐字列 `§4.8`，且 [01 §4.8](../标准/01-项目管理标准.md#delivery-metrics) 现文本「依据见 M-05」只引 M-05——M-17 对 §4.8 做的是 N2 合并（把重复判据改成引 §4.1），合并后留下的文字其来源仍是 M-05，把 M-17 补进去会造出「索引两卡、正文一卡」的新不对称，消它要改 `标准/01`；④ 「以各卡文末为准」取不到唯一答案：[M-13](../标准/参考资料/M-13-执行点冗余与自评级.md) `:61` 自报改两节，[M-14](../标准/参考资料/M-14-并行拆分与派生文档的纯度.md) `:61` 复述为三节（多出「§3.7 措辞收紧」）；[M-16](../标准/参考资料/M-16-旁路通道绕过既有控制.md) `:59` 记的波级动作「把 §4.8 重复的零否决结论合并回 §4.4」已落地于 01 `:418`，却不在任何卡的「本篇改」与任何索引行里。**沉淀候选（不立规）**：新卡的这一格由写卡者自填，不由收口者回填。**正文 0 改动、`标准/` 0 改动、生效登记表 0 改动。** | 不修不立的四条理由（按 Alan 2026-09-04 的顺序）：**行业标准**——[09 §5](09-跨工具通用性.md#feasibility-test)「清单、分类与例子是判据的例示，不是穷尽」「失败驱动的修订作用于判据，不作用于样例」，补格是改样例（该句出自 D-055 改动 5，D-055 仍`提议`；09 章不在 [D-057](#effective-register) 的正文 10～40 范围内，`repo_counts.py` 的「已被证明有实例的章」也不含 09——故此处按 [08 §3 分向降级](08-规范效力元治理.md#unmarked-default) 只作**拒绝**理由用，不作执行或授权理由）；[33 §2 P6](33-评估与演进.md#case-registry) 晋升链以观察到失败为起点，而本轮未取得可指认的漏看事件（执行者、轮次、漏看的节三项皆无书证），按 [30 §2 P1](30-验证与测试.md#verification-layers) 记未定·无法核验——不据此断言漏看不存在，只据此不立 Case；**少就是多**——列名「主要」已是非穷尽声明，再加一句「本列非穷尽」是同义重复；补 M-17 一格而留下同形的其余各格是只修一半，整表补齐须先裁 ④ 的矛盾并发明「波级改动挂哪一行」；**好设计**——[失败Case清单](失败Case清单.md) C-027 与读数八：读数八逐字「已经试过的两种处置各有其限」，并逐字「"算不算一次"的判据从没定义过，所以这里不再写总次数」，故本行不写次数；漏列机制不因补格而变——`d7e411b` 提交体逐字只写到「八波并行，每波一个执行者独占一份正文与一个卡片前缀，逐篇闭环：读原文 → 写卡 → 立刻改标准 → 校锚点」与「两个执行者中途被流看门狗判停，落盘核对后由集成者补齐未完成部分」，「索引这一格由谁回填」该提交体未写，本条不据此断言机制；**模型智能**——要查「哪些卡动过 01 §4.8」时现跑 `git log -S` 或 grep 各卡，不为索引造导出脚本。**依据取 `docs/` 侧不取 `标准/01` N2**：`标准/01` `:23` 对本仓效力为零且 [D-089](#decision-index) 待裁，援引它作依据正是 D-089 点名的重演；11 §2 P2 已由 [失败Case清单](失败Case清单.md) C-001／C-027／C-032 三格绑定（`repo_counts.py` 的「已绑定原则」导出值含 `11-P2`），在 D-057 的实例判据下生效，可引。**不并入 D-089**：D-089 待裁、本条已裁，可核性分两档 | **重开条件（任一命中即重开）**：① 出现第一个按该列找落点而漏看的真实事件（可指认的执行者、轮次与漏看的节）——届时先答「该列是主要还是穷尽」，答穷尽则整表按各卡与 01 现文本对账并把 ④ 两处矛盾一并裁掉，不单补一格；② [D-089](#decision-index) 裁为其 ② 或 ③（本仓以 `标准/01` 自我约束）——届时 N2 对该表生效，处置按「合并到权威处、别处改指针」判，候选是把该列改为指向各卡「逐篇闭环」节的指针，不是补格。**可复跑**：`grep -c 'M-17 .*§4.8' 标准/参考资料/README.md` 现取 0；`grep -c '主要落点' 标准/参考资料/README.md` 现取 8；`grep -c '本文只做索引' 标准/参考资料/README.md` 现取 1；`grep -c '依据见 \[M-05\]' 标准/01-项目管理标准.md` 现取 1；`grep -cE '^\| A-06 .*§2\.2' 标准/参考资料/README.md` 现取 0；`grep -cE '^\| C-08 .*§10\.1' 标准/参考资料/README.md` 现取 0；`grep -cE '^\| C-11 .*§13' 标准/参考资料/README.md` 现取 0；`grep -cE '^\| C-13 .*§3\.2' 标准/参考资料/README.md` 现取 0；`grep -cE '^\| O-15 .*§8' 标准/参考资料/README.md` 现取 0——九数任一变化即本条前提变了。**本条不产生规则，不进生效登记表；授权来自 Alan 2026-09-11 的裁准，不来自本条。** |
| D-092 | 2026-09-11 | 已拒绝 | **01 §4.7 执行点复审队列的定义域收窄到 03；01/02/04 补执行点字段本轮不做，重开条件写死**（Alan 2026-09-11 裁；状态值取`已拒绝`与 [D-090](#decision-index)、[D-079](#decision-index) 同一用法——不走「补字段／写检查器」这条路、重开条件明写）。**改了什么**：[`标准/01` §4.7](../标准/01-项目管理标准.md#enforcement-queue) 队列段首句「本标准集内执行点值为「无」的条款」改为「03 中执行点值为「无」的条款」，一文件一行。依据：执行点字段约定只写在 [`标准/03`](../标准/03-Agent信息获取与上下文管理.md) `:5`，01/02/04 无一处字段形态的「执行点」（01 的执行点逐条散在句内、一节多条各带各的，03 的「一节一字段」模型在 01 不成立），队列表全部条目以 `[03 §` 开头——首句原来那个更宽的范围主张写不出成立条件，按 01 §2 N1 该记未定，却以陈述句立在正文。**明确不做（本条登的就是这件）**：不给 01/02/04 补执行点字段；02 全章零「执行点」信息，此后在文本上被正式排除在队列对账之外——这是把 `dc9bbb9` 只动 03 的既有选择写明，不是新决定。不写队列计数检查器（计数从未漂移）。不改 [M-27](../标准/参考资料/M-27-输入里的实际状态与转述.md) `:69` 括注「该队列口径在 03，本条在 01」——首句收窄后它是充分理由（那两条各带具名角色是第二条独立理由）。**§3.7 的门**：[01 §3.7](../标准/01-项目管理标准.md#budget) 严格读法下，队列段不绑任何 Case/M/O/C（`dc9bbb9` 引入时的既有缺口，本条不修也不掩盖），逐字「反例不可重放时按 N1 记未定，该次合并不作完成」；本条按 `标准/01:23`「在本仓库效力为零」不援引 §3.7——这是 [D-089](#decision-index) 待裁问题的又一实例，随 D-089 裁。**后续（2026-09-11 同日另一批，Alan 裁准改道）**：上文「队列段不绑任何 Case/M/O/C」是本条写下时的状态；该批在[队列段](../标准/01-项目管理标准.md#enforcement-queue)首句后补绑 [M-10](../标准/参考资料/M-10-守卫的执行点.md)（体例同 01 §4.7 审核容量段末引 O-16 的「在…侧的同一条」句；`grep -c '在条款侧的同一条' 标准/01-项目管理标准.md` 现取 1），补的是 01 文本对其自身 N3 的绑定——与本条「为什么零效力还改 01 的正文」同一理由，N3 与 N1／N2 同为 §2 纪律；本条四项「不做」与两条重开条件不动；该缺口的处置路径由「随 D-089 裁」改为「绑定已补，§3.7 是否约束本仓仍随 D-089 裁」，此改道未命中本条重开条件、经 Alan 一句话，不代裁 D-089。**`标准/` 1 行改动、正文 0 改动、生效登记表 0 改动。** | 不补字段的三条理由：**行业标准**——[33 §2 P6](33-评估与演进.md) 晋升链起点「观察到失败」不成立：仓内无一条"本该入队却被挡在外面"的书证，M-27:69 是理由漂移不是计数漂移，依据等级是「有依据的风险」；**少就是多**——补字段是 01/02/04 三章逐节的语义裁定，产出主要是新未定，与 `dc9bbb9` 提交体「一条机械检查只在对象今天已存在且这类漂移已真实发生过时才写」反向；**好设计**——字段约定的归属（03:5）不上提，01/02/04 就没有可对账的定义域，先补字段再改口径是修修补补。**为什么零效力还改 01 的正文**：01 是交给采用方的候选实现，对本仓零效力不等于文本可以不自洽；自洽的判据用 01 自己的 N1／N2。**为什么进本表而不是只写提交体**：本条带一条将来要有人来收的重开条件，与 [D-090](#decision-index) 同型、与 `dc9bbb9`／`b9e3571` 零决策行的两批不同型（那两批无将来触发条件）；[D-089](#decision-index) 已写明「提交信息不在任何检索面上」，提交体不能做落点 | **重开条件（任一命中即重开）**：① `标准/03:5` 的执行点字段约定被上提为标准集级，或 01/02/04 任一章开始采用字段形态的「执行点」——`grep -c '^\*\*执行点\*\*' 标准/01-项目管理标准.md 标准/02-项目架构描述规范.md 标准/04-可靠性安全与运行维护.md` 现各取 0，任一非 0 即重开；② D-089 裁定 `标准/01` 在某范围内约束本仓且该范围含 §3.7——届时本次改写按 §3.7 补重放或记未定。**重开时同批做**：01 §4.7 首句按新定义域重写；复核 M-27:69 括注（其正确性依赖首句停在 03）——`grep -c '该队列口径在 03，本条在 01' 标准/参考资料/M-27-输入里的实际状态与转述.md` 现取 1。**可复跑**：`grep -c '本标准集内' 标准/01-项目管理标准.md` 现取 0；`grep -c '无](01' 标准/03-Agent信息获取与上下文管理.md` 与 `grep -c '^| \[03' 标准/01-项目管理标准.md` 两数相等（队列不变量，不抄数） |
| D-093 | 2026-09-11 | 已执行 | （2026-09-30 Alan 裁「删示例 `docs/INDEX.md` 的权威域列」，原话「按建议执行」；已删，示例内无引用该列之处，示例只剩 `AGENTS.md` 一份「事实→位置」映射，本条待裁部分结案。执行记录见 [D-129](#decision-index)。）**示例 EX-006 三处「排在 WI-0151 之后」补成「WI-0151 `done` 之后」；示例两份「事实→位置」映射不一致记候选、本轮不补。** 已落地：示例项目 `governance/exceptions.md:8` 理由格、`docs/state/STATUS.md:34`、`docs/state/work/WI-0151-新品导入四类拆分与一品多码.md:102` 三处只写裸工作项名加「之后」，未指明是 `done`、合入还是发版之后，而同表相邻行已用精确事件（`exceptions.md:7`「WI-0148 完成即删」、`WI-0151:103`「v2.5.0 发布后两周清理」）；示例是 [`标准/01`](../标准/01-项目管理标准.md) 的演示物（[`标准/README`](../标准/README.md) `:15`「不作真实效果证据」），01 `:264`「`done` 不代表已合并、已部署、已发布」在这三处没有被演示。取 `done`：理由格自述的前置是「升级需改导入模板解析」，是串行冲突面（01 `:327`「重叠消不掉的片改串行」），解除事件取工作项状态机里留有转换记录的那个（01 `:264` 每次转换留一行；`GATES.md:14` G8 在 `done` 前对账），与 EX-004 同表锚同一类事件（`:7`「WI-0148 完成即删」是它的白话写法，本轮不动）；不取合入（多阶段工作项在示例里合入不止一次：`WI-0142:110`、`:114`）、不取发版（`docs/operations/RISK-maintenance.md:14` 把「安排补丁」与「受控发布 → 回读」分开，`:16`「主分支更新后但旧部署仍运行，不满足关闭」与 04 `:91`「仅主分支修完不能关单」管的是关闭不是排期）。**记候选**：示例有两份「事实类别 → 位置」映射且不一致——[示例 `AGENTS.md`](../标准/示例项目-连锁零售中台/AGENTS.md) `:24` 表自称「每类事实只有一处」、`:26–:39` 无 `exceptions.md` 行；[`docs/INDEX.md`](../标准/示例项目-连锁零售中台/docs/INDEX.md) `:5` 第三列列名「权威域」、`:10` 给 `exceptions.md` 的权威域逐字「例外」、`:7` 又把 `AGENTS.md` 的权威域写成「规则、合同、权威位置表」；`docs/architecture/dependency-rules.md:48`「`check_deps` 读该文件的白名单」是机器级归属。两份映射并存即 01 `:34` G2／`:62` N2 的副本形态。**本轮不补**：`AGENTS.md` 按 01 `:574` 归具名人类负责人，`:565`「责任和批准不随委托转移」，执行者不能顺手补行；补 AGENTS 一行还是删 INDEX 那一列，须先答「哪份是主」。**`标准/` 仅改三行口径、01 正文 0 改动、生效登记表 0 改动；本条引 01 只作量示例的尺，不作本仓的约束，[D-089](#decision-index) 待裁不受预判。** | **少就是多**——三处各改一个短语，不扩权威表、不加锚点、不写检查器（本题无检查器覆盖，D-088 已记「不是多了一道防线」）；**好设计**——`done` 由状态机定义一次、有转换记录可回读，日程滑动三处不用回改；指针化会让 `STATUS.md:8` 自述承载的「项目级阻塞」那句与工作项遗留表那句各丢一句；**行业标准**——01 `:327` 只要求「说明前置关系」不定粒度，在留白内取值不加条款；示例无真实读者受损，按 [33 §2 P6](33-评估与演进.md#case-registry) 晋升起点不成立，故不立规、不立 Case | **重开条件（任一命中即重开）**：① 两份映射之一再新增一行而另一份不同步；② 采用项目建权威表时问「例外归哪」；③ [D-089](#decision-index) 裁为本仓以 `标准/01` 自我约束——届时本仓自己的权威表同题。**可复跑**：`grep -c 'exceptions.md' 标准/示例项目-连锁零售中台/AGENTS.md` 现取 0；`grep -c 'exceptions.md' 标准/示例项目-连锁零售中台/docs/INDEX.md` 现取 1；`grep -rl '排在 WI-0151 之后' 标准/` 现取 0 文件；`grep -rlE 'WI-0151 .done. 之后' 标准/` 现取 2 文件——四数任一变化即本条前提变了 |
| D-094 | 2026-09-11 | 已执行 | **执行完毕（2026-09-23）：五份各有结论——032 钉到 `0a4c9ec`，021、024、036、040 记未定。**原标题：五份被本表引用的审计记录，其正文行号坐标系未钉——另行处理（待裁）。执行时配方有两处缺口（多棵树同时全中、坐标只差一行），由调度方裁定后补进验证格「补充」句，属仓内可回退的方法细节，Alan 可否决。各份的试命中结果与未定原因写在各自文件头的 `引用须知:` 字段；036 原无文件头，补了只含 `doc_id`、`title`、`引用须知` 的最小文件头。执行记录：本批提交，定位用 `git log -S'按 D-094 配方' -- docs/审计记录/`。以下为登记时的原文。[021](审计记录/021-执行前审计-删减路.md)、[024](审计记录/024-第二十五轮第二批提交前对抗性复核.md)、[032](审计记录/032-第二十五轮第三批提交前对抗性复核.md)、[036](审计记录/036-三条待裁的独立复验.md)、[040](审计记录/040-会漂计数的综合审计与推荐.md) 正文各含指向本仓文件的 `文件:行号` 坐标，头部均无写时提交声明（036 连 front matter 也没有），坐标以哪棵树为基准无处可查；其中 [D-057](#effective-register) 上游依据格末尾的「修订」句逐字以「审计记录 040 §7」为裁准依据、`后续验证` 格把唯一可复算的重算方法指向「036 §1.1」，而 040 自陈「本文的行号出厂即漂」。049 已于同批在文件头把坐标系钉到 `256dd59`（并入 `引用须知:` 字段，正文零改动、净 0 行）；这五份要先考古出各自的写时树才能同型处理，是新工作面，本批不做。**正文 0 改动、五份记录 0 改动、生效登记表 0 改动。** | **行业标准**——行号坐标只有钉到提交树才不过期，049 的处置已示范同型做法；**少就是多**——不建目录 README（`docs/审计记录/` 下只有 047/049 两份头部有可钉的提交，README 说不出其余的真话；份数跑 `git ls-files docs/审计记录/ \| wc -l` 现取，本行不写）、不升原则（[32 §2 P5](32-证据与追踪.md) 已判扩大解释的责任在引用方，[D-079](#decision-index) 裁「已有明文不新增」）；**好设计**——本表引这五份的是生效规则的依据格与验证格，下游曝露最大，与 049 只被 `标准/参考资料/M-27` 按路径引不对称，不能与 049 一并按"不做"结案，落点在此 | **处置配方**：逐份按文件头 `日期` 字段取当日（036 取正文首行日期）及前后一日的全部提交（`git log --format=%h --since --until`），把正文全部本仓坐标补全路径后在每棵树上逐条试命中（锚句取自该记录正文对该坐标的逐字引文或关键词；只给行号不给引文的坐标不可用此法，不计入分母并在结果里列出），唯一全中的那棵才是基准（049 用此法在日期窗内得唯一全中者 `256dd59`；窗内提交棵数随新提交增长，本行不写）；无一全中则该份记未定、不钉。命中后在文件头加与 049 `引用须知:` 同型的一句（036 须先补文件头，净行数变化写进提交体）。**完成判据**：五份文件头各含一个可 `git show <sha>:<路径>` 复算的 SHA；`linkcheck` 断链 +0；`check_all` 三态与身份不变。**不改任何一份正文。** **补充（2026-09-23，执行时由调度方裁定）**：① 窗内多棵同时全中时，这些树上被引文件逐字相同（`git diff <a> <b> -- <被引文件…>` 为空）才视为唯一、钉在该记录入库的提交上，有一处不同即记未定；② 坐标只差一行的一律记未定，理由为写时工作区状态没有入库、坐标无法在任何提交上复算，不以锚句修正。完成判据相应改为：五份文件头各含一个可复算的 SHA，或一句未定及其原因；其余两项不变。 |
| D-095 | 2026-09-11 | 已执行 | **`标准/` 三章卷首「候选实现修订日期」与「覆盖与采用检查」卷首日期：删值、留指针；不升修订号，仍属 `2026-09-10`。** 已落地：[`标准/01`](../标准/01-项目管理标准.md) `:3`、[`标准/02`](../标准/02-项目架构描述规范.md) `:3` 逐字「候选实现修订日期2026-09-08；采用修订见[README]…」改为「候选实现修订见[README]…」（括号内的链接目标 `README.md` 不变）；[`标准/03`](../标准/03-Agent信息获取与上下文管理.md) `:3` 同改、后半句导航句一字不动；[覆盖与采用检查](../标准/覆盖与采用检查.md) `:3` 删句首「日期：2026-09-08。」。[`标准/04`](../标准/04-可靠性安全与运行维护.md) `:3` 自 `d7e411b` 起就没有日期、只写「采用关系见[标准入口]」，是既有实例，不动。**明确不动的两处**：[`标准/README`](../标准/README.md) `:3` 的 `2026-09-10` 是这个量唯一的权威处，本条不动它（它自己是否该升，见后续验证重开条件 ③）；`governance/STANDARD_VERSION` 本条不碰、不加对账。它与 README `:3` 是不是同一个量，**按 N1 记未定**：一面是 [`标准/01` §8](../标准/01-项目管理标准.md)「标准升级后由项目显式评估并升级，不在任务中自动跟随」允许两者不等；另一面是该文件 `:3` 自陈「本仓库即产地，与标准/README.md 的候选实现修订同轮」——「同轮」本身就是一份对 README 值的投影，README 先升它不跟时假的是这句自陈。本条不依赖任一取值；不加对账的理由独立于此：为维持两份一致而新建同步机制，01 §3.8 自己写明「登记为待删对象」，且 [D-088](#decision-index) 已把这份文件记为「诚实的未定」。**本条不产生规则，不进生效登记表。** | 四处日期自 `d7e411b`（09-08）引入后一次未动，而四份正文此后都被多次改过（次数权威在 git，`git rev-list --count d7e411b..HEAD -- <文件>` 现取，本行不写），README `:3` 经 `12bb446`、`7d0ae95` 升到 09-10：**四份带日期的卷首没有一份等于自己文件的末次提交日，也没有一份等于 README 的值**。「它是整套修订号的副本」还是「各章各自的最后修订日」没有权威文本，按 N1 记未定——但两种读法下它都错，且两种读法下权威都在别处（前者在 README `:3`，后者在 `git log -1 --format=%ad -- <文件>`），所以本条不依赖任一取值，删值都成立。**删的这个字段当初是按用户要求加的**：[A-04](../标准/参考资料/A-04-Stripe渐进在线迁移.md) `:34` 逐字「02 版本头按用户要求改为候选修订日期及 README 采用修订指针」、[M-01](../标准/参考资料/M-01-SRE接管与所有权.md) `:36` 逐字「版本头按用户要求更新候选修订日期」——当时要的是「有且被更新」，此后没有一次更新；删它是对那条既往指示的显式推翻，由本条裁定承担：默认删，替代项见本批须确认项，不是顺手清理。依据分两侧：`docs/` 侧是 [00 总览](00-总览.md) 第 3 条「知识单一权威」；`标准/` 侧 01 N2「版本号…在别处写一份便于阅读的投影，它必然漂移」是该文本自述的判据（效力零，适用关系 [D-089](#decision-index) 待裁），引它只为指出写下 N2 的文件自己漂了两天。与 [D-088](#decision-index) 落地①「只留指针、不抄值」同型；落选：改成 09-10 对齐是让 4 处死字符串变成 4 处需同步的活副本、此后每改一章都要同批改四处且零检查器能报下一次漂移；补「各章各自日期」的定义是新加一条规则看守一个会漂的值（01 §3.7「先查有没有已经说过同一件事」）；不做则采用方读 01 拿到旧两天的值。不升号：本轮不新增任何一条采用方要满足的要求（D-088 判据）。 | **可复跑**：`grep -rn "2026-09-08" 标准/*.md` 改前命中 4 行、改后 0 行；带值的「候选实现修订」全仓只剩权威一处：`grep -rnE "候选实现修订(日期\|：)" --exclude-dir=.git .`（表内竖线已转义，跑时去掉反斜杠）改前 4 行（三章 `:3` 与 README `:3`）、改后 2 行（README `:3`，加本行引的旧文）；不带值的短语 `grep -rn 候选实现修订 --exclude-dir=.git .` 改前 5 行、改后 6 行（三章 `:3` 改后仍含「候选实现修订见」、README `:3`、`governance/STANDARD_VERSION:3` 那句「同轮」括注、本行）——这个短语本就不是要清零的对象，列在这里是为了不把检索面锁死在单个文件里；linkcheck 断链 0 不变（三章的 README 链接与 03 的两条导航链接都保留）。**重开条件**：① README `:3` 与 `governance/STANDARD_VERSION` 首行不等——先答 N1 那个未定：同一个量则 `STANDARD_VERSION:3` 的「同轮」自陈已假、改那句；两个量则是 §8 的升级评估该跑一次；都不是本条的缺陷；② 出现第一个需要「各章各自修订日」的读者——届时先答权威在 git 还是在卷首，答在卷首才回头补字段，且补的是 §3.5 那种 `updated_at` 而不是散文日期；③ `标准/README.md:3` 的值与 `git log -1 --format=%ad --date=short -- 标准/0[1-4]*.md 标准/README.md` 中最晚日期相差 > 1 次采用方要满足的要求变更时——本条落地前（`b367f26`）01 在 README `:3` 末改 `dc9bbb9` 之后已被改过、含 09-11 的 `b9e3571`、`bad4694` 两次实质改动而 README 未升：(b) 只把漂移从五份收成一份，没有消除；那一份升不升是 D-088「升级信号」语义的问题，不在本条内裁。 执行记录：提交 `9b22886`。 |
| D-096 | 2026-09-11 | 已执行 | **示例 `GATES.md` G6 行重同步到 `标准/01` §5.6 现行默认行，删去 G6、G9 两格的豁免上限；`exceptions.md` 一字不动。** 三个矛盾叠在同一行上：① [示例 `GATES.md`](../标准/示例项目-连锁零售中台/governance/GATES.md) `:12` 通过条件「无 high/critical」与同仓 [`exceptions.md`](../标准/示例项目-连锁零售中台/governance/exceptions.md) `:8` EX-006（`openpyxl` medium 级 CVE）互不相合——按门槛 medium 不破门，例外便无所豁免；② `governance/project.yaml:40` 的 python 半边是裸 `pip-audit`、无严重度过滤，npm 半边才有 `--audit-level=high`，命令与门槛格各说一套（`docs/INDEX.md:8-9` 把命令与闸门分别定权威域，N2 在此给不出唯一答案）；③ git 溯源：`GATES.md:12` 第 4、5 格逐字等于 `c844671` 时 [`标准/01`](../标准/01-项目管理标准.md) 第一轮 G6 行「无 high/critical \| 升级或 ADR 接受」，`d7e411b` 把 01 的 G6 改成现行「按 04 完成适用风险判定及处置…」并同批改了示例 G3、G13，未动示例 G6——示例 G6 自此停在 01 已改掉的旧文本上，是示例 GATES 那张表里唯一这样的一格（G1/G2/G3/G4/G8 与 01 是措辞差与细化，出生即如此；G5/G7 两格逐字同 01，改前改后都同；`GATES.md:25`「G1–G8：标准 01 §5.6 默认集」在「来源」节，说的是出处，改前改后都真）。**取重同步**：通过条件改为「按 `docs/operations/RISK-maintenance.md` 完成适用风险判定及处置，无未解决的阻断风险或过期例外」——门的通过条件写本项目自己的处置流程：该文件 `:12`「收到一条依赖漏洞通知时」一节（`:14`「核对暴露面、可利用性与业务影响 → 安排补丁或限时缓解」，`:16`「无补丁：记录缓解措施、适用版本、负责人、风险接受人和复查日期」）就是 04 那张表在示例里的落地，且已被 `docs/operations/README.md:10` 收编为运维入口的「维护风险与依赖处置」；示例树以编号引 04 有 `docs/operations/SVC-inventory.md:20` 一处先例（带链接的「04 事故响应」），故写「按 04」同样可索引，两者可索引性无高下，取项目自己的文件是因 01 `:510`「按 04」在采用项目里指的就是它按 04 建起的流程。失败去向取 01 `:510` 逐字「补证、修复/缓解；有权人限时接受风险，不能将接受写为漏洞消失」——它是 01 的立场句，示例无本地文本可指；同表 G5/G7 两格本就逐字同 01，逐字取用不是本行首创。改后 ①② 消、③ 就地补上：新条件不谈严重度，EX-006 正是 [`标准/04`](../标准/04-可靠性安全与运行维护.md) `:90`「尚无补丁/不能即时升级」→「有权人确认限时风险接受或隔离替代；例外记录影响版本与到期条件」的形状，其理由格首句「无 high」按 04 `:89`「严重度是输入而非全部结论」读作输入，不再读作"无需登记"的推理；`pip-audit` 分不分级不再影响结论（分级则 medium 是扫描命中，不分级则 CVE 仍是「通知」，`RISK-maintenance.md:16`「不用“扫描没报”代替判断」）；旧失败去向「ADR 接受」与 EX-006 走 `exceptions.md` 而非 ADR 的事实也一并对齐。② 改掉的是 medium 的语义地位（从判据宣告它无关，变成判断的输入），不是命令的退出码：裸 `pip-audit` 仍对 medium 非零退出、门仍会红，由 `exceptions.md` 的记录吸收，`GATES.md:3`「豁免与跳过留同样的记录」即此。**豁免上限做减法**：`≤30 天`（G6）与 `≤1 迭代`（G9）两格删去数字只留豁免人，依据是 01 `:44`「闸门 ID 属**项目自己的命名空间**，采用项目可增删改」——这两个数是示例自加的：01 `:501` 只要求门声明「谁能限时豁免」，`:514`「到期…超期自动失效」、`:625`「到期」都只要求有到期、不设单次时长上限；同表 G11 豁免格本就只写「Alan」。它按 01 `:516` 是提醒不是约束——示例给到期列写了消费者（`exceptions.md:3`「到期未清理 CI 转红」），给这两个数一个消费者都没写（示例项目不含可执行脚本，`tools/` 下 0 个 `.py`，所以"没接线"的 grep 是空集、不承重；承重的是 01 `:44` 与 `:501`/`:514`/`:625` 三处只要求有到期、不设单次时长上限）；上限与到期是两个量：到期列管的是"过了到期还挂着"，上限管的是"一次能批多久"，删上限后少的只是强制每 30 天/每迭代重新批一次，到期 + CI 转红照旧：`docs/state/STATUS.md:33`「**EX-004 到期 2026-10-31**…例外到期 CI 转红」就是到期机制在示例里的书证，01 `:355` 每迭代复核「例外与依赖期限」、`:615`「豁免到期扫描」是它的标准侧依据（示例 `维护时间线.md` 对复核与上限同样零演示）。**本次删除的直接后果**：EX-004（批准 2026-05-12 → 到期 2026-10-31，172 天 vs ≤1 迭代）与 EX-006（2026-08-20 → 2026-11-20，92 天 vs ≤30 天）由"超上限"变为"无上限可超"，示例全树无第三处引用这两个数，删后再无一行判它们不合；上限此前从未被执行过（EX-004 的日期与 `≤1 迭代` 同出 `c844671`），本次取"撤掉提醒"而非"按 01 `:614` 把它做成约束"（两条超限例外变合规这一后果，Alan 2026-09-11 按默认裁准接受）。**不动的**：`exceptions.md` 三处 `done` 句（`2f2bc5e` 与 [D-093](#decision-index) 的四个可复跑数不变）；`project.yaml:40` 不动；`STANDARD_VERSION` 不动；`templates/agent-skills/delivery-gates.md:17` 同样停在 01 旧 G6 判据（`无 high/critical`，出生于 `b7ca80e`、2026-09-04、早于 01 本身），且是唯一"复制到项目根即生效"的载体（`templates/README.md`）：本批不改，登记为候选；改后示例 `GATES.md:12` 与该模板不再一致，按示例 `AGENTS.md:94`「方法库旧摘要与当前标准矛盾时登记并按适用权威处理」即此登记。**`标准/` 仅改示例 2 行、01/04 正文 0 改动、生效登记表 0 改动；本条引 01/04 只作量示例的尺（[`标准/README`](../标准/README.md) `:15`「不作真实效果证据」），不作本仓的约束，[D-089](#decision-index) 待裁不受预判。** | **好设计**——只处理 ① 会把 ②③ 留下，而 ② 是判定 ① 方向的关键输入；重同步一行两消一补，另两条路（把到期日缩到 30 天内、改理由格）各只平一个矛盾，且分别新造「到期早于自陈解除条件」或触发 D-093 重开；**少就是多**——2 行、`exceptions.md` 0 改动、不加锚点、不加检查器、不给上限下定义（把上限做成约束要加检查器加条款，删是减法）；**行业标准**——门槛格改成 01 现行判据不是新造，是补 `d7e411b` 的漏网；**模型智能代替代码**——「限时」由到期列与每迭代复核（01 `:355`）承载，不靠一个没接进任何检查的数字 | **重开条件（任一命中即重开）**：① 采用项目要求为例外设单次时长上限——届时先答上限防什么、与到期+复核有何区别，并按 01 `:614` 做成真约束而非再写一个数；② [D-089](#decision-index) 裁为本仓以 `标准/01` 自我约束——届时示例与 01 的逐字差异归本仓自己的副本核对；③ `pip-audit` 离线验证为**有**严重度阈值且示例想演示「低于阈值主动登记」——届时理由格首句该改写（并入 D-093 的 `done` 句范围一起动）。**可复跑**：`grep -c '无 high/critical' 标准/示例项目-连锁零售中台/governance/GATES.md` 现取 0；`grep -cE '≤30 天\|≤1 迭代' 标准/示例项目-连锁零售中台/governance/GATES.md` 现取 0；`grep -c 'RISK-maintenance.md' 标准/示例项目-连锁零售中台/governance/GATES.md` 现取 1；D-093 四数现取 0/1/0/2 不变。 执行记录：提交 `5aac98a`（授权补记 `567d527`）。 |
| D-097 | 2026-09-12 | 已执行 | **采用标准导致会话起点上下文爆炸，改三处：**[`标准/README`](../标准/README.md) `:11` 01 章读法改为「采用时由人通读一次；agent 会话不通读，只读被引用的节」（S1）；[`templates/CONTEXT_MANIFEST.md`](../templates/CONTEXT_MANIFEST.md) 的排除项与解析规则各补一行——四章全文默认不加载、「NN §x.y」按标题外延取节（S4′）；NFBY `CLAUDE.md` 的目录指针段替换为默认加载合同（N1）。授权形态：Alan 默认裁准（仓内可逆）。 | 三处叠加把采用方的会话起点放大一个量级，实测见 [C-050](失败Case清单.md)。**不升修订号**：三改都不新增采用方要满足的要求（[D-088](#decision-index) 判据），[D-095](#decision-index) 明写 `标准/README` `:3` 不动，NFBY 的 `STANDARD_VERSION` 因此一字不动。**不改 `标准/03` 正文**：`§x.y` 不是 `#片段`，§3.2 规则 2 自留「外延由唯一合同规定」的口子。**不加检查器**：C10 的定义域不覆盖 `标准/0N §x.y`。**落选**：改 `#锚点` 外延会静默改写 `标准/` 内既有引用；拆章要重写全仓指向四章的链接。 | NFBY 下一次真实会话的起点加载面；`标准/04` §6.1 的运行记录缺，现记未定。 执行记录：提交 `21a49a4`。 |
| D-098 | 2026-09-12 | 提议 | **标准的取用机制定为方案 A「tag + subtree 内嵌」**（Alan 2026-09-12 裁）。**问题**：采用项目入口硬编码本仓绝对路径 `C:/Programs/AI辅助开发规范及工作流确定/…`，换机 clone 即失效；本仓 0 个 git tag，`governance/STANDARD_VERSION` 里的值指不到任何可获取的制品（[`tools/std/README`](../tools/std/README.md) 自认「已知缺口」）。**裁定**：本仓新建线性发布分支 `release`，只含 `标准/`、`templates/`、`tools/std` 三目录加一个根 `README.md`；tag 名 = `STANDARD_VERSION` 的值（日期格式，本次 `2026-09-12`），打在 `release` 的发布提交上；采用项目 `git subtree add --prefix=.std … <tag> --squash` 把标准内嵌到 `.std/`，入口改写 `.std/标准/…` 与 `python .std/tools/std/check_all.py .`；升级走 `git subtree pull … <新 tag> --squash`，读两 tag 间 diff 评估后再改 `STANDARD_VERSION`；发布步骤由维护者按文档手工执行，**不写发布脚本**。 | **依据**：Alan 2026-09-04 优先级「行业标准 > 少就是多 > 好设计」——subtree + tag 是现成的行业做法，零运行期代码。与 [01 §8](../标准/01-项目管理标准.md#adoption)「由项目显式评估并升级，不在任务中自动跟随」一致：副本只能由一次显式 `pull` 移动。**对「内嵌副本会静默失效」的反驳**（原写在 `tools/std/README`）：会静默失效的是无版本的手工拷贝——副本停在拷贝当天而版本号照旧；按 tag 取的副本与 `STANDARD_VERSION` 由取用命令本身构造出一致，不会分叉，检查器身份仍由 [CONTRACT §8](../tools/std/CONTRACT.md) 的身份哈希钉住。**落选 B「取用器脚本」**：为分发再引入一层运行期代码与它自己的维护面，收益是 subtree 已经给的。**落选「脚手架生成器」与「harness 代码中间层」**：[D-020](#decision-index)／[09 §…](09-跨工具通用性.md#validation) 已裁规范不维护工具映射表；中间层的现有形态就是 AGENTS.md 常驻核 + 各 harness 入口一行指针，无需新建。 | 影响的文件：[`tools/std/README.md`](../tools/std/README.md)（「一条命令」「接入一个项目」两节）、[`标准/README.md`](../标准/README.md) `:3`（修订号 `2026-09-10`→`2026-09-12`，并说明该值即 tag 名）、[`标准/01`](../标准/01-项目管理标准.md) §3.1 文档树加 `.std/` 一行、[`标准/覆盖与采用检查.md`](../标准/覆盖与采用检查.md) 试点条件第 3 条、[`docs/附录-载体实例/仓库工作须知.md`](附录-载体实例/仓库工作须知.md) `:56`、[`tools/std/checks/check_adoption.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/checks/check_adoption.py) 的注释与限定语（身份哈希随之变，属预期）。**后续验证**：首个真实采用项目 `NFBY_CMS_FullStack` 换一台机器 clone 后 `.std/` 能否离线跑通检查；下一次标准升级实际走一遍 `subtree pull` + 两 tag diff 评估，看升级差异是否真的可读。 |
| D-099 | 2026-09-21 | 提议 | **标准强制力四缺口一轮补齐**（Alan 默认裁准，仓内可逆）。**问题**：门只规定状态不规定谁记，首错即停即产出空白；规则齐全而无执行点；ADR 就地追加"修订块"正文无据；未定项无登记入口。**裁决**：① 未定登记入口＝`governance/exceptions.md`，Finding 加稳定 `id`，退出码 2 只看未登记的未定（落 `tools/std/**`）；② [`标准/01`](../标准/01-项目管理标准.md) §5.6 加一段执行语义——门相互独立、每道落三态、没跑成的由这一次跑门的那一层记未定，不造"编排者"名词，[`delivery-gates`](../templates/agent-skills/delivery-gates.md) 同步；③ 执行层不发任何可执行件，只在 [`tools/std/README`](../tools/std/README.md) 写"进必经路径、退出码非 0 不放行"并给 2 行钩子示意，[`templates/AGENTS.md`](../templates/AGENTS.md) 补一条不可逆动作（改内嵌 `.std/`）；④ [`标准/02`](../标准/02-项目架构描述规范.md) §8 定"ADR 不就地修订，决定变了开新 ADR 取代；局部取代写明哪一条、旧份保持 `active`"，配 [`code-review`](../templates/agent-skills/code-review.md) 两条人工走查（日期自洽、ADR 改过就核正文），不做机械判据。**顺手修**：ADR/ARCHITECTURE/PRD 状态值域与 ADR 模板抬头对齐 02 §8、示例 ADR-0001/0012 抬头两行、模板 G6 行、示例 `GATES.md:5` 改指「命令」节、`CONTRACT.md:5` 删版本值留指针。 | 原则顺序：行业标准 > 少即是多 > 好设计 > 模型智能代替代码；加条款是最后手段。**先例**：[D-020](#decision-index) 与 [09 §6/§7](09-跨工具通用性.md) 判规范不维护工具映射表、只给一种即必填，[D-098](#decision-index) 判中间层已有形态——故 templates 不放钩子/CI/agent 配置；01 `:521` 判"对层②加规则无效"，执行层只补执行点不补条文；02 `:368` 正面授权"登记带范围/到期的例外后再判"，故退出码只看未登记。**落选**：project.yaml 新键（与 01 `:87`、02 `:176` 成第二处权威）、独立基线文件、同行标记词（撞 01 `:492`）、`--freeze-baseline`、ADR 漂移的机械判据（与事后补记结构性冲突，示例 4 份误报 2 份）、只改模板（正文仍无主）。 | NFBY 升级后三项：19 条数值声明逐条登记后 `check_all` 退出码回 0；`gate.sh` 改逐门跑、逐门贴三态；现存 ADR 的追加修订块按 02 §8 清理。**修订号本批不升**——本批新增采用方义务（问题二、四·乙）该升，但升值与发布六步捆为同一项上交 Alan，值取发布日。 |
| D-100 | 2026-09-21 | 已执行 | **新增检查器 `check_drift.py` 机械化两漂移信号**（Alan 2026-09-21 裁：轻工具化防文档脱离）。**问题**：[D-099](#decision-index) 把日期自洽、ADR 改后核正文两信号留给评审走查。**裁决**：新增 `tools/std/checks/check_drift.py`，四判据一律只产 `UNDETERMINED`，靠 CONTRACT §9 逐条登记后放行；两份词表是工具常量，不进 `project.yaml`。①`future-date`：日期后 10 字内命中裁定/批准/完成等 18 个已发生动作词、左侧 6 字内无复查/到期等 7 个计划词，且晚于该行 git blame 提交日（按提交时区折算；未提交或浅克隆整条取未定）→ 未定。②`adr-revision`：ADR 文件行首（第 0 字符起）命中修订/变更记录等 9 个标记词 → 未定。③索引对账收窄四支：`adr-unindexed`（有实物索引无 ID，`layout.artifacts.decisions` 已声明时 FAIL，回退时未定）、`adr-index-missing`（索引有 ID 无实物，一份索引一条未定）、`adr-index-absent`／`adr-index-unreadable`（未定）。④`work-item-missing`：状态文件 `WI-` ID 在 `work_root` 无文件 → 未定。**不重开 [D-099](#decision-index)**：不发安装器、不发 agent 钩子样例、不做运行回执；只在 [`tools/std/README`](../tools/std/README.md) 加 `.std/` 写入拒绝 3 行钩子示意，写明 merge／`--no-verify` 两盲区；`CONTRACT.md` 不动。示例 `governance/exceptions.md` 登记三条：`WI-0148`、`WI-0157` 声明无文件；索引 11 个 ID 无实物、示例只展开四份。**落选**（各一句）：索引状态/日期比对（示例假 FAIL，真阳 0）；ADR 头日期改动判据（示例 4/4 误报）；决定摘要 `sha`（新采用方义务，强度看是否重算）；`--install-hook`（pre-commit 对 subtree/merge 不触发）；运行回执（01 §5.2/§5.5 不采信自述）；PreToolUse 样例（09 §6 只给一种即必填）；代码路径存在性（全仓 735 误报，真阳 0）；GATES 命令存在性（PATH 属本机事实，示例 5/5 误报）；`source_rev` 落后次数（`check_derived` 已按提交判 FAIL，计数留作已知缺口）。 | 原则顺序：行业标准 > 少即是多 > 好设计 > 模型智能代替代码（Alan 本次裁「这类必须机械化」，末条让位于裁决）。与 01 §5.6「代理指标最多做提醒」的共存：四判据只产未定不产 FAIL，靠 §9 登记留痕，不越权代人拍板。已知误报形态（复查/到期等计划日、行首以外的"补充"）已用左侧排除词与第 0 位起判规则消掉。先例：[D-020](#decision-index)、[09 §6/§7](09-跨工具通用性.md)、[D-098](#decision-index) 判中间层已有形态、[D-099](#decision-index) 维持执行层不发可执行件。 | NFBY 升级后两条外部样本：ADR「修订五」块被 `adr-revision` 报出，`2026-09-22 裁定` 被 `future-date` 报出；本仓与示例交付面这两条判据真阳为 0，活性只能靠外部样本证明。发布号 `2026-09-22`。 |
| D-101 | 2026-09-22 | 已取代 | **Claude Code 一家的拦截层随标准发布，收窄「标准不发钩子」的作用域**（Alan 2026-09-22 裁「暂时只做 Claude Code 的 plugin/适配，仍按我的偏好裁，能做的直接做」）。收窄 [`tools/std/README`](../tools/std/README.md)「标准不发钩子、流水线或 agent 侧配置」那条一般规则的作用域为"Claude Code 以外"。载体取「内嵌目录根即插件」：仓根 `.claude-plugin/plugin.json`（hooks 指 `tools/std/hooks/hooks.json`）+ `marketplace.json`（自指），零新可见目录，随 subtree pull 原位更新。两条 hook：PreToolUse（Edit/Write/MultiEdit/NotebookEdit/Bash 一个条目，脚本按工具分支）——写内嵌目录 deny（路径是确定事实，[标准/01](../标准/01-项目管理标准.md) §5.6）、写 `.claude/settings*.json` 与 Bash 写内嵌目录 ask（命令串是代理指标）、`git commit`（含 `--no-verify`、`git -c … commit`、`&&` 链）先跑 check_all 非 0 即 deny（未定不放行；超时 300 s、崩溃、编码错同 deny）；SessionStart 注入「std 拦截层已加载 · guard sha8」在场行（01 §5.6 静默失效探测）。回执写 `CLAUDE_PLUGIN_DATA/receipts.log`（仓外，拦截层写非被约束者自述）。自检：`check_all --selftest` 连带跑 `guard.py --selftest`，guard 不在位记未定；guard 不进 [CONTRACT §8](../tools/std/CONTRACT.md) 身份，自报 sha8。解释器沿用 `python`（README 前提补 `python-is-python3`）。接入清单第 0 步"先跑绿再装"。**不做**：Stop 门（每回合 10 s+、block 后第二次必放行）、skills 迁移（技能只是提醒，7 文件 + 决策日志两行链接）、`--install-hook`、运行回执进项目、双解释器/userConfig、`if` 预筛（少匹配即静默失效）。 | **已由 [D-115](#decision-index) 取代**（superseded_by：D-115，2026-09-23）：自写拦截层（`.claude-plugin/`、`tools/std/hooks/guard.py`）已删，`.std/` 只读改由 `check_adoption` 判，Claude Code 侧改用原生权限规则与钩子，见 D-115。以下为原记录。 原则顺序；实测依据：`--plugin-dir`+PreToolUse 无头下真拦（含子 agent，`bypassPermissions`/`--no-verify` 绕不过）；拦 Edit/Write 时 `echo >` 可绕过；settings 无头不自动注册 marketplace；超时/解释器缺失放行。先例边界：①收窄 README `:144` 一般规则，[D-098](#decision-index) 行/落选项不动；②[09 §6/§7](09-跨工具通用性.md) 映射表禁令在——发的是实现非对照表，`标准/`正文未动，09:124 不触发，09 §6 与本批无关。 | NFBY 装上后 `echo > .std/…` 被 ask、`git commit --no-verify` 被 deny；交互模式 settings 是否自动注册 marketplace；公开仓提供可装插件（需显式 add），guard bug 影响全部采用方；升号 `2026-09-22`。 **2026-09-22 服务器 `--plugin-dir` 冒烟**：在场信号 12/12 会话出现；Write `.std/x.md` 被 deny；`echo zz > .std/y.md` 判先问、无头自动拒绝；`git commit`／`git subtree` 三次都没被模型发出（在场行与 README 劝住或回合用尽），钩子表态未取到端到端佐证；底稿在仓外 `~/Programs/交接-2026-09-22/smoke/`。 |
| D-102 | 2026-09-22 | 已执行 | **解释器只认 Linux（`python3`）；检查器自动排除工具自身所在的内嵌目录**（Alan 2026-09-22 裁「服务器解释器按软件工程标准，只考虑 Linux，不再兼容 Windows」「工具要能在不同项目里正常使用」）。① `hooks.json` 两处 command 与 [`tools/std/README`](../tools/std/README.md) 四处命令全改 `python3`，前提行写明 **Windows 不再是支持平台**（2026-09-22 起，旧实测只作历史记录）；盲区第 2 条改述为「`python3` 缺失或 hook 崩溃／卡死 → 静默放行」；`guard.py` 的写形态识别同时认 `python3 -c`，语料补一条 ask。② [`stdlib`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/stdlib.py) 新增 `embedded_std_rel(root)`：工具自身仓根在被扫 root 之下且不等于它即返回相对路径（`.std`），`tracked_files` 据此把该前缀移出**扫描面**；链接目标与 `layout` 候选路径走文件系统、不经该函数，不受影响。报告首部「配置 ·」行后打「排除 · `.std/`」，`--json` 由 `tool-identity` 的 evidence 记 `scan_excluded`，[`CONTRACT`](../tools/std/CONTRACT.md) §2 写明。**在标准仓自己身上无此排除**。**落选**：`python-is-python3`（把环境问题推给采用方）、双解释器条目（噪声）、`layout.frozen` 手工排除（每个项目配一次，漏配即锁死）。 | 实测：Ubuntu 只有 `python3`，`hooks.json` 写 `python` 时 hook 退出码 127、Claude Code 静默放行，整层不生效而无人知道；临时采用项目 30 条 FAIL／45 条未定全部来自扫描内嵌的 `.std/`，排除后同一项目 0 FAIL／12 未定，提交门不再装上即锁死。上游内容不是本项目的判定对象；检查器起子进程用 `sys.executable`，不受解释器名改动影响。原则：少即是多——一个函数加一行首部，不新增配置键。 | NFBY 装拦截层后首跑的退出码；服务器 claude 周限额重置（9-25）后补跑 `--plugin-dir` 冒烟，确认在场信号那一行出现（已于 2026-09-22 补跑，出现）；发布号 `2026-09-22.1`。 |
| D-103 | 2026-09-23 | 已执行 | **移除 Windows 相关的现行内容。** 删／改三类：① [`tools/std`](../tools/std/README.md) 交付面——`check_all` 入口冒烟 3d) 的盘符用例与 `os.name == "nt"` 断言段删，只留 `/t/proj` 两条取值断言；`config_outside_root` 去 `normcase`，docstring 只讲带分隔符前缀比较；`hooks/guard.py` 删 `os.name == "nt"` 分支与「Write 大小写 .STD」自检、删只为跨盘符存在的 `relpath` try/except（`_rel` 由此依赖唯一调用点传入非空 target），另补一条 POSIX 符号链接用例接替被删用例对 `realpath` 的覆盖；`stdlib.embedded_std_rel` 去 `normcase`；`check_links`／`check_cross_repo` 去 `normcase`；`check_all` 用法说明与 `check_derived` 自检夹具 `python`→`python3`；[`CONTRACT`](../tools/std/CONTRACT.md) §4 与 [`README`](../tools/std/README.md) 前提行、盲区第 6 条随之改；[示例项目](../标准/示例项目-连锁零售中台/governance/GATES.md)里 11 处 `python tools/…` 命令同改 `python3`（交付面一律 `python3`，D-102）；② `.gitattributes` 注释去 Windows 字样，eol 规则保留（防任何来源的 CRLF）；③ [仓库工作须知](附录-载体实例/仓库工作须知.md) §7「Windows 副本与服务器的同步」整节删，留一行占位（含服务器为唯一主工作地的事实）、不重编节号。**不删**：本日志既有行、审计记录、`会话交接-*.md`、`归档/`、`参考资料*`、`失败Case清单.md` 与外部文章快照里的 Windows 字样——它们是历史与外部材料，改写即篡改记录，保留。代码里的 `_WIN_ABS_RE` 与 `.replace("\\", "/")` 保留：前者查文档里写成盘符绝对路径的坏链接，后者处理任何来源的反斜杠，都与平台无关。 | 用户 2026-09-23 指示；D-102 已定 Windows 不再支持。行为不变：`config_outside_root`／`embedded_std_rel`／`guard._rel`／`check_cross_repo._norm`／`check_links._Cache` 改前改后同一组输入取值逐字一致；`check_all` 自检 69 条不变，guard 自检 51→52（+1 为符号链接用例），示例项目与本仓 `--no-scope` 计数不变。 | 发布号 `2026-09-22.4`。 |
| D-104 | 2026-09-23 | 已执行 | **拦截层补提交期兜底与模糊提交识别；`adoption` 缺采用日期降为未定。** ① `hooks/guard.py` 提交门先查 `.std/` 下有无已暂存或已跟踪未暂存的改动（`git status --porcelain --untracked-files=no`；不只看暂存区，因为 `git commit -a` 在钩子之后才暂存），有即不放行——写入动词清单永远列不全，这是结构性兜底，写入期检测降为提早提醒；② 写入期对 `.std` 的识别改为「提及」匹配：`.std`、`./.std`、`<项目根>/.std`，带不带尾斜杠都算，重定向写 `.claude/settings*.json` 也认绝对路径；写入动词不扩（`git rm`/`git mv` 本就被 `rm`/`mv` 命中，原先漏判只因判据要求尾斜杠）；③ 精确解析不变（不过即 deny），另加模糊识别：同段同时出现 `git` 与 `commit` 两词而未被精确认出（`bash -c`、子 shell、`/usr/bin/git`、`env`/`command`/`nohup`/`time` 前缀）→ 过同一道门，不过给 ask；④ `hooks.json` PreToolUse 显式 `timeout: 310`，大于内部 check_all 300 秒 + git 5 秒——宿主时限先到即取消钩子、动作照常执行，等于放行；guard 自身超时本就走拒绝；⑤ [`check_adoption`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/checks/check_adoption.py) 缺采用日期由 FAIL 降为未定（`adoption/adopted-date-missing`）：01 §8 只要求记录版本，日期字段名是工具词表，按 [CONTRACT §1.1](../tools/std/CONTRACT.md) 落空只能记未定；why 只逐字引 01 §8 第一条与 §4.7「标准升级」行原文，删去标准里 grep 不到的「何时采用的哪一版」；[README](../tools/std/README.md)「取用」补一句可同写 `adopted_at: <日期>`，「Claude Code 拦截层」的行为描述与盲区（六条→七条）随实现改。**刻意没做**：git 别名解析（列为盲区 7）；写入动词穷举（由提交期兜底代替）；检查器间重复报告（如 `evidence` 与 `freshness` 同报工作项目录不存在）与候选路径不一致，留待后续。`check_derived`／`check_drift` 自检夹具里造临时提交的 `git` 调用同样补 `-c commit.gpgsign=false -c core.hooksPath=/dev/null`（写法抄 `guard.py` 自检），堵住全局 `commit.gpgsign=true`／`core.hooksPath` 指向失败钩子时自检记未定；`tools/std` 下其余 `git init`/`add`/`log`/`blame`/`rev-parse` 调用不涉及提交签名或钩子，未改。 | 评估实测 `rm -rf .std`、`mv .std old`、`git rm -r .std`、绝对路径重定向写 `.std/` 与 settings、`bash -c "git commit …"`、`(git commit)`、`/usr/bin/git commit`、`env`/`command`/`nohup`/`time git commit` 共 12 种写法 decide() 无意见；check_adoption 那条 FAIL 引了标准里不存在的原文、又用工具词表产出 FAIL，违反 CONTRACT §1.1。行为变化：guard 自检 52→81 条（5 种写入改为 ask，7 种提交写法门不过时 ask、门过时无意见；另含兜底、非 git 仓与读 `.std` 不误报的反例）；`check_all --selftest` 69 条不变；check_adoption 缺日期由失败→未定；本仓与 NFBY 都已记 `adopted_at`，`check_all` 计数不变（本仓 9/2/19/5 退出 1，NFBY 71/0/19/21 退出 0）；提交时 `.std/` 有已跟踪未暂存改动也被拒，比 `git diff --cached` 严一档。 | 发布号 `2026-09-23`。 |
| D-105 | 2026-09-23 | 已执行 | **同一事实只由一个检查器报；工作项目录与状态工件候选各收成 [`stdlib`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/stdlib.py) 一处。** ① `stdlib` 新增 `DEFAULT_WORK_ROOT`、`STATUS_CANDIDATES`、`rebase_docs`、`work_root(cfg)`、`work_root_absent(check, cfg)`；`evidence`／`freshness`／`drift` 三份 `_DEFAULT_WORK_ROOT`、`drift` 的 `_STATUS_CANDIDATES`、`layout` 的 `_rebase_docs` 删去改调它。② 工作项目录不在这件事归 01 §3.1 的存在性判定，由 `layout` 报一次（L1 起的 `work_current` 一项）；`layout` 的 `work_current` 未声明 `layout.artifacts.work_current` 时先认 `layout.work_root`（此前不认，声明的目录在也报"没找到"），该目录不在时标题与理由直说「layout.work_root 声明的目录不在」，不再推给"可能是有意裁剪"；`evidence`／`freshness` 改记 `SKIP`（`<检查器>/work-root-absent`，标题「本检查只扫工作项目录，它不在」），证据写明负责报告的检查器是 `layout`，两者 not_covered 各补「L0 合在状态工件里的工作项不扫」；`drift` 判据 4 在状态文件列出 ID 而目录不在时同样只记一条 `drift/work-root-absent`（`SKIP`），不再逐 ID 报 `work-item-missing`——L0 按模板把工作项写在 `WORK.md` 里、本无此目录，逐 ID 报既与「L0 不要求该目录」矛盾，又是同一事实报 N 次（审查指出，自检 4f 钉住）。[CONTRACT](../tools/std/CONTRACT.md) §1 加「同一事实只由一个检查器报」一条，§3、§4、§5 两行随之改。③ 状态候选统一为 `WORK.md`（模板 L0 树）与 `docs/state/STATUS.md`（01 §3.1）；`drift` 去掉 `PROJECT_STATUS.md`——那是模板文件名不是落点（同 `PRD.md` 落成 `ACCEPTANCE.md`），只有标准仓自己这么叫，而本仓已在 `layout.artifacts.status` 声明；`drift` 的候选改为随 `docs_root` 改基、文件或目录都认，与 `layout` 同一判据。④ 缺省 `work_root` 随 `layout.docs_root` 改基，与 `layout` 候选同一规则（`docs_root` 为 `docs` 时不变）；`docs_root≠docs` 的项目读数可能变（缺省工作项目录随之改基，能扫到原先被掩盖的真实工作项）。⑤ `check_all --selftest` 加 `shared-fact` 两条跨检查器反例（单个检查器的自检看不见别的检查器）；用改前的四个检查器跑这两条均为 FAIL。**刻意没做**：`layout.docs_root` 缺省两检查器不一致（CONTRACT §5 已记为实现现状）与 `metadata_fields` 缺省在 `layout`／`freshness` 各一份（不是工件落点）不在本批；`layout.artifacts.work_current` 与 `layout.work_root` 同时声明且指向不同路径时，`work_root` 不在无人报，边角不加代码；L0 档不要求工作项目录，此时两条 `SKIP`、`layout` 不报。 | 用户裁定修；原则：一个事实一个报告者（01 §1 G2 用在报告上）。行为变化：`check_all --selftest` 69→72（`shared-fact` 两条 + `drift` 4f）；guard 81 不变；本仓 `check_all .` 与 `--no-scope` 均为 通过 9／失败 2／未定 19→17／不适用 5→7，退出 1 不变（少的两条未定即重复报告）；NFBY 73／0／19（已登记 19）／21 退出 0，finding id 与状态逐条不变；示例项目 42／1／21（已登记 4）／25 不变；临时最小 L1 采用项目（无工作项目录）未定 11→9、不适用 5→7；临时 L0 采用项目（`WORK.md` 列 WI-0001、无工作项目录）通过 10 不变、未定 7→5、不适用 5→7——两条"工作项目录不存在"未定变 SKIP，`drift` 由"候选里没有 WORK.md 故跳过"变为认出 `WORK.md` 后记一条 `work-root-absent`。**finding id 变化**：`evidence/<sha1(标题)[:8]>` 与 `freshness/<sha1(标题)[:8]>`（标题「工作项目录不存在：<路径>」，两者同哈希，缺省路径时为 `fd7e1636`）不再产出，新增 `evidence/work-root-absent`、`freshness/work-root-absent`、`drift/work-root-absent`（`SKIP`，不可登记）；目录不在时 `drift/work-item-missing/<ID>` 不再产出；声明了 `layout.work_root` 而目录不在时，`layout` 那条 `work_current` 未定标题改变，兜底 id 随之变（此前 `layout` 不认 `work_root`，按候选报「没找到」或判通过）。**对采用方**：登记过上述消失 id 的，升级后那几行成孤儿（`exception-register/orphan` 未定、退出 2），删掉即可；该事实改由 `layout` 的 `work_current` 那条承载，未登记它的补登记。NFBY 未登记这两条，不受影响。 | 发布号 `2026-09-23.1`。 |
| D-106 | 2026-09-23 | 已执行 | **被多个检查器读的配置键，缺省只在 [`stdlib`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/stdlib.py) 写一处。** ① 逐个 grep `tools/std` 的 `cfg_get` 与模块级缺省常量：多处读且各带缺省的只有两个键——`layout.docs_root`（`layout` 与 `stdlib.rebase_docs`／`work_root` 取 `docs`，`freshness` 与 `drift` 缺了整条记未定「未配置文档根目录」；[CONTRACT](../tools/std/CONTRACT.md) §5 只记了前两家的不一致，漏了 `drift`）与 `metadata_fields`（`layout`、`freshness` 各一份 `updated_at` 与各自的解析：`layout` 不去空白不滤空项，`freshness` 另认契约里没有的映射写法）；其余键（`budgets.*`、两个 `work_item_*_states`、`layout.rule_files`、`layout.frozen`、`tailoring`、`derived`、`repos`、`metadata_required`）各只在一个检查器里有常量缺省或缺省一致，未动；`layout.entry` 多家读但没有常量缺省，见「刻意没做」。② `stdlib` 新增 `DEFAULT_DOCS_ROOT` 与 `docs_root_of(cfg)`（放「工件落点」一节，返回 (路径, 证据注记)，同 `work_root`）、`DEFAULT_DATE_FIELDS` 与 `date_fields_of(cfg)`（放 `STATUS_FIELDS` 旁与 `cfg_get` 旁）；`layout`／`freshness` 的 `_DEFAULT_DATE_FIELDS` 与 `_date_fields` 删去改调它，`layout`／`freshness`／`drift` 的 `docs_root` 读取与 `rebase_docs`／`work_root` 的改基都改调 `docs_root_of`；取了默认时的证据注记由 `stdlib.note_default` 在出口统一补（`freshness` 文档部分整组，`drift` 日期判据整组与未声明 `decisions` 时的 ADR 部分），不逐条拼，标题不动、id 不变。③ **取舍**：`docs_root` 统一为缺省 `docs` 并注明，而不是统一为未定——01 §3.1 文档树根就是 `docs/`，`layout` 候选与缺省 `work_root` 早已按它改基，改成未定会让 `layout` 与工作项目录缺省一并失去依据；契约 §5 原话即「这处不一致是实现现状，不是有意设计」。`metadata_fields` 以契约 §5 的类型（字符串列表，也接受单个字符串）为准，去空白、滤空项，映射写法不再认（契约没写、无采用项目用）。CONTRACT §5 两行与例外段随之改，加一句「被多个检查器读的键，常量缺省只在 `stdlib` 写一处」，并注明 `layout` 的分档候选路径是 §1.1 的提示、不算缺省。④ `check_all --selftest` 的 `shared-fact` 加第三条：未配 `docs_root` 时四个检查器无一记「未配置文档根目录」，`freshness` 按缺省判出 `docs/` 下的缺日期文档且证据注明用了默认；用改前的检查器跑这条为 FAIL。**刻意没做**：只在单个检查器里用的缺省常量（`_DEFAULT_ENTRY_LINES`、`_DEFAULT_STALE_DAYS` 等）不搬进 `stdlib`——一处定义已满足 G2，搬了是无关重构。`layout.entry` 未配时 `layout` 退回分档候选名找入口、`entry-budget` 与 `cross-repo` 记未定——候选属契约 §1.1 的提示而非常量缺省，不在本条「常量缺省一处」的范围，两家读法要不要进一步对齐留待后续。 | 用户裁定修（D-105「刻意没做」两项）；原则：同一配置一种读法（01 §1 G2 用在缺省上）。行为变化：未配 `layout.docs_root` 的项目，`freshness`／`drift` 不再整条记未定，改按 `docs/` 巡检（`docs/` 不在时 `freshness` 记「文档根目录不存在：docs」未定，`drift` 判据 4 此前被这条短路、现在照跑），可能新出 FAIL／PASS；`metadata_fields` 写成映射的项目 `freshness` 改取默认，写了空白或空项的 `layout` 不再拿空名去匹配。实测：`check_all --selftest` 72→73 通过、退出 0；guard 81 不变；本仓 通过 9／失败 2／未定 17／不适用 7 退出 1、示例项目 42／1／21（已登记 4）／25、NFBY 73／0／19（已登记 19）／21 退出 0，三者都配了 `docs_root`，finding id 与状态逐条比对：示例项目与 NFBY 全同，本仓只有 `links` 的 PASS 兜底 id 变（标题含链接总数，随同期工作区里 `templates/`、`标准/` 的他人改动与本行新增的链接而变，与检查器改动无关）。未配 `docs_root` 的项目，**finding id 变化**：`freshness/485ed7e7`、`drift/485ed7e7`（标题「未配置文档根目录」）不再产出；改为 `freshness` 按 `docs/` 逐份判（新出以各自标题计 id 的 FAIL／PASS，`docs/` 不在时出一条「文档根目录不存在：docs」未定），`drift` 各判据照常产出；证据里注明用了默认 `docs`，标题不变。**对采用方**：登记过 `*/485ed7e7` 的，升级后成孤儿（`exception-register/orphan`），删掉即可。 | 发布号 `2026-09-23.2`。 |
| D-107 | 2026-09-23 | 已执行 | **命名统一：以 [`标准/01`](../标准/01-项目管理标准.md#doc-tree) §3.1 为唯一命名权威。** 逐项（按 `git diff 标准 templates` 核对）：① [`templates/文件树与落地路径.md`](../templates/文件树与落地路径.md) §2 表定为「模板名 → 落地名」映射表，新增「对应 01 §3.1 路径」列（`AGENTS.md`；`docs/product/acceptance/`；`docs/state/STATUS.md` + `docs/state/work/` + `docs/state/handoff/`；`docs/knowledge/PLAYBOOK.md`；`docs/knowledge/FAILURES.md`），`WORK.md` 行的对应模板补 PROJECT_STATUS，表下加一句「命名以 01 §3.1 为准；项目实际落点以 `governance/project.yaml` 的 `layout.artifacts` 声明为准」；② L0 入口由 `CONTEXT.md` 改为 `AGENTS.md`（加载合同是其中一节）：同文 §2 树与表、§3 与 §4 两棵树、§6 两处、§8 对照表一并改，§8 本仓 `CONTEXT_MANIFEST.md` 的差异列补「单列成一份文件」；③ [`templates/AGENTS.md`](../templates/AGENTS.md) 用法说明加「默认加载合同按 `templates/CONTEXT_MANIFEST.md` 写成本文件的一节」，§1 权威位置表加「路径以 `layout.artifacts` 为准」，决策一行 `docs/adr/NNNN-*.md` → `docs/decisions/ADR-*.md`（同 01 §3.2 `decisions/ADR-*`）；④ [`templates/README.md`](../templates/README.md) 注明 CONTEXT_MANIFEST 落地为入口 `AGENTS.md` 的加载合同一节、PROJECT_STATUS 落地为 `WORK.md` 的摘要部分（01 §3.1 大项目树为 `docs/state/STATUS.md`）；⑤ [`templates/CONTEXT_MANIFEST.md`](../templates/CONTEXT_MANIFEST.md) 开头补一句落地位置；文件树 §4「对应模板」里的项目状态改指 §2——原写法与 ADR、Eval Manifest 并列在 L2 树下，读成只在 L2 使用，与 §2 表 `WORK.md` 行矛盾；⑥ [`标准/03`](../标准/03-Agent信息获取与上下文管理.md) §3 删「本仓库沿用 `CONTEXT_MANIFEST.md`」半句（交付面里「本仓库」指代不明，采用方读到会当成指自己）；⑦ 01 §3.1 引言加一句「本树是命名权威」，并指向上述对照表与 `layout.artifacts`。**检查器代码不动**：`check_layout` 的入口候选仍是 `CONTEXT.md`、`AGENTS.md`、`CLAUDE.md` 三个，按旧模板落地的项目读数不变。 | 同一工件在 01 §3.1、模板树、模板 README、AGENTS 模板里各有一套名字（`CONTEXT.md`／`AGENTS.md`，`docs/adr/`／`docs/decisions/`），采用方照哪一份建都与另一份对不上——命名是一份清单，按 01 §1 G2 只能有一处权威。取 01 §3.1 而不是模板树：它是标准正文，模板是实例。**落选**：同时从检查器入口候选里删 `CONTEXT.md`——按旧模板落地的项目入口会无故变未定，而命名统一的收益在文档侧已拿到。 | 本仓 `check_all .` 与示例项目读数改前改后相同（本仓 通过 9／失败 2／未定 17／不适用 7，示例项目 42／1／21／25），`links` 无新增断链；下一个按模板新建的采用项目，入口是否直接落成 `AGENTS.md`、决策是否落在 `docs/decisions/`。发布号 `2026-09-23.2`。 |
| D-108 | 2026-09-23 | **已接受** | **实际交付形态，取代 [D-041](#decision-index)**（Alan 2026-09-23 在对话中批准：「批准，D-041 按你起草的记」）。① **交付面**：`标准/`、`templates/`、`tools/std/` 三目录，加仓根 `.claude-plugin/` 与两份许可——`LICENSE`（MIT，代码）、`LICENSE-DOCS`（CC BY 4.0，`标准/` 与 `templates/` 的正文与模板），以及发布时在 `release` 分支根写的 `README.md`（说明本分支是 main 的发布产物，见 `tools/std/README`「发布」步骤）；② **分发**：私有 `main` → `release` 分支上的线性发布提交 + 日期 tag（同日第二次起加 `.1`、`.2`）→ 公开仓 `github.com/Alan-IFT/ai-dev-std` 的 `main`；采用项目 `git subtree add`／`pull --prefix=.std <公开仓> main --squash`，**默认取 `main`，要钉某一版把 `main` 换成 tag 名**——这一条 2026-09-13 起写在 [`tools/std/README`](../tools/std/README.md)「接入一个项目」节的「取用、升级、发布三条命令线」段落，而 [D-098](#decision-index) 写的是按 tag 取，此前没有决策依据，本行补上；③ **执行层**：检查器 `check_all` 与 Claude Code 拦截层随标准发（[D-101](#decision-index)），其它宿主工具的钩子、流水线与 agent 侧配置由采用项目自接（`templates/` 与示例项目里的 `AGENTS.md`、skill 文件是载体实例，不属执行层）；④ **落选**：生成器、脚手架、安装器、取用器脚本（D-098 落选项，[D-099](#decision-index) ③ 执行层不发可执行件，D-101 不做 `--install-hook`）；⑤ **保留 D-041 的两句**：不按文件在不在、有几个打分；模板与 Skill 效力为零（`docs/附录-载体实例/` 同样效力为零，且不进交付面）；⑥ 私有 `main` 不公开，只推 `release`。（**2026-09-23 按 [D-115](#decision-index) 修订**：交付面去掉 `.claude-plugin/`；③ 里的 Claude Code 拦截层不再随标准发，Claude Code 接法改为 `tools/std/README`「Claude Code 接法」里的原生配置示意，登记行已同步。） | 交付形态早已按 D-098（tag + subtree）、D-101（拦截层）与 2026-09-13 的开源发布落成，并逐次发布到 tag `2026-09-23.1`；而 D-041 仍写「项目侧存在性检查器/生成器」且一直未裁，活文档据此写「最终交付形态尚未决定」——状态与事实不符。D-098、D-099、D-101 三行状态不改，保留作来源追溯；其内容凡写进本行的随本行生效，未写进的不生效（同 [D-057](#effective-register) 对被认领决策的写法）。 | 下一次发布照 `tools/std/README`「发布」一条走完后，公开仓 `main` 与本仓 `release` 同一提交；采用项目换机 clone 后 `.std/` 能离线跑通 `check_all`（D-098 后续验证原句）。`review_at` 取 2027-03-23：6 个月，同 D-015、D-020、D-043、D-047，D-014 的 3 个月是宪法性元规则的特例。 **（2026-10-05 按 [D-135](#decision-index) 再修订）**：交付面再加 `tools/dsh-std/`（DeepSeek Harness 插件，本仓唯一受支持宿主上的执行层）；blocks 里「任何宿主工具（含 Claude Code）的钩子、权限或流水线配置」加唯一例外 `tools/dsh-std/`；Claude Code 不再是受支持宿主，上文 ③ 与 D-115 里面向它的接法一并退出。效力以生效登记表那一行为准。 |
| D-109 | 2026-09-23 | 已执行 | **入口文件只有一种读法，收进 [`stdlib`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/stdlib.py) 一处；加载合同落成入口一节时，合同头怎么写补上说明，模板与示例项目随之补齐。** ① `stdlib` 新增 `ENTRY_CANDIDATES`（`CONTEXT.md`、`AGENTS.md`、`CLAUDE.md`，从 `layout` 的 `_TIER_ITEMS` 挪来）与 `entry_files(cfg)`，放「工件落点」一节，返回 (路径列表, 注记)：先取 `layout.entry`（未配时认 `layout.artifacts.entry`，同 `layout` 原行为），不判存在、注记为空；未配则按候选顺序取第一个存在的，注记写明来自候选，同时存在几个也只取第一个、注记列出其余——与 `layout` 原行为一致；`layout` 与 `entry-budget` 改调它。② `entry-budget` 不再记「未配置入口文件」：候选命中且在预算内记 `PASS`，超预算记 `UNDETERMINED`（`entry-budget/candidate-over/<路径>`），不记 `FAIL`，声明后仍超才判 `FAIL`。**依据**：[CONTRACT](../tools/std/CONTRACT.md) §1.1 原文「判据靠猜测得出的结论只能是 `PASS` 或 `UNDETERMINED`，永不产出 `FAIL`」，所列猜测包括「从模板快照抄来的候选路径」，并写明「要把某项判成 `FAIL`，先让项目在 `project.yaml` 里声明落点」。行数是事实，但「这份就是入口」这个前提来自候选，结论建立在猜测上，照契约记未定。③ 入口不在（候选都不在，或 `layout.entry` 列的文件不在）由 `layout` 按 01 §3.1 ★ 入口报一次，`entry-budget` 改记 `SKIP`（`entry-budget/entry-absent[/<路径>]`，证据写明负责报告的是 `layout`），做法同 D-105 的 `work-root-absent`。④ `layout` 候选命中时，标题由「入口（entry）在：X」改成与声明时同一句「入口 X 在」，注记写进证据；候选都不在时仍走通用分支，记「★ 入口 类工件没找到（entry）」，标题与 id 不变；`_LEGACY_CANDIDATES` 删去，旧模板那句说明挪到 `stdlib` 注释里。⑤ CONTRACT §1（加第二例）、§4（kind 清单）、§5（`layout.entry` 一行、缺省段一句、01 §3.7 表入口一行）随之改。⑥ `check_all --selftest` 的 `shared-fact` 加第四条：两个候选同时在时两检查器都取 `AGENTS.md`，候选超预算记未定，声明后判 `FAIL`，候选都不在时入口缺失只由 `layout` 报一次；用改前的检查器跑这条为 FAIL。⑦ [`templates/CONTEXT_MANIFEST.md`](../templates/CONTEXT_MANIFEST.md) 的落地说明补一句：落成 `AGENTS.md` 一节时，YAML 头不搬到文件头（会读成整份入口的元信息），改写成该节标题下的一行（合同 ID、版本、`updated_at`、状态、当前工作项）；只有单列成一份文件时才保留 YAML 头。03 §3 只要求这几项能在 §3.2 第 4、5 条核对时对得上，不要求可机读，也没有检查器读它们，03 正文不动。⑧ [`templates/AGENTS.md`](../templates/AGENTS.md) 原先没有加载合同一节，与文件树 §2「加载合同是其中一节」对不上：在 §1 权威位置表下加小节「加载合同（唯一一份）」，只给合同头一行的样式和一句「按 `templates/CONTEXT_MANIFEST.md` 写成本节」，不抄 CONTEXT_MANIFEST 正文；放成 §1 的小节而不是新开 §2，是为了不给后面各节改号（本文件里有 §2、§3、§4、§6 的按号引用）；用法引用块指向这一节。⑨ [示例项目 `AGENTS.md`](../标准/示例项目-连锁零售中台/AGENTS.md)「## 2. 加载合同」下补合同头一行：`retail-core-context-001` · 第 1 版 · `updated_at` 2026-09-07（同该项目 `docs/state/STATUS.md` 的冻结日期）· `proposal` · 当前工作项 无（第 4 行按 STATUS 解析）。状态取 `proposal`：模板写明 trial/accepted 要带批准记录才有执行效力，示例项目里找不到这份合同的批准记录，不编一条；入口 101→103 行，仍在预算 150 内。审查另修三处：只配 `layout.artifacts.entry` 时证据误写「layout.entry 列了它」，三处统一为「来自项目声明（layout.entry／layout.artifacts.entry）」；`layout` 覆盖边界改调 `entry_files`，候选命中时不再显示「未配置」；`entry-budget/entry-absent` 的证据注明 `layout` 被裁剪、入口一项被裁剪或 `tier` 未声明时它不报。`shared-fact` 第四条同时加一种情况：声明的入口不在时 `layout` 记 `FAIL`、`entry-budget` 记 `SKIP`（原第四条没覆盖这条路径）。**刻意没做**：`cross-repo` 在未配 `layout.entry` 时，入口相关判据仍记未定。原因：它要在每个仓里认同一组入口名，四条判据的结论大多是 `FAIL`，改用候选来源后按 §1.1 只剩通过和未定，得在三个函数里加一个来源标记，而受益的只有「多仓且没配入口」的项目；这条未定说的是它自己的判据判不了，不是把入口在不在重复报一次。D-106「刻意没做」里「`layout.entry` 两家读法」那一句由本行了结，`cross-repo` 部分见上。`layout` 被裁剪、入口一项被裁剪或 `tier` 未声明时，入口不在就没有检查器报；这与 D-105 的边角相同，不加代码。 | 用户裁定做（D-106「刻意没做」中的 `layout.entry` 一项）；D-107 把 L0 入口定为 `AGENTS.md`、加载合同落成其中一节，但模板没交代合同头放在哪。原则：同一配置一种读法（01 §1 G2），同一事实只报一次（CONTRACT §1）。行为变化：`check_all --selftest` 73→74，退出 0（敌意 git 配置下同样）；guard 81 不变；配了 `layout.entry` 的项目，读数与检查器改动引起的 finding id 逐条不变——本仓 9／2／17／7 退出 1，示例项目 42／1／21（已登记 4）／25 退出 1（它的 `AGENTS.md` 因⑨多两行，`entry-budget` 那条 `PASS` 的标题行数 101→103，兜底 id `entry-budget/36570b83`→`07c3109f`；改示例前用新工具跑一次，与改前工具逐条全同；`single-authority` 各条标题都没变），NFBY 72／0／19（已登记 19）／21 退出 0，PMC-Planner 91／0／65／26 退出 2（四者前后 `--json` 的 (id, 状态) 多重集逐条比对，本仓变了两条兜底 id，都与检查器改动无关：`links` 的 PASS 标题含链接总数，随本行新增的链接由 6495 变 6500；`single-authority` 那条原有的 FAIL（`templates/AGENTS.md` 与 01 §5.5 受控动作清单三行重复）标题含行号，因⑧在前面插了 6 行由 `:55` 变 `:61`，id `763e0d81`→`d5cbf23d`，FAIL 不可登记，无登记受影响；NFBY 通过数比 D-106 记的 73 少 1，是它自身仓库的变动，改前的工具跑出来也是 72）。未配 `layout.entry` 的项目：临时最小 L0 项目（`AGENTS.md` 与 `CLAUDE.md` 并存）通过 5→6、未定 6→5。**finding id 变化**：`entry-budget/62b41433`（「未配置入口文件」，未定）不再产出，改为候选命中时出 `PASS`（兜底 id）或 `entry-budget/candidate-over/<路径>`（未定，可登记），候选都不在时出 `entry-budget/entry-absent`（`SKIP`）；`layout.entry` 列的文件不在时，`entry-budget` 的「入口文件不存在：X」（兜底 id，未定）改为 `entry-budget/entry-absent/<路径>`（`SKIP`），同一事实由 `layout` 的 `FAIL` 承载；`layout` 候选命中的 `PASS` 兜底 id 随标题变（如 `AGENTS.md` 由 `layout/8a627a64` 变为 `layout/a15f35e6`，即声明时的那一个）。只配 `layout.artifacts.entry` 的项目也走这个统一分支，`layout` 的 id 同样会变：实测文件不在时 `FAIL` 由 `layout/cd14822f`（「★ 入口 类工件缺失（entry）」）变为按「★ 入口缺失：<路径>」算的兜底 id（`GONE.md` 时是 `layout/56b8452f`），文件在时 `PASS` 由 `layout/3ded24ff` 变为 `layout/25ea0170`（`CLAUDE.md`）；`entry-budget` 由记「未配置入口文件」改为按行数照判，这是声明值，所以超预算判 `FAIL`。**对采用方**：登记过 `entry-budget/62b41433` 或「入口文件不存在」兜底 id 的，升级后那几行成孤儿（`exception-register/orphan`），删掉即可；超预算的候选入口若要接受，登记 `entry-budget/candidate-over/<路径>`，或者在 `layout.entry` 里声明它（声明后超预算就是 `FAIL`，不可登记）。四个在册项目都配了 `layout.entry`，不受影响。 | 发布号 `2026-09-23.3`。 |
| D-110 | 2026-09-23 | **已接受** | **效力状态值域增设`已执行`**（Alan 2026-09-23 在对话中批准：「批准，按推荐 A 增设'已执行'」）。[08 §1](08-规范效力元治理.md#force-states) 状态表加一行：不可阻断、不可授权，必需字段为 decision_id、日期、执行记录指针（提交号、审计记录或发布号），不进生效登记表。本表整条执行完毕、无待裁部分的`提议`行同批改记`已执行`，行内补执行记录指针，删去「状态记`提议`是记账上的将就」一类免责句；未执行完或仍有待裁部分的（如 D-073、D-078、D-086、D-093）保持`提议`；生效登记行明写其状态不改的（[D-057](#effective-register) 之于被 `governed_by` 认领的决策，[D-108](#effective-register) 之于 D-098、D-099、D-101）亦不动。[`check_normative_force.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/docs/%E9%99%84%E5%BD%95-%E8%BD%BD%E4%BD%93%E5%AE%9E%E4%BE%8B/check_normative_force.py) 的 `FORCE_STATES` 加该值、不进 `EFFECTIVE_STATES`；执行记录指针齐不齐不加机械校验，由改记时人工核对 | 值域里没有「已执行但不产生规则」一档，`提议`同时装着真待裁与已了结两类：D-056 起五条各写一段免责句自辩（「为 n=1 增设一个状态值不划算」），此后同类行累积到近二十条，查待裁须逐行读正文。改的是 D-014 所定的值域，属元规则修正，故由项目所有者直接批准并登记 | 两项自检 PASS；按状态计数改前 `提议` 74、`试行` 1、`已接受` 6、`已取代` 13、`已拒绝` 15，改后由 `check_normative_force.py` 的索引解析现取，本行不抄。**证伪信号**：出现一条记`已执行`的决策被援引为阻断或授权依据，或记`已执行`的行事后查出仍有待裁部分 |
| D-111 | 2026-09-23 | 已执行 | **本仓自检两条 FAIL 清零、清一批未定：模板受控动作清单改指针，补两件工件落点，删四组抄写的数，修检查器两处误报，README 裁剪粒度改准，验收工件登记不适用。** ① [`templates/AGENTS.md`](../templates/AGENTS.md) §3 的前六条与 [01 §5.5](../标准/01-项目管理标准.md#controlled-actions) 清单逐字或近乎逐字重复（其中三行逐字，即 `single-authority/d5cbf23d` 那条 FAIL），改为一句「动作清单见 `.std/标准/01-项目管理标准.md` §5.5，此处不抄」，只留模板特有的三条：`ACCEPTANCE.md` 冻结条目与本文件／`WORK.md`／`FAILURES.md` 的覆盖删除、`.std/` 只读、§0 项目特有动作。② `governance/project.yaml` 的 `layout.artifacts` 加 `failures: docs/失败Case清单.md`、`playbook: docs/附录-载体实例/仓库工作须知.md`。③ 删抄写的数，改指向权威处：`check_single_authority.py`、`check_cross_repo.py` 两处注释里的 M-26 同名文件数；`linkcheck.py` 文档串里的 C-016 假断链数（改为「数字与经过见 Case C-016」）；[失败 Case 清单](失败Case清单.md) §0 的决策条数（写于当时，现决策已逾百条，改为「当时已记的决策」）及 [图工程落地包 03](图工程落地包/03-通用落地套件.md) 对该句的逐字引文；根 README、`templates/README.md`、[架构图 README](架构图/README.md) 的「部件数与文件数、L0 文件数」三处改为链到[文件树与落地路径 §1](../templates/文件树与落地路径.md#not-14-files)。④ `check_single_authority` 的数值声明加序数排除：数字前紧挨「第」、或处在「第 N、」起头的并列序数里时不计，不带「第」的并列照计；selftest 加「探测三之四」两侧钉住，用改前的检查器跑为 FAIL。⑤ `metadata_required: []` 有了语义：解析器只多接受空列表 `[]` 这一种流式写法（`[a, b]` 仍拒）；`freshness` 把显式空列表读作项目声明没有 01 §3.5 那六类文档，无日期文档整轮记一条 `SKIP`，键缺失才落到原来那条聚合未定；selftest 加「反例四之二」（取值经解析器读出），改前为 FAIL；CONTRACT §5 的流式写法一段、`metadata_required` 表行与专段同步；`check_evidence` 判「完成态是否用默认」由 `is None` 改为假值判断，免得空列表被说成「取自 project.yaml」。⑥ [`tools/std/README.md`](../tools/std/README.md) 说裁剪「粒度是整个检查器」，与 CONTRACT §5 允许 `layout:<role>` 单裁一个工件矛盾，按实现改为「整个检查器，或 `layout` 下的单个工件」。⑦ 独立审查通过，另提三条低严重度问题，照调度裁定改：解析器在列表项位置写 `- []` 时拒收（原先会静默解析成嵌套空列表），`contract-examples` 加一条自检钉住三种形状（键值 `[]` 收、`- []` 与 `[a, b]` 拒）；根 README 那句改为「L0 落地几个文件」；CONTRACT §5 两处「键缺失」改为「键缺失或值为空」（`metadata_required:` 不写值解析为空，同样落到未定）。⑧ `core.autocrlf=true` 加 `core.safecrlf=true` 时自检夹具里的 `git add` 失败（selftest 退出 1、guard 自检崩），凡是夹具里造提交的 git 调用都补 `-c core.autocrlf=false -c core.safecrlf=false`（`check_all`、guard 与六个检查器的夹具），被测代码不动。⑨ **Alan 2026-09-23 批准**：验收工件那条 FAIL 按裁剪处理——`governance/project.yaml` 的 `tailoring` 加 `layout:acceptance`（`applicable: false`，理由引 D-057「本仓库不是一个交付软件的项目」），删去 `layout.artifacts.acceptance` 那条为示范而保留的声明及其注释；[`tools/std/README.md`](../tools/std/README.md)「本仓库自己的采用结果」一节改成现状（仍有未定未登记，验收工件是登记的不适用、不是修好）。 | 分析席对本仓自检（9／2／17／7，退出 1）给的处置方案里可自决的部分，调度裁定执行。依据：01 §1 G2（数值的权威只有一处，别处写链接不抄值）、01 §2 N2（副本即缺陷）、01 §5.5「写在入口、提示词或流程说明里的同一句话只是提醒，不构成受控」——入口里抄一份清单不增加受控性，只多一处会漂的副本；序数与空列表是检查器自身的误报与语义缺口（CONTRACT §1.1、§5）。**行为变化**：`check_all --selftest` 74→77，退出 0（普通配置、敌意 git 配置、`autocrlf`+`safecrlf` 配置下同样）；guard 81，三种配置下同样通过；本仓 9／2／17／7 → 12／0／10／8，退出码 1→2（没有 FAIL 了，剩未登记的未定）。**finding id 变化（本仓）**：不再产出 `single-authority/d5cbf23d` 与 `layout/1ba3a520`（两条 FAIL，后者由新增的 `layout/46549a1c` 不适用承接）、`layout/57c4349f`、`layout/e8f1afc3`，以及 `single-authority/count-claim/` 下的 `14:个:文件`、`1614:个:同名`、`16:个:部件`、`40:条:假断`、`56:条:决策`（均为未定）；新增 `layout/cdf1b608`、`layout/fb0efc06`（failures／playbook 在）与 `single-authority/0eb1835e`（无跨文件重复文本块）三条 PASS；`links` 的 PASS 兜底 id 随本批新增链接变。**对采用方**：示例项目 42／1／21／25、NFBY 72／0／19（已登记 19）／21 退出 0、PMC-Planner 91／0／65／26，改前改后 `--json` 的 (id, 状态) 逐条全同——三者既没有被序数误报的数值声明，也没写 `metadata_required: []`，无登记成孤儿。此后写了「第 N 个」「第 N、M 个」的项目，对应的 count-claim 未定不再产出，登记过的成孤儿（`exception-register/orphan`），删掉即可；要把「没有六类文档」说成定论的项目可写 `metadata_required: []`。**刻意没做**：改 `docs/00-总览.md`、登记例外，两项待 Alan。本仓**没有**声明 `metadata_required: []`：[架构确定](架构确定.md)自称架构基线、本文件是决策记录，说本仓没有 01 §3.5 的六类文档是一句假事实；要给定论就得列出它们的路径，而它们没有日期字段，列入即转 FAIL，同属待 Alan 的一类。其余数值声明未定（`52:个:来源`、`52:个:独立`、`14:个:部件`、`18:家:店`、`60:家:门店`）不在本批。 | 发布号 `2026-09-23.4`；「刻意没做」里待 Alan 的两项由 [D-112](#decision-index) ⑥⑦ 落地，提交 `d618312`、`eecb5ac`。 |
| D-112 | 2026-09-23 | 已执行 | **本仓自检未定清零：补三件工件落点与一份元信息清单，删两组来源数与一组部件数的投影，非文档重复改记不适用，示例项目修一处笔误两处抄值，裁剪工具原文落点、登记部件数一条。** ① `governance/project.yaml` 加 `metadata_required:`，只列 [架构确定](架构确定.md)（01 §3.5 六类里本仓只有架构一类；本文件是逐行带日期的表，不列入）；[架构确定](架构确定.md)头部补 `updated_at：2026-09-05`（取该文件最后一次提交的日期）。原聚合未定 `freshness/e83ab26d` 消失，架构确定一份 PASS，其余无日期文档逐份 SKIP（项目声明，确定结论）。② `layout.artifacts.work_current: docs/决策日志.md`——本仓不开工作项，进行中的事以本文件状态列为准；同步改写 D-105 时留下的「work_current 记一条未定」注释。③ `docs/附录-载体实例/会话交接-2026-09-22.md` 用 `git mv` 改名为 [`会话交接.md`](附录-载体实例/会话交接.md)，滚动单文件、每次交接整份重写、历史交给 git，声明 `layout.artifacts.handoff`；该文件效力行的「核对完可归档或删除」改为滚动说法（删了就是声明落点却不存在）。全仓活文档无旧文件名引用；D-103 行里的 `会话交接-*.md` 与审计记录、归档是历史记录，不改。④ **Alan 2026-09-23 批准**：`tailoring` 加 `layout:work_artifacts`（`applicable: false`，写法照 `layout:acceptance`）——01 §3.1 允许工具原文用完即弃，本仓各决策行靠可复跑命令现取；不建空目录，因为空目录在干净克隆和本机上的读数不一致。⑤ `check_single_authority` 的 `nondoc-dup-block` 与 `nondoc-count-claim` 两条汇总由 `UNDETERMINED` 改记 `SKIP`：判据的对象是文档，这组的全部位置都不是文档，所以不适用（源码之间的重复仍按 02 §4 记技术债）；`kind` 不变故 id 不变。同时修 [CONTRACT §1](../tools/std/CONTRACT.md) 三态表里 `UNDETERMINED` 含「判据本身不适用」与同节「不适用记 `SKIP`」的自相矛盾，[`tools/std/README.md`](../tools/std/README.md) 对应一句同步；selftest「边界一」改断言为 SKIP 且 id 不变，新增「边界一之二」钉住数值那一条，两条用改前的检查器跑均为 FAIL。⑥ 来源数的投影改为指针或不含数字的说法：`PROJECT_STATUS.md`、根 README 两处、[00 总览](00-总览.md)两处（Alan 已同意改）、[架构图 README](架构图/README.md) 对照表、`标准/参考资料/A-11` 第 5 行（第 3 行已写明范围）、两份架构图 JSON 的 subtitle。权威处[架构确定](架构确定.md)与本日志 D-043 行不改。JSON 是 archify 的源，HTML／PNG 不入库、本机也没有现存产物，无需重出；本仓未配 `derived:`，不产生派生检查结论。⑦ **Alan 2026-09-23 批准**：部件数先删投影——`PROJECT_STATUS.md`、根 README、[仓库工作须知](附录-载体实例/仓库工作须知.md)、总图 JSON 的卡片——再把本检查器报出的剩下三处（架构确定是权威、本日志里是 D-043 的生效登记行、`templates/文件树与落地路径.md` 是交付给采用方的唯一说法，交付面不得链回本仓 `docs/`）登记为新建的 `governance/exceptions.md` 首行，批准人 Alan、到期取 D-043 复核日，登记行不复述数值（CONTRACT §9「已知边界」）。⑧ 示例项目：ADR-0001（2025-03-05）写的门店数早于 2025-09 并购，与维护时间线和 `docs/state/STATUS.md` 的拆分对不上，属笔误，改为并购前的门店数；示例 README 的门店数改指向 `vision.md`；WI-0155 的厂商 B 门店数括注改指向 `STATUS.md`。ADR-0012 与维护时间线是历史记录，不改。⑨ 独立审查裁定：例外登记里规则匹配不到本次任何**未定**发现的行一律报 `exception-register/orphan`，含匹配到 PASS／SKIP／FAIL 的情形（原先这类行静默无效，日后该条转回未定时会静默复活）；`check_all` 删去按全部 id 判孤儿的分支，[CONTRACT §9](../tools/std/CONTRACT.md) 同步，入口冒烟自检加「⑤ 匹配到 SKIP 的行报 orphan」，用改前实现跑为 FAIL。 | 分析席对本仓自检（12／0／10／8，退出 2）逐条出的方案，调度裁定执行；④⑦ 经 Alan 批准。依据：01 §1 G2（数值的权威只有一处）、01 §2 N2（副本即缺陷）、01 §3.1（工件可按职责合并映射）、01 §3.5（元信息清单由项目声明）、01 §8（例外必填项）、CONTRACT §1（不适用记 SKIP）、§9（登记只改退出码，死行报孤儿）。**行为变化**：`check_all --selftest` 77→78，退出 0（敌意 git 配置下同样）；guard 81 通过；本仓 12／0／10／8 → 15／0／1（已登记 1）／44，退出码 2→0。**finding id 变化（本仓）**：消失的未定为 `freshness/e83ab26d`、`layout/48a7178c`、`layout/406021ec`、`layout/ab22034a` 与 `single-authority/count-claim/` 下的 `52:个:来源`、`52:个:独立`、`18:家:店`、`60:家:门店`；`single-authority/nondoc-dup-block` 同 id 由未定转 SKIP；新增 `layout/06f51c69`、`layout/fbd365e2`（work_current／handoff 在）与 `freshness/d42160c6`（架构确定新鲜）三条 PASS，`layout/7a5d1a4b`（工具原文落点已登记不适用）与逐份的 freshness SKIP；`links` 的 PASS 兜底 id 随链接数变。剩 `single-authority/count-claim/14:个:部件`，已登记。**对采用方**：示例项目 42／1／21／25 → 43／1／19／25（退出 1 不变，那条 FAIL 是 WI-0151 活性，与本批无关），少了两条数值未定，多一条判据 2 PASS，`links` 兜底 id 变；NFBY 72／0／19（已登记 19）／21 → 72／0／18（已登记 17）／23，**退出码 0→2**——`nondoc-dup-block`、`nondoc-count-claim` 两条转 SKIP，它登记这两条的 EX-014、EX-015 按⑨成孤儿，多一条未登记的 `exception-register/orphan`；采用方升级到本版时删掉对应登记行即回到退出 0；PMC-Planner 91／0／65／26 → 91／0／64／27，`nondoc-dup-block` 转 SKIP，其余逐条全同。 | 发布号 `2026-09-23.5`。 |
| D-113 | 2026-09-23 | 已执行 | **检查器工作项扫描的重复小工具收进 stdlib；数值声明识别千分位。** ① `check_evidence` 与 `check_freshness` 各持一份、逐字或语义相同的小工具收进 `tools/std/stdlib.py` 新设的「工作项扫描」小节：`norm_rel`、`under`、`markdown_under`、`clean`、`find_field`、`agg`（加检查器名参数）与常量 `HEAD_CHARS`、`LIST_CAP`；两边同形的两段逻辑提成 `item_status`（头部状态字段取值、去括注、小写）与 `state_list`（状态词表配置归一）；自检夹具 `_write`／`_git_init` 收成 `write_text`／`git_track`。第三份副本在 `check_drift`（`_norm_rel`、`_under`、`_LIST_CAP`、`_write`），一并改调。唯一差异是 drift 的 `_write` 带 `newline="\n"`，取它（夹具换行确定；交付面只支持 Linux/macOS，另两处行为不变）。`check_evidence` 文档串里「它们本该在 stdlib 里」一句随之删去。不收的：`check_layout._norm` 多去尾斜杠、`check_cross_repo._norm` 取绝对路径（`normpath(abspath())`）、`check_layout._has_field` 只认行首字段、`check_drift._md_under` 以已列好的文件表为入参、`_cap` 用「条」与顿号、`_git_commit` 要真提交，均为有意差异；`stdlib.in_frozen` 对 `.` 的处理与 `under` 不同，不并。② `check_single_authority` 的数值声明正则把「1,614 字」截成「614」：首位后只取两位以上数字，逗号前的「1」进不了匹配，从逗号后起算。改为半角逗号后恰好三位才算千分位（`[1-9][0-9]{0,2}(?:,[0-9]{3})+` 优先，否则照旧两位以上），比较前去逗号，「1,614」与「1614」同键；全角「，」不再当千分位——采用方实测「09-21，933 个自然日」「200，200 行」这类都是标点，原先会并成 21933、200200；「3,45 个」「1、2」不并数。selftest 加「探测三之五」，用改前的正则跑为 FAIL。 | 调度下达的收敛任务，执行席实施。依据：01 §1 G2（同一写法一处权威）、02 §4（等价的重复实现按技术债收敛）、CONTRACT §3（新判据带反例）。**行数**：`tools/std` 下 `.py` 总行数 8329 → 8273，净删 56 行（①净删 75，②净增 19，其中自检 16 行）。**行为变化**：`check_all --selftest` 78→79，退出 0（普通配置与敌意 git 配置——`commit.gpgsign`、失败钩子的 `core.hooksPath`、`color.ui=always`、`autocrlf`+`safecrlf`、`init.defaultBranch=trunk`——下同样）；guard 81 通过。检查器身份哈希变（预期）。**finding (id, 状态) 无变化**：本仓 15／0／1（已登记 1）／44 退出 0、示例项目 43／1／19／25 退出 1、NFBY 74／0／17（已登记 17）／23 退出 0、PMC-Planner 91／0／64／27 退出 2，用 `git archive HEAD tools/std` 导出的改前版对照 `--json` 逐条全同；除本仓 `single-authority/nondoc-dup-block` 的标题计数 27→20（①消掉的源码重复块，同 id 同状态）外，其余字段也全同。②在四者上不改变任何 count-claim：改后没有哪个千分位数凑满三文件门槛，改前截出的尾数也没有凑满；采用方写成「12，345 个」的全角形态此后按两个数读，若恰有三文件同写，其 count-claim 键会变、登记行成孤儿，删掉即可。 | 发布号 `2026-09-23.6`（release 提交 `7ab4033`，源 main `a4446b3`）。 |
| D-114 | 2026-09-23 | 已执行 | **一批待裁项的落地（Alan 2026-09-23 在对话中对 ①～⑧「全按推荐」，⑨⑩ 由调度方裁定）。** ① [D-078](#decision-index) 2b 裁「续」：[D-057](#effective-register) 续期一期，`approved_at` 2026-09-23、`review_at` 2027-02-17、`expiry` 2027-03-03（原期 3 个自然月、复审提前 14 天，接在原到期日之后再算一期），再次续期以三项检验有真实项目数据为条件，写在登记行「修订」句；D-078 两半都已了结，改记`已执行`。② [D-081](#decision-index)：[08 §5](08-规范效力元治理.md#effective-register) 加一句「章头 `governed_by` 只作来源追溯，不作效力声明」；不产生阻断或授权，改记`已执行`。③ [D-077](#decision-index)：三句写进 [08 §6](08-规范效力元治理.md#trial-expiry)，改记`已接受`并登记，生效规则数 8→9。④ [D-087](#decision-index)：首个真实项目按审计记录 045（Claude Code 宿主）开工，已由 [D-101](#decision-index)（发布号 `2026-09-22`）事实落地，改记`已执行`。⑤ [D-089](#decision-index)：本仓用 `标准/01` 约束自己，范围由 `governance/project.yaml` 的裁剪表达；只是记录已发生的采用（`7d0ae95`、`d553fa0`、`eecb5ac`），不另产生阻断或授权，改记`已执行`，不登记。⑥ [D-060](#decision-index)：不允许 AI 评定低风险后团队自批，[40 §2 P7](40-人的检查点与授权.md) 维持，改记`已拒绝`，重开条件为有风险评定的实测数据；[40 §1](40-人的检查点与授权.md)「未决」里那句同步改为已裁。⑦ [D-063](#decision-index)：不以图工程作规范骨架，[D-043](#effective-register) 已挡住另立骨架，改记`已执行`。⑧ [D-068](#decision-index)：类型头试点不跑，[D-074](#decision-index) 已拒绝、[D-073](#decision-index) 写死的开工条件不会满足，改记`已拒绝`；D-073 判据留档，状态不动。⑨ [D-111](#decision-index)（发布号 `2026-09-23.4`，其「刻意没做」两项由 D-112 ⑥⑦ 落地，`d618312`、`eecb5ac`）、[D-112](#decision-index)（发布号 `2026-09-23.5`）与 [D-113](#decision-index)（发布号 `2026-09-23.6`，release `7ab4033`，源 main `a4446b3`）改记`已执行`；根目录 README 两处写死的 D-057 到期日改为指向登记表该行。⑩ 修 [D-082](#decision-index)：[`check_normative_force.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/docs/%E9%99%84%E5%BD%95-%E8%BD%BD%E4%BD%93%E5%AE%9E%E4%BE%8B/check_normative_force.py) 的 C3 收集已到期 ID，生效集合只算一处并排除它们，报头另列「已到期」，C9 的散文数恰好多出已到期条数时归入到期通告、不进 FAIL；改记`已执行`，[C-047](失败Case清单.md) 标已修。 | ①～⑧ 都是积压的`提议`，逐条有推荐，Alan 一次批准；⑨ 三条已发布、无待裁部分；⑩ 的缺陷在 D-057 续期后仍会在新到期日重现，与续不续无关，故不等 2b 直接修。按 [08 §1](08-规范效力元治理.md#force-states)：产生阻断或授权的只有 ③，其余是一次性处置 | **实测（本批）**：`check_normative_force.py` PASS，报头生效规则 9，与登记表一致；`linkcheck.py` 0 断链；`check_all.py .` 通过 15、失败 0、未定 1（已登记）、不适用 44，退出 0。按状态计数（不含本行）改前 `提议` 57、`已执行` 20、`已拒绝` 15、`已取代` 13、`已接受` 7、`试行` 1；改后 45、29、17、13、8、1。**⑩ 修复前后**（脚本复制到会话临时目录、把取今天的那一行换成固定日期再跑，仓内脚本不动）：修复前 12-04（按原到期日）报头「生效规则：8（…D-057…）」同屏印 D-057 到期通告，PASS；修复后 12-04 报头「生效规则：7」，另起一行「已到期：1（D-057）」，PASS、退出 0；12-03 两版相同。续期后 2027-03-03 修复后报 9、无通告，2027-03-04 报 8 加「已到期：1」、PASS。反例：03-04 把散文数改成 7 或 10 时 C9 仍 FAIL、退出 1，改成 8 时 PASS。**证伪信号**：出现一条本行记`已执行`的决策被查出仍有待裁部分 |
| D-115 | 2026-09-23 | 已执行 | **Claude Code 侧改用原生能力，删除自写拦截层；`.std/` 只读改由检查器判。**（Alan 2026-09-23 批准：「实测完直接按推荐替换」。）① **`.std/` 只读进检查器**：[`check_adoption`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/checks/check_adoption.py) 在内嵌运行时跑 `git status --porcelain --untracked-files=no -- <内嵌目录>`，有已跟踪文件改动（已暂存或未暂存，覆盖 `git commit -a`）判 FAIL `adoption/embedded-modified`，git 查不了记未定 `adoption/embedded-readonly-unknown`，内嵌目录没被本仓跟踪（`git ls-files` 为空：被 .gitignore 忽略或是嵌套的独立 clone，此时 git status 恒空、会假通过）记未定 `adoption/embedded-untracked`，非内嵌运行记 SKIP；git 调用带 `--no-optional-locks`。自检经 `run(cfg, tool_root=…)` 注入内嵌走真实分支：未暂存／已暂存改动→FAIL、干净与仅未跟踪→PASS、被忽略→未定、非 git 仓→未定；`check_all --selftest` 汇总层另加一条跨检查器断言（`shared-fact`）：内嵌仓 `.std/` 有改动时 adoption 必须报 `embedded-modified` FAIL，不借用检查器自身夹具——变异验证：内嵌分支改成返回空、git status 结果改成恒空、换回旧版 check_adoption，三种 `--selftest` 均退出 1。规则进检查器后，git 钩子、CI 与 Agent 的提交前钩子只要调 `check_all` 都拦得住，钩子本身只剩一行。② **删自写拦截层**：`git rm` `tools/std/hooks/`（`guard.py`、`hooks.json`）与仓根 `.claude-plugin/`；`check_all --selftest` 去掉 `hook-guard` 一条；[CONTRACT](../tools/std/CONTRACT.md) §3、§8 删 guard 相关句，§2 补内嵌目录只读的判法；`tools/std/README`「发布」的 checkout 列表去掉 `.claude-plugin`。③ **`tools/std/README`「Claude Code 拦截层」重写为「Claude Code 接法」**：采用项目在自己的 `.claude/settings.json` 里配 `permissions.deny: ["Edit(/.std/**)"]` 与一条 PreToolUse 钩子（`matcher: Bash`，`if: Bash(*git*commit*)`，命令 `cd "$CLAUDE_PROJECT_DIR" && python3 .std/tools/std/check_all.py . --no-scope >&2 || exit 2`）；写明只有 exit 2 阻断、Edit deny 的覆盖面、宽 `if` 的代价、`.claude/` 与 `.git` 由内置受保护路径管、权限不能随插件分发故不再用插件、五条盲区与官方文档链接；在场信号、回执、guard 身份哈希、marketplace 装法等说明全部删除。git pre-commit 示意同步为只调 `check_all`。④ [D-108](#effective-register) 登记行按 [D-077](#effective-register) ② 实质修改就地改（见该行「修订」句），不另立登记行：D-115 的效力全部落在 D-108 那一行里，再给本条立一行就是同一规则的第二处权威，故本条记`已执行`而不记`已接受`；[D-101](#decision-index) 改记`已取代`。⑤ 发布号 `2026-09-23.7`（`标准/README.md` 第 3 行与 `governance/STANDARD_VERSION` 同步）。 | 实验席 2026-09-23 在 claude 2.1.280 上实测原生权限规则加一条钩子可覆盖自写拦截层的主要功能：Edit deny 连同 Bash 的重定向、`tee`、`sed -i`、`cp`、`mv`、`rm` 一并拒绝，比 guard 的「先问」更硬；宽 `if` 覆盖 `bash -c`、`env`、绝对路径 git 这些 guard 只能「先问」的变形；插件的 `settings.json` 不支持 `permissions`，自写层要靠 hook 模拟权限。原则：Claude Code 已有的不再造轮子；少即是多——tools/std 删掉 guard.py 与 hooks.json 两个文件和 check_all 的 hook-guard 一段。**代价**：没有在场信号与仓外回执（配置在项目 settings 里，谁都看得见，靠 `git diff` 追改动）；`check_all` 红时含 git…commit 字样的只读命令也被拦（**2026-09-23 按 [D-116](#decision-index) 修订**：此句低估了误拦面——`if` 只是尽力而为的预过滤，解析不了的命令形状一律触发，真实采用项目里不含 commit 的复合命令也被拦过；钩子命令加文本过滤前半段后，误拦才收窄到文本含 git…commit 的命令，见 D-116）；解释器子进程写 `.std/` 写入时不拦，只在提交时由 `check_all` 兜住。 | `check_all --selftest` 退出 0；本仓、示例项目、NFBY、PMC-Planner 前后 id 比对；临时仓里用 `claude -p` 实测：Edit/Write、`echo >`、`tee`、`cp`、`mv`、`sed -i`、`rm -rf .std` 被拒，读 `.std` 放行，`check_all` 红时 `git commit -am`、`bash -c`、`env`、`/usr/bin/git` 提交被拒，`.std` 有改动时提交被拒、理由为 `adoption/embedded-modified`。采用项目（NFBY）需按新接法迁移：删 `.claude/settings.json` 里的 `extraKnownMarketplaces`／`enabledPlugins` 两键，并入新配置，升级 `.std` 到 `2026-09-23.7` |
| D-116 | 2026-09-23 | 已执行 | **提交前钩子加文本过滤前半段，`if` 降为预过滤。** ① **问题**：D-115 给采用项目的 PreToolUse 钩子只靠 `if: Bash(*git*commit*)` 过滤。[官方文档](https://code.claude.com/docs/en/hooks#bash-if-matching)写明 `if` 是尽力而为，解析不了的命令形状一律触发钩子；[审计记录 052 §9](审计记录/052-L3验证冲刺-NFBY.md) 记下 NFBY 两条全文不含 commit 的复合命令（含 `$(git rev-parse --short HEAD)`）在 `check_all` 红时被拦。② **方案**（调度方裁定，方案 B）：保留 `if` 作原生预过滤；钩子命令前半段 `python3 -c` 从 stdin 读 `tool_input.command`，`re.search(r'git.*commit', …, re.S)` 不中则退出 3，`[ $? -eq 3 ] && exit 0`；其余情形（中了、`python3` 缺失、stdin 不是合法 JSON 或缺 `command` 字段致未捕获异常退出 1）都往下 `cd "$CLAUDE_PROJECT_DIR" && python3 .std/tools/std/check_all.py . --no-scope >&2 || exit 2`。[`tools/std/README`](../tools/std/README.md)「Claude Code 接法」同步：换 JSON 片段；「提交前必过 `check_all`」写前半段；「`if` 故意写宽」改为「`if` 只是预过滤」，列实测触发形状并附官方文档链接；实测段补本次读数；盲区 3 补一句前半段出错时的退化。调度方裁定 fail-closed 而非 fail-open：旧配置下 `python3` 缺失即阻断，改成放行是安全性倒退，且 Python 未捕获异常的退出码本就是 1、与「不是提交」分不开，故「不是提交」单用退出 3。③ D-108 登记行不动：改的是 README 里的示意片段，D-108 覆盖的动作集合与成立条件不变，不构成 [D-077](#effective-register) 意义上的修改；D-115 行的「代价」句加修订句。④ 发布号 `2026-09-23.8`（`标准/README.md` 第 3 行与 `governance/STANDARD_VERSION` 同步）。 | [审计记录 052 §9](审计记录/052-L3验证冲刺-NFBY.md) 的发现。原则：Claude Code 已有的不再造轮子——`if` 仍用，只在它兜不住的地方补一行文本判断；少即是多——不另立脚本文件，片段仍是一条命令。**代价**：`check_all` 红时，文本含 git…commit 的命令（如 `git log --grep=commit`）仍被拦；前半段本身出错（stdin 不是合法 JSON、缺 `command` 字段）时退化为凡触发了 `if` 的命令都要过 `check_all`，即回到 D-115 原先的宽度；`python3` 缺失、`cd` 失败、`check_all` 跑不起来仍转为阻断。**新盲区**：文本里看不到 `git` 在前、`commit` 在后的提交（git 别名，或经变量拼出，如 `c=commit; git $c -m x`）被判为不是提交而放行（审查实测 `check_all` 红时退出 0；`git $(echo commit)` 字面可见，仍退出 2）。调度方裁定只写明、不堵：要堵只能在「含 git 又含 `$`」时一律跑 `check_all`，即退回 NFBY 被误拦的原状；刻意这样拼提交命令不是模型的正常行为；兜底是提交时 git 自己的 pre-commit 钩子或 CI 调 `check_all`。 | 实测（claude 2.1.280，haiku，2026-09-23，`claude -p`，证据 [`审计记录/052-钩子if实测/`](审计记录/052-钩子if实测/)：`log.txt` 为逐条命令的 ATTEMPT／FIRED／CHECK_ALL_RAN 记录，`settings-phase1.json` 测 `if` 何时触发，`settings-B.json` 测方案 B，`nfby_cmds.txt` 为 NFBY 两条命令路径替换后的副本）：只用 `if` 时 `$(…)`、反引号、`{ …; }`（无 `$` 无重定向也算）、循环体里用变量都触发，`$VAR` 作普通参数、单条重定向不触发，这两条命令的副本触发；方案 B 下这两条与 `echo $(git rev-parse HEAD)` 放行，`check_all` 红时 `git commit -am`、`bash -c`、`env`、`/usr/bin/git`、`git -C . commit`、`git -c x=y commit`、`git log --grep=commit` 均被拒（`claude -p` 实跑用的是早先出错即放行的版本 `settings-B.json`，与发布版只在过滤自身出错那条路径上不同）；发布的 fail-closed 版只经 shell 复跑验证：整条钩子命令在 shell 里配假 `check_all` 复跑（[`failclosed-replay.txt`](审计记录/052-钩子if实测/failclosed-replay.txt)）：非 JSON、缺 `command` 字段、`git commit -m x`、反斜杠续行的提交在 `check_all` 红时退出 2、绿时退出 0，`git status` 红绿都退出 0，`python3` 缺失退出 2。采用项目升级 `.std` 到 `2026-09-23.8` 后需把 `.claude/settings.json` 里钩子的 `command` 换成新片段 |
| D-117 | 2026-09-24 | 已执行 | **`check_all` 入口先剥离 git 注入的仓库定位变量，钩子里的 `GIT_DIR` 不再把自检夹具写进真实仓。** ① **事故**：2026-09-24 08:26 一个采用项目从 git worktree 提交，pre-commit 钩子照 [`tools/std/README`](../tools/std/README.md) 的示意调 `check_all`；检查器每次运行都跑自检，自检用 `git -C <临时目录> init/add/commit` 建夹具仓，结果真实分支被写进一串垃圾提交，`.git/config` 被写成 `core.bare=true`，主工作区的 git 全部失效。② **根因**：git 跑钩子时向子进程注入仓库定位变量；从 worktree 提交时 `GIT_DIR`、`GIT_INDEX_FILE` 是绝对路径，显式 `GIT_DIR` 压过 `-C`，旧版夹具会写坏仓库（`core.bare`、垃圾提交）；主工作区里 `GIT_DIR` 是相对的 `.git`、随 `-C` 落到临时目录，但用 `git commit -a` 或 `git commit -- <路径>` 时钩子收到的是绝对路径的 `GIT_INDEX_FILE`（`.git/index.lock` 或 `next-index-*.lock`），旧版夹具会写进真实的待提交索引，提交以「无法创建树对象」失败，不写坏 `core.bare` 与分支。受影响的不只夹具：对目标仓的只读查询（`git -C <root> ls-files`、`check_cross_repo` 对兄弟仓的 `git grep` 等）同样被改道到钩子所在仓，root 就是钩子所在 worktree 时结果碰巧相同，root 是别的仓时查错仓。③ **修法**：[`stdlib`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/stdlib.py) 加 `GIT_LOCAL_ENV`（取自 `git rev-parse --local-env-vars`，即 git 自己进入另一个仓库前清掉的那张表）与 `scrub_git_env()`，[`check_all`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/check_all.py) 的 `main` 第一行调用，从本进程环境里去掉这些变量；此后全部 git 子进程（夹具与目标仓，约二十处调用点）靠 `-C`／cwd 定位，调用点一处不改，新写的检查器也自动受保护。未采用在每个调用点传 `env=` 的写法：同一目的要改约二十处且新调用点容易漏。`GIT_CEILING_DIRECTORIES` 不在表里（只挡上溯、不改定位，`check_adoption` 的自检自己要设它）。代价（调度方裁定：只写明，不改代码）：清理后检查器读的是默认索引，不是待提交的索引——`git commit -a` 删已跟踪文件时会报未登记的未定、退出 2（多拦不漏放）；按路径提交时，已暂存但不在本次提交里的文件也会参与判定。避开办法：先 `git rm`，或不按路径提交。理由：要读待提交索引就得逐个调用点区分目标仓和夹具，复杂度明显上升，而偏差方向是多拦。`check_derived`、`check_drift` 夹具里的 `dict(os.environ)` 只为追加提交日期，继承的已是剥离后的环境，未改。④ **回归断言**：`check_all --selftest` 汇总层加一条（`shared-fact`）：建牺牲仓，照 worktree 钩子实测的注入形态把绝对 `GIT_DIR`、`GIT_INDEX_FILE` 指向它（不带 `GIT_WORK_TREE`：带上它反而掩盖泄漏），以子进程走真实入口 `check_all.py <临时项目> --config …` 跑一遍会建夹具的扫描，断言牺牲仓的 `HEAD`、`config`、`refs/` 一字未变且子进程跑到了检查器。⑤ [`tools/std/README`](../tools/std/README.md) 的 git pre-commit 示意后补一句：从 worktree 提交也安全；`2026-09-23.9` 之前的版本在 worktree 里会写坏仓库、在主工作区用 `commit -a` 或按路径提交会失败，先升级；并补一句检查器读默认索引的偏差与避开办法。⑥ 发布号 `2026-09-23.9`（`标准/README.md` 第 3 行与 `governance/STANDARD_VERSION` 同步）。 | 采用项目的真实事故。原则：少即是多——一个函数、一处调用，覆盖全部现有与将来的 git 子进程；以 git 自己的 `--local-env-vars` 为表，不自拟变量清单。**代价**见 ③；进程内直接 import 检查器、不经 `main` 的调用方不受保护（本仓与交付面没有这样的入口，`checks/` 下各检查器没有独立入口）。 | **变异验证**：把 `main` 里的 `scrub_git_env()` 换成 `pass`，`--selftest` 退出 1，证据「牺牲仓被改：refs/heads/main」；恢复后退出 0（[`mutant-selftest.txt`](审计记录/053-GIT_DIR泄漏/mutant-selftest.txt)）。**端到端复现**（[`审计记录/053-GIT_DIR泄漏/`](审计记录/053-GIT_DIR泄漏/)，git 2.53.0，`repro.sh` 建带 worktree 的仓、`cp` 一份 `tools/` 与 `标准/` 作 `.std/`、直接写 `.git/hooks/pre-commit` 调 `check_all`，从 worktree 提交）：修复前 `core.bare` 由 false 变 true、真实提交以 `cannot lock ref 'HEAD'` 失败（退出 128）、主仓 `git status` 报「该操作必须在一个工作区中运行」、`feature` 上多出十余个夹具提交（`s`、`add docs/map.html` 等）（`修复前/`）；修复后唯一差异是 `feature` 上那一个正常提交，`core.bare=false`（`修复后/`）。主工作区 `commit -a`：修复前提交退出 1、stderr 为「无法创建树对象」，`core.bare` 与分支不变（`修复前-主工作区commit-a/`）；修复后正常提交（`修复后-主工作区commit-a/`）。各组 `commit-rc.txt` 含提交的 stderr。`hook-env.txt` 为 worktree 钩子实收的 `GIT_*` 变量，`target-redirect.txt` 为目标仓查询被改道的实测。已按 README 示意接了 git pre-commit 钩子又用 worktree 的采用项目需升级 `.std` 到 `2026-09-23.9`，并检查自己的仓是否已被写坏（`git config core.bare`、分支上有无提交信息为 `s`、`add …` 的夹具提交） |
| D-118 | 2026-09-24 | 已执行 | **`check_drift` 判据 4 认状态源文件里的 `work_item_id` 字段为工作项载体，工作项文件只认 work_root 直接一层；判据 1 的基准改为提交时刻在 UTC+14 下的日期。** ① **问题**：判据 4 从状态源收集全部 `WI-<数字>`，却只认 work_root 下以该 ID 开头的 *.md 为载体；而 [文件树与落地路径](../templates/文件树与落地路径.md) 的 L0/L1 允许工作项写在状态源（`WORK.md`、`work/current.md`）里，检查器文档串也承认状态源可以是单个文件。一个 L1 采用项目因此报了 32 条 `drift/work-item-missing`，其实各项都在 `work/current.md` 里有自己的「# 工作项：」小节。反方向还有一个假 PASS：`_md_under` 递归，`work/artifacts/WI-0021-回灌记录.md` 这类过程留证被当成工作项文件。② **修法一（载体在状态源里）**：状态源是文件时逐行匹配 `^work_item_id[:：]\s*(WI-\d{3,})\b`，命中的 ID 算有载体。写法取自 [WORK_ITEM](../templates/WORK_ITEM.md) 第 3 行首字段 `work_item_id：`（行首、全角冒号、无反引号与列表符）；示例项目与采用项目实物都是 `work_item_id：WI-0155　state_revision：…` 同行续写，所以只锚行首与 ID、不要求行尾；半角冒号一并收（同一字段的输入法差异）；ID 位数与判据 4 的 `WI-\d{3,}` 一致。只提到 ID 的正文、标题里带 ID 的小节都不算。不新增配置键。状态源是目录时不扫字段（目录模式本就是一件一文件）。③ **修法二（只看直接一层）**：work_root 下只认直接一层的 *.md，子目录一概不算。未取『排除声明的产物目录（`layout.artifacts.work_artifacts`）』：[01 §3.1](../标准/01-项目管理标准.md) 的文件树与职责表写的就是 `state/work/WI-*` 一件一文件、没有子目录形态；L1 模板把 `artifacts/` 放在 `work/` 之下，产物目录可能未声明或另起名字，按声明排除会漏；状态源为目录时判据 4 已按『直接一层、不递归』取 ID，两边同一口径。代价：把工作项文件放进 work_root 子目录的项目会被报 missing（未定，不 FAIL），本仓、示例项目与两个采用项目都没有这种放法。④ **判据 1 的基准**：原按提交自带的 `committer-tz` 取提交日，写日期的人与提交者时区不同就误报——采用项目 ADR 里「2026-09-14」一行的提交是 `2026-09-13 21:46 -0700`，+0800 下已是 09-14 12:46。改为取提交时刻在最晚时区 UTC+14 下的日期，文档日期严格大于它才报；未提交行的基准（运行时刻）同样按 UTC+14 取日。`git blame` 不再读 `committer-tz`。**代价**：作者时区与 UTC+14 之间那几个小时内写下的提前日期不再报——同一采用项目有 5 条 `updated_at: 2026-09-21` 写于 `2026-09-20 20:12 +0800`，按作者时区确实提前约 4 小时，修后不报；时区自由的判据分不出它与「东边的人当天写下」。⑤ scope 的 covered 条与模块文档串同步改写。⑥ **自检**：`check_drift.selftest` 的 1e（旧的「同一 epoch 两种 tz 差一天」，随 committer-tz 一起删）换成真提交 1e/1f：`-0700` 时区 09-13 晚上的提交里『2026-09-14 裁定』不报、『2026-09-15 裁定』照报；加 4g（状态源里 `work_item_id：WI-0001` 算载体）、4h（只在正文提到的 WI-0002 仍报）、4i（`work/artifacts/WI-0003-…` 不算载体，直接一层的 `WI-0004-a.md` 照旧算；附带断言 `work_root: work/` 带尾斜杠时照样算——比较前去尾斜杠、`.` 归一为仓根）。⑦ 发布号 `2026-09-23.10`（`标准/README.md` 第 3 行与 `governance/STANDARD_VERSION` 同步）。 | 采用项目的误报。原则：少即是多——不加配置键，以模板已有的首字段为载体标记，让写在状态源里的工作项自证；只看直接一层与目录状态源的既有口径一致。判据 1 本就永不 FAIL、只出未定，取最晚时区把「不可能是今天」作为报出门槛，误报换召回。 | **变异验证**（[`变异.txt`](审计记录/054-工作项载体/变异.txt)）：撤掉 `have = set(inline)` → 4g FAIL；正则放宽到任意提及 → 4h FAIL；撤掉直接一层过滤 → 4i FAIL；基准改回提交自带时区（夹具的 -0700）→ 1e FAIL；基准再放宽一天（UTC+38）→ 1f FAIL；去掉 work_root 尾斜杠归一（`work/` 与 `work` 比不上）→ 4i 附带断言 FAIL；六种 `check_all --selftest` 均退出 2，未变异时退出 0。**影响面**（[`drift-前后.txt`](审计记录/054-工作项载体/drift-前后.txt)，前为 730a575 的 tools/std，采用项目用 clone 副本替换 `.std/tools/std`）：本仓、示例项目、以目录为状态源的采用项目 drift 条目无差异；L1 采用项目 45→11 条，32 条 missing 中 28 条消失，余 WI-0030～0033（小节无 `work_item_id` 行）；其 WI-0021、0022 修前靠 `work/artifacts/` 里的留证算有文件，修后靠状态源里的 `work_item_id` 行算有载体，前后都不报；future-date 10→4，消失的 6 条是 ADR「2026-09-14」一条误报与 ④ 所述 5 条召回代价，余 4 条在 UTC+14 下仍晚于提交日。 |
| D-119 | 2026-09-24 | 已执行 | **用 Claude Code 原生能力补执行点（`SessionStart` 注入、审查子 agent 与收工 skill 模板），并给 `check_all` 补四项机械检查（01 §3.7 其余四项篇幅预算、01 §5.3 `compatibility.policy` 必填、01 §5.5 免审批清单不留通配放行、02 §4 项目自有例外到期转红）。** ① **Claude Code 原生执行点**：**问题**：01 §4.2 开工与收工、§4.4 生产者≠验证者、03 §3 按合同加载、§8.1 两半交接、§9.2/§9.4 返回三态与 expected/received/missing，都落在会话开始、收工、子 agent 这几个时点，而这些时点上项目侧一个执行点都没有；已有的两个原生执行点（`Edit(/.std/**)` deny 与提交前钩子）只管编辑前和提交。**做法**：直接用 Claude Code 自带的能力，不写新代码。(a) `SessionStart` 设 `"matcher": "resume\|compact"`：startup 时 Claude Code 已自带 gitStatus 快照，不重复注入。按官方文档，这个事件的 stdout 直接进上下文，所以不用 `hookSpecificOutput`。钩子只注入动态事实：`git log -1` 与 `git status -sb \| head -20` 放在同一组里（`git log` 失败不短路 `git status`），再加一句「压缩或恢复后先重读当前工作项」；静态提醒（按加载合同开工、先读状态源与当前工作项、身份不一致先停）写进入口文件的加载合同，照官方「CLAUDE.md for static context」。(b) `std-reviewer`：`tools: Read, Grep, Glob`，不给 Bash，因为 Bash 限定不了只读；`model` 以注释形式留给项目定。正文只写输入只认产出物与验收标准、逐条三态加 expected/received/missing、标自核还是转述、不改文件，条款只引用章节号，不复述。(c) `std-handoff`：用 `!` 注入 `git status -sb` 与 `git log --oneline -5`，`allowed-tools: Bash(git status *) Bash(git log *)` 只预批这两条，指向项目自己的模板，找不到就停下问，不复制模板字段。(d) tools/std/README「Claude Code 接法」相应增加约 34 行（JSON 片段改 6 行），`templates/README.md` 加 1 行指针。标准/覆盖与采用检查.md 没有执行点表，不动。**没接的**：Stop 钩子卡收工。官方文档写明 `decision:"block"` 可行，本次也实测生效，但"交接写全了没有"需要判断，command 钩子判不了，要判就得上 prompt/agent 类型钩子，成本和误拦都另议，本条不接。 ② **check_all 四项机械检查**：**问题**：requirements 清单里这四条是"机械可判却没有执行点"：CONTRACT 自认 01 §3.7 六项预算只执行入口一项；`compatibility.policy` 写着"必填"却没有读者；01 §5.5 审批疲劳段说"能执行任意代码的通配放行项……不作为免审批项保留"，没人读 `.claude/settings.json`；例外登记只理规则列含 `/` 的行（D-099 为了与项目自己的门号例外共用一张表、不把它们成批报成孤儿），结果 02 §4"依赖例外带到期，到期未清理 CI 转红"在工具侧落空。**做法**（都扩展现有检查器，不新开文件）：(a) `check_entry_budget` 增加状态 80／交接 60／工作项 150／模块文档 200 四项，键 `budgets.status_lines`／`handoff_lines`／`work_item_lines`／`module_lines`；**只有项目声明了对应键才判**，未声明记 SKIP `budget-undeclared/<键>`，默认值只作参考——01 §3.7 原文说表中数字是「试验参数，不是合格门槛」；入口预算不变，未声明仍按 150 判；落点先认 `layout.artifacts.status`／`handoff`／`modules` 与 `layout.work_root`，未声明按候选（候选超预算只记未定，契约 §1.1）；工作项只认直接一层、头部带状态字段的 `*.md`；状态声明为目录记 SKIP；一份文件同时是几类工件时超过最宽的预算才判 FAIL，只超较紧的记未定 `merged-over`；INDEX 的"每份文档一行"不是行数，不执行，写进覆盖边界。交接候选提到 `stdlib.HANDOFF_CANDIDATES`，与 `check_layout` 共用。(b) `check_adoption` 增加 `compatibility.policy`：缺或空判 FAIL，不分档（原文"必填"未分档），只判有没有。(c) `check_adoption` 增加读入库的 `.claude/settings.json`：`permissions.allow` 里 `Bash`、`Bash(*)`，或解释器／脚本运行器／包管理器运行命令后面只剩通配（`Bash(python3 *)`、`Bash(npm run *)`、`Bash(uv run:*)` 等，固定清单）以及整类放行 `PowerShell`、`PowerShell(*)`、`Monitor`、`Agent`（取自 auto 模式会丢弃的那份原生清单）判 FAIL；文件不在记 SKIP。auto 模式下 Claude Code 自己就会丢弃这类规则，本检查的增量在 manual、acceptEdits 等照单放行的模式下。不判 `defaultMode`：`bypassPermissions` 写在项目级或 local 设置里 Claude Code 自身不生效（官方 settings 文档），交给宿主。**不读 `settings.local.json`**：它不入库、因人因机器而异，同一提交在不同机器上会得出不同结论，CI 也看不到；写进覆盖边界。(d) `load_exceptions` 的关闭判定改为排除否定与未完成前缀（「待关闭」「未处理」「not closed」「undone」不算关闭，原先含词即关闭会把它们当历史行放过）；对规则列不含 `/` 的未关闭行只取到期：已过期判 FAIL `exception-register/own-expired/<编号>`（FAIL 不可登记，不能拿登记去静音一条过期的登记），到期写不成日期汇成一条未定 `own-undated`；仍不登记、不校验五项、不当孤儿。CONTRACT §3.7 表、§5 键表、§4 kind 列举、§9 同步。 | ① 原则：Claude Code 已有的直接用——事件、子 agent 的 `tools` 字段、skill 的 `!` 注入都是原生能力，本条零新代码；少即是多——三处都是可选件，并入同一段 settings 或拷走即用；用模型智能代替代码——一致性判断、交接写法交给模型按标准做，钩子只供事实。**代价与盲区**：SessionStart 只是提醒，模型可以不理，注入的是事实而不是判断；std-handoff 没人调就没有交接；std-reviewer 只做到上下文隔离，输入仍由委托方挑，因为不给 Bash，也不能复跑测试，只能读附带的原始证据；模板拷走即归项目所有，上游升级不跟随。README 原句"不随标准发任何配置文件"改为"不随标准发 settings 文件"，与新增模板对齐。 **交付面边界的解释（调度方已裁，所有者可事后否决）**：D-108 生效登记行的阻止集合是「作为生效执行层的任何宿主工具（含 Claude Code）的钩子、权限或流水线配置」，不含 agent 定义与 skill；`templates/claude-code/` 下的子 agent 定义与 skill 文件放在 `templates/` 下，不拷进 `.claude/` 就不生效，不在该集合内。tools/std/README「执行层由采用项目自己接」一句据此改为"标准不发**生效的**钩子、流水线或 agent 侧配置"，并注明模板拷进 `.claude/` 后才生效、由采用方决定；两份模板头部各加一句"本文件是载体实例，拷进 .claude/… 才生效"。 ② 原则：尽量扩展现有检查器、不新开文件，判不了记未定。**篇幅预算的裁定（调度方已裁，所有者可事后否决）**：01 §3.7 原文说表中数字是「试验参数，不是合格门槛」，所以状态、交接、工作项、模块文档四项只有项目在 project.yaml 声明了 `budgets.*_lines` 才判，未声明不判、默认值只作参考；入口预算照旧，默认值即判——入口每次会话都加载，预算直接决定每次会话的固定上下文成本。**代价与盲区**：不读 `settings.local.json` 与用户级设置，个人攒下的通配放行项看不见；解释器与运行器按固定清单认；INDEX 预算不执行；compatibility.policy 只判有没有。修订号：候选实现修订升为 `2026-09-23.11`。 | ① **实测**（claude 2.1.281，`claude -p --model haiku`，临时 git 仓，串行 6 次，合计 0.29 美元，当时为未设 matcher 的旧片段；现行 `resume\|compact` 片段另测 2 次合计 0.05 美元：startup 不注入，新提交后 `--resume` 逐字读出新 HEAD 与提醒句，见 [`c-sessionstart-resume实测.txt`](审计记录/055-原生执行点/c-sessionstart-resume实测.txt)；[`log.txt`](审计记录/055-原生执行点/log.txt)、[`transcript-摘录.txt`](审计记录/055-原生执行点/transcript-摘录.txt)）：r1 startup，禁读类工具，模型答出 HEAD、分支、未提交改动，并逐字引用了提醒；r2 resume 前先新提交一次，上下文里出现两次注入，HEAD 分别为 c5143c9 和 5bd6e02；r3 在 resume 会话里 `/compact`，会话记录中 `compact_boundary` 之后出现 `SessionStart:compact` 注入；clear、fork 未测。r4 在 acceptEdits 下，主 agent 写 ctrl.txt 成功（对照）；std-reviewer 被调起（meta `agentType: std-reviewer`），让它写 sub.txt 时它零工具调用，文件不存在；"只有 Read/Grep/Glob"来自它的自报，会话记录不含工具清单。r5 `/std-handoff` 触发，技能正文里的 `!` 占位已替换成 git 输出，没写 allowed-tools 也照样执行；无项目模板时停下询问。r6 顺带测试：Stop、SubagentStop 各返回一次 `decision:"block"`，主会话继续并输出了指定标记，子 agent 在返回末尾补上了指定标记。配置：[`settings-A.json`](审计记录/055-原生执行点/settings-A.json)（与 README 片段中的 SessionStart 命令逐字一致）、[`settings-stop.json`](审计记录/055-原生执行点/settings-stop.json)；原始输出见 `out-r1..r6.json`。 ② **验证**：`--selftest` 通过 94 失败 0（改前 86）；13 个变异体（关闭判定回到含词即关闭、整类放行不判、删掉「未声明不判」分支、通配判据恒不命中、去运行器清单、去解释器判据、compatibility 恒 PASS、预算加 1000、候选也判 FAIL、合并按最紧判、工作项不要求状态字段、自有例外不判到期、已关闭也判过期）逐个跑 `--selftest` 全部被抓；linkcheck 0 断链，check_normative_force PASS。**影响面**（底稿 [c-四项机械检查-影响面与变异](审计记录/055-原生执行点/c-四项机械检查-影响面与变异.md)）：四仓都没声明四个预算键，篇幅预算各只出四条 SKIP；本仓与示例项目的 `compatibility.policy` 已补键（本仓措辞经调度方接受；示例只写指针，指到 INV-07 与契约登记表的兼容策略列），本仓 `check_all .` 退出 0；NFBY、PMC 各新增 1 条 FAIL `adoption/compatibility-policy`（两仓确实缺这个键），升级到本版后需补键。 |
| D-120 | 2026-09-24 | 已执行 | **重开并取代 [D-074](#decision-index)：本仓挂提交闸门，按 [31 章](31-守卫与权限边界.md)补齐挂上之后欠下的义务；01 的 a～c 三项先在本仓落地。**（Alan 2026-09-24 原话「选A，a～c也先在本仓试行」。方向由 Alan 裁定；ask 规则的取舍与钩子写法由执行席定、经独立审查与调度方裁定修改，所有者可事后否决。本条是执行记录，**阻断依据是 [01 §5.1、§5.6](../标准/01-项目管理标准.md#gates) 与 [D-057](#effective-register) 下的 31 章**，不是本条。）**接上的执行层**：仓根 `CLAUDE.md` 以 `@CONTEXT_MANIFEST.md` 导入加载合同（此前合同从未被机械加载；`layout.entry` 不加 CLAUDE.md，它不含规则）；版本化 `.githooks/pre-commit` 跑三道闸门（check_all、linkcheck、check_normative_force），每个克隆装一次 `git config core.hooksPath .githooks`，相对路径使 release worktree 的发布提交不触发。Claude Code 发起的提交同样经过 pre-commit，故**不再挂 PreToolUse 提交前钩子**（原先挂过，与 pre-commit 重复，且造成一次误拦）；它原本防的 `--no-verify` 改由 ask 规则拦。**生效的 31 章条目与落实**：P1、P4、P5、P9、P10——**P4** 合同 11 项写成[仓库工作须知](附录-载体实例/仓库工作须知.md) §7 一张表，不另开文件；**P5** 检查器崩溃也是非 0、拒绝提交，`-p`／dontAsk 下 `permissions.ask` 等于拒绝（应答缺席即拒绝）；**P9** SessionStart 钩子每次开会话查 `core.hooksPath` 与四个钩子是否可执行，失效即提示，另有 `docs/审计记录/056-自用闸门/regress.sh` 作「应被拦截」回归；**P10** `commit-msg` 放行时写回执「提交前 HEAD + 暂存树」，`post-commit` 比对「HEAD@{1} + 本次树」，对不上就给该提交挂 `git notes --ref=gate-skip`，SessionStart 报条数；`pre-merge-commit` 让合并提交也过闸门。**P1** 落「警告」还是「约束」照 [C-041](失败Case清单.md) 更正 ① 仍记未定，但两者都非空。**a～c 结论**：a 先在本仓落地——`permissions.ask` 27 条，覆盖 01 §5.1 末条与 §5.5 里本仓确有对象的几类（`reset --hard`、强推与删分支、`git rm`／`git clean`、删状态与失败清单、`git tag` 与推公开仓、改钩子、碰 `hooksPath`、`--no-verify` 与 `commit -n`、删 gate-skip note 或引用、跳过权限起嵌套 claude、改入口）；`.claude/settings*.json` 不列，Claude Code 已把它当受保护路径；CI、锁文件、生产、schema、验收条目本仓没有，不列；发布六步的 `git tag` 与推公开仓因此每次被问，已写进须知。b 先在本仓落地——`.githooks/commit-msg` 查首行 `type(scope)!?: subject`，Merge／Revert／Reapply／fixup!／squash!／amend! 放行；比 01 §5.1 宽（scope 可省、type 任意小写词、可带 `!`），须知 §7 记为本仓裁剪；本仓不开工作项（`layout:work_artifacts` 已裁剪），按 01 §4.1「轻量项简记、不虚构 ID」不要求尾部 ID。c **本仓不适用**——`layout:acceptance` 已裁剪（[D-111](#decision-index)），没有验收文件可守；**这本身是个发现：c 只能到 NFBY 试**。**连带**：[C-041](失败Case清单.md) 追加一句（原文不改），「约束／警告级为空集」自本条起不成立；[D-068](#decision-index) 的重开条件已满足，是否开跑待裁，记在该行，本条不开跑；PROJECT_STATUS「任何全部 Gate 通过判未定」一句改为只在生效 Gate 集合为空时成立。`CONTEXT_MANIFEST.md` 的 YAML 头改写为标题下一行正文（依据见 [D-121](#decision-index)），第 1 项措辞改为「含标题下的合同头行」，updated_at 改为 2026-09-24；先核了依赖：`check_normative_force.py`、`check_all`、`linkcheck` 都不按 YAML 头解析这份文件；**`contract_revision` 保持 14 不升**——合同第 6 条解析规则只在「切换工作项或审议焦点时」递增，本次只改格式；`CLAUDE.md` 只留导入与 hooksPath 安装一行；[C-029](失败Case清单.md) 追加一句更正。本条只改本仓内部，不改交付面，不发版。 | **实测**（证据在 [056](审计记录/056-自用闸门/)，只放小文件）：`regress.sh` 经真钩子在带入工作区改动的临时 worktree 里跑，全部符合预期——正常提交退出 0 且无 note；断链提交退出 1；坏信息退出 1；`--no-verify` 退出 0 且挂上 note；amend 退出 0 且无 note；`git revert --no-edit` 与 revert-of-revert（首行 `Reapply "`）都退出 0、都挂上 note（它们不跑 commit-msg）；正常 merge 生成双亲提交；T9「merge 之后接一个 `--no-verify` 空提交」挂上 note。commit-msg 回放 f9e8c7b 往前 50 条，**拦 7 条、误拦 0**，7 条都是旧写法「标准/README 第 3 行：…」的发版提交，2026-09-23.7 起已改为 `chore(release)`。`claude -p --model haiku`：unset hooksPath 后新会话逐字复述出闸门警告，设回后警告消失，两次都只凭导入答出 contract_revision 14；dontAsk 下让模型执行 `git reset --hard HEAD` 被拒，`permission_denials` 点名这条命令；另加 `--allowedTools "Bash(git *)"` 仍被拒，而删掉 ask 规则的对照组照常执行——说明拒绝来自 ask 规则，不是 dontAsk 的默认拒绝；在一次性临时仓里核 ask 边界：`-f`、`-n` 放在前后两种位置与 `--no-verify` 都被拒，`--follow-tags` 与分支名 `fix-foo` 不误问。六次 claude 调用合计约 0.21 美元。原 PreToolUse 钩子误拦一次（命令正文含 git…commit 字样、恰逢 check_all 红），属 [D-116](#decision-index) 已写明的代价，只记 056，不进 Case 清单。 | **设计问题（自用要检验的，逐条）**：① **P10 八字段钩子拿不到**：`--no-verify` 不给钩子任何输入，post-commit 只能记时间与 git user.name，理由、范围、批准人、失效时间、补偿控制、复查日期、关闭证据全靠事后手补；单人仓里批准人与跳过者是同一人，P10 的「批准」形同自批；notes 默认不随 push 走；cherry-pick、rebase、revert 也会被记成跳过（判得对，但会有噪声）。② **P9 的探测只在 Claude Code 会话里有**：人直接用 git 时没有探测；unset hooksPath 或 `-c core.hooksPath=` 会连 post-commit 一起绕过，只能靠 SessionStart 发现；SessionStart 自己失效没人探，回归脚本要人想起来跑，只到「工具」级。③ **P6「按动作对象与参数判定，不按命令字符串」做不到**：`permissions.ask` 按字符串匹配——`git tag` 分不开读写（列 tag 也被问）；`git commit -n` 只能按「 -n」匹配，提交信息正文里含「 -n」会被误问（实测一例），组合短旗标（如 `-an`）与 `git -c … commit -n` 漏；refspec 形式的删分支、别名与脚本间接调用都会漏；01 §5.1「有未提交改动时」这个条件表达不了，只能一律问。④ **01 §5.5「覆盖或删除状态／失败清单」分不出改与覆盖**：Edit 规则一挂，每次常规编辑都会被问（近两周这两份分别有 5 个、9 个提交改过），只好只拦 `rm`；入口改得少（两周 1 次），整份询问。⑤ **P4 合同对单人仓偏重**：带宽度量、呈现格式对事实门禁只能填「不适用」；维护者与豁免批准人都是 Alan 一人。⑥ **闸门判的是工作区，不是暂存区**：部分暂存时判错对象。⑦ ask 规则只在本仓根启动的会话里生效，在 release worktree 另起的会话不受控；非交互流水线里的发布步骤会被直接拒绝。⑧ c 在本仓试不了。⑨ **`git merge --no-verify` 不留痕**：合并不跑 post-commit，不为此加 post-merge 钩子。⑩ **01 §5.1 要求 `type(scope)`，产地仓自己不照做**：本仓历史提交常省 scope，commit-msg 只能放宽；是标准该放宽还是本仓该收紧，待所有者裁。**证伪信号**：闸门拦下一条人工执行确实漏掉的真实缺陷之前，「挂上的价值」仍按 D-074 原记法记未定；ask 规则若在一个周期内让人习惯性点通过，按 01 §5.5 审批疲劳一段收窄。**2026-09-25 修订**：设计问题 ⑩ 已由 [D-122](#decision-index) 处理（01 §5.1 放宽为 scope 可省，commit-msg 不再是本仓裁剪）；① 与 ⑤ 所指的单人仓负担一并由 D-122 按单人最小集减掉，`post-commit` 回执与 `gate-skip` note 已删，上文对它们的描述只作历史。 |
| D-121 | 2026-09-24 | 已执行 | **合同头一律写成标题下的一行正文，模板不再带 YAML 头。**（调度方裁定选 (i)，所有者可事后否决。）**触发**：2026-09-24 本仓自用暴露——Claude Code 导入或自动加载入口文件时剥掉 YAML front matter，合同要求核对的修订号模型看不到。**改动**：`templates/CONTEXT_MANIFEST.md` 删 YAML 头、加合同头行、改落地说明一句；`templates/AGENTS.md` 占位 `<N>` 改为 `<contract_revision>`，与模板对齐；[tools/std/README](../tools/std/README.md)「Claude Code 接法」节加一条实测结论。`标准/` 正文没有「入口导入合同」的原文，未改。本仓根 `CONTEXT_MANIFEST.md` 的同样改写记在 [D-120](#decision-index)。**理由**：`templates/AGENTS.md` 的加载合同一节早已是正文行写法，只有「单列成文件时保留 YAML 头」这条分支暴露问题；去掉分支即闭合，也消除了 YAML 与正文行两处副本。另一选项 (ii) 靠模型自觉先 Read 文件开头，属提醒不是执行点。不需要检查器：`tools/std` 与 `docs/附录-载体实例` 都不读模板的 YAML 字段（`check_layout._has_field` 只对 acceptance／status 工件查头部、且认正文行写法；`check_normative_force` 只把根 `CONTEXT_MANIFEST.md` 纳入 C5 文本扫描，不读字段）。改动了交付面，发版号 `2026-09-23.12`（`标准/README.md` 第 3 行与 `governance/STANDARD_VERSION` 同步）。 | **实测**（claude 2.1.281，haiku，`claude -p`，禁用读文件类工具，约 0.046 美元）：① `CLAUDE.md` 自身的 front matter、它 `@` 导入文件的 front matter，都**整段**不进上下文（contract_id、contract_revision、name、description 与自定义字段全部缺席），不是按字段挑；② 同一内容写成正文行完全可见；③ 目录里只有 `AGENTS.md` 时它被自动加载，front matter 同样整段剥掉、正文可见；与 `CLAUDE.md` 并存时 `AGENTS.md` 不被自动加载（未经 `@` 导入）。本仓改写后另测两次，只凭导入答出 contract_revision 14（见 [056](审计记录/056-自用闸门/)）。 | **证伪信号**：宿主改为保留 YAML 头时，正文行写法仍可用，不必回退；若出现某个宿主剥正文首行或只认 YAML 字段，本条重开。 |
| D-122 | 2026-09-25 | 已执行 | **单人 L1 仓的 Gate 义务减为最小集；提交信息 scope 可省。**（Alan 2026-09-25 原话「简化 31 章对单人 L1 仓的 Gate 义务；放宽标准，允许省 scope」，另「D-068 按建议」即暂不开跑。方向由 Alan 裁定；最小集措辞与本仓删减由执行席定、经独立审查与调度方裁定，所有者可事后否决。本条是执行记录，**阻断依据是 [01 §5.1、§5.6](../标准/01-项目管理标准.md#gates) 与 [D-057](#effective-register) 下的 31 章**，不是本条。）**义务的出处**：对采用项目只有 01 §5.6 一处（合同字段、豁免与跳过的记录字段、静默失效的探测都在这一节），01 不援引 31 章；本仓按自己的标准采用，同时受 01 §5.6 与 D-057 作用域判据下的 [31 章](31-守卫与权限边界.md) P4、P9、P10 约束。两处作用域不同，各改一次，别处不复述。**改法**：① 01 §5.6 豁免句后加一句单人最小集，末句「多人项目按本节全部要求」；② 31 章 P4、P9、P10 的删除条件尾标在原「写不出」之后各追加一段「起始档」（[09 §4](09-跨工具通用性.md#two-axes) 的取值），原文一字不动，L2 起照旧；③ 01 §5.1 改为「按 Conventional Commits：`type[(scope)]: subject`，scope 可省」，`templates/agent-skills/commit-and-version.md` 同改；`标准/README`、`templates/README` 与示例项目没有这种写法，未改。**单人最小集**（01 §5.6 原文）：「每道门的合同只写查什么、失败怎么办、怎么绕过三项；静默失效的探测在会话开始时自动运行的检查与人工开工检查之间二选一；豁免与跳过只要求事后可发现（宿主的操作记录查得到跳过动作，或下一次全量检查会重新判到它放进来的问题），不要求上列字段齐全，也不要求他人批准——批准人就是本人，照实写明。」**本仓删减**：删 `.githooks/post-commit`（放行回执比对与 `gate-skip` note）；`commit-msg` 去掉写放行回执，注释删「本仓裁剪」；`permissions.ask` 删 3 条（`git notes` 的 remove、prune 与 `update-ref -d`，只为护 note 而设），27 条减为 24 条；SessionStart 去掉 note 计数，查的钩子由四个改三个；[仓库工作须知](附录-载体实例/仓库工作须知.md) §7 由 11 项合同表改为三项表，删「本仓裁剪」段与 note 用法。删前现跑 `git notes --ref=gate-skip list` 为 0 条，无存量丢失。**留下**：`pre-commit` 三道、`commit-msg`、`pre-merge-commit`（管的是闸门查什么，不是三项义务）、SessionStart 探测（即最小集的失效探测）、其余 24 条 ask（依据是 01 §5.5 与 §5.1 末条，不是 Gate 义务，`--no-verify`／`commit -n` 那三条同时是「怎么绕过」的人侧通道）。[056](审计记录/056-自用闸门/) 的 `regress.sh` 是历史证据，其中「note 应有」两例对新实现不再成立，不改。**元治理**：生效登记表不改——D-057 行给的是判据，各条范围由尾标承载（09 §4），行内一字未动，不触发 [D-077](#effective-register)；三段新尾标各给出两种机制类型不同的落法（会话开始自动检查／人工开工检查；宿主操作记录／下一次全量检查），满足 [D-020](#effective-register) 的两种机制检验；原则条数不变，C7 对账不受影响；章头 `governed_by` 不加本条（本条`已执行`，按 [D-110](#effective-register) 不作依据）。改动了交付面，发版号 `2026-09-23.13`（`标准/README.md` 第 3 行与 `governance/STANDARD_VERSION` 同步）。 | [D-120](#decision-index) 自用实测：P10 八字段钩子拿不到，`--no-verify` 不给钩子任何输入；批准人与跳过者同一人，「批准」形同自批；notes 默认不随 push 走；P4 的带宽度量与呈现格式对事实门禁只能填「不适用」。P4、P10「写不出」的理由是具名责任可分，单人仓里维护者、批准人、被误伤者是同一人，这个理由在单人档没有对象。本仓三道闸门都查整个工作区，跳过放进来的问题下一次正常提交就会被重新判到，事后可发现不必另建记录。scope：01 原写 `type(scope)`，比 Conventional Commits 原文严，产地仓自己历史上常省，放宽后标准与 commit-msg 一致 | **影响面**：`tools/std` 与 `CONTRACT.md` 不引用被改的句子，检查器未改。check_all 前后对照（HEAD 临时 worktree 为基线）：本仓退出 0，除 `links` 计数因须知 §7 删去 3 条链接外逐项相同；示例项目逐项相同（退出 1，FAIL 为基线已有的 freshness 一条，随日期出现）；NFBY、PMC 各浅克隆到内存盘，内嵌 `.std/` 换成本次交付面、版本升 `.13` 后与各自基线逐项相同（NFBY 退出 2；PMC 退出 1，4 条 FAIL 是克隆缺少仓外兄弟目录的断链，基线同样有）。**回归**（临时 worktree 带入工作区改动、真钩子）：带 scope 的正常提交退出 0；注入断链退出 1；坏信息退出 1；`docs: …` 无 scope 退出 0；`feat!: …` 退出 0；无 note 产生。**顺带查出并修了一处既有缺陷**：四个钩子入库时是 `100644`（本仓 `core.fileMode=false`，本地 chmod 不进索引），新克隆与新 worktree 里钩子不可执行、git 只提示不执行，闸门静默不生效（SessionStart 探测在这种克隆里会报警告）；首跑回归即因此全部放行，已用 `git update-index --chmod=+x` 把三个钩子记为 `100755` 后重跑得上述读数。**证伪信号**：出现一次跳过放进来的问题在下一次正常提交后仍未被发现（例如问题不在三道闸门判据内，或跳过后长期不再提交），单人最小集的「事后可发现」重开；本仓有第二个人参与提交时按 L2 恢复全部要求。 |
| D-123 | 2026-09-27 | 已执行 | **修复 `tools/std` 三份独立审计（安全 2026-09-26、bug 2026-09-26、优化 2026-09-27，基线 main `49c5ba0`）查出的问题。**（Alan 2026-09-26 原话「审核项目是否有安全问题、bug、需要优化的，然后先把你能决策和执行的做了，做完后，再把需要我决策的列出来」。方向由 Alan 给定；逐条修法由执行席定、经两轮独立审查、调度方裁定；所有者可事后否决。本条是执行记录，不是阻断依据。）**改动**（分支 `fix-123` 共 11 个提交，合并提交 `62fde16`，只改 `tools/std`）：安全——被扫仓 `.git/config`／`.gitattributes` 不再能让 git 执行外部程序（`GIT_CONFIG_COUNT` 覆盖 `core.fsmonitor`/`hooksPath`/`sshCommand`/`gitProxy`/`askPass`/`pager`、`diff.external`、`log.showSignature`；过滤器名经 `GIT_CONFIG_KEY_n`/`VALUE_n` 置空并按仓缓存；`blame --no-textconv`；`status --ignore-submodules=dirty`；`GIT_OPTIONAL_LOCKS=0`）；读任何路径先字面判 `..`/绝对路径再 `realpath` 护栏，仓外一律不探测、记未定，报错不回显内容；两处正则改线性（n=20000 由 349 秒降到 0.01 秒内）；YAML 递归过深记未定退出 2。bug——浅克隆、读不了、超大、查不到、读不到状态一律记未定不翻 PASS；通配放行按官方 permissions 文档语义重写；粗体状态字段、WI 前缀冒充、64 位 sha、BOM、GBK、非 UTF-8 文件名、`SystemExit` 全部兜住；YAML 子集不再静默误读，不支持的写法带行号拒收；finding id 不含天数与份数；自检闸门拒收空自检；关闭态按段首判。优化——`single-authority` 有效字符计数提速（NFBY 5.3→3.6 秒，findings 逐字段一致），删三处死代码。**裁定**（调度方）：约定落空一律按 [CONTRACT §1.1](../tools/std/CONTRACT.md) 记未定不判失败；项目之外的链接记未定；evidence/freshness 只看 `work/` 直接一层（同 [D-118](#decision-index) 对 drift 的裁定）；工作项按 [01 §3.2/§3.3](../标准/01-项目管理标准.md) 的 `state/work/WI-*` 认，非 `WI-*` 但自带状态字段的也算，两者都不是的聚合记一条不适用；no-status 只由 freshness 报一次；drift 找不到 ADR 目录按 [文件树与落地路径 §4](../templates/文件树与落地路径.md) 从 L2 起算；layout 元信息只在声明了 `metadata_fields` 时缺失才 FAIL；`duplicate_*` 阈值写错为配置错误失败关闭；`setsid`/`ionice`/`flock` 这类官方说前缀规则无效的不判。安全审计第 5 条（钩子索引模式探测）不属 `tools/std`，另由 `aac1906` 在本仓 SessionStart 落地。**未做、待裁**：示例项目随运行日期漂红（超龄判据随日期变 FAIL）；D-124 候选——各检查器 `run()` 外壳与自检夹具的样板重复（预计减 100～150 行）、`tools/std/README` 瘦身（约 45 行，验收层面）；evidence 在 freshness 被裁剪时不再提无状态 WI 的完成证据（审查备注，可在 CONTRACT 补一句）。**发版**：与 [D-122](#decision-index) 合并发一版。[tools/std/README](../tools/std/README.md)「发布」规定 tag 为发布日期、同日再发加 `.1`，故本版为 `2026-09-27`，不用 D-122 行写的 `2026-09-23.13`（此前 `.9`～`.12` 四版实际发布于 09-24/25 却沿用 09-23 日期，已列给所有者裁）。 | 三份审计各给出可复现的问题：安全侧被扫仓配置能让 git 执行任意外部程序（钩子、`core.fsmonitor`、过滤器、ReDoS、深递归）；bug 侧多类输入被误判为 PASS 或直接崩溃；优化侧正则回溯与逐字符计数在大仓上退化。逐条修法即对齐 [CONTRACT §1.1](../tools/std/CONTRACT.md) 的失败关闭原则，未定语义分歧按同一条裁定统一，不逐检查器各判一次。 | **验证**：`--selftest` 94→142（失败 0、未定 0）；四项闸门退出 0；本仓 `check_all` 退出 0、单次运行含自检门 1.33→1.31 秒；NFBY 退出 0、17 条已登记未定全在、无孤儿登记、无新增 FAIL；PMC 退出 1→2（4 条仓外链接 FAIL 变 2 条 `outside-root` 未定，待其登记）；示例项目退出 1→1（新增 15 条 `outside-root` 未定，因其链接到上层正文）。两轮审查：第一轮查出 gpg（`log.showSignature`）、过滤器名含 `=`、子模块三条执行路径与四处护栏顺序，第二轮实跑夹具确认全部修好。**证伪信号**：再出现一条被扫仓配置触发外部程序的路径；或某采用项目因未定口径出现无法登记的恒退 2。 |
| D-124 | 2026-09-29 | 已执行 | **收拢 `tools/std` 检查器样板、README 瘦身；行为零变化。**（D-123 记为候选；Alan 2026-09-29 原话「继续」。修法由执行席定、经独立审查两轮、调度方裁定；所有者可事后否决。本条是执行记录，不是阻断依据。）**改动**（分支 `refactor-124`）：`stdlib` 新增 `run_guarded`（裁剪记 SKIP、异常转未定的 run 外壳，九个检查器改用，adoption 裁剪语义不同未动）、`probe`/`probe_crashed`（自检断言，约 130 处）、`write_files`/`git_fixture`（自检夹具，删去各检查器与 check_all 里的重复实现；夹具只用于自建临时仓、不走 `filter_env`）；stdlib 自检加三条外壳断言，使公共断言函数本身回退也能被抓；README 删重复叙述、登记与加检查器两节改指 [CONTRACT](../tools/std/CONTRACT.md) §9/§3，「本仓库自己的采用结果」一节（D-111 ⑨ 批准保留）按现状改写为指向 `governance/project.yaml`；顺带修原有缺陷：`tailoring` 写成非列表时整份配置拒收并报行号，不再崩溃。**净删**：代码 197 行，README 23 行。 | 样板重复使每个检查器的外壳与夹具各自维护，D-125 的多处修复都要在十处重复落地。 | **验证**：`--selftest` 218→222（原 218 条 id、状态、标题不变，新增 4 条）；本仓、三个采用项目、示例项目共六个对象改前改后 `--json` 排除 tool-identity 逐字段零差异；变异 12 处判据改前改后都抓出；耗时变化在 ±5% 内；四项闸门退出 0。独立审查两轮：第一轮查出 README 裁剪项表述不实 1 条阻断，第二轮确认修好。**证伪信号**：同一输入下改前改后任一 finding 不同，或某判据变异在改后漏抓。 |
| D-125 | 2026-09-29 | 已执行 | **修复第二轮全仓审计（基线 main `20fad36`，四路：check_all/stdlib、四个大检查器、六个小检查器、钩子与仓内脚本及模板）查出的问题。**（Alan 2026-09-28 原话「审核项目是否有安全问题、bug、需要优化的，然后先把你能决策和执行的做了，做完后，再把需要我决策的列出来」。方向由 Alan 给定；逐条修法由执行席定、经独立审查两轮、调度方裁定；所有者可事后否决。本条是执行记录，不是阻断依据。）**改动**（分支 `fix-125`/`fix-125-c`/`fix-125-d`）：安全——内嵌运行时核身份的 `git status` 也走过滤器置空，被扫仓的 clean/smudge 过滤器不再能执行外部程序；读文件统一经 `stdlib.read_bytes`（只读常规文件、单一 2MB 上限、打开后复核真实位置），FIFO 不再挂死提交；护栏挪到一切 `isfile`/`getsize`/`listdir` 之前，仓外不再能经软链探测；`project.yaml` 以 `_` 开头的顶层键拒收（原可缩小 links 扫描面自关闸门）；工具目录移出 `sys.path` 前部，同名模块不能顶替；报告转义换行、U+2028/2029 与双向控制符，不能伪造结论行；十余处平方级正则改线性（最坏由数十秒降到毫秒）。bug——按 [CONTRACT §1.1](../tools/std/CONTRACT.md) 把约定落空一律改记未定、已声明落点不成立才判失败；同一事实只报一次（work_root、cross-repo 仓数、layout 目录）；finding id 不再随行号序号漂；freshness 不再被备注或第二张表洗成通过；git pathspec 按字面；配置形状写错整份拒收并报键名行号。钩子与仓内脚本——`commit-msg` 首行取第一个非空行、Merge/Revert 放行收紧到 git 自动生成形态；`pre-commit` 三道都跑；三个自检脚本只扫已跟踪（含已暂存）文件；生效规则集为空时效力检查退出 2；追溯账本缺失不再静默通过；[仓库工作须知 §7](附录-载体实例/仓库工作须知.md) 如实补写 cherry-pick/rebase/revert/快进合并与"先暂存后修工作区"的盲区。**裁定**（调度方）：不加全局超时，改为消除挂死根因；通配放行按解释器登记带值选项，通配前出现未登记选项记未定（验收层面，所有者可否决）；证据条目确有认不出的"标签: 值"行时才记未定、缺字段照旧失败；无转换小节时 freshness 仍取 git 时间。**未做、待裁**：检查器自身崩溃的未定可否登记；例外登记到期上限；跨检查器反例是否进提交路径；adoption 被裁剪时 `.std` 只读守卫是否仍强制；提交绕过（`--no-verify` 缩写、`-c core.hooksPath`）是否纳入宿主询问；钩子改查暂存快照。**升级影响**：配置解析收紧（值含「: 」、字符串键写成列表/映射整份拒收）；登记册表头精确匹配 `id` 列、关闭词整词匹配、到期只收纯日期；部分 finding id 变化；新增若干未定；NFBY 升级后 EX-016 成孤儿，按其约定改状态为关闭并随升级同一次提交。 | 四路审计给出可复现的问题：被扫仓过滤器仍能在一处执行外部程序；FIFO 与平方级正则能挂死提交闸门而宿主超时后放行；多处护栏顺序允许探测仓外；若干输入被误判为通过或同一事实重复报；钩子与自检脚本的文档陈述与行为不符。修法对齐 CONTRACT §1.1 与"同一事实只报一次"，不新增配置键。 | **验证**：`--selftest` 142→213（失败 0、未定 0）；本仓四项闸门退出 0；示例项目 FAIL 仍只有已知的 WI-0151 超龄；NFBY 无新增 FAIL，退出 0→2 仅因 EX-016 孤儿。独立审查两轮：第一轮查出 find_field 平方级、同名模块顶替、证据未定口径过宽、D 路文档不实等 4 条阻断，第二轮查出返修回归 `python3 -m *` 与 Merge 放行过宽，均已修并复核。底稿在仓外 `~/Programs/交接-2026-09-29/audit/`。**证伪信号**：再出现一条被扫仓内容触发外部程序、挂死闸门或把确定违规洗成通过/未定的路径。 |
| D-126 | 2026-09-29 | 已执行 | **落地所有者对 D-125 上交问题的裁定，并发版 `2026-09-29`。**（Alan 2026-09-29 原话「按照建议的做，发版与tag命名你来做就可以了」。方向由 Alan 裁定；未给建议的两问由调度方补裁，所有者可事后否决。本条是执行记录，不是阻断依据。）**改动**（分支 `fix-126`）：① 检查器真崩溃的未定改为 `<检查器>/internal-error`，登记它记不合格行、不生效；读不了文件、列不出文件、`settings.json` 损坏等改出 `unreadable`/`enum-failed`/`settings-invalid` 等专门 kind，仍可登记且按文件区分。② 例外登记到期晚于运行日加 365 天的记不合格（工具认领行），项目门号行同样受限、汇成一条不可登记的 `own-too-far` 未定；上限按运行日滚动。③ 跨检查器反例不进提交路径，[tools/std/README](../tools/std/README.md)「发布」第一步改为在 main 上跑 `--selftest` 与 `check_all . --no-scope` 都退出 0 才继续，本仓另跑两项自检（写在[仓库工作须知 §7](附录-载体实例/仓库工作须知.md)，不进交付面）。④ adoption 被裁剪时内嵌目录只读守卫与 `compatibility.policy` 必填照判，`version-mismatch` 仍随裁剪关闭。⑤ 钩子维持查工作区。**调度方补裁**：提交绕过（选项缩写、组合短选项、`-c core.hooksPath`、钩子失去执行权限）不加宿主询问规则，只在须知 §7 与 README 盲区如实写明——缩写形态无穷，规则拦截只能打地鼠；tag 命名——已公开的 `2026-09-23.9`～`.12` 不改名（采用方可能已钉），补打 `2026-09-27` 于 release `726d6de`，本版 `2026-09-29`，此后严格用发布当天日期；删除测试分支 `fix-123`、`rv122-side`、`rvb-side`、`rvb-side2`；NFBY/PMC 升级交各自会话。**升级影响**：登记过崩溃类 id 或门号行到期超一年的，升级后变为未登记未定。 | D-125 列出的四个上交问题与发版、分支清理事项由所有者一次裁定。 | **验证**：`--selftest` 214（失败 0、未定 0）；本仓四项闸门退出 0；示例项目新旧逐条一致；NFBY 的 EX-016、EX-017 到期 2027-09-30，发版当天超出一年上限记不合格（此前写"零影响"不准，升级实跑查出）；NFBY 升级时 EX-016 改关闭、EX-017 到期改为 2027-03-31。独立审查两轮：第一轮查出崩溃判定范围过宽（误锁读文件失败等）与门号行未受上限 2 条阻断，第二轮确认修好。**证伪信号**：出现一种写法能登记真崩溃或一年以上的静音，或非崩溃类未定被误锁为不可登记。 |
| D-127 | 2026-09-29 | 已执行 | **工作项模板状态词对齐 01 §4.1 六态；检查器认不出的状态记未定；cross-repo 理由如实。**（Alan 2026-09-29 原话「那先把问题修复了」。修法由执行席定、经独立审查两轮、调度方裁定；所有者可事后否决。本条是执行记录，不是阻断依据。）**原因**：`templates/WORK_ITEM.md` 的状态行（DEFINED/DESIGNED/READY/IMPLEMENTING/IMPLEMENTED/INTEGRATION_READY/RELEASED/RELEASE_NA/ACCEPTED/OPERATING）沿自 2026-09-03 基线的研究期生命周期；2026-09-07 写 [01 §4.1](../标准/01-项目管理标准.md) 时改为 planned/in_progress/blocked/in_validation/done/cancelled 六态、发布另记发布记录，模板未随改。检查器按 01 词表认状态，照模板写的工作项永远不被认成进行中或完成，超龄与完成证据两道检查静默失效；新采用项目 NFBY_Reservoir 的 WI-001 已照模板写成 DEFINED。**改动**（分支 `fix-127`）：模板状态行改为「六选一」括注、各态必需工件与转换记录列对齐 01 §4.1、发布字段改指发布记录、去掉随复制会断的链接；`stdlib.state_class` 一处把状态值（去加粗/反引号、取开头状态词）映射到六态，freshness 与 evidence 共用；项目声明的 `work_item_*_states` 从替换缺省改为并入，声明词与内置别名冲突整份配置拒收；认不出的状态由 freshness 记 `freshness/unknown-state` 未定，evidence 记 `evidence/unknown-state-by-freshness` SKIP，freshness 被裁剪或工作项在 frozen 时改由 evidence 记 `evidence/unknown-state`；cross-repo 本机可读仓不足两个时理由只写实际出现的分支（原先固定带一句"path 不在"）。**核实**：此前"NFBY 的 cross-repo/65ba1081 理由写 repos 未声明"一说不属实——该条只在未声明 repos 的项目产出，NFBY 不出。**升级影响**：`work_item_*_states` 语义由替换改并入；新增三个 id；工作项状态不在六态及别名内的出新未定。 | 模板与标准正文两套词表并存，检查器只认一套，照模板写的项目两道检查静默失效。 | **验证**：`--selftest` 215→218（失败 0）；本仓四项闸门退出 0；NFBY、PMC、示例项目新旧逐条无新增；NFBY_Reservoir 退出 0→2，仅 WI-001（DEFINED）出新未定，随其升级改为六态。独立审查两轮：第一轮查出模板相对链接随复制断链、「已完成」等别名未进完成态 2 条阻断，第二轮查出原样照抄模板被认成 planned 的回退与声明词撞别名被静默忽略，均已修。**证伪信号**：照模板或 01 写的状态再被检查器静默放过。 |
| D-128 | 2026-09-29 | 已执行 | **变更级别的确认约束放行、不约束开工；高影响提议确认前只做调查与 ADR 起草、不开始实施。**（Alan 2026-09-29 原话「这个问题也一并解决吧，推荐方案应该怎么做？」。修法由调度方提议、执行席落地，经独立审查后调度方改裁高影响一句（原"确认前不得进入 `in_progress`"与 in_progress 的事实型进入依据冲突、会让高影响项重演 C-051，且"本须先批（§4.3）"引错，先批的依据在 02 §5.4、卡的是实施），所有者可事后否决。本条是执行记录，不是阻断依据。）**原因**：[C-051](失败Case清单.md)——NFBY_Reservoir 的 WI-001 调研产出已提交，状态仍停在 `planned`，执行者在工作项里写「变更级别与完成判据待 Alan 确认，本次不推进状态」；[01 §4.1](../标准/01-项目管理标准.md#work-item-lifecycle) 的进入依据是事实，§4.3 只说「级别由执行者提出、由能对该工件负责的人确认」，没写待确认能否挡开工，执行者只能自行决定。**改动**（分支 `fix-128`）：01 §4.1 规则段补一句——级别待确认不阻止按进入依据转换，提议为轻量或常规的照常进入 `in_progress`、`in_validation`，转换行「依据」注明"级别待确认"，确认前不得进入 `done` 或合并；提议为高影响的确认前可进入 `in_progress` 做调查与 ADR 起草，不得开始实施（同 02 §5.4 第 1 条）；确认级别高于提议时按确认级别补齐必需工件后再往下转换。活性段 `in_validation` 的长期等待加入"级别确认"。§4.3 补一句——确认约束的是表中"放行"（进入 `done`、合并），不约束开工。`templates/WORK_ITEM.md` 变更级别字段允许 `<级别>（提议，待 <确认人> 确认）` 写法、限制指回 01 §4.1 不复述，转换记录节注明依据列写法。C-051 处置格改为已由规则修正处置。**未做**：不新增检查器——"产出目录有晚于最后一次状态转换的提交"须猜工作项与产出的对应关系，按 `tools/std/CONTRACT.md` §1.1 只能记未定，价值低于成本；规则写明后级别一侧的成因已消除；执行者原话里的另一半「完成判据待确认」同样不挡 `in_progress`、`in_validation`（进入依据是事实），只挡 `done`（验收条件满足），现文已覆盖，不另补。重新考虑条件：规则生效后同型滞后再现一次。未升标准修订号、未发版，留调度方。 | 01 未规定级别待确认对状态转换的作用，执行者把确认当作开工前提，产出已在库而状态不跟。 | **验证**：只改文字，检查器代码未动。`--selftest` 通过 218、失败 0，退出 0；本仓 `check_all . --no-scope`、`linkcheck.py`、`check_normative_force.py` 退出 0；用本分支与 main `8d9c534` 的 `check_all.py` 分别扫 NFBY_CMS_FullStack（0/0）、PMC-Planner（2/2）、NFBY_Reservoir（0/0）、示例项目（1/1），计数逐项相同，差异只在检查器身份的 git HEAD 与 tool-identity id。**证伪信号**：规则生效后，采用项目再出现以级别待确认为由不推进状态、或高影响项未经确认开始实施、或待确认项停在 `in_validation` 不被巡检。 |
| D-129 | 2026-09-30 | 已执行 | **落地所有者对四条历史提议的裁定：D-040 接受、D-046 与 D-061 拒绝、D-093 执行完毕。**（Alan 2026-09-30 原话「按建议执行」，依据分诊建议；执行席落地，所有者可事后否决。本条是执行记录，不是阻断依据。）**改动**（分支 `fix-130`）：① D-040——生效登记表新增一行（`已接受`，approved_at 2026-09-30，review_at 2027-03-30），当前生效规则数 9→10；[09 §2](09-跨工具通用性.md#criteria-whether) 判据一表增「运行中观察提炼的经验」行（须绑定它防的失败与删除条件）与「不写是默认非禁令、二次失败即写并绑定删除条件、缓存须对账」一句，[§3](09-跨工具通用性.md#criteria-which) 判据三增第二问「换一个团队，这句话会不会不一样」（会变的内容不进正文，正文只写该类内容必须存在并有所有者），§2 末段与 §4 首句随之改为四行、两问的说法；09 文件头 `governed_by` 补 D-040；[11](11-项目知识.md) §1 删去「D-040 需宪法性批准」的未决表述，§2 P8「这是判据一的已知间隙」改指 09 §2；D-020 登记行不改；提交 `178a17a`。② D-046、D-061 改记`已拒绝`，理由与去向写在各自行内；D-057 登记行不改；提交 `c2d5876`。③ D-093——删示例项目 `docs/INDEX.md` 的「权威域」列，D-093 改记`已执行`；提交 `b06ef11`。④ [`标准/01`](../标准/01-项目管理标准.md) §3.1 文档树里 `INDEX.md` 的注释由「每份文档的职责、权威域、加载时机」改为「每份文档去哪找、一句摘要、加载时机」，与同文 §3.2 职责卡同义、与示例删列一致；[PROJECT_STATUS](../PROJECT_STATUS.md)「下一步」加指针：D-057 于 2027-02-17 复审时一并复核 D-061 的六组跨章边界；提交 `3375a76`。未升标准修订号、未发版。 | 四条提议挂账已久：D-040 的修正内容部分已随 D-057 在 11 P8 试行，与 09 判据一并存成张力；D-046 前提不存在；D-061 与 D-057 复审重复；D-093 待裁部分只差一个取舍。 | **验证**：`check_normative_force.py` PASS（生效规则 10）、`linkcheck.py` 0 断链，均退出 0；`check_all --selftest` 通过 222、失败 0，退出 0；本仓 `check_all . --no-scope` 退出 0；示例项目 `check_all` 改前改后同为通过 44、失败 1、未定 34、不适用 26（退出 1 是改前既有的那 1 项失败），差异只在检查器身份的 git HEAD。**证伪信号**：09 判据一新行或「不写非禁令」一句被援引去写入无删除条件的内容；示例两份映射任一再出现。 |
| D-130 | 2026-09-30 | 已执行 | **落地 D-062/D-018（工程闸门）与 D-023（全绿而目标未达成）的分诊改动，全部为文字、改动最小。**（Alan 2026-09-30 原话「按建议推进」，调度方据两份差距分析的建议改动清单裁定，执行席落地；验收层面项列所有者否决。本条是执行记录，不是阻断依据；D-018、D-023、D-062 登记行不改。）**改动**（分支 `fix-131`）：① 闸门——[`标准/01`](../标准/01-项目管理标准.md) §5.6 合同字段加「执行点」（R1），单人最小集三项改四项、写不出自动执行点的门记未定；四步验收段末补「接进执行点同样是一次新增，③ 的反例从执行点入口喂入」（R2）；八道门表下补 G3/G6/G7 适用即不得删去（R6，§1 引的「默认八道（可增删，写在 `GATES.md`）」原句未动）与 G6 执行点一句（R4）；§5.2 存量失败逐条登记、带修复工作项与到期（单人项目同样适用，不属单人档放宽的豁免与跳过）、到期仍在的存量失败移出基线、视同新增（R3；返修前写作「回到阻断」，与句首「只对新增失败成立」及 G3 表格「全绿（对新增失败）」字面矛盾，改后语义同裁定「到期仍红恢复阻断」）；§5.1 末加「生成物由忽略规则事前挡住」（R5 前半）；提交 `eea0ed4`。② D-023——01 §4.2 收工前第 1 条 ⑥ 后补直接观察要求（使用者入口、目标或等价环境、真实或等价输入；证据全是测试/检查/审查结论时按 N1 记未定；直接观察做不到或由有权人放弃、改按其他证据验收的在 limitations 写「未直接观察」并挂补观察触发）；初稿曾把分析稿删除条件栏里的「按这三项在等价环境自动运行的端到端本身即算直接观察」写进正文，越出裁定且让端到端断言逃出记未定，经独立审查已删去；§4.4「评审看什么」补一短语作执行点；`templates/WORK_ITEM.md` 验证计划提示行指回 ⑥；提交 `ef3a5f1`。③ [`tools/std/README`](../tools/std/README.md)「接法只有一条」段后补 `check_all` 不是 01 §5.6 的 G1–G8（R7）；提交 `b1caa2e`。**私有定位**（交付面只写项目无关描述）：R1 防 PMC-Planner F-044、NFBY_CMS_FullStack `verify_all` 无执行点、NFBY_Reservoir PLAYBOOK P-005；R2 防 PMC OPT-16（恒真 grep）、F-049（`PYTHON=true`）、NFBY pre-commit `files:` 空匹配、Reservoir P-005（`pytest \| tail`）；R3 防 PMC OPT-13/WI-0010（常态退 1、无到期）、NFBY `d04511f2`（unchanged and not grown）、`2ee1ab8e`（自建仓起红）；R4 防 PMC 66 号审计一次性 pip-audit、NFBY `0ef452c7`（non-blocking、撤 CI）与 11 个 dependabot PR；R5 防 PMC `1e110344`（41 个生成物、55 MB blob），正面佐证 NFBY `9870c7ff`；R6 防 P-005（G3）、PMC 66 号审计与 NFBY `0ef452c7`（G6）、NFBY `d82ea726` 险情（G7）；R7 防 NFBY 与 Reservoir 钩子只接 `check_all`；D-023 防 NFBY B-253→B-256、PMC F-035、F-042/043、F-044 观察那一半，limitations 一句另防 NFBY `fc79516c`（有权人以审查与测试代替观察）。**未做**：R5 后半「单文件超 2 MB 提交硬失败」不写——只有 PMC 一例，硬失败会误伤正当数据夹具；R5 前半措辞取「构建产物与运行产出等生成物」，未写草案里的「数据文件」，同一理由。不另立失败分类表，不扩 ④ 的重启边界（B-256 单例，照 N3 不立）；研究正文 31 章「未决」不动，按项目类型增配维持未定；不加检查器、不加配置键（存在性检查判不了门跑没跑、观察有没有发生，同 01 §4.4「不为本条写检查器」）。未升标准修订号、未发版。**验收层面（列所有者否决）**：R3 的「到期仍在的存量失败移出基线、视同新增」（即到期仍红恢复阻断）——即 D-062 ④ 的答复为不设一刀切冻结新功能；D-023 第 1 条的「证据全是测试/检查/审查结论时记未定」。 | D-018 合同字段漏了执行点，单人最小集不要求写；存量失败无到期致常态红被放过；D-023 的「判据全过而目标未达成」在 01 无落点，「可观察终点」未定义。 | **验证**：只改文字，检查器代码未动。`--selftest` 通过 222、失败 0，退出 0；本仓 `check_all . --no-scope`、`linkcheck.py`、`check_normative_force.py` 退出 0；用本分支与 main `3e8050c` 的 `check_all.py` 分别扫 NFBY_CMS_FullStack（退出 0/0）、PMC-Planner（2/2）、NFBY_Reservoir（0/0）、示例项目（1/1），`--json` 的 (id, 状态) 多重集逐条全同，差异只在检查器身份。**证伪信号**：采用项目的 `GATES.md` 写了执行点而门仍未进必经路径；存量失败登记带到期后到期仍不回阻断；交付型声明写了直接观察而使用者入口一跑即失败。 |
| D-131 | 2026-09-30 | 已执行 | **落地两个缺口：检查器查不出状态文件过时、采用方发现的标准问题没有回流渠道。**（Alan 2026-09-30 原话「按建议推进下一批两个缺口」，调度方据两份分析的建议改动清单裁定，执行席落地；验收层面项列所有者否决。本条是执行记录，不是阻断依据。）**改动**（分支 `fix-132`）：① 检查器缺陷——`check_freshness` 文档巡检的扫描面由只扫 `layout.docs_root` 改为与 `metadata_required` 各前缀的并集，文档根之外的前缀（根下验收文件、L1 的 `work/`）此前一条结论都不出；反例八（修前无结论、修后无日期判 FAIL／有日期判 PASS）；[`CONTRACT`](../tools/std/CONTRACT.md) §5 `metadata_required` 行写明；提交 `5d1aa22`。② 新判据只到未定——`metadata_required` 命中而头部没认出状态字段的文档汇成一条 `freshness/no-status-field` 未定（状态字段名是工具词表，契约 §1.1），不判 FAIL、不判取值是否在 01 §3.5 四值里；`layout` 已查元信息的验收、状态工件与工作项目录里的 `WI-*`（`freshness/no-status`）不重报（契约 §1）；验收候选路径并入 `stdlib.ACCEPTANCE_CANDIDATES`，`layout` 与 `freshness` 共用；反例九（含份数变 id 不变、两类排除各做变异验证），三个既有样本补状态字段；删除条件写在检查器文档串：采用项目连续一季度复审零命中且 01 §3.5 状态要求被移出或合并；提交 `05112bd`。③ [`标准/01`](../标准/01-项目管理标准.md) §3.2 交接行判据由恒成立的「HEAD 与当前不符」改为接手者读交接所记 HEAD 之后的提交历史、逐条对下一动作、工作项状态与未决项，表后补防的事件与删除条件；STATUS 行「超过两周」改指 §4.7「每周」行时限（去掉同一参数的第二处权威）；§7「文档过期」「状态丢失」与 §4.7 每迭代行点名的 `check_docs_fresh`、「缺身份的交接被检查器拒」并无实物，改为新鲜度巡检、派生件与源的提交先后比对与 03 §8.3 接收方核验；提交 `654381d`。④ 回流渠道——01 §8 新增「标准自身的缺陷回到标准仓修」：根因在标准或内嵌工具的在原记录行标 `上游`（修订号＋定位），按 `tools/std/README` 所列渠道报告并记回链接，项目取舍不在必报之列；01 §4.7「标准升级」行加逐条核对 `上游` 记录、产出含核对结果；[`tools/std/README`](../tools/std/README.md) 接入节加渠道（公开仓 issues：修订号、定位、最小复现），发布条开头加过 open issues 一步；「合并回标准仓再拉取」五处（`templates/AGENTS.md`、`tools/std/README` 两处、`标准/覆盖与采用检查.md`，及返修补上的 `check_adoption` 内嵌副本被改 FAIL 文案）同批改为「向上游报告（01 §8），修复发布后再拉取」；提交 `e9affa3`。⑤ 按独立审查 R131 返修（无阻断项）：layout 已查的验收、状态工件缺日期也不重报，layout 被裁或该工件在 tailoring 里登记不适用时改由 freshness 报（`artifact_tailored` 挪进 stdlib 共用）；扫描面并集后一半改由 `_metadata_requirement` 一处判定；第二轮核验指出 `.`／`./` 被当成不命中是静默放过（把没看记成项目声明的不适用），调度方裁定 `metadata_required` 元素写成空、`.`、`./` 或以 `/`、`..` 起头时整份配置按解析失败拒收并报行号（`stdlib._bad_metadata_required`，同 `duplicate_*` 写错口径；三个采用项目与示例项目均无此写法），反例八之二改为断言拒收；「layout 整个被裁」分支补反例（反例九之二的 `check: layout` 变体），删掉该排除行 selftest 即红；反例九补候选路径验收工件、头部 4000 字外的状态字段、缺日期的声明状态工件，新增反例九之二（tailoring）、反例八之二（frozen 前缀与 `./`），审查存活的三个变异（去验收候选排除、状态读全文、去 frozen 跳过）及另三个变异均被抓出；`check_adoption` FAIL 文案同批改；提交 `3ac925b`。01 §7「文档过期」探测收窄为派生检查器实际做的「比派生件与源的提交先后，不比 `source_rev` 的值」；README 第 95 行补「先撤掉改动」；调度方裁定本批补 [`标准/03`](../标准/03-Agent信息获取与上下文管理.md) §8.3：交接所记 HEAD 是当前 HEAD 的祖先时不失败关闭、按 01 §3.2 逐条对其后的提交，仓库、分支不符或非祖先仍失败关闭，§3 第 4 条挂指针（防接手者只读 03 §8.3 而按 HEAD 不等失败关闭、去问人）；提交 `2d1716a`。**私有定位**（交付面只写项目无关描述）：① 防 PMC-Planner `metadata_required: [ACCEPTANCE.md, work, …]` 而 `work/`、`ACCEPTANCE.md` 零结论（审计 057 §2.6）；② 防 NFBY_CMS_FullStack 23 份声明文档缺状态、`yingji-4148-dedup-deferred.md` 文件名「暂缓」而正文已翻盘（057 §2.6 判据⑥）；③ 防 PMC 交接停在 09-22 后 32 个非 `.std` 提交（14 个轻量）而接手者把可回读的 U-7 裁定、ADR-0025 未否决拿去问人（057 §2.1），STATUS 8 天落在两个时限之间；④ 防 PMC F-025（`.std/tools/std/stdlib.py` 根因，09-19 入库至 D-117 修复从未回流，升级后 `FAILURES.md` 仍写「未修」），正例 NFBY `standard-version-upgrades.md` 升级时逐条撤 EX-018～020。**未做**：「状态或交接落后于 HEAD」检查器——代理指标（轻量提交按 01 §4.1 本不必改交接），`check_all` 无提醒档、未登记未定即退 2 而采用项目钩子要求退 0，等于在代理指标上硬拦，违反 01 §5.6，且三个采用项目无一例能稳定抓对；重新考虑条件：`check_all` 有不影响退出码的提醒通道，或 ③ 落地后同型「交接落后、可回读却问人」再现。工具缺省 `work_item_stale_days` 14 与 01 §4.1 默认 5 不一致不改（PMC 显式声明 14，改了无效，D-021）。未升标准修订号、未发版。**待办指针**：01 §4.7 执行点复审队列里 03 §8.1 一条的复审条件（出现交接工件）已满足、已到期，按队列规则应补执行点或具名角色，不在本批。**验收层面（列所有者否决）**：`tools/std/README` 把公开仓 issues 定为对外回报渠道（对外、公开）；② 的 `freshness/no-status-field` 未定会让升级后的采用项目退出码变 2。 | 状态工件与交接过时无人发现，且条文把不存在的检查器写成执行点；`metadata_required` 声明的前缀被静默跳过、声明文档缺状态无人看；采用方发现的标准缺陷只能按「合并回标准仓」读成禁令，没有打标、渠道与升级回查，维护方发布前也不看外部回报。 | **验证**（返修后）：`--selftest` 通过 226、失败 0（第二轮后条数不变，两条反例改为更强断言），退出 0；本仓 `check_all . --no-scope`、`linkcheck.py`、`check_normative_force.py` 退出 0。用本分支与 main `0c76e2f` 的 `check_all.py --json` 只读扫（扫前扫后各仓 `git status` 不变）：NFBY_CMS_FullStack 退出 0→2，新增 1 条 `freshness/no-status-field` 未定（23 份：`docs/decisions` 18、`docs/architecture/README.md`、`docs/ops` 4，逐份核头部确无状态字段；其中 `README`、`insight-index`、`insight-history` 等索引页是项目声明范围过宽，项目可收窄）；PMC-Planner 退出 2→1，新增 10 条 FAIL（`work/artifacts` 下无 `updated_at` 的 md，项目同时声明了 `metadata_fields`）与 1 条 `no-status-field` 未定（12 份：`work/artifacts` 11 份＋`work/handoff.md`），逐份核属实，根因是项目把整个 `work` 列进 `metadata_required`，修法在项目侧（收窄前缀或把 `work/artifacts` 放进 `frozen`）；NFBY_Reservoir 0→0、示例项目 1→1，均无新增；消失项全为零；返修前后四个对象的新增项逐条相同。升级后新出现的失败按 D-130 的存量失败登记处理，发版说明须写明 ①② 会让 CMS 与 PMC 升级后变红。**证伪信号**：`no-status-field` 在采用项目上主要命中索引页之类非 01 §3.5 六类文档而项目不愿收窄；接手者照新判据逐条对提交仍把可回读事项交给人；公开仓 issues 两个季度零回报而采用项目里出现 `上游` 候选。 |
| D-132 | 2026-09-30 | 已执行 | **复审 03 §8.1 执行点（01 §4.7 队列行，D-131 待办指针）：补具名角色、移出队列、模板节名对齐、给活动工作集一半写删除条件。**（Alan 2026-09-30 原话「第 03 章 8.1 节有一项执行点复审也处理」，调度方据分析席复审推荐 ②＋③ 裁定，执行席落地；验收层面项列所有者否决。本条是执行记录，不是阻断依据。）**复审结果**：叙事摘要一半三个采用项目从未缺过；活动工作集一半 PMC-Planner 与 NFBY_Reservoir 整体缺、NFBY_CMS_FullStack 早期缺（22 份有 `## 上下文` 节列路径，7 份无）；PMC 09-13～09-20 各版把模板节「按需读取的精确路径#fragment」读成加载清单、填「按 CONTEXT.md 的表加载」，09-21（`1b244db3`）起该节整个消失，是该半从未真正填过的直接原因；三项目查 FAILURES／PLAYBOOK／提交说明，无一条因缺路径清单导致接手失败或返工（只说明无记录，不证明未发生）；已记的接手失败全是交接过期，由 01 §3.2 交接行与 03 §8.3 覆盖。**改动**（分支 `fix-133`）：① [`标准/03`](../标准/03-Agent信息获取与上下文管理.md) §8.1 执行点由「无」改为「执行者写 / 接手者核验（§8.2 重建验收）」，与 §8 父节、§8.2「活动引用」逐项核验的现有文字一致；② [`标准/01`](../标准/01-项目管理标准.md) §4.7 执行点复审队列删去 03 §8.1 一行（已补具名执行点，按队列本意移出；队列与 03 中「无」的小节数同为 17，对得上）；③ [`templates/SESSION_HANDOFF.md`](../templates/SESSION_HANDOFF.md) 节名「按需读取的精确路径#fragment」改为「活动工作集（正在编辑或验证的文件路径，重建后原样重载）」，属模板与正文对齐（N2）；④ 03 §8.1 活动工作集一半补删除条件：依据类型＝补模型能力缺口，宿主压缩是否自带重载最近文件未验证；下次模型或宿主换代时按 01 §4.7「每次模型换代」重放「压缩后不给路径清单，接手者能否找回在编辑的文件」，无差异即删这一半，其间采用项目记录到「接手时找不到在编辑的文件」即条件作废（该重放本身即验证）。**未做**：检查器判交接两半字段齐全——只能按节名判，节名是工具约定，落空按契约 §1.1 只能记未定，判 FAIL 需新增配置键（违 §1.1），PMC 与 Reservoir 会恒报未定、CMS 对 7 份旧工作项报未定，「上下文」节名在别处可指别的内容而产生假 PASS，且所防失败无记录（D-013／D-021）；新增 project.yaml 键；要求采用项目回填历史交接；示例项目 WI-0151 交接与载体实例交接仍用旧节名，属带日期的历史快照，不改。未升标准修订号、未发版。**验收层面（列所有者否决）**：条目移出 01 §4.7 执行点复审队列无先例（D-092 是收窄定义域）；§8.1 活动工作集一半挂上删除条件。 | 03 §8.1 执行点标「无」而同章 §8、§8.2 已点名执行者与接手者，字段与正文对不上；模板把活动工作集节写成加载清单式节名，采用项目照填成空话。 | **验证**：只改文字，检查器代码未动。`--selftest` 通过 226、失败 0，退出 0；本仓 `check_all . --no-scope` 通过 17、失败 0、未定 1（已登记），退出 0；`linkcheck.py` 441 个文件 0 断链、`check_normative_force.py` PASS（决策 132、生效规则 10），均退出 0。03 中执行点「无」的小节数与 01 §4.7 队列行数同为 17。**证伪信号**：采用项目出现「接手时找不到在编辑的文件」失败（删除条件作废）；换代重放无差异（删该半）。 |
| D-133 | 2026-09-30 | 已执行 | **`metadata_required` 增加 `!` 排除前缀。**（Alan 2026-09-30 原话「按建议推进，先登记例外，再加除外写法」，调度方裁定，执行席落地；验收层面项列所有者否决。本条是执行记录，不是阻断依据。）**语法**：元素以 `!` 起头为排除前缀，先取全部包含前缀的并集，再减去排除前缀命中的文件；YAML 里须加引号（裸 `!` 是标签，解析器按歧义拒收）。排除表达的是项目自己的事实（这些文件不是须带元信息的文档），不是替检查器修判据，不违反契约 §1.1。**改动**（分支 `fix-134`）：① [`tools/std/stdlib.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/stdlib.py) 新增 `metadata_required_hit`，包含与排除只在这一处判，[`check_freshness`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/checks/check_freshness.py) 经它读（全仓读该键的判定只此一处；`check_layout` 不读该键）；被排除的与不在清单内的同样对待——排除只免缺日期、缺状态两类结论：文档根内无日期记一条不适用，带日期的照按日期判陈旧（与不在清单内同），文档根外不进扫描面；② `_bad_metadata_required` 并入校验，整份拒收并报行号：`!` 之后为空、`.`、`./`、以 `/` 或 `..` 起头；排除前缀不落在任何包含前缀之下（只有排除没有包含即属此列，裁定所列「只有排除」一项由此覆盖，不另写分支——变异验证表明单独那一支删掉后 selftest 仍过，属冗余）；排除前缀与某条包含前缀相同（等于删掉那条包含）；裸写 `!` 被解析器拒收时报错提示加引号；③ selftest 增反例八之三（排除生效、同一事实只报一次、未排除照判 FAIL，`./` 起头写法同判）与八之四（十种写法拒收、两种合法照收）；④ [`tools/std/CONTRACT.md`](../tools/std/CONTRACT.md) §5 该键一格写明语法、校验、免除范围，以及 `!` 起头的真实路径无法再作包含前缀；⑤ **原有缺陷一并修**：元素以 `./` 起头（如 `./docs`）此前被接受却永远不命中，现去掉开头的 `./` 后再匹配，排除同理（`!./docs/x` 视同 `!docs/x`），单独的 `./` 仍拒收；freshness 覆盖边界写明「包含前缀减去排除」（R133 审查返修）。tools/std/README 与标准正文未提该键的写法，无须同步。**未做**：不给被排除文件另出一类结论；不改 SKIP 的原因文字（改了会让未用 `!` 的项目输出逐条不同）；不升标准修订号、不发版。**验收层面（列所有者否决）**：`metadata_required` 元素以 `!` 起头从字面前缀改为排除语法——此前以 `!` 起头的真实目录名不再能直接写成包含前缀（四个扫描对象均无此写法）。 | 采用项目排不掉索引页、工具原文目录，只能逐份列其余文件，今后新增的决策、工作项须手工补清单。 | **验证**：`--selftest` 通过 228、失败 0，退出 0；变异六处（去掉排除判定、去掉「排除须落在包含之下」、按原字面校验排除元素、去掉「与包含相同」拒收、去掉 `./` 归一、去掉加引号提示）各使 selftest 退出 1。本仓 `check_all . --no-scope` 通过 17、未定 1（已登记），退出 0；`linkcheck.py`、`check_normative_force.py` 退出 0。主仓版与工作树版 `check_all --json` 只读扫三个采用项目与示例项目，除工具身份一条外逐条相同（退出码 0/2/0/1 两版一致），扫描期间各项目 `.std`、`governance` 未变。**证伪信号**：采用项目写了 `!` 排除后被排除文件仍出缺日期或缺状态结论；未写 `!` 的项目结论随本改动变化。 |
| D-134 | 2026-09-30 | 已执行 | **文档状态（01 §3.5）与工作项状态（01 §4.1）分流。**（来源：采用方经「上游」渠道回报、Alan 转来；调度方裁定「身份优先、取值兜底」，执行席落地，经审查 R134 返修一轮；验收层面项列所有者否决。本条是执行记录，不是阻断依据。）**问题**：两套词表共用状态字段（`stdlib.STATUS_FIELDS`），`check_freshness` 与 `check_evidence` 把工作项目录里任何带状态字段的文件当工作项按六态判，`metadata_required` 命中的交接文件按 01 §3.5 写 `status: superseded` 记 `freshness/unknown-state`（外加 `evidence/unknown-state-by-freshness`），不写记 `freshness/no-status-field`，写不写都消不掉未定；另外状态取自前 4000 字符，小节正文里的 `状态：active` 字样也被读成状态。**改动**（分支 `fix-135`）：① [`tools/std/stdlib.py`](https://github.com/Alan-IFT/ai_dev_system/blob/archive-pre-ts-refactor/tools/std/stdlib.py) 新增 `DOC_STATES`（四值及中文别名，与 `WORK_ITEM_STATES` 并列）与 `status_kind`，两个检查器只经它分流（全仓只此一处）：`WI-*` 命名或值属六态／声明词 → 工作项；其余的 `layout.artifacts` 声明工件 → 文档（值属 `DOC_STATES` 记 `freshness/document-state` 的 `SKIP`，不巡检活性、不查完成证据；认不出记 `freshness/unknown-doc-state` 未定）；其余（未声明、非六态，含写 `active`/`draft` 的非 `WI-*` 工作项）→ 工作项，照记 `freshness/unknown-state`；② 声明词撞 `DOC_STATES` 按既有撞词口径整份拒收，selftest 断言两表无交集；③ 新增 `head_of`：状态字段只从头部读——YAML 头里有状态字段时只读 YAML 头，否则读到第一个二级及以下标题之前，`no-status-field` 判据与 `layout` 查 ★ 工件状态字段都改用同一个 `item_status`；④ [CONTRACT](../tools/std/CONTRACT.md) §5 补一段适用对象与读取范围。01 正文未改（§3.5 已写「不用文档状态代替实施状态」）。**与裁定的偏差（最小改动）**：a. 裁定第 1 条「声明工件一律按文档」与事实冲突——L1 允许 `work/current.md` 同时是声明的状态工件与在做的工作项（值写 `in_progress`），故值属六态的照按工作项判；b. 裁定第 1 条的「工作项目录之外 → 文档」分支删去：两个调用方只传工作项目录直接一层的文件，生产路径走不到（R134 R1）；c. 裁定第 3 条「目录内值属文档四值 → 文档」按 R134 B2 撤回：它让写 `active` 的 B-* 工作项从未定降为 `SKIP`，违反契约 §1.1；d. 头部划界按 R134 B1 改为 YAML 头有状态才只读它、否则截到二级标题：初版「有 YAML 头只读 YAML」让「YAML 只写日期、状态在一级标题下」的合法写法丢状态、超期 FAIL 静默消失；另保留「YAML 头里有状态字段才只读 YAML 头」一支（第一轮返修曾以「与 `find_field` 取首次出现等价」删去，第二轮审查证伪：`find_field` 按字段名顺序状态→status→state 逐个找，YAML 写 `status: superseded`、一级标题下写 `状态：进行中` 时会读到后者，已恢复并补反例）。代价：YAML 删掉状态后一级标题下引导段里留的「改回 `status: active`」字样会被读到——非声明文件记 `unknown-state` 未定，不静默；要彻底排除需把状态字段限定在行首，改面更大，未做。裁定所说「与 no-status-field 同一常量」本已成立，头部改按结构界定而非另设常量。 | 同一字段两套合法词表，任何一种写法都消不掉未定，采用方只能长期登记例外。 | **验证**：`--selftest` 通过 230、失败 0，退出 0（原 228，增反例 F 与拒收 p41）；变异 13 处（去掉 YAML 分支、YAML 头不查状态即只读它、去掉声明工件判定、去掉 `WI-*` 优先、去掉六态优先、去掉二级标题界、去掉撞文档词拒收、去掉 `./` 归一、`no-status-field` 退回旧读法、`layout` 退回前 40 行读法、freshness 去掉文档分支、去掉 `unknown-doc-state`、evidence 去掉文档跳过）各使 selftest 退出 1。本仓 `check_all . --no-scope`、`linkcheck.py`、`check_normative_force.py` 退出 0。主仓版与工作树版 `check_all --json` 只读扫三个采用项目与示例项目：NFBY、Reservoir、示例项目除工具身份外逐条相同；PMC `freshness/unknown-state` 与 `evidence/unknown-state-by-freshness` 消失、新增 `freshness/document-state` 一条 `SKIP`，其余相同；退出码两版一致（0/2/0/1）。**证伪信号**：写 01 §3.5 四值之一的声明工件仍出 `unknown-state`；非 `WI-*` 工作项的活性或完成证据结论随本改动消失或降为 `SKIP`。 |
| D-135 | 2026-10-04 | 已执行 | **本仓只支持 DeepSeek Harness（DSH），不再支持 Claude Code；执行层实现为 DSH 原生插件。**（Alan 2026-10-04 原话：「项目需要重新改造为DeepSeek harness能使用的工具，不再支持claude code」「修改为只支持DeepSeek harness吧，然后这个工具可要做实现为插件形式」；范围由 Alan 在对话中选定：现行件与标准/docs 正文里的 Claude 具名引用一并清，研究卡片与审计记录等冻结历史不改写；D-020 §5 改单载体；守卫写成 DSH 原生插件；环境以 Windows 为准、Ubuntu 后续再支持。执行席落地；**D-020、D-108 两行的实质修改经 Alan 2026-10-05 明确确认后才写 `approved_at`**（提交前独立审查指出「事后否决」与 D-077 ② 要求的事前重新批准有张力，故改为先确认）。本条是执行记录，不是阻断依据；效力落在 D-020、D-108 两行的「修订」句里。）**改动**：① 入口 `CLAUDE.md` 改 `AGENTS.md`（DSH 的 `dsh-agent-instructions` 原生读 `AGENTS.md`），`CONTEXT_MANIFEST.md` 去 Claude 专属表述并递增 `contract_revision`；② 删 `.claude/`，受控动作询问与闸门失效探测改由 `tools/dsh-std/` 插件承担；③ 新增 `tools/dsh-std/`：DSH 原生插件，订阅 `tools/pre-execute`，对受控动作返回 ask、对写内嵌标准目录返回 deny，与下游决定合并时取最严；**不使用 `ctx.tools.guard()`，也不检查提交信息**（提交信息仍由 `.githooks/commit-msg` 查；2026-10-04 提交前独立审查指出本行原文写错，已更正）；④ `tools/std/README`「Claude Code 接法」改「DSH 接法」，`check_adoption` 的免审批清单判据**改记 SKIP**（本宿主没有项目级入库的放行清单可读，不是「改读 DSH 权限配置」；原文写错，已更正）；⑤ `templates/claude-code/` 删除；⑥ 载体附录、标准/ 与 docs/ 正文中的 Claude 具名引用改写；⑦ [09 §5](09-跨工具通用性.md#feasibility-test) 与 D-020 登记行：可行性检验改为「两种互不相同机制类型、可同宿主」，跨工具一项记未定。**Windows 兼容修复**（判据不放宽，但**不是只改夹具**）：`stdlib.GIT_HARDEN_CONFIG` 是**生产代码、所有平台都生效**，本轮改了它的取值——`core.sshCommand`／`core.gitProxy`／`core.askPass`／`diff.external` 由空串改 `true`，`core.hooksPath` 由 `/dev/null` 改 `os.devnull`（原因：Windows 上 `os.environ[k]=""` 不传给子进程，`GIT_CONFIG_COUNT` 不变而少一个 VALUE，git 报 missing config value 整条命令失败；`true` 是不会执行被扫方指定程序的取值，经 PATH 解析的理论面独立审查标为建议、未排除；`hooksPath=nul` 已实测使钩子不运行）；`linkcheck` 的仓根路径规整与两条自检夹具（FIFO、含冒号路径）换等价夹具，无等价夹具的断言在 Windows 上记 SKIP；`linkcheck` 的仓根路径规整；两条自检夹具（FIFO、含冒号路径）在 Windows 上换成等价夹具。 | **DSH 一手查证**（读 `app.asar` 内 `@deepseek-ai/*` 包源码与 README，2026-10-04，DSH 0.2.0-rc.2，补全[载体映射](附录-载体实例/DSH载体映射.md) §6 的三项未定）：① `ctx.tools.guard()`：同步单调守卫，普通 context 注册为全局生效，经 `agent.ctx` 注册则只对该 agent 生效；② `tools/pre-execute` 是可订阅的 allow/deny/ask 瀑布，ask 走 `dsh-user-approval`，应答缺席即拒绝；③ 插件可从 profile 的 `package.json` 依赖加 `dsh.profile.bundles` 里的 bundle 装入，`cordis-plugin-loader` 支持 `name: './plugins/x'` 路径形态；`dsh-invariants` 只在随包的 `./invariant` 伴生件上跑，本插件不依赖它。**未验证**：插件尚未在真实 DSH 会话里加载运行，只做了源码对读与单测，见本行验证格。 | **本轮不做**：① Ubuntu 支持；② 改写 `docs/参考资料*/`、`docs/审计记录/`、`docs/归档/`、决策日志旧条目里的 Claude 字样——它们记录的是当时的事实，改写即篡改证据；③ NFBY_CMS_FullStack 的迁移（它按 D-115 的 Claude Code 接法装过，需要自己的工作项）。**验证**：三道提交闸门与 `check_all --selftest` 的原始输出见[本轮完善记录](审计记录/本轮完善记录.md)；插件单测与真实会话加载状态见同处，加载未跑的记未定。 |
| D-136 | 2026-10-05 | 已执行 | **发布 2026-10-05，并裁定两件事：①DSH 审批弹窗不在本插件验证范围；②推送与发布由执行席决策并执行，不再逐次过问所有者。**（Alan 2026-10-05 原话：「要不要在审批策略为 ask 的会话里验证弹窗，这个的意义是什么？DeepSeek harness已经有这个功能了啊？不要重复造轮子；保留守卫在 profile 里；推送与发布你来决策和执行就行，不用过问我」。本条是执行记录，不是阻断依据。）**① 弹窗**：此前我把「审批策略为 `ask` 时弹窗与批准后放行」列为待验证项，被指出是重复验证 DSH 自带的 `dsh-user-approval` 功能。本插件的职责止于「返回 `{kind:'ask'}` 并被 DSH 采纳」，这一点已在真实会话里观察到（`git tag`、改 `AGENTS.md` 被拒）。已把相关「未验证」改为「不属本插件验证范围」。**② 推送与发布的授权边界**：Alan 授权执行席按 [`tools/std/README`](../tools/std/README.md)「发布」步骤自行决策并执行推送与发布。**这个授权不覆盖**：强制推送、删除远端内容、覆盖他人工作、绕过 `release` 分支直推公开仓、把 `main` 推到公开仓（[D-108](#effective-register) 的 blocks 仍然生效）；它也**不改变** `git tag`／推公开仓在 `tools/dsh-std/` 里仍返回 ask——该会话审批策略为 `never` 时执行席需要由所有者调整策略或经其确认；本次发布由执行席在受控动作处如实说明并执行。**③ 发布内容**：修订号 `2026-09-30.5` → `2026-10-05`（`标准/README.md` 第 3 行与 `governance/STANDARD_VERSION` 同步）；交付面 checkout 清单加 `tools/dsh-std`（D-108 登记行已加，发布步骤原漏写）；`release` 分支根 `README.md` 去掉面向 Claude Code 的描述、补 DSH 取用与插件说明。 | 发布前在 `main` 上跑：`check_all --selftest` 退出 0（通过 225 失败 0 未定 0）、`check_all . --no-scope` 退出 0、`linkcheck` 0 断链、`check_normative_force` PASS、插件单测全过；数字以命令现取为准，不在此抄。 | `release` 分支新提交的 tag `2026-10-05`；公开仓 `main` 指向它；采用项目 `git subtree pull` 取到后 `check_adoption` 能比对到 `候选实现修订：2026-10-05`。**未验证**：公开仓推送后的取用端到端（本仓无采用项目可当场拉）。**后续记录（2026-10-06，不改上面与 D-135 的原文，只补现状）**：①D-135 写的「本轮不做 CMS 迁移」与「插件尚未在真实会话加载」已过期——NFBY_Reservoir、NFBY_CMS_FullStack、PMC-Planner 三个采用项目都已 `git subtree pull` 到 `2026-10-05` 并迁到 DSH 接法、推送，因此「公开仓取用端到端」在这三个项目上已走过（`check_adoption` 的比对见各项目自己的提交）；插件已在真实会话里加载并真跑，子 agent 与 `subagent_fork` 都继承。②Ubuntu 一侧的测试改在本机 Docker 容器里做：插件单测 471 条 0 失败（22 条只在 Windows 成立的路径语义跳过，不算通过），暴露并修了 8 条把平台相关断言写成无条件的测试。③`main` 上 `tools/dsh-std` 有 4 个文件比 tag `2026-10-05` 新（PowerShell 方言转义、变量赋值首词两处误报修复与测试），Alan 定「不发」，等下次有别的标准改动时一并发布；见[会话交接](附录-载体实例/会话交接.md)。**更正（2026-10-06 稍后）**：③已不成立——Alan 2026-10-06「都做了吧，该抽成公共就抽成公共」，抽出 `tools/std/pick-python.sh` 是实质改动，发了 `2026-10-05.1`（`release` `d7f8b1f`，来自 `main` `7138563`）并把那 4 个文件与公共写法一并带出；CMS 已升，Reservoir、PMC-Planner 仍是 `2026-10-05`。**再更正**：Reservoir、PMC-Planner 随后也已升到 `2026-10-05.1`，三个采用项目一致。 |
| D-137 | 2026-10-10 | 提议 | **分发改为 DSH 插件、主仓公开后，D-108 的交付面、发布流程与公开仓部分不再对应现实；提议以新条目取代它，待三个采用项目迁完后再生效。**（Alan 2026-10-10 先后说：主仓 `Alan-IFT/ai_dev_system` 已在 git 上设为公开；D-108 与公开仓 `ai-dev-std` 的处置「按推荐做」。本条是**提议**，状态 `提议`，**不进生效登记表**；D-108 的状态与效力一字不改，直到下面的触发条件满足并经 Alan 确认。）**变了什么**：①主仓已公开，D-108 blocks 里「阻止把私有 `main` 上交付面以外的任何内容推到公开仓」与 ⑥「私有 `main` 不公开」的前提不成立；②取用方式由「`git subtree` 内嵌公开仓 `release` 的 `main`」改为「`dsh plugin add github:Alan-IFT/ai_dev_system#<标签>`，从**主仓**的标签取」（设计文档 §12.33、§12.34），不经 `release` 分支与 `ai-dev-std`；③D-108 blocks 的唯一例外指名 `tools/dsh-std/`，该目录随换装删除，执行层现在是插件包本身（`src/guard/`、`lib/`、`cordis.patch.yml`）。**提议的新约束**（取代 D-108）：保留 D-108 里与分发方式无关的三项——不在交付面新增生成器、脚手架、安装器或取用器脚本；不把工件文件在不在、有几个汇总成分数或等级来评价规范或采用项目；不援引模板、Skill 或载体实例的文字作为执行、放宽或授权的依据；**改写**一项——交付面（`标准/`、`templates/`、`tools/std/CONTRACT.md`、两份许可）里不放作为生效执行层的宿主钩子、权限或流水线配置，**唯一例外是插件包自身的守卫**（`src/guard/` 及其构建产物）；**删去**三项——私有 `main` 不得推公开仓、不得绕过 `release` 直改公开仓、grants 里按 `release` 线性发布与「取用命令默认写公开仓 `main`」。**对 `release` 与 `ai-dev-std` 的处置**（提议，同样等触发条件）：`release` 分支**保留不动**——三个旧项目靠 `git subtree pull` 取它，删了就断了它们的升级路径；公开仓 `ai-dev-std` **已由 Alan 于 2026-10-10 归档**（先于本条原先设想的“迁完再归档”）。归档前后我在临时目录实测：匿名 `git subtree add`（tag `2026-10-05`）与 `git subtree pull`（tag `2026-10-05.1`）都成功，`git push` 被 403 拒绝——**归档只读，不断三个旧项目的升级路径**，所以“迁完才能归档”的前提不成立。归档后它的 `main` 与全部 tag 原样保留；它的 README 与描述仍是旧的（`check_all`、`git subtree`），归档仓无法再改，需要说明的话写在主仓。**触发条件（只剩 D-108 的取代，不再含公开仓归档）**：NFBY_Reservoir、NFBY_CMS_FullStack、PMC-Planner 三个采用项目都已迁到插件接法（迁移方案由 `std-check migrate` 只读产出；**迁移由各项目自己执行，本仓不替它们执行**）。条件满足前，D-108 继续生效、发布流程一段原样保留。 | 不就地改 D-108 的原因：D-108 是生效项，一行里同时改五处，按 [D-077](#effective-register) ② 属实质修改，难以逐处审；取代能把「哪些没变、哪些改了、哪些删了」写成一份可读的对照，旧行改「已取代」留痕。不现在就生效的原因：三个旧项目仍靠 `release` 与公开仓升级，登记表若先说「不用 release 了」就与它们的现状矛盾。 | 触发条件满足时：Alan 确认后，①把本条改「已接受」并写进生效登记表（`approved_at`、`blocks`、`grants`、`review_at` 必填，见 08 §2），D-108 改「已取代」并从登记表移除；②（已提前完成）公开仓 `ai-dev-std` 归档；③`tools/std/README`「接入一个项目」里已无 subtree 取用，发布一段改写。**未验证**：三个旧项目是否有人在用公开仓的 `main` 而非 tag（实测了 `main` 与 tag 两种取用在归档后都能拉，但没读三个项目的 subtree 记录）。**已实测**：归档公开仓后匿名 clone／subtree 拉取仍成功。**更正**：本条正文里的 `Alan-IFT/ai_dev_system` 是主仓改名前的名字，现为 `Alan-IFT/dsh-project-std`（设计 §12.39）。 |

<a id="round4-revisions"></a>

## 第四轮修订提议登记（2026-09-02，全部为`提议`）

来源与论证见[输入材料 004](https://github.com/Alan-IFT/dsh-project-std/blob/archive-pre-ts-refactor/docs/%E5%BD%92%E6%A1%A3/%E8%BE%93%E5%85%A5%E6%9D%90%E6%96%99/004-%E7%AC%AC%E5%9B%9B%E8%BD%AE%E5%85%AC%E4%BC%97%E5%8F%B7%E6%96%87%E7%AB%A0%E7%BB%BC%E5%90%88%E8%AE%B0%E5%BD%95.md)与[第四轮主题综合](参考资料/12-第四轮主题综合/README.md)。原索引行保留原貌；采纳后由 Alan 决定是改写原行还是新增"取代"记录。正文 00–07 章与术语表已按下列语义修订（同为提议）。

| 决策 | 修订内容 | 主要来源 |
|---|---|---|
| D-003 | 停机条件三类并存（证据型 / 停滞型 / 上限型），任一触发即停并升级；重试前须改变输入变量并记录；重试预算按失败所在层分配；止损后转证据驱动排查（可证伪假设、可清除的临时观测、复现由人或可信环境执行） | WX-04/06/07/08/11/14/22/35 |
| D-005 | 长时或异步执行的成功判据是可重读的持久状态；自动化运行记录实际消费的输入版本；工具副作用由系统观察或工具声明，不由模型转述；每类工件只有一个权威记录系统 | WX-14/44/12/40 |
| D-007 | 拟被 D-033 取代 | — |
| D-008 | 判据可确定的规则下沉；判据为代理指标的只能提醒；下沉时机由观察到的违规触发 | WX-42/44/14/26 |
| D-009 | 六项最小字段（断言、原始证据、精确版本与工作区身份、适用范围、观察时间、确认方法）+ 按复杂度信号追加 + 变更验证附加（变更前失败集合、实际消费输入版本、逐层三态与盲区、验证者身份、认知覆盖可选） | WX-44/07/14/42/35 |
| D-010 | 阶梯双向：升级须 eval 且满足重复频次、跨会话/中途审批、边=数据依赖、失败去向、同步点必要性；降级判据为同输入多次运行结果一致；多单元与单单元比较须等 token 预算；子执行者独立计费、编排者成本单列；验证器先于触发器 | WX-06/11/14/21/28/18/32 |
| D-013 | Thin 从信号升级为结构性机制（入必有出）；候选发现自带限流；作用域限定为共享组件，一次性工件重复生成才成 Add 候选；删除门槛低于新增 | WX-20/16/44/22 |
| D-015 | 合同唯一但可按角色×环境参数化；约束集优先级显式可查；权限分档独立于加载分档；项目规则不进个人配置 | WX-15/13/30 |
| D-016 | 状态由工件事件推断优先于自报，人工改写标低可信；进行中单元绑定执行者与最后活动时间；阶段切换时写入方清理过时字段；压缩前同样生成交接 | WX-34/40/11/43/25 |
| D-018 | Gate 合同增字段：判据类型（确定事实 / 代理指标）、检查器自检、未知默认值、屏障、失效探测、呈现格式与带宽度量；最低 Gate 试行集合候选见 004 §6 | WX-42/44/08/12/17/26 |
| D-021 | 规则三分类（能力补偿 / 组织信息 / 责任结构），仅补偿类须删除条件，组织信息类登记迁移形态，责任类声明无到期；"可复现失败"含已观察与已构造两种来源；到期审计三种触发并存（日常观测 / 代际全删对照 / 周期清扫）；到期规则可能反转为负作用，处置含"改触发条件"；评估集自身有饱和过期 | WX-26/44/42/24/16 |
| D-022 | 作用域声明为"单条交付链"，上游需求规划在链外只作流动观测；流动指标不得单独报告，须与质量/集中度反指标成对并带基线期；四类摩擦根因作初始分类；延期须级联影响链 | WX-34/35/11 |
| D-023 | 客服案例更正为"说明性示例"；新增"多轮累积偏离"形态与方向性指标；现实锚点前移到理解阶段（静态可达≠运行可达）与工具执行粒度 | WX-23/38/27/12 |
| D-024 | 拆为事实门禁上限（误报率）与人工判断检查点上限（判断带宽）；代理指标不得阻断；检查点集中在少数状态转换处并记录耗时/频率/否决率/队列；对策是让 Gate 便宜到能真判（呈现格式属 Gate 合同）；并行自主流上限 = 人能认真审的数量 | WX-42/26/40/07/11 |
| D-025 | 先判"是否改变模型所见"，路径中性者才可仅组件级对照且只能对局部层下结论，组件须在受控负载下可复现；成本按计费类别加权并声明价表版本、同一 baseline、同预算；声明重复次数/隔离条件/噪声基线，效果量小于噪声不作依据；来源改为"ATT-F 数据 + ATT-L 方法主张" | WX-32/18/36/24/42 |
| D-026 | 增发现端限流；去重细化为"唯一位置 + 显式优先级"；强调性措辞绑定代际并消融；删除门槛低于新增；作用域为共享组件；效力元信息不进模型常驻指令（登记为 D-014 已知限制） | WX-16/26/44/13 |
| D-027 | 范围增"所选能力"与"可通信主体"；至少两处检查（会话建立时冻结 + 工具/目标侧复核）；工具可见性限制与权限边界分别声明；被委托者权限 ⊆ 委托者；未登记动作与应答缺席默认不放行 | WX-30/40/29/17 |
| D-028 | 交互式审批不得沉淀为永久授权，免审批集合可枚举可扫描有复审周期；生成权与写入权结构分离；授权移交（自批、预批准动作集）是慢变可审计的角色图变更并附抽样复核 | WX-01/17/26/12/40/42 |

## D-014 决策记录

**背景**：本仓库全部规范正文使用命令语气写成，执行者无法从措辞区分"已生效门禁"与"讨论中的提议"，产生三类失效——虚假授权、虚假阻断、空集合合规。v0.2 审计已识别前两类并加了效力声明，但状态值散落各处会过期，且第三类（空 Gate 集被读成已通过）没有机制拦截。

**选择**：见[规范效力元治理](08-规范效力元治理.md)全文。核心是四条：状态语义表、blocks/grants 分离、未标注规则分向降级、空集合判 UNDETERMINED。

**备选与取舍**：

| 议题 | 已选 | 被否 | 取舍 |
|---|---|---|---|
| 未标注规则默认行为 | 分向降级：可拒绝、不可授权 | 失败关闭 | 失败关闭最安全但理论文档遍布未标注句子，会使仓库不可用 |
| | | 一律按提议 | 摩擦最小，但安全相关句子会因未及时标注而被无声跳过 |
| 标注载体 | 章节头 `governed_by` 只写 ID + 日志唱唯一效力源 | 行内逐条标注 | 状态值出现大量副本，与单一权威原则冲突，文档不可读 |
| | | 正文完全不标 | "这段受哪条决策管"不可见，检索成本高且易错配 |
| 试行到期 | 自动失效回提议 + 历史不追溯 | 降为仅阻断不授权 | 会积累无人维护的僵尸阻断规则 |
| | | 不自动失效仅提醒 | expiry 退化为提醒而非机制 |

**风险与已知限制**：

- 分向降级依赖执行者能正确区分"拒绝方向"与"授权方向"。边界模糊的动作（例如"重构"既非纯拒绝也非纯授权）需要在实践中积累判例。
- 生效登记表是人工维护的单点，检查器只能验证内部一致性，无法验证 approved_by 是否真的有权批准。
- 本决策的效力范围仅限本仓库；采用本规范的项目需各自完成宪法性批准。

**验证方式**：[反例推演表](08-规范效力元治理.md#validation)。§9 只声明"效力标注必须可机械校验"这一语义要求，不规定实现载体；一份 Markdown + Git 的参考实现存放于[附录·载体实例](附录-载体实例/README.md)，不属于规范正文。

## D-020 决策记录

**背景**：用户确立适用范围约束——规范必须在既有 AI 辅助编程工具上通用。但"正文只写通用内容"这句话无法机械执行：载体绑定通常不以工具名出现，而以该工具的默认假设出现（假定有文件、文件头、目录、版本控制、会话）；且一个约定用得足够久就会显得像定义。

**选择**：见[跨工具通用性](09-跨工具通用性.md)全文。核心是三条判据 + 一条硬性检验 + 探测提示机制。

**备选与取舍**：

| 议题 | 已选 | 被否 | 取舍 |
|---|---|---|---|
| 可行性检验强度 | 硬性：说不出两种机制类型不同的载体即不得进正文 | 软性登记已知载体 | 检验退化为提醒，无法证伪 |
| | | 只声明原则不检验 | 正是"无法机械执行的抽象提醒"，实践效果差 |
| 版本控制身份 | 换为"工作区身份"语义 + 并列探测提示 | 保留字段标为示例 | 写在必填字段位仍会被当成要求，即"参考材料与规则打架" |
| | | 保留现状，视 Git 为事实标准 | 把当下工具生态当成永久真理，正是补偿面警告的对象 |
| 工具映射表 | 不维护，只给探测提示 | 附录维护主流工具映射 | 工具约定变化快于规范复查，过期映射成为第二事实来源；且部分工具的当前约定超出 AI 可核实范围 |

**本轮实际清理**：`repository/worktree/branch/HEAD` 共 5 处（02 §4、03 §2/§3/§7、05 §4、入口清单 §Resolution rules）改为工作区身份语义 + 探测提示；00 §5"可变实现"清单重写为"载体绑定"并改由判据判定；08 §7 标注载体、templates/ 全目录重新声明为载体实例；D-014 §9 的检查器已于本轮前移出正文。

**风险与已知限制**：

- 两种机制类型的检验依赖判断者对机制类型的正确归类，本身可能被规避（举两个名义不同实则同类的载体）。
- 探测提示与必填字段的边界在实践中容易滑移，需在后续审计中重点复核。
- 本决策**尚未在任何真实工具上验证**。D-020 自身也是一条未绑定可复现失败的规则，须在 D-021 接受后补齐。
- **第四轮补注（2026-09-02）**：首批验证材料已出现——同一语义在两个宿主上字段名与决策值集不同（WX-17）、DSH 各层形态的一手核对（WX-29 §5.1）、网关冻结 + 工具侧复核的两处检查（WX-30）；两种机制类型检验在"进程内类型化事件 vs 外部进程钩子"上成立。同时暴露判据一的间隙，见 D-040 修正案。机制类型清单见[附录](附录-载体实例/机制类型清单.md)。

**验证方式**：[反例推演表](09-跨工具通用性.md#validation)。

## D-043 决策记录

**背景**：前五轮的正文按"八层模型 + 四闭环"组织。八层并列没有主次，读者看不出哪几层是骨架；且它不回答"这套东西怎么用现成工具拼起来"。用户提出的示例（agent team + 代码图谱 + 记忆 + 上下文管理 + 方法库）覆盖面不足，用户随后明确要求"架构怎么定，还是要综合参考资料提供的信息来确定"。

**方法**：不预设部件清单，对 57 个来源（同源合并后 52 个）逐一抽取部件、关系、不可省略声明与失败归因，跨来源统计后再裁决。过程与全部数据见[架构确定](架构确定.md)与[参考资料 13](参考资料/13-架构要素抽取/README.md)。

**选择**：四个平面加一条交付线，14 个部件。知识平面是资产、执行平面是工具、控制平面是纪律、责任平面是人。

**备选与取舍**：

| 议题 | 已选 | 被否 | 取舍 |
|---|---|---|---|
| 架构骨架 | 四平面按职责划分 | 工具组合式（示例五块） | 只覆盖"做事"部件，缺验证、证据、守卫、状态、意图，而这些在不可省略票与失败归因中居前 |
| | | 原八层并列 | 覆盖完整但无主次，读者无法判断先做什么 |
| | | 范式阶梯 | 是演进史不是职责划分；8 个一手来源无一使用 |
| 人的位置 | 单列为责任平面 | 放在控制平面内 | 会被读成"控制手段之一"；而人是控制平面的授权来源与最终收敛点，且不可省略票数第一 |
| 边缘部件 | 暂列为边缘适配，待定 | 直接升为一等部件 | 个人项目要为不适用的部件写两次"不适用"，与"简单且灵活"相悖 |
| | | 直接并入现有部件 | 会丢掉它们各自的纪律（写限两处加幂等加软降级；判定器先于触发器） |

**风险与已知限制**：

- 证据偏向：52 个来源中一手厂商文档只有 8 个，编码 Agent 场景占 19 个；二手来源存在系统性转述升格（第四轮登记约 90 处）。四平面的划分对一手来源加权，但仍未在任何真实项目上验证。
- 部件边界会在写作中被反复挑战：本轮重组已发现七组跨章重复语义，均已就地裁定归属，但下一轮仍可能出现新的边界争议。
- "控制平面可以只用文档和人工实现"这一主张来自最小形态推演，尚无项目实测。

**验证方式**：在真实项目上运行一个完整切片，记录每一步落在哪个部件、有没有出现无处归属的内容；无处归属的条目数是本决策的证伪信号。

<a id="d-047"></a>

## D-047 决策记录

**日期**：2026-09-02　**状态**：已接受（Alan）　**上游依据**：D-014、D-020、D-043

### 背景

第五轮架构裁决把 14 个部件定下来后，留下两块无处安放的内容：外部系统交接（9/52）与触发和入口（6/52）。两者都在统计断崖之下，但性质是场景相关——需要它们的场景把它们列为不可省略，不需要的场景里它们根本不出现。初评给出三个选项（A 保持边缘适配 / B 升为一等部件 / C 并入现有部件），三者都有不可避免的代价。

### 方法

不接受"放进哪个盒子"这个问法，先问三个选项的代价有没有共同来源。有：它们都默认这是**两个部件**。回到 §6.1 与 §6.2 列举的全部纪律逐条看它们在讲什么——读多写少、写限窗口、幂等、软降级、必需与推荐分档、判定器先于触发器——没有一条在讲"这个部件自己要做什么"，全部在讲"跨过这条边界时什么不许变"。部件回答"谁做"，约束回答"做的时候什么不许变"，两者形状不同；架构里已有安放后者的位置。

### 选择

不设部件。改为：

1. 一条可判定的"外部"判据：权威记录源不由本项目治理，或其上已发生的事不能单方面撤销，满足任一即为外部。
2. 第六条架构级不变量「边界外不由我们控制」，四条推论各自收紧一条已有规则（11 的记录源与派生缓存规则、30 三态与 32 证据字段、31 的豁免须带失效期、21 P3 与 40 的授权规则）。
3. 三处一行标注：11 的权威记录源、24 的工具、21 的一次运行起点。

同时澄清：不变量与平面接口是架构级内容，与 14 个部件并列，D-043 的"须归属某个部件"针对部件级内容，不约束这一类。这是澄清而非对 D-043 的修正——§5.3 原本就有五条不变量，第三类内容一直存在。

### 备选与不选的理由

| 选项 | 不选的理由 |
|---|---|
| A 保持边缘适配 | 纪律散在两节"待定"里，长期悬置；且没有回答"这算不算外部"这个前置问题 |
| B 升为一等部件 | 每个项目多两个必答问题，个人项目要写两次"不适用"；正文约增 110 行；与"简单且灵活"相悖 |
| C 并入现有部件 | 七条纪律并入后失去共同来源，在被并入的章节里显得突兀，且仍然无判据 |

### 风险与证伪信号

- 不变量比章节更容易被跳过。缓解：三章各有一句交叉引用，[00 总览](00-总览.md) §5 与诊断表各有一处，成长路径在 L2 点名。
- 判据第二条依赖"能否单方面撤销"的判断，边界情形需个案裁定；规则是判不清按外部处理。
- **证伪信号**：跨边界纪律在实际使用中反复被绕过（说明约束力不足以替代章节），或出现一条无法由判据与四条推论覆盖的跨边界纪律（说明这里确有部件级内容）。任一出现即回到选项 B。

### 验证方式

在走通第一个完整切片时（D-043 的验证方式）一并检验：切片中每一个跨系统的读与写，是否都能由判据判定内外、并被四条推论之一覆盖。


<a id="round7-anthropic"></a>

## 第七轮来源登记（2026-09-02）：Anthropic 创业公司指南

来源 `SRC-ANT-STARTUP`（V1，一手），卡片见[参考资料-Claude 01](参考资料-Claude/01-claude-code-startup-guide.md)。本轮不新增已接受规则，产出三条候选（D-044、D-045、D-046）与三处证据加强。

**证据加强（不新增决策，只提升既有语义的来源等级）：**

| 既有语义 | 原证据 | 本轮新增 |
|---|---|---|
| 判定器必须先于自动触发器就位 | 二手来源为主 | 一手直述"没有可靠的监控与验证手段就不能把流程自动化" |
| 守卫在模型控制流之外 | 二手来源为主 | 一手直述闸门"每次都执行，与模型的决定无关" |
| 评估集须定期更新 | 一手访谈（SRC-BORIS）的消融纪律 | 一手补上目的表述：评估集是为了防漂移并评估未来模型 |

**不采纳**：全部自报效果数字、全部产品机制名（按 D-020）、组织与产品化叙事。理由逐条见卡片 §7。


<a id="round8-slice"></a>

## 第八轮登记（2026-09-02）：首次切片演练

三个构造切片（维护期变更与回填 / 告警触发的定位与修复 / 停滞工作项的冷启动接手）各由一名独立 Agent 在"只能引用现有原则、不得发明新原则"的约束下逐步走查，共 81 步。记录见[审计记录 002](审计记录/002-切片演练.md)。

**对两条已接受规则的裁定：**

- **D-043 未被证伪。** 10 条无归属内容中 0 条需要新部件：8 条是现有部件缺一项最小职责或一句作用域，2 条是不变量缺方向。
- **D-047 裁决方向成立，四条推论不完备。** 其证伪信号第二条被三个切片各触发一次且三次同源——四条推论全部站在"我方是主动方"的位置，未建模"我方被外部消费"与"外部内容进来"。三名 Agent 独立判断修补仍是约束的形状而非部件的形状，故裁决保留、推论补齐（D-048）。另有一处真实损失：压缩"触发与入口"时丢掉了分流、去重、误报计数与退场（D-050）。

**产出**：候选 D-048～D-054，其中 D-051 与 D-052 是**收窄**现有原则的作用域而非新增，本轮对正文规模接近中性。

**最重要的单条发现**：规范为"从头开始"写得完备，为"从半路接上"没有留合法降级路径——而这正是本项目立项时要解决的问题（大型项目后期变慢、新会话一开始就臃肿）。见审计记录 §2。


## 记录规则

每个决策至少包含：背景、选择、备选项、取舍、状态、日期和验证方式。进入`试行`或`已接受`时还必须补充 `approved_by`、`approved_at`、`effective_scope`（含 blocks/grants 分栏）；试行项增加 `review_at` 与 `expiry`，并同步写入生效登记表。

当决策变化时不要删除旧记录。新增记录并标明"取代 D-xxx"，使后续维护者能理解变化路径。