walden

Walden

有意识地编写和审查；将工作流机制交给 CLI。使用用户偏好的语言回复。此技能提供判断，不会代替用户批准。

入口决策

创建功能或选择阶段之前，先检查请求、适用的项目规则和现有契约。存在 .walden/constitution.md 和相关的 .walden/lessons.md 时，阅读它们。如果存在已批准的 .walden/contracts.md，则从中开始探索：完整阅读其中认定为相关的功能，然后按需追溯其引用。不要仅仅因为用户提到了 Walden 就创建规范。

契约影响	路径
保留或恢复预期行为	不要开启新的规范编写流程，除非用户明确要求的范围或项目规则要求编写规范。运行现有测试并更新适用的 Walden 证据。
引入或更改预期行为	进入编写流程：新功能编写需求，现有规范则进入受影响的最早阶段。
不明确	在选择路径或创建推测性文档之前，针对预期行为提出一个有针对性的问题。

缺陷修复可以在不更改已批准契约的前提下恢复契约要求的行为。重构可以保留契约。无论哪种路径，都不能跳过测试、证据检查或执行授权。用户明确要求实施维护修复，即授权执行该工作；仅仅批准规划文档并不代表授权。

结束维护工作之前，确定适用的当前契约，运行现有测试，并在声明的检查点使用 walden verify <feature> 更新选定的受影响证据。只有在有充分理由进行强制检查时才使用 --all。检查 CLI 的结果；原始测试输出本身不会更新证据。如果没有规范涵盖此次变更，应说明这一限制，不要仅为获得一个勾选项而创建规范。

对于现有项目组合，在建议采用或重放之前，先在用户请求的范围内确认适用性：

建议的适用性	审查操作
当前	在选定的验证范围内保留必需行为。
已被取代	引用取代或移除该内容的决策及其后续方案；建议退役，不要自动执行。
部分适用	确定仍然有效的需求及其约定去向，然后再舍弃过时的设计／任务。
未解决	提出具体的业务／范围问题；不要凭空认定符合要求。

建议应以决策来源为依据。年代久远、缺少指纹和已完成的复选框都不能证明内容已过时。即使实施计划已过时，需求仍可能有效。当前需求并不意味着其历史上的引导／部署任务就是当前的回归检查：在建议重放之前，先检查实际证据。如果记录的是一次性交付工作，应提议审核所需的当前基线／回归契约，而不是仅仅因为 CLI 报告需要重新证明的数量，就自动补录并执行。代码描述的是观察到的行为，并非改写意图的依据；较新的草案不会自动取代已批准的契约。如果来源相互冲突，应先询问，再退役或更改契约。案例研究请求应提供针对被改进产品的一般性发现，而不是主动对示例仓库执行操作。

对于现有规范，使用 CLI 状态和验证结果，而不是猜测其时效性。对于新规范，使用 CLI 生成的脚手架作为规范文档模板。不要凭记忆重建完整模板。

CLI 前置条件

需要 Walden CLI v0.10.4 或更新的兼容版本。首次执行 CLI 操作前，检查 command -v walden 以及该可执行文件的 version --json。如果 PATH 中没有可用的兼容 CLI，也检查 $HOME/.local/bin/walden（Windows 上：Get-Command walden 和 %USERPROFILE%\go\bin\walden.exe）。通过已验证的路径或仅对当前会话生效的 PATH 修正来复用兼容的二进制文件；不要降级，也不要编辑持久化的 shell 配置。版本不明确时，不得假定其兼容。

如果 CLI 缺失或不兼容，请停止依赖 Walden 的操作。本指南绝不安装 CLI：不要运行安装程序、获取脚本或二进制文件，也不要编写供 Agent 执行的安装命令；安装应由用户在自己的终端中完成。确定平台（POSIX shell 上使用 uname -s；PowerShell、$env:OS、MSYS/MINGW 表示 Windows），并且运行 command -v go（PowerShell：Get-Command go），这样下面的分支是查找结果，而不是向用户提问。然后指出一条路径：

• go 可解析（任何平台）：将 go install github.com/andrearaponi/walden/cmd/[email protected] 作为单个命令块，然后确保 $(go env GOPATH)/bin（Windows：%USERPROFILE%\go\bin）位于 PATH 中。
• go 无法解析，macOS/Linux：打开 https://github.com/andrearaponi/walden — README 中有单行安装程序，releases 页面上有二进制文件。不提供命令块：你不能携带那行安装程序命令。
• go 无法解析，Windows：从 https://github.com/andrearaponi/walden/releases 下载 walden-v0.10.4-windows-<arch>.exe，将其重命名为 walden.exe 并放到 PATH 中。

如果用户随后仍要求你安装，只需再次说明你不会安装，并重复相同的单个指引或代码块——每条回复中恰好一个代码块，不得改用另一个分支，也不得获取脚本。不要第三次重复拒绝；不要获取任何内容。不要用手动工作流元数据替代缺失的 CLI。

本指南通过 Skills CLI 分发，CLI 二进制文件则单独分发；二者互不安装、检查或更新对方。使用 npx skills update walden 更新指南；使用 walden update 或 README 安装程序更新二进制文件。不要寻找用于安装、移除或报告指南的 Walden 命令：不存在这样的命令。

所有权与授权

• 在执行任何 Walden 操作前，先满足上述 CLI 前置条件。引导阶段的同意不代表批准规格、授权任务执行或允许发布；绝不要臆造替代状态机。
• 绝不要手动编辑工作流 frontmatter、时间戳、指纹、复选框或证据内容。编辑文档正文；状态变更使用 CLI。保留脚手架中已有的架构和扩展字段。
• 绝不要将沉默视为批准。展示相关文档，并等待明确批准后再执行 review approve。
• 规划止于已批准的任务。实施计划需要明确的执行请求；批准任务并不会自动触发实施。
• 豁免需要用户在当前对话中明确批准待处理的范围和理由。绝不要为了方便而提供 --allow-pending。
• 退役需要用户明确确认。不要把已被取代的规格或证据当作日常清理内容删除。
• 对于非简单请求，请说明简短计划及其验证步骤。如果约束冲突、证明失败或规格不充分，请停止并从最早受影响的阶段重新规划。
• 如果现有章程只包含占位内容，在编写前请用户提供稳定的项目背景。不要编造项目的技术栈或规则。
• 指纹绑定的是已批准的内容，并不代表语义正确。仍然需要良好的需求、有意义的证明和人工审查。

命令速查

操作机制请使用命令；语法详情请查阅 walden --help 和命令帮助。请阅读 JSON 结果和警告，不要只看表面上显示成功的摘要。

命令	使用时机
walden repo init	选择编写方式后，初始化尚未初始化的仓库。
walden feature init <feature>	创建三份规范文档；名称会规范化为 kebab-case。
walden status <feature>	检查阶段、新鲜度、阻塞项和下一步操作。
walden validate [<feature>] [--all]	验证当前阶段；--all 会检查完整规范。省略名称则检查整个项目集。
walden review open <feature> --phase <phase>	提交已就绪的文档供审阅，阶段可选 requirements、design 或 tasks。
walden review approve <feature> --phase <phase>	仅在用户明确批准后，确认该阶段。
walden reconcile <feature>	修复已批准链中发生变更的部分，然后重新审阅。
walden task status <feature>	检查可执行工作和证据警告。
walden task start <feature> [task-id]	在实施已授权的任务前，获取执行上下文。
walden task complete <feature> <task-id>	运行声明的验证，仅在成功时记录完成状态。
walden task complete-all <feature>	完成明确授权的可运行批次；遇到首个失败时停止。
walden evidence status <feature>	检查派生证据和环境差异；会执行诊断配置探测。
walden verify <feature>	重新验证证据不再有效的已完成任务。
walden verify <feature> --all	强制运行每个已完成任务的验证，包括当前已验证的任务。
walden verify <feature> --check	仅报告，不持久化账本；添加 --all 可强制验证所有已完成任务。
walden release check [<feature>] [--strict]	评估现有证据和发布阻塞项；绝不执行验证或发布。
walden adopt [<feature>] [--apply]	检查旧版绑定关系、新鲜度和来源，不执行验证或探测；--apply 会执行选定的验证，需要获得授权。
walden consolidate	只读报告：自上次整合以来的合约变更、审阅范围、确定性发现、每项变更与其关联陈述的比较，以及标识符。
walden consolidate start	开始跟踪整合；已批准的功能会成为待整合事项。
walden consolidate open	打开 .walden/contracts.md 供审阅；若其与规范不一致，或存在待处理变更但一致性审阅尚未完成，则拒绝打开。
walden consolidate approve	仅在用户明确批准后，确认已审阅的视图并记录检查点；若有涵盖的功能仍处于修订审阅中，则拒绝操作。
walden lesson log --feature <name> --phase <phase> --trigger "..." --lesson "..." --guardrail "..."	记录可复用的修正及其预防规则。阶段包括 execute 和 release。
walden version	检查二进制文件和架构版本。

命令支持 --json，包括失败时。封装对象包含 schema_version、command、ok 和 result；请检查警告和命令专属字段。不要重新实现该封装，也不要仅凭标准输出推断成功。

编写阶段

完成入口决策后，定位 .walden/specs/<feature>/。使用最早一个缺失、未获批准或已过时的阶段。新功能始终从需求阶段开始。现有工作只有在需求仍然有效且已获批准时才能进入设计阶段；只有在设计仍然有效且已获批准时才能进入任务阶段。

每个阶段都使用相同的评审流程：

1. 阅读上游内容和相关经验；起草或修订当前正文。
2. 验证当前阶段，并解决结构缺陷和重要警告。
3. 通过 CLI 发起评审，展示文档并征求批准。
4. 获得明确批准后，通过 CLI 封存该阶段，并且仅在用户要求的范围内继续。

不要因为一次含糊的确认就机械地批准多个阶段。如果实现过程中发现契约缺口，请暂停，修订最早受影响的文档，协调相关内容，并重新走完受影响的评审关卡。

决策检查点协议

在需求、设计和任务起草期间应用，不适用于执行阶段。

• 分岔测试： 只有当不同选择会丢弃或大幅改写下游内容时，才设置检查点。如果无法确定，默认自主解决。
• 先探索再询问： 检查代码库、章程和已批准的上游文档。如果它们能解决这一选择，记录 `` 并继续。
• 检查点： 插入 [decision: <question>]，说明分歧，推荐一个选项并用一句话说明理由，然后停止生成依赖该选择的内容。如果没有哪个选项能更站得住脚，不要凭空编造偏好。
• 恢复： 继续之前，说明将如何应用用户的回答。新发现的重要分歧应单独设置检查点，并在编写依赖内容之前解决。
• 自主权： 如果用户将检查点决策交由你处理，记录 ``，并在该授权范围内继续，不再设置其他检查点。
• 数量限制： 每个阶段的起草过程中最多设置五个检查点。未解决的检查点保留在草稿中；只要仍有未解决的检查点，就不要发起阶段评审。
• 常规假设： 在文中记录 ``，不要打断用户。

要求

一旦意图足够明确，可以选择编写需求，就先起草，再迭代。用户故事用于说明背景；验收标准是约定。

• 为需求分配稳定 ID（R1），为标准分配稳定 ID（R1.AC1），为质量属性分配 NFR1，为约束分配 C1。不要重新编号其他地方已引用的 ID。
• 使用 EARS 为每条 AC 编写一个可观察的响应。CLI 会验证关键词结构，而不是行为的质量或完整性。
• 当范围风险较高时，明确列出范围外事项。不要仅因为 AC 数量超过阈值就自动拆分功能；应重新评估内聚性和范围。
• 在每条 AC 下方附上一条简短的 Acceptance check: 补充说明。描述区分成功与失败的观察结果，而不是选定的框架或实现命令。如果无法陈述该观察结果，请先澄清或重写标准，再请求批准。

每次修订后（包括恢复原始 AC 文案时），都要检查所有已展示的标准，并保留或重新附上其验收检查。适当时，保持所请求的 EARS 句子不变；单独的检查补充说明是解释性内容，不是新的行为要求。

EARS 形式	结构
普遍适用	The system SHALL <response>
事件驱动	WHEN <event>, the system SHALL <response>
状态驱动	WHILE <state>, the system SHALL <response>
可选功能	WHERE <feature>, the system SHALL <response>
非预期行为	IF <undesired condition>, THEN the system SHALL <response>
复合形式	WHILE <state>, WHEN <event>, the system SHALL <response>

起草期间的质量检查：

• 形式： 不变量无需虚构用户触发条件。对于始终适用的唯一性规则，优先使用“The system SHALL assign distinct identifiers”，而不是“WHEN the user starts, ...”。
• 原子性： 将“生成记录并发送通知”拆分为可独立观察的标准。起草下一条之前，先检查每个响应；仅凭“and”一词，不能证明存在两种行为。
• 具体事件： 优先使用“WHEN an OrderCreated message arrives”或“WHEN a lease expires”，而不是“WHEN processing happens”。API 和后台事件与点击或提交一样有效。
• 失败覆盖： 对每种现实中可能出现的约束失败，明确所需响应。存储要求需要涵盖读取、写入及相关失败行为，而不只是成功保存。
• NFR 提升： “IF the connection fails, THEN ... reconnect”属于行为，应放在 AC 中；同时将弹性属性保留为 NFR。
• NFR 衔接： 将每个 NFR 与可测试的 AC 联系起来。“无障碍”需要具体的键盘／屏幕阅读器结果；资源限制可能需要内部测量，而不是虚构 UI 交互。对于含糊的质量要求，应主动询问。

最小化标准示例，不是文档模板：

1. `R1.AC1` WHEN a lease expires, the system SHALL release its lock.
   - Acceptance check: another holder can acquire a lock after its lease expires.

从 walden validate --json 读取 ears_validation、ears_distribution 和警告。检查形式是否恰当、响应是否原子化、事件是否具体、现实失败场景、NFR 衔接、持久化要求是否平衡，以及领域特定的缺漏。数量用于诊断，而非配额；不包含非预期形式可能意味着缺少失败处理。在进入 Design 前，使用常规审查循环。

设计

阅读已批准的需求。仅在决策取决于外部事实时进行调研。使用 CLI 生成的设计脚手架，不要插入标准的冗长架构文档。

当前内核要求恰好包含以下六个标题：

• 架构
• 已考虑的选项
• 简洁性与优雅性审查
• 故障模式与权衡
• 验证计划
• 需求覆盖

其他部分——组件/接口、数据模型、错误处理、安全性、测试策略、图表——可根据相关决策、契约或验证需求酌情扩展。不要为了显示工作全面而添加空章节。

与一个真实可行的替代方案进行比较。如果没有有意义的替代方案或相关讨论，给出一句理由，而不要凭空制造复杂性。需求覆盖和验证计划仍需提供实质性的映射和检查；不能以不适用为由省略它们。

对初稿进行一次质疑：是否能用更简单的结构或更低的耦合满足相同契约？记录真实的故障模式和已接受的权衡。在覆盖表中，所有需求/NFR ID 都必须用反引号括起来：验证器要求使用如下行：| `R1` | ... |。

如果设计揭示了新的范围或缺失的验收行为，请返回需求阶段。否则进行验证，并在进入任务阶段前使用评审循环。

任务

阅读已批准的需求和设计。保持工作增量化且可测试，最多两层层级。每个可执行叶子任务都要注明其 AC ID、设计引用和验证步骤。使用规范脚手架和下方的最简语法，不要复制完整计划。

- [ ] 1. Implement and test the behavior
  - Requirements: `R1.AC1`
  - Design: Architecture
  - Verification:
    - command: ["go", "test", "-v", "-count=1", "-run", "^TestExample$", "./pkg/example"]
      expect_output: "--- PASS: TestExample"
      covers: ["R1.AC1"]

顶层叶子任务的元数据缩进两个空格；子任务缩进两个空格，元数据缩进四个空格。证明步骤比 Verification: 再多缩进两个空格，属性比其命令再多缩进两个空格。

将证明分配给合理的验收标准组，不要对每个复选框都运行同一套宽泛测试套件。已经通过的测试套件不能证明新引入的行为：每个实现叶子任务都必须包含相应的新断言，才能标记为完成。不要将这些测试推迟到后续叶子任务，同时又通过未更改的旧 PASS 标记宣称新的 AC 已得到满足。应使用直接断言，或使用新的、特定于测试的选择器/标记，以确保在预期检查尚未存在时无法通过。断言 AC 的证明步骤必须在 covers: 中注明这些 AC。如果任务排序暴露了缺失的接口或无法测试的步骤，请返回设计阶段。完成验证并请求批准任务计划；然后停止，除非明确要求同时执行。

证明编写

在提交任务计划前：

1. **实际断言：**每个步骤都有明确的通过条件；只有当命令确实断言了预期属性时，退出码为零才有意义。
2. **非空验证：**防止在没有运行任何预期测试的情况下通过。使用原生的无测试即失败行为、结构化测试结果，或适当的输出断言。Go 的 -run 即使没有匹配到任何测试也可能成功：请使用带锚点的选择器、-v、-count=1，以及上文所示的指定 PASS 输出。
3. **只读复验：**断言不得更改工作树。优先使用 go mod tidy -diff，而不是 go mod tidy；将构建器或生成器的输出写到仓库之外。不得通过证明来“修复”缺失文件或失败的断言。
4. **有界执行：**每个步骤的默认超时时间为 10 分钟。若有理由使用其他时限，请声明一个正数 timeout:，例如 timeout: 30m。超时即判定步骤失败。
5. 声明覆盖范围：covers: 填写已知且经过断言的 AC ID，不代表承诺命令在语义上足够。请分别检查任务引用和证明引用的覆盖范围。
6. **可复现条件：**使用已知输入和相关环境探测。不得通过弱化已批准的证明来掩饰环境故障。

命令使用 JSON argv 数组，不会隐式按 shell 语法解释。管道、重定向和运算符需要显式调用 shell，例如：command: ["sh", "-c", "test -d src && test -f src/main.go"]。对于真正的否定断言，请使用 expect_exit: 1。expect_output 匹配合并输出中的子字符串，而非正则表达式。多步骤证明会在首次失败时停止。

旧的单行格式 Verification: go test ./... 无法表达引号、shell 运算符或属性；新工作请使用结构化步骤。未经授权的修订和重新审核周期，不得改造已批准的证明。

执行与恢复

对于已明确授权的任务或批次：

1. 阅读三份已批准的文档。使用 task status 和 task start 检查就绪状态并了解上下文；绝不实施未经批准或已过期的计划。
2. 声明已授权的批次范围及其验证检查点，然后通过有针对性的测试进行实施。除非用户要求或批准的验证计划中包含完整测试套件，否则不要运行完整测试套件。如果未确定任务或批次，先确定下一个任务并在实施前询问。
3. 通过 task complete 完成任务，不要手动勾选。CLI 会执行证明并记录证据，然后更新完成状态。先完成子项，再完成容器项。
4. 仅在提交已获授权且项目政策允许时，才随工作一并提交证据。此技能不授予提交、创建 PR、打标签或发布的权限。
5. 检查证据警告，但普通的全仓库代码过期提示并不意味着每次编辑后都要重跑所有已完成的前置步骤。对于依赖项已更改、证明失败或契约缺口，应提前执行有针对性的检查；否则，在声明的批次、功能或交付检查点汇总重新验证。每个叶子项仍须通过各自的完成证明。在中途暂停时，应明确记录批次和剩余的过期项；在关闭任务时，先完成代码、README 和其他交付项，再进行最终的限定范围验证，然后检查发布结论并报告任何延期的缺口。

TDD 描述的是开发顺序，而不是证明通过。要求使用 TDD 时，必须先观察到可运行的行为断言失败，再实现该行为；最精简的可编译脚手架可以先行。编译或导入失败以及标记为 PASS 的输出，都不能证明顺序符合要求。如果代码已经存在，应如实说明之后补充的测试或测试驱动的修复。不要为了事后制造 TDD 而破坏并还原现有代码；突变测试应单独标注。

编辑文档正文会破坏其审批封印。reconcile 会重置受影响的审批状态；应再次审核变更链。重新批准相同内容不会导致下游内容过期。缺少旧版指纹时，应采用或协调处理，而不是手写封印。

完成流程可以合理地运行生成器，并记录生成后的树。重新验证则不同：其证明是只读的。verify --check 可阻止账本写入，但不能阻止命令产生副作用。检测到变更或缺少必需的身份信息，会使本次运行受到污染：即使字节已恢复，之后的执行也无法获得已验证证据。请调查指出的原因；获得授权并修复证明或重新审核后，对受影响范围执行一次全新的干净验证。绝不要自动回滚用户源代码。

证据状态是派生状态：verified、stale-spec、stale-code、failed、unattested、unrecorded 和 pending。应分别检查绑定关系、代码新鲜度和执行完整性来源，包括被状态优先级掩盖的缺口。unattested 表示缺少必需的保证，并不表示新发现了代码故障。记录为 passed 并不足以证明当前验证通过。有意变更契约时，需要完成受影响的审核周期并提供新证明；仅涉及代码的维护则不必创建新规范。仅提交未变更的字节本身不会使代码证据过期；应依据 CLI 报告的差异判断，不要猜测原因。

环境上下文

可选的 .walden/environment.md 探针使用 argv，例如 - go: ["go", "version"] 和 - node: ["node", "--version"]。名称采用小写 kebab-case；platform 和 walden 是保留的配置键。所有探针共用 30 秒预算。声明格式错误会导致生成证据的命令失败；探针失败或超时则会生成诊断标记值。

配置文件仅用于诊断，不是状态门槛，也不能证明生产者策略。归咎于代码之前，应先比较环境差异；切勿通过放宽断言来掩盖版本不匹配。如果请求禁止执行环境探针，请使用只读的 adopt <feature> 评估，而不是 evidence status。

采用与退役

adopt 评估的是现有 Walden 规范，而不是将任意代码库转化为规范。确立当前契约后，应展示其不执行操作的计划：backfill、re-prove、complete 或 blocked 属于技术分类，并不代表业务适用性。恢复出的绑定不能证明以往执行过程的纯粹性。complete 表示无需采用任何内容，并不意味着所有产品工作都已实现。升级或检查都不会自动重放整个项目组合。

Backfill 会信任已记录的批准并封存当前主体；应说明无法检测指纹记录前期间隔内发生的编辑。当前存在的矛盾需要人工协调。Apply 会运行实际证明：仅针对已审查的范围提出请求，并保留功能选择器。新的 v1alpha2 台账可能包含未触碰的旧版记录；应使用兼容的 CLI，切勿为了满足旧版读取器而删除或降级证据。

如果可用，应将采用评估中的工作量视为已声明的步骤，而非测试或预计完成时间：不可用的功能与已知为零的功能不同，计数也不构成执行授权。Apply 后，应保留每项任务的诊断信息，并分别读取已接受的执行结果（passed）、最终状态和完整性。evidence_persisted: false 表示观察到的结果未保存；如果功能在任何尝试之前就出错，则不会生成任务结果。elapsed_ms 衡量的是当前尝试或包含它的功能／调用所用时间，而非历史耗时。在较旧的兼容 CLI 中，这些字段可能不存在；缺失不等于零。应保护重定向的诊断信息，其中可能包含命令输出；Walden 不会自动添加日志或计时历史。在提出诊断重放之前，先检查可用的失败原因。

退役需要明确确认。删除之前，应确认 Git 会在可恢复的最近一次存续提交中保留每个规范／证据文件，明确退役原因和后继项，并就任何仍然有效的需求应归属何处达成一致。历史记录缺失或混合契约尚未解决时，必须停止，而不是伪造恢复记录或创建未经授权的提交。不得将不保留历史的删除说成等同于 Walden 退役，或视为免除其恢复前提。之后，仅删除获准删除的文件，并在 .walden/RETIRED.md 中记录名称、日期、原因、最近存续提交和后继项。可选的 walden-history 配套工具可以提供帮助，但并非必需；退役本身不构成提交或发布的授权。

整合

通过小步操作保持项目组合的一致性，而不是等写完几十份规范后再进行审查。status 会在建议或到期整合时发出警告：自上次整合以来，已批准的需求发生了变化，涉及两份或三份规范。feature init 和 release check 会重复显示到期警告，但不会阻止操作。如果已安装的 CLI 中没有 walden consolidate --help，请跳过本节。

在收到建议或到期警告时，或用户提出要求时，运行 walden consolidate。阅读 .walden/contracts.md，并且只阅读报告范围内的功能；对于仅通过广泛引用的文件关联的功能，通常只需查看其视图条目。然后，将报告比较项中每条新增、变更或删除的陈述，与报告在旁边显示的关联陈述逐一比较：报告每一处矛盾、重复规则，或对已删除或已变更陈述的依赖，并列出双方的限定标识符。在此过程中需要检查的材料就是这些比较项，因此无需通读无关规范。在 .walden/contracts.md 的 ## Coherence Review 下记录结果：每个待处理功能对应一个 ### <feature> 条目，列出发现的不一致；如无则注明没有，并用行内代码 feature#ID 引用比较过的关联陈述。如果条目缺失、为空或未引用任何关联陈述，CLI 会拒绝打开或批准视图。查找重叠、矛盾、其他位置仍在引用的已删除内容，以及过时的义务，并为每项列出限定标识符。确定性检查的结果只是线索，不是结论。

将每项修复作为对受影响规范的修订，通过其常规审核流程提出。整合不授权任何其他工作：不得在整合过程中批准、退役或执行任何事项。然后更新范围内各功能的视图：Purpose:（用一行说明该功能目前保证什么）、Active:（报告列出的标识符）、Reserved:（已删除的标识符；保留的标识符须永久列出）、Sources: 和 Related:。运行 walden consolidate open，展示视图，并且只有在用户明确批准后才运行 walden consolidate approve。如果 status 报告视图已过时，请重新审查并再次运行 walden consolidate open。记录和审核状态由 CLI 管理：不得手动编辑 .walden/consolidation.json 或视图的 frontmatter。

在已有项目组合中，walden consolidate start 会将今天已批准的规范记录为尚未整合的待办项。仅在用户提出要求时，才分批小规模整合待办功能，绝不要一次性全部整合。

发布判断

用户询问是否可以发布或进行交付交接时，请使用 release check；不要根据单独的状态摘要自行推断结论。该命令会评估现有状态，不会发布。请另外使用 verify 生成证据。

默认情况下，待处理工作会阻止发布。用户批准的部分交付可以使用 --allow-pending --reason "..."；此选项不会豁免缺失的旧版保证或严格输入绑定。--strict 会将实际评估的规范／证据字节及其存在状态与一次捕获的提交进行比较，即使文件被忽略也不例外。非严格模式的输出不会声称本地元数据已提交。未提交的代码没有绕过机制，且必须能够使用 git。

准确报告范围、保证、阻碍项、完成类别、提交和豁免。选定功能的通过结果不是整个仓库的认证。未分类／未评估的功能不能从整个项目组合的结论中消失；要排除功能，必须明确选择范围或经过授权将其退役。不要将参考覆盖率或已存储的通过结果等同于形式化正确性。

经验教训与摘要

开展类似工作前，请先查阅相关经验教训。用户更正、草稿被拒、验证失败、重新规划或意外执行失败，都应触发一项内部判断：是否有可复用的经验教训。对于有意义的模式，请使用 walden lesson log 记录触发原因、经验教训和可防止问题重演的防护措施。不要把普通且符合预期的 TDD 红灯测试列成虚构错误清单。

准确描述观察到的触发原因。如果用户最初要求 A+B，后来只保留 A，请记录“范围从 A+B 缩小到 A”，而不是“Agent 擅自添加了 B”。如果两种行为原本各自对应单独的 AC，就不要声称它们共用一个 AC。经验教训应保留事实和有用的防护措施，而不是虚构错误。引用或近似转述实际且不敏感的范围澄清内容来描述触发原因：“请求”不等于“批准”。用户可能会要求制定预防性经验教训，而实际上并未发生任何错误；应将其标记为预防性，而不是编造一段失败经过。

新记录的经验教训应附上简短的用户可见条目，并说明实用的防护措施。如果没有新经验教训，则完全省略经验教训状态输出；但仍须进行内部判断。

摘要应说明发生了哪些变更、实际检查了哪些内容、尚未解决的阻碍，以及接下来需要用户作出的决定。区分计划执行、已执行、执行失败和未运行的检查。保持简洁，不要混淆对当前阶段的批准与对后续阶段或发布的许可。