@wnlen/agent-execution-template 0.8.18 → 0.8.20

package/README.md

@@ -161,7 +161,8 @@ The user can still give a natural-language goal, for example:
 Build the settings page with profile editing, notification toggles, and export entrypoint
 ```
 
-Before execution, the AI decomposes L1 tasks:
+Before execution, the AI decomposes L1 tasks. Each L1 must be an independently
+acceptable vertical slice, not a mechanical step checklist:
 
 ```text
 - [ ] L1-1 Profile editing Green
@@ -171,12 +172,19 @@ Before execution, the AI decomposes L1 tasks:
 
 Because there are two or more L1 tasks, the protocol automatically uses bounded
 continuous execution. Before each L1, the AI plans naturally derived L2/L3 work.
-After completing an L1, it checks and strikes the item, then writes status back
-to `execution_policy.task_tree` in `ai/project/task.md`.
+After completing an L1, it checks and strikes the item. `task_tree` is written
+back only at L1 start/done, Red/blocked, scope changes, or final wrap-up, so tiny
+steps do not churn files.
 
 Only Red risk stops for confirmation. Green continues automatically, and Yellow
-continues after local low-risk correction. Every checkpoint must include
-evidence: changed files, commands run, and verification results.
+only permits local low-risk correction inside the current L1/L2; it must not
+change public interfaces, data models, permissions, security, architecture
+direction, or acceptance. By default, users see L1, risk conclusions, evidence,
+Red confirmations, and final results; internal protocol details are not shown.
+
+If the AI just created or rewrote `ai/project/task.md` in the current run, it
+must stop for confirmation. Execution is allowed only when an existing task is
+explicitly `ready_to_execute`.
 
 ## Installed Layout
 

package/README.zh-CN.md

@@ -171,7 +171,7 @@ npx -y @wnlen/agent-execution-template strategy
 实现设置页，包括资料编辑、通知开关和导出入口
 ```
 
-AI 会在执行前先拆 L1 任务：
+AI 会在执行前先拆 L1 任务。L1 必须是可独立验收的垂直切片，不是机械步骤清单：
 
 ```text
 - [ ] L1-1 资料编辑 Green
@@ -180,11 +180,15 @@ AI 会在执行前先拆 L1 任务：
 ```
 
 因为 L1 有两个以上，协议会自动使用边界内连续执行。执行每个 L1 前，AI 再规划
-自然衍生的 L2/L3；完成一个 L1 后，在清单中打勾并划掉，同时把状态写回
-`ai/project/task.md` 的 `execution_policy.task_tree`。
+自然衍生的 L2/L3；完成一个 L1 后，在清单中打勾并划掉。`task_tree` 只在
+L1 开始/完成、Red/blocked、范围变化或最终收尾时写回，避免为微小步骤反复改文件。
 
-只有 Red 风险会停下来让你确认。Green 自动继续，Yellow 只做局部低风险修正后继续。
-每个 Checkpoint 都必须带证据：改了哪些文件、跑了哪些命令、验证结果是什么。
+只有 Red 风险会停下来让你确认。Green 自动继续，Yellow 只允许当前 L1/L2 内的
+局部低风险修正，不能改变公共接口、数据模型、权限、安全、架构方向或验收标准。
+用户默认只看 L1、风险结论、证据、Red 确认和最终结果；内部协议细节不默认展示。
+
+如果 AI 本轮刚新建或重写了 `ai/project/task.md`，必须先停下来交接确认；
+只有已有任务明确处于 `ready_to_execute` 时，才允许进入执行。
 
 ## 安装后的结构
 

package/bin/agent-execution-template.js

@@ -19,6 +19,8 @@ const REQUIRED_FILES = [
   "ai/template/protocol.md",
   "ai/template/rules/core.md",
   "ai/template/rules/output.md",
+  "ai/template/schemas/result.schema.json",
+  "ai/template/schemas/metrics.schema.json",
   "ai/project/inbox/.gitkeep",
   "ai/project/project.md",
   "ai/project/runtime.md",
@@ -39,11 +41,6 @@ const RECOMMENDED_FILES = [
   "ai/project/refs/roadmap.md"
 ];
 
-const JSON_HEALTH_FILES = [
-  "ai/project/result.json",
-  "ai/project/metrics.json"
-];
-
 const TASK_HEALTH_PATTERNS = [
   /^task_id:\s*/m,
   /^type:\s*/m,
@@ -132,6 +129,7 @@ const TEXT = {
     fail: "失败",
     empty: "为空",
     invalidJson: "JSON 无效",
+    invalidSchema: "不符合协议 schema",
     taskFrontMatterIncomplete: "任务 front matter 缺少关键字段",
     versionMismatch: "模板版本与包版本不一致",
     runInit: "请运行 npx -y @wnlen/agent-execution-template init",
@@ -241,6 +239,7 @@ Usage:
     fail: "FAIL",
     empty: "is empty",
     invalidJson: "contains invalid JSON",
+    invalidSchema: "does not match protocol schema",
     taskFrontMatterIncomplete: "task front matter is missing required fields",
     versionMismatch: "template version does not match package version",
     runInit: "Run npx -y @wnlen/agent-execution-template init",
@@ -701,6 +700,117 @@ function isPermissionError(error) {
   return error && (error.code === "EACCES" || error.code === "EPERM");
 }
 
+function parseJsonFile(file) {
+  return JSON.parse(fs.readFileSync(file, "utf8"));
+}
+
+function valueMatchesType(value, type) {
+  if (type === "array") return Array.isArray(value);
+  if (type === "integer") return Number.isInteger(value);
+  if (type === "number") return typeof value === "number" && Number.isFinite(value);
+  if (type === "object") return value !== null && typeof value === "object" && !Array.isArray(value);
+  return typeof value === type;
+}
+
+function valuesEqual(left, right) {
+  return JSON.stringify(left) === JSON.stringify(right);
+}
+
+function validateJsonSchema(value, schema, location = "$") {
+  const errors = [];
+
+  if (schema.const !== undefined && !valuesEqual(value, schema.const)) {
+    errors.push(`${location} must be ${JSON.stringify(schema.const)}`);
+  }
+
+  if (schema.enum && !schema.enum.some((candidate) => valuesEqual(value, candidate))) {
+    errors.push(`${location} must be one of ${schema.enum.map((item) => JSON.stringify(item)).join(", ")}`);
+  }
+
+  if (schema.type && !valueMatchesType(value, schema.type)) {
+    errors.push(`${location} must be ${schema.type}`);
+    return errors;
+  }
+
+  if (schema.minimum !== undefined && typeof value === "number" && value < schema.minimum) {
+    errors.push(`${location} must be >= ${schema.minimum}`);
+  }
+
+  if (schema.minLength !== undefined && typeof value === "string" && value.length < schema.minLength) {
+    errors.push(`${location} must have length >= ${schema.minLength}`);
+  }
+
+  if (schema.required && valueMatchesType(value, "object")) {
+    for (const key of schema.required) {
+      if (!Object.prototype.hasOwnProperty.call(value, key)) {
+        errors.push(`${location}.${key} is required`);
+      }
+    }
+  }
+
+  if (schema.properties && valueMatchesType(value, "object")) {
+    for (const [key, childSchema] of Object.entries(schema.properties)) {
+      if (Object.prototype.hasOwnProperty.call(value, key)) {
+        errors.push(...validateJsonSchema(value[key], childSchema, `${location}.${key}`));
+      }
+    }
+  }
+
+  if (schema.items && Array.isArray(value)) {
+    value.forEach((item, index) => {
+      errors.push(...validateJsonSchema(item, schema.items, `${location}[${index}]`));
+    });
+  }
+
+  if (schema.allOf) {
+    for (const childSchema of schema.allOf) {
+      if (childSchema.if) {
+        if (validateJsonSchema(value, childSchema.if, location).length === 0 && childSchema.then) {
+          errors.push(...validateJsonSchema(value, childSchema.then, location));
+        }
+      } else {
+        errors.push(...validateJsonSchema(value, childSchema, location));
+      }
+    }
+  }
+
+  return errors;
+}
+
+function printSchemaValidation(file, schemaFile, text) {
+  const fullPath = path.join(process.cwd(), file);
+  const schemaPath = path.join(process.cwd(), schemaFile);
+  if (!fs.existsSync(fullPath) || !fs.existsSync(schemaPath)) {
+    return 0;
+  }
+
+  let value;
+  try {
+    value = parseJsonFile(fullPath);
+    console.log(`[${text.pass}] ${file} JSON`);
+  } catch {
+    console.log(`[${text.fail}] ${file} ${text.invalidJson}`);
+    return 1;
+  }
+
+  let schema;
+  try {
+    schema = parseJsonFile(schemaPath);
+  } catch {
+    console.log(`[${text.fail}] ${schemaFile} ${text.invalidJson}`);
+    return 1;
+  }
+
+  const errors = validateJsonSchema(value, schema);
+  if (errors.length > 0) {
+    console.log(`[${text.fail}] ${file} ${text.invalidSchema}: ${errors.slice(0, 3).join("; ")}`);
+    return 1;
+  }
+
+  console.log(`[${text.pass}] ${file} schema`);
+  return 0;
+}
+
 function printFatal(error, lang) {
   const text = getText(lang);
   if (isPermissionError(error)) {
@@ -756,18 +866,12 @@ function doctor() {
     console.log(`[${text.pass}] ${file}`);
   }
 
-  for (const file of JSON_HEALTH_FILES) {
-    const fullPath = path.join(process.cwd(), file);
-    if (!fs.existsSync(fullPath)) {
-      continue;
-    }
-    try {
-      JSON.parse(fs.readFileSync(fullPath, "utf8"));
-      console.log(`[${text.pass}] ${file} JSON`);
-    } catch {
-      console.log(`[${text.fail}] ${file} ${text.invalidJson}`);
-      missing += 1;
-    }
+  const schemaChecks = [
+    ["ai/project/result.json", "ai/template/schemas/result.schema.json"],
+    ["ai/project/metrics.json", "ai/template/schemas/metrics.schema.json"]
+  ];
+  for (const [file, schemaFile] of schemaChecks) {
+    missing += printSchemaValidation(file, schemaFile, text);
   }
 
   const taskPath = path.join(process.cwd(), "ai/project/task.md");

package/docs/SPEC.md

@@ -22,7 +22,7 @@ npx 安装协议 -> AI 整理项目上下文 -> 人类确认 -> AI 生成任务
 
 ```text
 Protocol: v0.8
-Package: @wnlen/agent-execution-template@0.8.18
+Package: @wnlen/agent-execution-template@0.8.19
 中文安装: npx -y @wnlen/agent-execution-template init
 英文安装: npx -y @wnlen/agent-execution-template init --lang en
 ```
@@ -392,7 +392,7 @@ npx -y @wnlen/agent-execution-template doctor
 ```text
 Agent Execution Template 检查
 
-模板版本: 0.8.18
+模板版本: 0.8.19
 模板语言: zh
 
 [通过] ai/template/LANG
@@ -664,7 +664,10 @@ ai/template/execution-policy.md
 执行前规划：
 
 - AI 根据用户目标、项目上下文和仓库事实推断目标、范围、验收、权限和验证方式；
+- 只有 `ai/project/task.md.readiness = ready_to_execute` 时才进入执行；本轮新建或重写
+  `task.md` 时必须停在确认交接；
 - 先列 L1 任务清单，并给每个 L1 标注 Green / Yellow / Red；
+- L1 必须是可独立验收的垂直切片，不是机械步骤清单；
 - L1 少于 2 个时使用 `normal`；
 - L1 为 2 个或更多时自动使用 `bounded_continuous`；
 - 任一 L1 为 Red 时停止等待人类确认；Green 和 Yellow 不阻塞启动。
@@ -675,16 +678,20 @@ ai/template/execution-policy.md
 - 默认最多 3 层，只有当 L3 仍过大、不可验证或不可回退时才动态增加 L4；
 - 每个任务节点必须有风险评级、预期改动范围、验收方式和证据要求；
 - L1 清单必须用待办列表展示，每完成一个 L1 就打勾并划掉；
-- 执行前和执行中必须把任务树写回 `ai/project/task.md.execution_policy.task_tree`；
+- `task_tree` 写回应集中在执行前、L1 开始/完成、Red、blocked、范围变化和最终收尾；
 - 默认按 `vertical_slice` 推进，每轮都要产生可检查增量；
+- Checkpoint 只在风险从 Green 变 Yellow/Red、即将扩大范围或权限、完成 L1 垂直切片、
+  验证失败后准备继续或最终收尾时输出；
 - 每个 Checkpoint 必须包含证据：已改文件、已运行命令、验证结果或无法验证原因；
 - Green 可自动继续；
-- Yellow 做局部低风险修正后继续；
+- Yellow 只允许当前 L1/L2 内的局部低风险修正，不能改变公共接口、数据模型、权限、
+  安全、架构方向或验收标准；
 - Red 必须停止等待人类确认；
+- 用户可见输出默认只展示 L1、风险结论、证据、Red 确认和最终结果，不展示内部协议细节；
 - 目标、范围、验收和权限由 AI 推断，但不能越过项目规则、显式用户限制、
   `permission.modify.denied`、安全边界或破坏性操作限制；
-- 需要扩大权限、运行未允许命令、访问网络、执行破坏性操作、改变产品方向或核心架构时，
-  当前节点必须标为 Red。
+- 需要扩大权限、运行未允许命令、访问网络、执行破坏性操作、改变产品方向、核心架构、
+  公共 API、持久化数据结构、安全边界、支付、账号或权限时，当前节点必须标为 Red。
 
 它不适用于方向未定且无法推断、验收无法定义或高风险架构取舍任务；这些应直接评为 Red。
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wnlen/agent-execution-template",
-  "version": "0.8.18",
+  "version": "0.8.20",
   "description": "Low-friction AI execution protocol template for coding agents.",
   "bin": {
     "agent-execution-template": "bin/agent-execution-template.js"

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

@@ -11,6 +11,8 @@ execution_policy:
   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: ""
@@ -86,6 +88,9 @@ permissions, and acceptance from the human goal, project context, and repository
 facts. If inference would cross permission or safety boundaries, or acceptance
 cannot be defined, set `readiness` to `blocked` or mark the relevant task node
 `Red` and wait for human confirmation.
+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`.
 
 ## Goal
 
@@ -143,26 +148,36 @@ fewer than 2 L1 tasks, use `normal`; if it finds 2 or more L1 tasks, use
   before execution.
 - `readiness = blocked` means the task cannot execute and must produce a
   blocked result.
+- If this run creates or rewrites `ai/project/task.md`, stop at the confirmation
+  handoff; do not execute while the task is still a draft.
 - Before execution, write the L1 checklist to `execution_policy.task_tree`.
 - Before execution, list the L1 task checklist; mark each L1 complete with a
   checked and struck-through item.
+- Each L1 must be an independently acceptable vertical slice. Do not split a
+  single mechanical step into L1 tasks, and do not merge multiple independently
+  acceptable user-visible outcomes into one L1.
 - Before executing an L1, plan the naturally derived L2 tasks; if an L2 still
   needs decomposition, plan L3 tasks.
 - Default to at most 3 levels; add L4 dynamically only when leaving it out
   would make L3 too large or unverifiable.
 - The AI assigns Green / Yellow / Red risk to every task node.
 - Only Red stops for human confirmation; Green continues automatically, and
-  Yellow continues after local low-risk correction.
+  Yellow only permits local low-risk correction inside the current L1/L2. It
+  must not change public interfaces, data models, permissions, security,
+  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.
-- Emit a checkpoint only when `checkpoint_triggers` fire, risk rises, or final
-  review is about to start.
+- 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.
 - Every checkpoint must include evidence: changed files, commands run,
   verification results, or why verification was not possible.
-- During execution, update `task_tree` node status: `pending`, `running`,
-  `done`, or `blocked`.
+- `task_tree` write-back frequency: write the L1 checklist before execution;
+  update an L1 when it starts or completes; write back immediately on Red,
+  blocked, scope change, or final wrap-up; do not write back every tiny L3
+  operation.
 - After completion, run one final review; only re-check Yellow, Red, failed
   verification, or high-impact modules.
 - Continuous execution does not change model policy; escalate through
@@ -192,7 +207,8 @@ Stop and write `ai/project/result.json`, `ai/project/result.md`, and `ai/project
 - Required command cannot be run.
 - Risk level is high without explicit authorization.
 - A Red checkpoint appears during continuous execution.
-- The task would change product direction, core architecture, data structures,
-  security boundaries, payment, accounts, or permissions.
-- The task would delete many files, rewrite a core module, or require choosing
-  between multiple high-cost options.
+- The task would change product direction, core architecture, public API,
+  persistent data structures, security boundaries, payment, accounts, or
+  permissions.
+- The task would delete files beyond the current L1's directly related files,
+  rewrite a core module, or require choosing between multiple high-cost options.

package/template/en/ai/template/VERSION

@@ -1 +1 @@
-0.8.18
+0.8.20

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

@@ -13,7 +13,13 @@ Pre-execution planning must:
 
 - Infer goal, scope, acceptance, permissions, and verification method from the
   human goal, project context, and repository facts.
+- Enter execution only when `ai/project/task.md` already exists and
+  `readiness = ready_to_execute`. If this run creates or rewrites the task
+  contract, stop at the confirmation handoff instead of executing from a draft.
 - List the L1 task checklist and assign Green / Yellow / Red risk to each L1.
+- Each L1 must be an independently acceptable vertical slice. Do not split a
+  single mechanical step into L1 tasks, and do not merge multiple independently
+  acceptable user-visible outcomes into one 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
@@ -24,6 +30,10 @@ Pre-execution planning must:
 
 Execute the task tree in L1 -> L2 -> L3 order.
 
+- L1 is a work increment that can be verified, rolled back, and explained to the
+  user after completion.
+- L2 is an implementation substep needed to finish that L1.
+- L3 is a local operation step used when an L2 is still too large.
 - 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
@@ -32,8 +42,11 @@ Execute the task tree in L1 -> L2 -> L3 order.
   and evidence requirements.
 - Show the L1 checklist as task items; when an L1 is complete, check it off and
   strike it through.
-- During execution, update each `task_tree` node status: `pending`, `running`,
-  `done`, or `blocked`.
+- Task tree write-back rule: write the L1 checklist before execution; update an
+  L1 when it starts or completes; write back immediately on Red, blocked, scope
+  change, or final wrap-up. Do not write back every tiny L3 operation.
+- During execution, use `pending`, `running`, `done`, or `blocked` for node
+  status.
 
 Recommended node shape:
 
@@ -65,16 +78,19 @@ Yellow:
 - Still inside current task scope;
 - local uncertainty or local verification failure exists;
 - a low-risk local correction can continue the work;
-- no permission, scope, command, or acceptance expansion is needed.
+- the correction affects only the current L1/L2 local implementation and does
+  not change public interfaces, data models, permissions, security,
+  architecture direction, or acceptance;
+- no permission, scope, command, network, or acceptance expansion is needed.
 
 Red:
 
 - Permission expansion, unallowed command, network access, or destructive action
   is needed;
-- product direction, core architecture, data structure, security boundary,
-  payment, account, or permission would change;
-- many files must be deleted, a core module must be rewritten, or multiple
-  high-cost options require judgment;
+- product direction, core architecture, public APIs, persistent data structures,
+  security boundary, payment, account, or permission would change;
+- files beyond the current L1's directly related files must be deleted, a core
+  module must be rewritten, or multiple high-cost options require judgment;
 - acceptance cannot be defined, or task goal materially conflicts with project direction.
 
 Only Red stops for human confirmation. Green continues automatically. Yellow
@@ -82,9 +98,10 @@ continues after local low-risk correction.
 
 ## Checkpoint
 
-Emit checkpoints only when risk rises, a boundary is about to change, a vertical
-slice is complete, or final review is about to start. Do not report just to
-spend checkpoint budget.
+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 review is about to start.
+Do not report just to spend checkpoint budget.
 
 Every checkpoint must include:
 
@@ -102,6 +119,22 @@ Every checkpoint must include:
 Evidence must include changed files, commands run, verification results, or why
 verification was not possible. A purely subjective Green is not valid.
 
+## User-Visible Output
+
+- Use the installed template language by default. When `ai/template/LANG` is
+  `en`, user-visible plans, L1 checklists, checkpoints, task draft handoffs,
+  blocked explanations, and final results should default to English. Use another
+  language only when the human explicitly asks, or when preserving code,
+  commands, file paths, or protocol field names.
+- Show the L1 checklist by default; do not show full L2/L3/L4 by default.
+- Show risk conclusions and necessary reasons; do not output long internal reasoning.
+- Show evidence; do not show internal protocol fields, full YAML,
+  `checkpoint_budget`, or `model_policy`.
+- Say little for Green, be brief for Yellow, and stop with clear reasons and
+  options for Red.
+- Final output must include status, completed items, verification results, and
+  result files.
+
 ## Model Policy
 
 Continuous execution does not change `model_policy`. Still escalate through

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

@@ -69,12 +69,12 @@ In Task Draft Mode:
    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.
-5. If no Red preflight item exists, set `readiness` to `ready_to_execute`; if
-   human confirmation is needed, set it to `draft_for_confirmation`; if the task
-   cannot execute, set it to `blocked`.
-6. Stop for human confirmation only when a Red preflight item appears. If the
-   human asked to execute or continue, and preflight contains only Green /
-   Yellow, proceed directly to Execution Mode.
+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.
+6. Enter Execution Mode only when an existing task is explicitly
+   `ready_to_execute` and no Red preflight item exists; if it cannot execute,
+   set it to `blocked`.
 7. Do not modify source or business files in Task Draft Mode.
 
 End Task Draft Mode with:
@@ -129,12 +129,17 @@ In Execution Mode, read:
 Then follow `ai/template/execution-policy.md` for pre-execution planning: list
 the L1 checklist, mark each L1 Green / Yellow / Red, and write it to
 `execution_policy.task_tree`. Automatically choose `normal` or
-`bounded_continuous` from the L1 count. Plan L2 before executing an L1, and
-plan L3 as needed before executing an L2; default to at most 3 levels, with L4
-allowed when needed. When an L1 is complete, check it off, strike it through,
-and update the `task_tree` node status. Only Red stops for human confirmation;
-Green continues automatically, and Yellow continues after local low-risk
-correction. Write results to:
+`bounded_continuous` from the L1 count. Execute only when
+`readiness = ready_to_execute`; if this run creates or rewrites the task
+contract, stop at the confirmation handoff. Each L1 must be an independently
+acceptable vertical slice. Plan L2 before executing an L1, and plan L3 as needed
+before executing an L2; default to at most 3 levels, with L4 allowed when
+needed. When an L1 is complete, check it off and strike it through; write back
+`task_tree` when an L1 starts or completes, on Red/blocked, on scope change, or
+at final wrap-up. Only Red stops for human confirmation; Green continues
+automatically, and Yellow only permits local low-risk correction inside the
+current L1/L2. User-visible output follows the "User-Visible Output" rules in
+`ai/template/execution-policy.md`. Write results to:
 
 - `ai/project/result.json`
 - `ai/project/result.md`

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

@@ -54,11 +54,15 @@ Before task execution, read `ai/template/execution-policy.md`.
 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`.
+`bounded_continuous` when there are 2 or more L1 tasks. Each L1 must be an
+independently acceptable vertical slice. Execution is allowed only for an
+existing task with `readiness = ready_to_execute`; if this run creates or
+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 tree, risk rubric, checkpoint evidence, and `task_tree` write-back rules
+are defined in `ai/template/execution-policy.md`.
 
 ## Bootstrap Mode
 

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

@@ -125,15 +125,24 @@ explicitly say "enable continuous execution".
 
 Hard gates:
 
+- Execute only when `ai/project/task.md.readiness = ready_to_execute`; if this
+  run creates or rewrites `task.md`, stop at the confirmation handoff.
+- L1 must be an independently acceptable vertical slice, not a mechanical step
+  checklist.
 - `execution_policy.task_tree` must record the L1 checklist and execution state.
 - Every task node must have Green / Yellow / Red risk.
+- Yellow only permits local low-risk correction inside the current L1/L2. It
+  must not change public interfaces, data models, permissions, security,
+  architecture direction, or acceptance.
 - 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.
+- Any product direction, core architecture, public API, persistent data
+  structure, security, payment, account, permission, large deletion, core
+  rewrite, or high-cost option choice must stop.
 - Any need to expand scope, permission, commands, network access, or acceptance
   must stop.
+- `task_tree` write-back should happen at L1 start/done, Red, blocked, scope
+  change, and final wrap-up; do not write back every tiny L3 operation.
 
 The AI infers goal, scope, acceptance, and permissions, but must not cross
 project rules, explicit human limits, `permission.modify.denied`, security

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

@@ -25,7 +25,10 @@ verification, assumptions, issues, next steps, and runtime update proposals.
 
 ## Result Markdown
 
-`ai/project/result.md` is the human-readable summary. Keep it short:
+`ai/project/result.md` is the human-readable summary. Keep it short and use the
+installed language from `ai/template/LANG` by default. In the English template,
+headings and prose should default to English; preserve code, commands, file
+paths, and protocol field names as written.
 
 ```md
 ## Status

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

@@ -3,15 +3,15 @@
 ## 当前状态
 
 - 阶段：方向层与执行层一致性收口
-- 重点：保持文件协议可安装、可升级、可审计，并让项目方向治理与任务执行约束一致。
+- 重点：保持协议可安装、可升级、可审计，并让方向治理与执行约束一致。
 - 阻塞：无
 - 已知风险：
   - 超出当前任务范围
-  - 询问人类那些 Agent 可以安全推断的细节
+  - 询问可安全推断的细节
   - 用历史过程笔记污染运行时上下文
   - 没有验证证据就标记成功
   - 在明确权限之外运行命令
-  - 只优化 token 节省，而忽略成本可接受前提下的输出质量
+  - 只省 token，忽略可接受成本下的质量
   - 方向层已升级但规则、runtime 或 doctor 仍停留在旧语义
 
 ## 硬规则
@@ -36,8 +36,8 @@
 
 ## 项目约束
 
-- 引导读取集从 `ai/template/bootstrap.md`、`ai/template/protocol.md`、`ai/template/rules/core.md`、根目录文档、清单、文档、引用开始；当文档不足时，进行有限源码结构检查。
-- 执行读取集是 `ai/template/prompt.md`、`ai/template/protocol.md`、`ai/template/rules/core.md`、`ai/project/project.md`、`ai/project/runtime.md` 和 `ai/project/task.md`。
+- 引导读取集：`bootstrap.md`、`protocol.md`、`rules/core.md`、根文档、清单、项目文档、引用；文档不足时有限检查源码结构。
+- 执行读取集：`prompt.md`、`protocol.md`、`rules/core.md`、`project.md`、`runtime.md`、`task.md`。
 - `ai/project/refs/` 文件只在任务要求或任务类型触发时加载。
 - `ai/project/refs/final-shape.md`、`module-map.md`、`roadmap.md` 属于方向层正式文档。
 - 方向层正式文档不能被普通 reconcile 或普通执行任务直接修改。
@@ -53,9 +53,9 @@
 ## 当前上下文
 
 这个项目是协议 / 模板，不是复杂 Agent 框架。
-当前产品定位是：面向 AI Coding Agent 的项目方向治理 + 可审计任务执行协议。
-当前产品目标是减少人类交互频率和输入量，同时让任务随时间变得更精确，并减少长期方向漂移。
-允许增加少量服务于协议采用和治理闭环的 CLI；不要引入 UI、云同步或多 Agent 编排。
+定位：面向 AI Coding Agent 的项目方向治理 + 可审计任务执行协议。
+目标：减少人类交互和输入量，让任务随时间更精确，并降低长期方向漂移。
+允许增加少量服务协议采用和治理闭环的 CLI；不要引入 UI、云同步或多 Agent 编排。
 
 ## 引用路由
 
@@ -69,6 +69,6 @@
 
 ## 运行时更新治理
 
-除非 `ai/project/task.md` 明确允许，AI 不得直接更新这个文件。
-如果任务产生长期有效上下文，将建议写入 `ai/project/result.json.runtime_update`。
-通过单独任务应用运行时更新，该任务唯一允许目标是 `ai/project/runtime.md`。
+除非 `task.md` 明确允许，AI 不得直接更新本文件。
+任务产生长期上下文时，写入 `result.json.runtime_update` 建议。
+运行时更新应由单独任务应用，唯一目标是 `ai/project/runtime.md`。