@wnlen/agent-execution-template 0.8.16 → 0.8.18

package/template/en/ai/template/protocol.md

@@ -49,71 +49,16 @@ Project Bootstrap / Context Reconcile / Strategy Update -> Project Confirm -> Ta
 
 ## Execution Authorization Modes
 
-The default execution policy is `auto`: before each execution, the AI first
-decomposes the task and judges risk, then chooses `normal` or
-`bounded_continuous`. Continuous execution does not depend on a human keyword.
-
-Pre-execution planning must:
-
-- Infer goal, scope, acceptance, permissions, and verification method from the
-  human goal, project context, and repository facts.
-- List the L1 task checklist and assign Green / Yellow / Red risk to each L1.
-- Use `normal` if there are fewer than 2 L1 tasks.
-- Automatically use `bounded_continuous` if there are 2 or more L1 tasks.
-- Stop for human confirmation first if any L1 is Red; Green and Yellow do not
-  block startup.
-
-Bounded continuous execution rules:
-
-- Execute the task tree in L1 -> L2 -> L3 order. Before executing an L1, plan
-  its naturally derived L2 tasks; before executing an L2, plan L3 tasks if it
-  still needs decomposition.
-- Default to at most 3 levels. Add L4 dynamically only when L3 would otherwise
-  be too large, unverifiable, or hard to revert.
-- Every L1/L2/L3/L4 node must have risk, expected edit scope, acceptance method,
-  and evidence requirements.
-- Show the L1 checklist as task items; when an L1 is complete, check it off and
-  strike it through.
-- Default to `vertical_slice` progress: each loop should produce a runnable,
-  reviewable, or reversible increment.
-- The AI infers goal, scope, acceptance, and permissions, but must not cross
-  project rules, explicit human limits, `permission.modify.denied`, security
-  boundaries, or destructive-action limits.
-- `Green` may continue automatically.
-- `Yellow` may continue after local low-risk correction.
-- `Red` must stop for human confirmation.
-- If permission must expand, an unallowed command must run, network access is
-  needed, a destructive action is needed, or product direction / core
-  architecture would change, the current node must be Red.
-- After all work is complete, run one final review; re-check only Yellow, Red,
-  failed verification, or high-impact modules.
-- Every checkpoint must include evidence; a purely subjective Green is not valid.
-- Continuous execution does not change model policy; still escalate through
-  `model_policy` for planning, architecture, failure review, or acceptance disputes.
-
-Must stop when:
-
-- The task would change product direction, core architecture, data structures,
-  security boundaries, payment, accounts, or permissions.
-- The task would delete many files or rewrite a core module.
-- The task outline, acceptance, or permission contains a material conflict.
-- The current implementation affects multiple later modules and the task
-  contract does not cover that impact.
-- Tests fail and cannot be fixed locally.
-- There are two or more high-cost options that need human judgment.
-
-Use this compact checkpoint format:
+Before task execution, read `ai/template/execution-policy.md`.
 
-```text
-## Checkpoint
-### Task Tree
-### Progress
-### Completed
-### Evidence
-### Drift Risk: Green / Yellow / Red
-### Recommended Next Step
-### Auto-Continue Decision
-```
+The default execution policy is `auto`: the AI first decomposes L1 tasks and
+judges Green / Yellow / Red risk, then chooses `normal` or `bounded_continuous`.
+Use `normal` when there are fewer than 2 L1 tasks; automatically use
+`bounded_continuous` when there are 2 or more L1 tasks. Only Red stops for
+human confirmation.
+
+Task tree, risk rubric, checkpoint evidence, and `task_tree` status update
+rules are defined in `ai/template/execution-policy.md`.
 
 ## Bootstrap Mode
 

package/template/en/ai/template/rules/core.md

@@ -119,33 +119,16 @@ or dependency files unless the human explicitly authorizes it.
 
 ## Bounded Continuous Execution Gate
 
-Before every execution, the AI must decompose the task and judge risk instead
-of waiting for the human to explicitly say "enable continuous execution".
-
-Before execution:
-
-- Infer goal, scope, acceptance, permissions, and verification method from the
-  human goal, project context, and repository facts.
-- List the L1 task checklist and mark each L1 Green / Yellow / Red.
-- Use `normal` when there are fewer than 2 L1 tasks; automatically use
-  `bounded_continuous` when there are 2 or more L1 tasks.
-- Stop for human confirmation if any L1 is Red; Green and Yellow may continue.
-
-When enabled:
-
-- Execute in L1 -> L2 -> L3 order; plan L2 before executing an L1, and plan L3
-  as needed before executing an L2.
-- Default to at most 3 levels; add L4 dynamically only when L3 is still too
-  large, unverifiable, or hard to revert.
-- Show the L1 checklist as task items; when an L1 is complete, check it off and
-  strike it through.
-- Every task node must have risk, expected edit scope, acceptance method, and
-  evidence requirements.
-- The checkpoint budget is a maximum, not a required count.
-- Every checkpoint must include evidence.
-- `Green` may continue automatically.
-- `Yellow` continues after local low-risk correction.
-- `Red` must stop for human confirmation.
+Before every execution, the AI must read `ai/template/execution-policy.md`,
+decompose the task, and judge risk instead of waiting for the human to
+explicitly say "enable continuous execution".
+
+Hard gates:
+
+- `execution_policy.task_tree` must record the L1 checklist and execution state.
+- Every task node must have Green / Yellow / Red risk.
+- Every checkpoint must include evidence; a purely subjective Green is not valid.
+- Red must stop for human confirmation.
 - Any product direction, core architecture, data structure, security, payment,
   account, permission, large deletion, core rewrite, or high-cost option choice
   must stop.

package/template/zh/ai/README.md

@@ -11,6 +11,7 @@ project 是现场工作区
 
 - `template/prompt.md`：AI 启动提示。
 - `template/bootstrap.md`：项目发现和上下文引导提示。
+- `template/execution-policy.md`：自动连续执行、任务树、风险分级和 Checkpoint 规则。
 - `template/reconcile.md`：把新的权威资料合并进现有项目上下文。
 - `template/VERSION`：已安装模板版本。
 - `template/protocol.md`：引导流程、执行流程、模型分工、同步规则。
@@ -111,22 +112,5 @@ ai/project/inbox/ideas/
 - 只回流 `ai/template/**`。
 - 永远不要回流 `ai/project/**`。
 
-## 引导规则
-
-- 人类提供意图、硬约束和最终验收。
-- Agent 从现有文档、清单、引用和项目文件中起草 `project/project.md` 和相关 `project/refs/*`。
-- 人类提供当前任务目标后，Agent 起草 `project/task.md`。
-- 人类在执行前检查并确认项目和任务草稿。
-- 引导只能写项目上下文文件；当提供当前任务时，也可以写 `project/task.md`。
-- 引导不得编辑源码、测试、配置、依赖文件、生成文件、运行时文件、结果文件或指标文件。
-- 最多问 3 个澄清问题。
-- 只在答案会改变范围、风险、权限或验收时提问。
-- 重复出现的假设应变成 `project/runtime.md` 更新建议。
-
-## 模型分工协议
-
-- 模型策略位于 `project/task.md.model_policy`。
-- 常规执行默认使用 `cheap`。
-- 中等实现复杂度使用 `standard`。
-- 只有规划、风险判断、架构复核、失败复盘或验收判断才使用 `strong`。
-- 在 `project/metrics.json` 中记录实际档位、触发条件、角色和升级原因。
+详细执行规则见 `template/protocol.md`、`template/bootstrap.md`、
+`template/execution-policy.md` 和 `template/rules/`。

package/template/zh/ai/project/task.md

@@ -3,6 +3,7 @@ task_id: ""
 type: "bugfix | feature | refactor | docs | config | test | research | strategy_update | apply_strategy_update"
 priority: "P0 | P1 | P2 | P3"
 risk_level: "low | medium | high"
+readiness: "draft_for_confirmation | ready_to_execute | blocked"
 depends_on_previous_result: false
 execution_policy:
   mode: "auto | normal | bounded_continuous"
@@ -10,7 +11,17 @@ execution_policy:
   max_depth: 3
   allow_depth_4_when_needed: true
   progress_unit: "vertical_slice"
-  task_tree: []
+  task_tree:
+    - id: "L1-1"
+      title: ""
+      risk: "Green | Yellow | Red"
+      status: "pending | running | done | blocked"
+      scope:
+        allowed: []
+        denied: []
+      acceptance: []
+      evidence: []
+      children: []
   checkpoint_budget:
     l1: 0
     l2: 0
@@ -69,7 +80,9 @@ permission:
 这个文件是当前执行契约。优先在引导模式中，根据简短人类目标和仓库上下文生成，
 然后由人类在执行前检查。
 
-优先使用安全假设，少问额外问题；但不要猜测范围、风险、权限或验收。
+优先使用安全假设，少问额外问题。AI 应基于用户目标、项目上下文和仓库事实推断
+范围、风险、权限和验收；如果推断会越过权限、安全边界或验收无法定义，将
+`readiness` 标为 `blocked` 或将相关任务节点标为 `Red`，等待人类确认。
 
 ## 目标
 
@@ -116,6 +129,10 @@ permission:
 
 - 目标、范围、验收、权限和风险评级由 AI 基于用户目标、项目上下文和仓库事实推断；
   不要求用户预先逐项提供。
+- `readiness = ready_to_execute` 表示没有 Red 预检项，可以执行。
+- `readiness = draft_for_confirmation` 表示需要人类确认后才能执行。
+- `readiness = blocked` 表示当前任务不可执行，必须写 blocked 结果。
+- 执行前必须把 L1 任务清单写入 `execution_policy.task_tree`。
 - 执行前必须列出 L1 任务清单；每个 L1 用待办列表表示，完成后打勾并划掉。
 - 执行某个 L1 前，AI 先规划自然衍生出的 L2；如果 L2 仍需拆分，再规划 L3。
 - 默认最多 3 层；只有当不拆 L4 会导致 L3 过大或不可验证时，才允许动态增加 L4。
@@ -125,6 +142,7 @@ permission:
 - `checkpoint_budget` 是最多可用检查点预算，不是必须用完的次数；不要为了消耗预算而汇报。
 - 只有在触发 `checkpoint_triggers`、风险升高或准备收尾时才输出 Checkpoint。
 - 每个 Checkpoint 必须包含证据：已改文件、已运行命令、验证结果或无法验证的原因。
+- 执行中必须更新 `task_tree` 节点状态：`pending`、`running`、`done` 或 `blocked`。
 - 完成后只做一次总复盘；只对 Yellow、Red、失败验证或高影响模块做二次抽检。
 - 连续执行不改变模型策略；涉及判断、架构、失败复盘或验收争议时仍按 `model_policy` 升级。
 

package/template/zh/ai/template/VERSION

@@ -1 +1 @@
-0.8.16
+0.8.18

package/template/zh/ai/template/execution-policy.md

@@ -0,0 +1,95 @@
+# 执行策略
+
+不要总结这个文件。
+任务执行时按本文件选择 `normal` 或 `bounded_continuous`。
+
+## 默认策略
+
+默认执行策略是 `auto`：AI 在每次执行前先做任务分解和风险判断，再决定使用
+`normal` 还是 `bounded_continuous`。启用连续执行不依赖用户说出特定口令。
+
+执行前规划必须：
+
+- 根据用户目标、项目上下文和仓库事实，推断目标、范围、验收、权限和验证方式。
+- 列出 L1 任务清单，并为每个 L1 生成 Green / Yellow / Red 风险评级。
+- 如果 L1 少于 2 个，使用 `normal`。
+- 如果 L1 为 2 个或更多，自动启用 `bounded_continuous`。
+- 如果任一 L1 为 Red，先停止并让人类确认；Green 和 Yellow 不阻塞启动。
+- 将任务树写入 `ai/project/task.md` 的 `execution_policy.task_tree`。
+
+## 任务树
+
+任务树按 L1 -> L2 -> L3 执行。
+
+- 执行某个 L1 前，先规划它自然衍生出的 L2。
+- 执行某个 L2 前，如果仍需拆分，再规划 L3。
+- 默认最多 3 层。只有当 L3 仍过大、不可验证或不可回退时，才动态增加 L4。
+- L1/L2/L3/L4 都必须有风险评级、预期改动范围、验收方式和证据要求。
+- L1 清单必须用待办列表展示；每完成一个 L1，就打勾并划掉。
+- 执行中必须更新 `task_tree` 节点状态：`pending`、`running`、`done` 或 `blocked`。
+
+推荐节点结构：
+
+```yaml
+id: "L1-1"
+title: ""
+risk: "Green | Yellow | Red"
+status: "pending | running | done | blocked"
+scope:
+  allowed: []
+  denied: []
+acceptance: []
+evidence: []
+children: []
+```
+
+## 风险分级
+
+Green：
+
+- 在当前任务范围内；
+- 不需要新增权限、命令、网络或破坏性操作；
+- 验收方式明确；
+- 不改变产品方向、核心架构、数据结构、安全边界、支付、账号或权限。
+
+Yellow：
+
+- 仍在当前任务范围内；
+- 存在局部不确定或局部验证失败；
+- 可以用低风险修正继续；
+- 不需要扩大权限、范围、命令或验收。
+
+Red：
+
+- 需要扩大权限、运行未允许命令、访问网络或执行破坏性操作；
+- 需要改变产品方向、核心架构、数据结构、安全边界、支付、账号或权限；
+- 需要删除大量文件、重写核心模块或在多个高成本方案之间取舍；
+- 验收不可定义，或任务目标和项目方向发生实质冲突。
+
+只有 Red 停止等待人类确认。Green 自动继续。Yellow 做局部低风险修正后继续。
+
+## Checkpoint
+
+Checkpoint 只在风险升高、边界即将变化、完成垂直切片或准备收尾时输出。
+不要为了消耗预算而汇报。
+
+每个 Checkpoint 必须包含：
+
+```text
+## Checkpoint
+### 任务树
+### 当前完成度
+### 已完成
+### 证据
+### 偏离风险：Green / Yellow / Red
+### 下一步建议
+### 是否自动继续
+```
+
+证据必须包含已改文件、已运行命令、验证结果，或无法验证的原因。
+不接受只有主观判断的 Green。
+
+## 模型策略
+
+连续执行不改变 `model_policy`。遇到规划、架构、失败复盘或验收争议，
+仍按 `model_policy` 升级，并在 `ai/project/metrics.json` 中记录原因。

package/template/zh/ai/template/prompt.md

@@ -9,6 +9,7 @@
 
 1. `ai/template/protocol.md`
 2. `ai/template/rules/core.md`
+3. `ai/template/execution-policy.md`
 
 然后选择模式：
 
@@ -51,11 +52,14 @@
 2. 根据用户当前目标、项目上下文和仓库事实，推断目标、范围、验收、权限、
    验证方式和初始风险；不要要求用户逐项提供。
 3. 起草 `ai/project/task.md`，并将 `execution_policy.mode` 设为 `auto`。
-4. 执行前列出 L1 任务清单并标注 Green / Yellow / Red。L1 少于 2 个时使用
-   `normal`；L1 为 2 个或更多时自动使用 `bounded_continuous`。
-5. 只有出现 Red 预检项时才停止等待人类确认。若用户要求的是执行或继续，且预检
+4. 执行前列出 L1 任务清单并标注 Green / Yellow / Red，同时写入
+   `execution_policy.task_tree`。L1 少于 2 个时使用 `normal`；L1 为 2 个或更多时
+   自动使用 `bounded_continuous`。
+5. 如果没有 Red 预检项，将 `readiness` 设为 `ready_to_execute`；如果需要人类确认，
+   设为 `draft_for_confirmation`；如果不可执行，设为 `blocked`。
+6. 只有出现 Red 预检项时才停止等待人类确认。若用户要求的是执行或继续，且预检
    只有 Green / Yellow，可以直接进入执行模式。
-6. 不要在任务草稿模式中修改源码或业务文件。
+7. 不要在任务草稿模式中修改源码或业务文件。
 
 任务草稿模式必须以下面结构结束：
 
@@ -104,10 +108,11 @@
 2. `ai/project/runtime.md`
 3. `ai/project/task.md`
 
-然后先做执行前规划：列出 L1 清单，给每个 L1 标注 Green / Yellow / Red，
-并根据 L1 数量自动选择 `normal` 或 `bounded_continuous`。执行 L1 前规划 L2，
-执行 L2 前按需规划 L3；默认最多 3 层，必要时允许 L4。每完成一个 L1，
-在清单中打勾并划掉。只有 Red 停止等待人类确认；Green 自动继续，Yellow 做局部
+然后按 `ai/template/execution-policy.md` 做执行前规划：列出 L1 清单，给每个 L1
+标注 Green / Yellow / Red，并写入 `execution_policy.task_tree`。根据 L1 数量自动选择
+`normal` 或 `bounded_continuous`。执行 L1 前规划 L2，执行 L2 前按需规划 L3；
+默认最多 3 层，必要时允许 L4。每完成一个 L1，在清单中打勾并划掉，并更新
+`task_tree` 节点状态。只有 Red 停止等待人类确认；Green 自动继续，Yellow 做局部
 低风险修正后继续。最后把结果写入：
 
 - `ai/project/result.json`

package/template/zh/ai/template/protocol.md

@@ -43,57 +43,14 @@ ai/project/task.md             = 当前执行契约
 
 ## 执行授权模式
 
-默认执行策略是 `auto`：AI 在每次执行前先做任务分解和风险判断，再决定使用
-`normal` 还是 `bounded_continuous`。启用连续执行不依赖用户说出特定口令。
-
-执行前规划必须：
-
-- 根据用户目标、项目上下文和仓库事实，推断目标、范围、验收、权限和验证方式。
-- 列出 L1 任务清单，并为每个 L1 生成 Green / Yellow / Red 风险评级。
-- 如果 L1 少于 2 个，使用 `normal`。
-- 如果 L1 为 2 个或更多，自动启用 `bounded_continuous`。
-- 如果任一 L1 为 Red，先停止并让人类确认；Green 和 Yellow 不阻塞启动。
-
-边界内连续执行规则：
-
-- 任务树按 L1 -> L2 -> L3 执行。执行某个 L1 前，先规划它自然衍生出的 L2；
-  执行某个 L2 前，如果仍需拆分，再规划 L3。
-- 默认最多 3 层。只有当 L3 仍过大、不可验证或不可回退时，才动态增加 L4。
-- L1/L2/L3/L4 都必须有风险评级、预期改动范围、验收方式和证据要求。
-- L1 清单必须用待办列表展示；每完成一个 L1，就打勾并划掉。
-- 默认按 `vertical_slice` 推进：每轮都产出可运行、可检查或可回退的增量。
-- 目标、范围、验收和权限由 AI 推断，但不能越过项目规则、显式用户限制、
-  `permission.modify.denied`、安全边界或破坏性操作限制。
-- `Green` 可以自动继续。
-- `Yellow` 可以在局部低风险修正后继续。
-- `Red` 必须停止等待人类确认。
-- 如果需要扩大权限、运行未允许命令、访问网络、执行破坏性操作、改变产品方向或核心架构，
-  当前节点必须标为 Red。
-- 全部完成后只做一次总复盘；只对 Yellow、Red、验证失败或高影响模块做二次抽检。
-- 每个 Checkpoint 必须给出证据，不接受只有主观判断的 Green。
-- 连续执行不改变模型策略；遇到规划、架构、失败复盘或验收争议，仍按 `model_policy` 升级。
-
-必须停止的情况：
-
-- 需要改变产品方向、核心架构、数据结构、安全边界、支付、账号或权限。
-- 需要删除大量文件或重写核心模块。
-- 发现任务大纲、验收或权限之间存在实质冲突。
-- 当前实现会影响多个后续模块，且任务契约没有覆盖该影响。
-- 测试失败且无法局部修复。
-- 出现两个以上高成本方案，需要人类裁决。
-
-检查点使用紧凑格式：
+任务执行前必须读取 `ai/template/execution-policy.md`。
 
-```text
-## Checkpoint
-### 任务树
-### 当前完成度
-### 已完成
-### 证据
-### 偏离风险：Green / Yellow / Red
-### 下一步建议
-### 是否自动继续
-```
+执行策略默认是 `auto`：AI 先拆 L1 任务并判断 Green / Yellow / Red，再决定使用
+`normal` 或 `bounded_continuous`。L1 少于 2 个使用 `normal`；L1 为 2 个或更多
+自动启用 `bounded_continuous`。只有 Red 停止等待人类确认。
+
+任务树、风险分级、Checkpoint 证据和 `task_tree` 状态更新规则由
+`ai/template/execution-policy.md` 定义。
 
 ## 引导模式
 

package/template/zh/ai/template/rules/core.md

@@ -103,26 +103,15 @@
 
 ## 边界内连续执行门
 
-每次执行前，AI 必须先做任务分解和风险判断，而不是等待用户显式说“启用连续执行”。
-
-执行前必须：
-
-- 根据用户目标、项目上下文和仓库事实，推断目标、范围、验收、权限和验证方式。
-- 列出 L1 任务清单，并给每个 L1 标注 Green / Yellow / Red。
-- L1 少于 2 个时使用 `normal`；L1 为 2 个或更多时自动使用 `bounded_continuous`。
-- 任一 L1 为 Red 时，停止等待人类确认；Green 和 Yellow 可继续。
-
-启用后：
-
-- 按 L1 -> L2 -> L3 执行；执行某个 L1 前规划 L2，执行某个 L2 前按需规划 L3。
-- 默认最多 3 层；只有当 L3 仍过大、不可验证或不可回退时，才动态增加 L4。
-- L1 清单必须用待办列表展示；每完成一个 L1，就打勾并划掉。
-- 每个任务节点必须有风险评级、预期改动范围、验收方式和证据要求。
-- 检查点预算是上限，不是必须用完的次数。
-- 每个 Checkpoint 必须包含证据。
-- `Green` 可自动继续。
-- `Yellow` 做局部低风险修正后继续。
-- `Red` 必须停止等待人类确认。
+每次执行前，AI 必须读取 `ai/template/execution-policy.md`，先做任务分解和风险判断，
+而不是等待用户显式说“启用连续执行”。
+
+硬门禁：
+
+- `execution_policy.task_tree` 必须记录 L1 清单和执行状态。
+- 每个任务节点必须有 Green / Yellow / Red 风险评级。
+- 每个 Checkpoint 必须包含证据；不接受只有主观判断的 Green。
+- Red 必须停止等待人类确认。
 - 任何方向、核心架构、数据结构、安全、支付、账号、权限、大量删除、
   核心重写或高成本方案取舍，都必须停止。
 - 需要扩大范围、权限、命令、网络或验收时，必须停止。

package/test/check-release.js

@@ -0,0 +1,94 @@
+#!/usr/bin/env node
+
+const fs = require("fs");
+const path = require("path");
+
+const repoRoot = path.resolve(__dirname, "..");
+const packagePath = path.join(repoRoot, "package.json");
+const packageJson = JSON.parse(fs.readFileSync(packagePath, "utf8"));
+
+function fail(message) {
+  throw new Error(message);
+}
+
+function read(relativePath) {
+  return fs.readFileSync(path.join(repoRoot, relativePath), "utf8");
+}
+
+function listFiles(relativeDir) {
+  const root = path.join(repoRoot, relativeDir);
+  const files = [];
+
+  function walk(dir) {
+    for (const entry of fs.readdirSync(dir, { withFileTypes: true })) {
+      const fullPath = path.join(dir, entry.name);
+      if (entry.isDirectory()) {
+        walk(fullPath);
+      } else if (entry.isFile()) {
+        files.push(path.relative(root, fullPath).split(path.sep).join("/"));
+      }
+    }
+  }
+
+  walk(root);
+  return files.sort();
+}
+
+function assertEqual(actual, expected, message) {
+  if (actual !== expected) {
+    fail(`${message}\nExpected: ${expected}\nActual: ${actual}`);
+  }
+}
+
+function assertIncludes(content, expected, message) {
+  if (!content.includes(expected)) {
+    fail(`${message}\nMissing: ${expected}`);
+  }
+}
+
+function assertFileListsMatch(leftDir, rightDir, message) {
+  const left = listFiles(leftDir).join("\n");
+  const right = listFiles(rightDir).join("\n");
+  assertEqual(left, right, message);
+}
+
+function assertTreesMatch(leftDir, rightDir, message) {
+  const leftFiles = listFiles(leftDir);
+  const rightFiles = listFiles(rightDir);
+  assertEqual(leftFiles.join("\n"), rightFiles.join("\n"), `${message}: file list differs`);
+
+  for (const file of leftFiles) {
+    const left = read(path.join(leftDir, file));
+    const right = read(path.join(rightDir, file));
+    assertEqual(left, right, `${message}: ${file} differs`);
+  }
+}
+
+function main() {
+  const version = packageJson.version;
+  assertEqual(packageJson.name, "@wnlen/agent-execution-template", "package name changed unexpectedly");
+  assertEqual(
+    packageJson.bin && packageJson.bin["agent-execution-template"],
+    "bin/agent-execution-template.js",
+    "package bin entry should point to the CLI"
+  );
+
+  assertEqual(read("template/zh/ai/template/VERSION").trim(), version, "zh template version must match package version");
+  assertEqual(read("template/en/ai/template/VERSION").trim(), version, "en template version must match package version");
+  assertEqual(read("ai/template/VERSION").trim(), version, "installed zh template version must match package version");
+
+  assertFileListsMatch("template/zh/ai", "template/en/ai", "zh and en templates must expose the same file layout");
+  assertTreesMatch("template/zh/ai/template", "ai/template", "installed ai/template must mirror template/zh/ai/template");
+  assertEqual(read("template/zh/ai/README.md"), read("ai/README.md"), "installed ai/README.md must mirror template/zh/ai/README.md");
+
+  const spec = read("docs/SPEC.md");
+  assertIncludes(spec, `Package: @wnlen/agent-execution-template@${version}`, "SPEC package version must match package.json");
+
+  const scripts = packageJson.scripts || {};
+  assertIncludes(scripts.test || "", "test/selftest.js", "npm test should run the CLI selftest");
+  assertIncludes(scripts.test || "", "test/check-release.js", "npm test should run release consistency checks");
+
+  console.log("release check ok");
+}
+
+main();