@wnlen/agent-execution-template 0.8.20 → 0.8.22

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

@@ -7,61 +7,11 @@ readiness: "draft_for_confirmation | ready_to_execute | blocked"
 depends_on_previous_result: false
 execution_policy:
   mode: "auto | normal | bounded_continuous"
-  activation_rule: "auto_enable_when_l1_count_gte_2"
-  max_depth: 3
-  allow_depth_4_when_needed: true
-  progress_unit: "vertical_slice"
-  l1_granularity: "independently_acceptable_vertical_slice"
-  write_back_policy: "l1_start_done_red_blocked_scope_change_final"
   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
-    l3: 0
-    l4: 0
-  checkpoint_triggers:
-    - before_crossing_boundary
-    - after_vertical_slice
-    - before_final_review
-  auto_continue:
-    green: true
-    yellow: "low_risk_only"
-    red: false
-  risk_gate:
-    green: "continue"
-    yellow: "continue_with_local_fix"
-    red: "stop_for_human"
-  evidence_required: true
-model_policy:
-  default_tier: "cheap"
-  allowed_tiers:
-    - cheap
-    - standard
-    - strong
-  escalation_allowed: true
-  escalation_triggers:
-    - ambiguous_goal
-    - ambiguous_acceptance
-    - high_risk_change
-    - architecture_boundary
-    - repeated_failure
-    - verification_dispute
-  strong_model_roles:
-    - planning
-    - risk_judgment
-    - architecture_review
-    - failure_review
-    - acceptance_judgment
 refs:
   required: []
   optional: []
@@ -92,6 +42,13 @@ If this run creates or rewrites the task contract, keep
 `readiness = draft_for_confirmation` by default and stop at the handoff. Enter
 execution only when an existing task is explicitly `ready_to_execute`.
 
+Default to a compact task contract. A single-L1, Green, low-risk task should
+write only the goal, scope, acceptance, permissions, verification commands, and
+minimal `execution_policy.task_tree`. Multi-L1, Yellow/Red, cross-module,
+continuously executed, or highly uncertain tasks may expand checkpoint, model
+policy, risk gate, and fuller task-tree fields as needed. The complete default
+rules live in `ai/template/execution-policy.md`.
+
 ## Goal
 
 Describe the exact goal of this task. If generated from a short human request,
@@ -135,7 +92,8 @@ The task is complete when:
 Default to `auto`. The AI decides during pre-execution planning whether to use
 continuous execution; it does not wait for a human keyword. If planning finds
 fewer than 2 L1 tasks, use `normal`; if it finds 2 or more L1 tasks, use
-`bounded_continuous` automatically.
+`bounded_continuous` automatically. Each L1 must be an independently acceptable
+vertical slice.
 
 `bounded_continuous` means bounded continuous execution:
 
@@ -167,8 +125,10 @@ fewer than 2 L1 tasks, use `normal`; if it finds 2 or more L1 tasks, use
   architecture direction, or acceptance.
 - `progress_unit` defaults to `vertical_slice`: each work loop should produce
   a reviewable increment.
-- `checkpoint_budget` is the maximum checkpoint budget, not a required count;
-  do not report just to spend the budget.
+- Compact tasks should not expand internal control fields such as
+  `checkpoint_budget` or `model_policy`.
+- Expanded tasks may add checkpoint budgets, model policy, risk gates, and
+  fuller node fields as needed.
 - Emit checkpoints only when risk changes from Green to Yellow/Red, scope or
   permission is about to expand, an L1 vertical slice is complete, verification
   failed but execution is about to continue, or final wrap-up is about to start.

package/template/en/ai/template/VERSION

@@ -1 +1 @@
-0.8.20
+0.8.22

package/template/en/ai/template/bootstrap.md

@@ -44,7 +44,7 @@ runtime files, result files, or metrics files during bootstrap.
 
 Read high-signal project evidence in this order:
 
-1. Root docs: `README*`, `AGENTS.md`, `CLAUDE.md`, `CONTRIBUTING*`, `CHANGELOG*`
+1. Root docs: `README*`, `CONTRIBUTING*`, `CHANGELOG*`
 2. Manifests: `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`,
    `pom.xml`, `build.gradle*`, `Makefile`
 3. Project docs: `docs/**`, preferring overview, architecture, setup, testing,
@@ -62,6 +62,9 @@ bounded read:
   project purpose, module boundaries, commands, and constraints;
 - do not read the whole codebase unless the human explicitly authorizes it.
 
+Do not treat `AGENTS.md` or `CLAUDE.md` as project business evidence; they are
+AI entrypoint routing files only.
+
 Do not read dependency folders, build outputs, coverage outputs, lockfiles
 except to infer package manager, secret files, environment files, or archives
 unless the human explicitly references them.

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

@@ -3,6 +3,22 @@
 Do not summarize this file.
 During task execution, use this file to choose `normal` or `bounded_continuous`.
 
+## Task Contract Shapes
+
+`ai/project/task.md` has two valid shapes:
+
+- Compact task contract: for single-L1, Green, low-risk tasks. Write only the
+  goal, scope, acceptance, permissions, verification commands, and minimal
+  `execution_policy.task_tree`; do not expand internal control fields such as
+  `checkpoint_budget` or `model_policy`.
+- Expanded task contract: for multi-L1, Yellow/Red, cross-module, continuously
+  executed, highly uncertain, or high-risk tasks. Expand checkpoint, model
+  policy, risk gate, and fuller task-tree fields only when needed.
+
+Prefer compact by default. Upgrade to expanded only when complexity, risk, or
+auditability makes the extra structure worthwhile. The complete execution rules
+live in this file and do not need to be repeated in every task draft.
+
 ## Default Policy
 
 The default execution policy is `auto`: before each execution, the AI first
@@ -25,6 +41,8 @@ Pre-execution planning must:
 - Stop for human confirmation first if any L1 is Red; Green and Yellow do not
   block startup.
 - Write the task tree to `execution_policy.task_tree` in `ai/project/task.md`.
+  Simple tasks should write only minimal L1 nodes; complex tasks can add
+  `scope`, `acceptance`, `evidence`, `children`, and related fields.
 
 ## Task Tree
 
@@ -48,7 +66,16 @@ Execute the task tree in L1 -> L2 -> L3 order.
 - During execution, use `pending`, `running`, `done`, or `blocked` for node
   status.
 
-Recommended node shape:
+Minimal node shape:
+
+```yaml
+id: "L1-1"
+title: ""
+risk: "Green | Yellow | Red"
+status: "pending | running | done | blocked"
+```
+
+Recommended node shape for complex tasks:
 
 ```yaml
 id: "L1-1"

package/template/en/ai/template/prompt.md

@@ -5,23 +5,25 @@ Execute the workflow below.
 
 You are operating inside an Agent Execution Template workspace.
 
-First read:
+This file only routes the workflow. First read minimal state:
 
-1. `ai/template/protocol.md`
-2. `ai/template/rules/core.md`
-3. `ai/template/execution-policy.md`
+1. `ai/project/project.md` if present
+2. `ai/project/task.md` if present
+3. Shallow listings of `ai/project/inbox/`, `ai/project/inbox/ideas/`, and `ai/project/proposals/final-shape-updates/`
 
 Then choose the mode:
 
 - If the user asks to update the North Star, final shape, product constitution,
   module map, roadmap, or project direction, or if
   `ai/project/inbox/ideas/` contains non-`.gitkeep` ideas waiting for
-  evaluation, draft a `strategy_update` task or produce the proposal directly,
-  then stop for human confirmation.
+  evaluation, read `ai/template/protocol.md`, `ai/template/rules/core.md`, and
+  relevant direction refs, then draft a `strategy_update` task or produce the
+  proposal directly, then stop for human confirmation.
 - If the user explicitly confirms that a proposal under
   `ai/project/proposals/final-shape-updates/*.md` may be merged, draft or
-  execute an `apply_strategy_update` task. If the proposal is still
-  `proposed`, update it to `accepted` based on that explicit confirmation.
+  execute an `apply_strategy_update` task after reading
+  `ai/template/protocol.md` and `ai/template/rules/core.md`. If the proposal is
+  still `proposed`, update it to `accepted` based on that explicit confirmation.
 - If the user says "Start initializing this project and absorb the material in ai/project/inbox/",
   or asks to initialize while also absorbing material from
   `ai/project/inbox/`, inspect `ai/project/project.md` first. If it already
@@ -54,7 +56,8 @@ Then choose the mode:
   the human hunt through files for gaps.
 - Use Execution Mode only after `ai/project/project.md` and
   `ai/project/task.md` are ready enough to define identity, goal, scope,
-  permission, and acceptance.
+  permission, and acceptance. Only then read `ai/template/protocol.md`,
+  `ai/template/rules/core.md`, and `ai/template/execution-policy.md`.
 
 ## Task Draft Handoff
 
@@ -64,11 +67,17 @@ In Task Draft Mode:
 2. Infer goal, scope, acceptance, permissions, verification method, and initial
    risk from the user's current goal, project context, and repository facts; do
    not require the human to provide each field upfront.
-3. Draft `ai/project/task.md` and set `execution_policy.mode` to `auto`.
+3. Draft `ai/project/task.md`. For a single-L1, Green, low-risk task, default to
+   a compact task contract: write only the goal, scope, acceptance, permissions,
+   verification commands, and minimal `execution_policy.task_tree`. Use an
+   expanded task contract only for multi-L1, Yellow/Red, cross-module,
+   continuously executed, or highly uncertain tasks.
 4. Before execution, list the L1 checklist, mark each L1 Green / Yellow / Red,
    and write it to `execution_policy.task_tree`. Use `normal` if there are
    fewer than 2 L1 tasks; automatically use `bounded_continuous` if there are 2
-   or more L1 tasks.
+   or more L1 tasks. The complete default rules live in
+   `ai/template/execution-policy.md`; do not mechanically copy internal control
+   fields such as `checkpoint_budget` or `model_policy` into simple task drafts.
 5. If this run creates or rewrites `ai/project/task.md`, set `readiness` to
    `draft_for_confirmation` and stop at the handoff; do not execute while the
    task is still a draft.

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

@@ -5,12 +5,18 @@ execution context.
 
 ```text
 ai/template/ = reusable execution protocol
-ai/project/  = current project execution workspace
+ai/project/  = current repo execution context
 ```
 
-Template is protocol. Project is the field workspace.
+Template is protocol. Project is repo-local context.
 
-The project workspace stores both execution state and direction. The direction
+Here, "repo execution context" means the repo-local `ai/project/**` context,
+not an external workspace / session / sandbox runtime. An external
+runtime may enter the repository and read this protocol, but should not replace
+`task.md`, file modification rules, acceptance criteria, or concrete coding
+context.
+
+The repo-local context stores both execution state and direction. The direction
 layer answers "why is this worth doing and where should the project grow"; the
 execution layer answers "what is this task and how will it be accepted."
 
@@ -61,6 +67,13 @@ rewrites the task contract, stop at the confirmation handoff. Only Red stops for
 human confirmation, and Yellow only permits local low-risk correction inside the
 current L1/L2.
 
+Task contracts are layered by complexity. A single-L1, Green, low-risk task uses
+a compact task contract with only the goal, scope, acceptance, permissions,
+verification commands, and minimal `execution_policy.task_tree`. Multi-L1,
+Yellow/Red, cross-module, continuously executed, or highly uncertain tasks use
+an expanded task contract and may include checkpoint, model policy, and fuller
+task-tree fields as needed.
+
 Task tree, risk rubric, checkpoint evidence, and `task_tree` write-back rules
 are defined in `ai/template/execution-policy.md`.
 

package/template/zh/ai/README.md

@@ -7,6 +7,8 @@ template 是协议
 project 是现场工作区
 ```
 
+这里的 `project` 是仓库内 `ai/project/**` 的项目现场，不是外部 workspace、session 或 sandbox 运行时。
+
 ## 文件
 
 - `template/prompt.md`：AI 启动提示。

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

@@ -7,61 +7,11 @@ readiness: "draft_for_confirmation | ready_to_execute | blocked"
 depends_on_previous_result: false
 execution_policy:
   mode: "auto | normal | bounded_continuous"
-  activation_rule: "auto_enable_when_l1_count_gte_2"
-  max_depth: 3
-  allow_depth_4_when_needed: true
-  progress_unit: "vertical_slice"
-  l1_granularity: "independently_acceptable_vertical_slice"
-  write_back_policy: "l1_start_done_red_blocked_scope_change_final"
   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
-    l3: 0
-    l4: 0
-  checkpoint_triggers:
-    - before_crossing_boundary
-    - after_vertical_slice
-    - before_final_review
-  auto_continue:
-    green: true
-    yellow: "low_risk_only"
-    red: false
-  risk_gate:
-    green: "continue"
-    yellow: "continue_with_local_fix"
-    red: "stop_for_human"
-  evidence_required: true
-model_policy:
-  default_tier: "cheap"
-  allowed_tiers:
-    - cheap
-    - standard
-    - strong
-  escalation_allowed: true
-  escalation_triggers:
-    - ambiguous_goal
-    - ambiguous_acceptance
-    - high_risk_change
-    - architecture_boundary
-    - repeated_failure
-    - verification_dispute
-  strong_model_roles:
-    - planning
-    - risk_judgment
-    - architecture_review
-    - failure_review
-    - acceptance_judgment
 refs:
   required: []
   optional: []
@@ -86,6 +36,11 @@ permission:
 `Red`，等待确认。本轮新建或重写任务契约时，默认保持 `draft_for_confirmation` 并停下交接；
 只有既有任务为 `ready_to_execute` 时才执行。
 
+默认使用 compact task contract。单 L1、Green、低风险任务只写目标、范围、验收、
+权限、验证命令和最小 `execution_policy.task_tree`。多 L1、Yellow/Red、跨模块、
+连续执行或高不确定任务才按需展开 checkpoint、模型策略、风险门和更完整任务树字段。
+完整默认规则见 `ai/template/execution-policy.md`。
+
 ## 目标
 
 描述这个任务的准确目标。如果由简短人类请求生成，保留用户意图并明确写出假设。
@@ -124,7 +79,7 @@ permission:
 ## 执行策略
 
 默认 `auto`：AI 执行前规划并决定是否连续执行，不等用户口令。L1 < 2 用 `normal`；
-L1 >= 2 自动用 `bounded_continuous`。
+L1 >= 2 自动用 `bounded_continuous`。L1 必须是可独立验收的垂直切片。
 
 `bounded_continuous` 表示边界内连续执行：
 
@@ -143,7 +98,8 @@ L1 >= 2 自动用 `bounded_continuous`。
 - 只有 Red 停下来让人类确认；Green 自动继续，Yellow 只允许当前 L1/L2 内的局部
   低风险修正，不能改变公共接口、数据模型、权限、安全、架构方向或验收标准。
 - `progress_unit` 默认为 `vertical_slice`：每轮都应产生可检查增量。
-- `checkpoint_budget` 是上限，不是必须用完；不要为消耗预算而汇报。
+- compact 任务不要展开 `checkpoint_budget`、`model_policy` 等内部控制字段。
+- expanded 任务可以按需增加 checkpoint 预算、模型策略、风险门和更完整节点字段。
 - 只有在风险从 Green 变 Yellow/Red、即将扩大范围或权限、完成 L1 垂直切片、
   验证失败后准备继续、准备最终收尾时才输出 Checkpoint。
 - 每个 Checkpoint 必须包含证据：已改文件、已运行命令、验证结果或无法验证的原因。

package/template/zh/ai/template/VERSION

@@ -1 +1 @@
-0.8.20
+0.8.22

package/template/zh/ai/template/bootstrap.md

@@ -36,7 +36,7 @@
 
 按下面顺序读取高价值项目证据：
 
-1. 根目录文档：`README*`、`AGENTS.md`、`CLAUDE.md`、`CONTRIBUTING*`、`CHANGELOG*`
+1. 根目录文档：`README*`、`CONTRIBUTING*`、`CHANGELOG*`
 2. 清单文件：`package.json`、`pyproject.toml`、`Cargo.toml`、`go.mod`、
    `pom.xml`、`build.gradle*`、`Makefile`
 3. 项目文档：`docs/**`，优先阅读概览、架构、安装、测试、部署、API、ADR 和决策文件
@@ -51,6 +51,8 @@
 - 只读取足够识别目的、模块边界、命令和约束的路由、模块、配置和测试文件；
 - 除非人类明确授权，不要读取整个代码库。
 
+不要把 `AGENTS.md` 或 `CLAUDE.md` 当作项目业务证据；它们只是 AI 入口路由文件。
+
 除非人类明确引用或授权，不要读取依赖目录、构建产物、覆盖率输出、锁文件
 （推断包管理器除外）、密钥文件、环境文件或归档目录。
 

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

@@ -3,6 +3,19 @@
 不要总结这个文件。
 任务执行时按本文件选择 `normal` 或 `bounded_continuous`。
 
+## 任务契约形态
+
+`ai/project/task.md` 有两种合法形态：
+
+- compact task contract：用于单 L1、Green、低风险任务。只写目标、范围、验收、
+  权限、验证命令和最小 `execution_policy.task_tree`；不要展开
+  `checkpoint_budget`、`model_policy` 等内部控制字段。
+- expanded task contract：用于多 L1、Yellow/Red、跨模块、连续执行、高不确定或
+  高风险任务。需要时可展开 checkpoint、模型策略、风险门和更完整的任务树字段。
+
+默认优先 compact。只有复杂度、风险或审计需要证明它有价值时，才升级到 expanded。
+完整执行规则由本文件承载，不需要在每个任务草稿里重复。
+
 ## 默认策略
 
 默认执行策略是 `auto`：AI 在每次执行前先做任务分解和风险判断，再决定使用
@@ -19,7 +32,8 @@
 - 如果 L1 少于 2 个，使用 `normal`。
 - 如果 L1 为 2 个或更多，自动启用 `bounded_continuous`。
 - 如果任一 L1 为 Red，先停止并让人类确认；Green 和 Yellow 不阻塞启动。
-- 将任务树写入 `ai/project/task.md` 的 `execution_policy.task_tree`。
+- 将任务树写入 `ai/project/task.md` 的 `execution_policy.task_tree`。简单任务只写最小
+  L1 节点；复杂任务再补充 scope、acceptance、evidence、children 等字段。
 
 ## 任务树
 
@@ -37,7 +51,16 @@
   出现 Red、blocked、范围变化或最终收尾时立即写回。不要为每个微小 L3 操作写回。
 - 执行中使用 `pending`、`running`、`done` 或 `blocked` 表示节点状态。
 
-推荐节点结构：
+最小节点结构：
+
+```yaml
+id: "L1-1"
+title: ""
+risk: "Green | Yellow | Red"
+status: "pending | running | done | blocked"
+```
+
+复杂任务推荐节点结构：
 
 ```yaml
 id: "L1-1"

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

@@ -3,18 +3,20 @@
 不要总结这个文件。
 按下面流程执行。你正在 Agent Execution Template 工作区内操作。
 
-先读取：
+本文件只负责路由。先读取最小状态：
 
-1. `ai/template/protocol.md`
-2. `ai/template/rules/core.md`
-3. `ai/template/execution-policy.md`
+1. `ai/project/project.md`（如果存在）
+2. `ai/project/task.md`（如果存在）
+3. `ai/project/inbox/`、`ai/project/inbox/ideas/` 和 `ai/project/proposals/final-shape-updates/` 的浅层列表
 
 选择模式：
 
 - 用户要求更新北极星、最终形态、产品宪法、模块地图、路线图或项目方向，
-  或 `ai/project/inbox/ideas/` 有待评估灵感：走 `strategy_update`，生成提案后停下确认。
+  或 `ai/project/inbox/ideas/` 有待评估灵感：读取 `ai/template/protocol.md`、
+  `ai/template/rules/core.md` 和相关方向 refs，走 `strategy_update`，生成提案后停下确认。
 - 用户明确确认某个 `ai/project/proposals/final-shape-updates/*.md` 可合并：
-  走 `apply_strategy_update`。若 proposal 仍为 `proposed`，先改为 `accepted`。
+  读取 `ai/template/protocol.md` 和 `ai/template/rules/core.md`，走
+  `apply_strategy_update`。若 proposal 仍为 `proposed`，先改为 `accepted`。
 - 如果用户说“开始初始化这个项目，并吸收 ai/project/inbox/ 里的资料”，
   或要求初始化时吸收 inbox：先检查 `ai/project/project.md`。若已存在且有效，
   执行 `ai/template/reconcile.md`，不要重新 bootstrap；若为空、占位或不完整，执行
@@ -33,7 +35,8 @@
   待确认上下文、待确认任务、失败结果、未完成任务或明显风险；给出建议或起草
   `ai/project/task.md`，不要让人类自己找问题。
 - 只有当 `project.md` 和 `task.md` 足以定义身份、目标、范围、权限和验收时，
-  才进入执行模式。
+  才读取 `ai/template/protocol.md`、`ai/template/rules/core.md`、
+  `ai/template/execution-policy.md` 并进入执行模式。
 
 ## 任务草稿交接
 
@@ -42,9 +45,13 @@
 1. 读取已确认的 `ai/project/project.md` 和相关 `ai/project/refs/*.md`。
 2. 根据用户目标、项目上下文和仓库事实推断目标、范围、验收、权限、验证方式和初始风险；
    不要求用户逐项提供。
-3. 起草 `ai/project/task.md`，并将 `execution_policy.mode` 设为 `auto`。
+3. 起草 `ai/project/task.md`。单 L1、Green、低风险任务默认使用 compact task contract：
+   只写目标、范围、验收、权限、验证命令和最小 `execution_policy.task_tree`。
+   多 L1、Yellow/Red、跨模块、连续执行或高不确定任务才使用 expanded task contract。
 4. 执行前列出 L1 清单并标注 Green / Yellow / Red，写入 `execution_policy.task_tree`。
-   L1 < 2 用 `normal`；L1 >= 2 自动用 `bounded_continuous`。
+   L1 < 2 用 `normal`；L1 >= 2 自动用 `bounded_continuous`。完整默认规则由
+   `ai/template/execution-policy.md` 承载，不要把 `checkpoint_budget`、`model_policy`
+   等内部控制字段机械复制到简单任务草稿里。
 5. 本轮新建或重写 `task.md` 时，将 `readiness` 设为 `draft_for_confirmation` 并停止；
    草稿不能直接执行。
 6. 只有既有任务为 `ready_to_execute` 且无 Red 预检项，才进入执行；否则设为 `blocked`。

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

@@ -9,6 +9,10 @@ ai/project/  = 当前项目执行工作区
 
 `template` 是协议，`project` 是现场。
 
+这里的“项目执行工作区”只指当前仓库内的 `ai/project/**` 现场上下文，不是仓库外
+workspace / session / sandbox 运行时。外部运行时可以进入仓库并读取本协议，但不应
+替代 `task.md`、文件修改规则、验收标准或具体编码上下文。
+
 项目现场同时保存任务和方向层。方向层回答“为什么做、往哪里长”，执行层回答
 “这次做什么、如何验收”。
 
@@ -49,6 +53,11 @@ ai/project/task.md             = 当前执行契约
 L1 必须是可独立验收的垂直切片。只有既有任务 `readiness = ready_to_execute` 才能执行；
 本轮新建或重写任务契约时先停下确认。Red 停止确认，Yellow 只允许当前 L1/L2 内的局部低风险修正。
 
+任务契约默认按复杂度分层。单 L1、Green、低风险任务使用 compact task contract，只保留
+目标、范围、验收、权限、验证命令和最小 `execution_policy.task_tree`。多 L1、Yellow/Red、
+跨模块、连续执行或高不确定任务才使用 expanded task contract，按需展开 checkpoint、
+模型策略和更完整的任务树字段。
+
 任务树、风险分级、Checkpoint 证据和 `task_tree` 写回规则由
 `ai/template/execution-policy.md` 定义。