Goal Achiever: Self-Evolving Agent System

SKILL.md

---
name: 赢得目标
description: 在目标平台（goal_web）发布高质量内容的完整技能流程设计。用于：读取任务json与goal_prompt，拆解任务、执行任务引擎、开发与自检、结果回写与评分回写。触发词：修改目标、赢得目标、触发目标实现、触发{网站名称}任务实现。
---

# {goal_web} 内容发布 Skill（仅流程文档，无脚本）

> **变量说明**：`{goal_web}` 是全局目标平台变量，每次运行时从 `references/core_goal.json` 的 `goal_web` 字段读取，读取后注入本文档所有出现 `{goal_web}` 的位置。当前值由 core_goal.json 决定，本文档不硬编码任何平台名称。

## 目录结构（约定）
- `references/core_goal.json`：固定核心目标，每次启动 Step 1 时必须从此文件读取 `core_goal` / `core_flow` / `goal_web`，未经用户明确修改不得更改
- ~~`references/goal_prompt.md`~~：**已迁移至 `references/prompts/goal_prompt.md`，旧路径废弃**
- `references/prompts/`：**Prompt 专属目录**，所有 Prompt 文件统一存放于此
  - `references/prompts/prompt_registry.md`：**Prompt 注册表**，Step 1 / Step 6 必须先查此表确定读取路径
  - `references/prompts/meta_prompt.md`：**Lyra meta-Prompt**，生产任何新 Prompt 时必须先用此 Prompt 驱动生成，再用 authoring_guide 校验字段
  - `references/prompts/prompt_authoring_guide.md`：**Prompt 撰写规范**，新建任何 Prompt 前必读，定义输入/输出字段硬性约束
  - `references/prompts/goal_prompt.md`：通用任务拆解 Prompt（fallback）
  - `references/prompts/retro_prompt.md`：通用复盘 Prompt（fallback）
- `references/technical-decision-reference.md`：开发方案决策参考，Step 3.1 必须读取
- `references/external-publishing-design-reference.md`：外部平台发布设计参考，涉及发布任务时必须读取
- `references/logging.md`：日志记录规范，每次执行必须遵循
- `references/script_registry.json`：脚本索引表（注册表），必须存在，允许写入脚本记录
- `references/step5_example.md`：Step 5 结果评分示例（参考用）
- `run/{date}/{batch_seq}/compressed_log.json`：**结构化压缩日志**（V2.0 新增），Step 4 每次执行后必须生成；Step 6 的 `{past_3_runs_logs}` 变量改读此文件，降低 Token 消耗
- `references/cron-design-reference.md`：**Cron 脚本设计规范，开发任何 cron 脚本前必须先读取本文件**
- `references/hook_config.json`：**Event-driven 自动运行配置表**，Step 0 启动时读取，控制一次触发自动跑几个 batch
- `tasks/`：**分平台任务 JSON 统一存放目录**（详见下方「任务文件命名规范」）
- `run/{date}/{batch_seq}/`：批次运行日志、retro_output 存放目录（仍保留，供日志归档）

---

## 任务文件命名规范（必须遵循）

所有任务 JSON 和复盘 JSON **统一存放在 `tasks/` 目录**，按以下规则命名：

| 文件类型 | 命名格式 | 示例 |
|---------|---------|------|
| 任务拆解 JSON | `{goal_web}_tasks_{batch_seq}.json` | `微博_tasks_001.json` |
| 复盘输出 JSON | `{goal_web}_retro_{batch_seq}.json` | `微博_retro_001.json` |

**说明**：
- `{goal_web}` = `core_goal.json` 中 `goal_web` 字段的实际值（如 `微博`、`脉脉`、`知乎`）
- `{batch_seq}` = 三位数字序号（如 `001`、`002`）
- 同一平台的任务和脚本隔离，不同平台之间绝对不互相读取
- 脚本注册表（`script_registry.json`）已含 `target_web` 字段，检索时**必须先过滤 `target_web == goal_web`**，只使用本平台的脚本

---

> 硬性约束
> - **开发 cron 定时脚本前，必须先读取 `references/cron-design-reference.md`**，按其规范开发，完成后在规范文件的「已有脚本清单」中追加记录
> - 若任务需要开发新脚本，必须先撰写"技术方案"
> - 必须基于"技术方案"进行开发
> - 允许并要求开发脚本以落地任务
> - 脚本索引表允许写入脚本记录，**禁止**清空
> - 禁止模拟数据：所有任务结果必须来自真实执行与真实平台反馈
> - 禁止询问人工帮助，即使失败了也会记录为失败数据，对下一轮仍有极大帮助
> - 所有涉及 `{goal_web}` 平台的浏览器操作，必须通过 attach 谷歌浏览器实例进行（Browser Relay），不得自行启动新浏览器
> - **【核心约束·最高优先级】必须自动化完成全流程，严禁向用户要求任何形式的人工介入（包括但不限于：请你打开页面、请你点击、请你 attach Tab、请你确认、请提供数据等）。若因环境缺失（Tab 未 attach、权限不足、网络异常等）导致任务无法完成，必须将该任务回写为 `task_state: "failed"`，`task_result` 中写明失败原因，继续执行后续任务，不得中断流程，不得等待人工处理。**

---

## 输入/输出规范

### 输入 JSON — 首批次（batch_seq = 001）
首次运行包含以下基础字段：
- `goal_web`：目标平台（从 core_goal.json 读取）
- `core_goal`：今日核心目标
- `core_flow`：（可为空/null）核心过程约束，与 `core_goal` 同级别。**非空时**描述任务必须遵循的执行流程或操作顺序；**为空/null 时**不影响任何流程，按正常逻辑执行
- `date`：今日日期（每次运行时读取）
- `batch_seq`：从 `001` 开始

### 输入 JSON — 续批次（batch_seq ≥ 002）
从第二批次起，上游 JSON 是 Step 6 复盘输出，额外包含以下字段，**Step 1 读取后必须透传给 Step 2 使用**：
- `workflow_status`：`continue_to_next_batch` 或 `goal_achieved`
- `retrospective_context`：上一批次的复盘摘要
- `next_batch_guidance`：对下一轮拆解和开发的约束指导（含 `blacklist`）
- `carry_over_tasks`：未完成或低分任务的结转列表
- `core_flow`：（可为空/null）同首批次，从上一批次 retro 或 core_goal.json 继承透传

> 若 `workflow_status = goal_achieved`，终止工作流，输出完成报告。

### Prompt 文件（通过注册表查找）
- Step 1 / Step 6 均使用 **Prompt 注册表查找机制**（详见下方「Prompt 查找规则」）
- 注册表路径：`references/prompts/prompt_registry.md`
- 通用 fallback：`references/prompts/goal_prompt.md`（任务拆解）/ `references/prompts/retro_prompt.md`（复盘）

### 输出 JSON（任务拆解结果）
在输入字段基础上新增：
- `task_id`：按优先级排序，从 1 开始
- `task`：任务名
- `task_description`：任务描述
- `task_reason`：为什么有利于实现 `core_goal`
- `depends_on`：**（V2.0 新增）** 前置任务 ID 列表，空数组 `[]` 表示无依赖，可立即执行；非空时必须等所有前置任务 `task_state = done` 才能执行
- `task_state`：`done | pending | failed | blocked`
  - `pending`：尚未执行（含「就绪待调度」）
  - `done`：任务目标达成
  - `failed`：任务目标未达成（含脚本报错、外部拦截、超时等一切失败情形，回写原因后立即进入 Step 5）
  - `blocked`：**（V2.0 新增）** 前置任务 failed，本任务自动标记为 blocked，跳过执行，直接交由 Step 6 复盘处理
- `task_result`：初始为 `null`
- `source`：**（V2.0 新增）** 脚本来源标记，`registry`（从注册表召回）或 `new`（本批次新开发），Step 5 OB 老化降级依赖此字段

---

## 主任务文件 vs 分支任务文件

| 概念 | 文件 | 职责 |
|------|------|------|
| **主任务文件** | `tasks/master_task.json` | 每次运行的上下文快照：runtime_goal_web、runtime_core_goal、触发来源、从分支任务合并的上下文 |
| **分支任务文件** | `tasks/{goal_web}_tasks_{batch_seq}.json` | 某平台某批次的任务拆解与执行结果（历史档案） |
| **分支复盘文件** | `tasks/{goal_web}_retro_{batch_seq}.json` | 某平台某批次的复盘输出，供下一批次 Step 1 读取 |

**合并优先级**（高优先级覆盖低优先级）：
```
用户输入（当次触发）> core_goal.json > 分支任务历史数据（retro）
```

---

## 执行总流程（必须严格遵循）

### 日志记录规范（必须遵循）
- 读取并遵循 `references/logging.md`
- 每次完整执行必须生成主日志文件，命名：`运行日志_{date}_{batch_seq}.md`

---

### 0) 触发解析（每次 Skill 启动的第一步）

**目标**：从用户输入中解析出意图类型（**Prompt 生产** 或 **批次任务执行**），分别进入对应流程。

#### 意图识别（最优先判断）

```
用户触发 Skill
    ↓
Step 0.0：识别意图类型
    ├── 意图 = Prompt 生产
    │       触发词：「撰写/生成/写/创建 + Prompt + 平台名」
    │       或：「帮我写 {goal_web} 的复盘Prompt / 任务拆解Prompt」
    │       → 跳转至「Prompt 生产流程」（见下方独立章节），不进入批次任务流程
    │
    └── 意图 = 批次任务执行（默认）
            → 继续 Step 0.1：解析 goal_web 和 core_goal（原有逻辑不变）
```

---

#### 解析流程（批次任务执行，原有逻辑不变）

```
用户触发 Skill
    ↓
Step 0.1：解析用户输入，尝试识别 goal_web 和 core_goal
    ├── 情况一：仅解析出 goal_web（无 core_goal）
    │       → 从 tasks/{goal_web}_retro_* 读取最新 core_goal
    │       → 分支任务提供全部上下文（retro/blacklist/carry_over 等）
    │
    ├── 情况二：同时解析出 goal_web + core_goal
    │       → runtime_core_goal = 用户输入值（覆盖 core_goal.json 和历史 retro）
    │       → 分支任务仅提供历史上下文（batch_seq/retro/blacklist/carry_over），不提供 core_goal
    │
    └── 情况三：解析不出 goal_web
            → 检查 tasks/ 目录下有几个平台的历史文件
            │   ├── 仅一个平台 → 提示用户：「检测到只有 {X} 的任务记录，是否触发 {X} 任务？」
            │   └── 多个平台 / 无历史 → 询问用户：「请问要对哪个平台执行任务？」
            → 等待用户确认后，重新走情况一或情况二
```

#### goal_web 识别规则

优先按以下顺序识别：
1. 用户明确提到平台名（微博、脉脉、知乎、Producthunt、Twitter 等）
2. 用户消息含 `goal_web=xxx` 或 `web=xxx` 等参数格式
3. `core_goal.json` 中的 `goal_web` 值（作为兜底默认值，非强制）

#### core_goal 识别规则

1. 用户明确说「目标是…」「core_goal=…」「goal=…」→ 使用用户值
2. 用户未提供 → 从 `tasks/{goal_web}_retro_*` 最新文件读取
3. 无历史 retro → 从 `core_goal.json` 读取

#### core_flow 识别规则

1. 用户明确说「流程是…」「core_flow=…」「必须按…流程」→ 使用用户值
2. 用户未提供 → 从 `tasks/{goal_web}_retro_*` 最新文件的 `core_flow` 字段读取（若有）
3. 无历史 retro 或字段为空 → 从 `core_goal.json`（或分支 `core_goal_{goal_web}.json`）读取 `core_flow` 字段
4. 以上来源均为空/null → `runtime_core_flow = null`，跳过所有 core_flow 相关流程约束，无任何影响

#### Step 0.2：读取 hook_config.json，初始化 auto_run

在生成 `master_task.json` 之前，**必须**读取 `references/hook_config.json`：

```
读取 hook_config.json
  → 查找 platforms[goal_web].auto_runs
  → 未找到则使用 default_auto_runs（默认 1）
  → 将 auto_runs 写入 master_task.json 的 auto_run 字段
```

**仅用户首次触发时初始化**（`trigger_source = user_message` 或 `cron`）。
自动触发下一批次时（`trigger_source = auto_hook`），`auto_run.remaining` 直接从上一个 master_task.json 继承并递减，**不重新读取 hook_config**（避免重置计数器）。

**（V2.1 新增）`meta_optimization` 初始化规则**：
- 用户首次触发时：检查上一个 master_task.json 是否已有 `branch_context.meta_optimization` 字段
  - 有 → 直接继承（`batches_since_last_opt` 和 `prompt_iteration_seq` 均继承，不重置）
  - 无（全新平台）→ 初始化为 `{"prompt_iteration_seq": "000", "batches_since_last_opt": 0}`
- 跨平台切换时（goal_web 变更）：`meta_optimization` 随 goal_web 独立维护，不互相干扰

#### 输出：master_task.json

每次触发后，将解析结果写入 `tasks/master_task.json`：

```json
{
  "trigger_time": "2026-03-17T18:53:00",
  "trigger_source": "user_message",
  "runtime_goal_web": "Producthunt",
  "runtime_core_goal": "获取Producthunt每日和近一周的核心AI产品，并介绍产品价值，输出报告。",
  "context_source": {
    "goal_web_from": "user_input",
    "core_goal_from": "branch_retro",
    "branch_retro_file": "tasks/Producthunt_retro_001.json"
  },
  "branch_context": {
    "last_batch_seq": "001",
    "next_batch_seq": "002",
    "next_batch_guidance": {},
    "carry_over_tasks": [],
    "blacklist": [],
    "meta_optimization": {
      "prompt_iteration_seq": "000",
      "batches_since_last_opt": 0
    }
  },
  "auto_run": {
    "total": 1,
    "remaining": 1,
    "current_run": 1
  }
}
```

> **字段说明**
> - `runtime_core_flow`：（可为空/null）过程约束字段，从 core_goal.json 或上一批次 retro 读取后注入。**非空时**：Step 2 必须将其作为硬性过程约束注入任务拆解（每个 task 须注明 `flow_step` 对应哪一环节）；Step 4 执行后校验每个 task 是否遵从流程（写入 `flow_compliant: true/false`）；Step 6 复盘输出中必须新增 `flow_violations` 字段记录违反情况及归因。**为空/null 时**：跳过上述所有检查，不影响正常流程。
> - `trigger_source`：`user_message` / `cron` / `auto_hook`（自动连续运行时）
> - `context_source`：记录每个字段的来源，便于调试
> - `branch_context`：从分支复盘文件提取的历史上下文，传递给 Step 1
> - `auto_run.total`：本次触发的总批次数（从 hook_config 读取）
> - `auto_run.remaining`：剩余还需运行的批次数（每完成一个 batch 减 1）
> - `auto_run.current_run`：当前是第几次自动运行（从 1 开始）
> - `branch_context.meta_optimization`：**（V2.1 新增）元学习进化计时器**，每个 goal_web 平台独立维护
>   - `prompt_iteration_seq`：当前使用的 Prompt 版本号（`000` = 原始版，`001` = 第一次进化后，依此类推）
>   - `batches_since_last_opt`：上次进化后完成的批次数，每次 Step 6 末尾 +1；达到 10 时触发 Step 6.5 元学习进化流并清零

---

### 1) 读取输入

> Step 0 已完成触发解析并写入 `tasks/master_task.json`，Step 1 直接从该文件读取运行时上下文。

1. 读取 `tasks/master_task.json`，获取：
   - `runtime_goal_web` → 本批次 `goal_web`（全局变量，注入所有后续步骤）
   - `runtime_core_goal` → 本批次 `core_goal`
   - `runtime_core_flow` → 本批次 `core_flow`（可为空/null；非空时作为硬性过程约束贯穿后续全部步骤）
   - `branch_context` → 历史上下文（`next_batch_seq` / `next_batch_guidance` / `carry_over_tasks` / `blacklist`）
   - **合并优先级再次确认**：master_task.json 已按「用户输入 > core_goal.json > 分支历史」合并，Step 1 直接使用，不再重新读取 core_goal.json
2. 从 `branch_context.next_batch_seq` 确定本批次序号：
   - 有值 → 使用该值
   - 无值（首批次）→ 强制 `001`，严禁继承其他平台序号
3. **读取 goal_prompt（通过注册表查找）**：
   ```
   读取 references/prompts/prompt_registry.md
     → 查找 type=任务拆解 AND web={goal_web} 的记录
     → 找到 → 读取该记录 path 指向的 Prompt 文件
     → 未找到 → fallback：读取 references/prompts/goal_prompt.md
   ```
4. **若 `branch_context` 含 `next_batch_guidance`**：提取约束条件和 `blacklist`，暂存备用（Step 2 和 Step 3 使用）
5. **若 `branch_context.workflow_status = goal_achieved`**：终止，输出完成报告，不再继续

---

### 2) 任务拆解（基于 goal_prompt）
1. **若上游 JSON 含 `carry_over_tasks`**：优先将结转任务纳入本批次拆解（保留原 task_id，补充调整策略）
2. **若上游 JSON 含 `next_batch_guidance`**：拆解前先读取其中 `task_breakdown_advice` 和 `development_constraints`，将其作为硬性约束应用于本批次任务设计
3. **【core_flow 约束注入（非空时必须执行）】**：
   - 若 `runtime_core_flow` 非空：将 `core_flow` 描述的流程步骤作为**硬性过程约束**注入任务拆解：
     - 每个 task 必须对应 `core_flow` 中的某个流程环节，在 task 字段中新增 `"flow_step": "对应的流程环节名称"`
     - 拆解出的任务顺序、依赖关系必须与 `core_flow` 描述的流程顺序严格一致，不得跳步或乱序
     - 若某个 `core_flow` 流程环节在本批次无法执行，需显式拆解为一个 `task_state: "blocked"` 的占位任务，写明原因
   - 若 `runtime_core_flow` 为空/null：跳过此步骤，按正常 `core_goal` 拆解逻辑执行
4. 使用上一步查找到的 `goal_prompt`（专属版或 fallback 通用版）对 `core_goal` 进行拆解，输出新的任务 JSON
5. 保持：`goal_web / core_goal / core_flow / date / batch_seq` 与上游一致
6. 任务描述中涉及平台操作时，用实际 `goal_web` 值替换 `{goal_web}`
7. **（V2.0 新增）DAG 依赖图谱**：为每个任务输出 `depends_on` 字段：
   - 无前置依赖的任务：`"depends_on": []`
   - 有前置依赖的任务：`"depends_on": [task_id_1, task_id_2]`
   - 示例：数据采集任务（task_id=1）无依赖；报告生成任务（task_id=2）依赖采集任务 → `"depends_on": [1]`
   - 拆解时优先设计「可并发执行的任务对」，相互无依赖的任务 `depends_on` 均为 `[]`
7. **任务 JSON 保存路径**：`tasks/{goal_web}_tasks_{batch_seq}.json`（例：`tasks/微博_tasks_002.json`）

---

### 3) 任务执行引擎
1. 从任务 JSON 中按顺序找到第一个 `task_state = pending` 的任务
2. 从 `task` 与 `task_description` 中提炼搜索 query（query 中用 `goal_web` 实际值）
3. 在脚本注册表中检索 `script_description`（仅限 `score >= 0.8`）
   - **平台过滤（首要条件）**：只检索 `target_web == goal_web` 的记录，其他平台的脚本一律忽略
   - **安全校验（黑名单过滤）**：若上游 JSON 的 `next_batch_guidance.blacklist` 不为空，必须排除其中的脚本路径，即使 score >= 0.8 也不得使用
   - 检索结果为空或 score < 0.8 → 进入 OB 召回
4. OB 召回：
   - 进入 OB 召回流程，召回文档时优先检索与 `{goal_web}` 平台相关的文档
   - 阅读文档并进行置信度评分（0-1）
   - 置信度 >= 0.8：可作为开发参考
   - 否则：进入开发流程
5. 若无任何参考文档：直接进入开发流程

---

### 3.2) 沙盒预检（静态检查 + 局部自愈）【V2.0 新增，在 3.1 之后、Step 4 之前执行】

> **目标**：拦截低级代码错误，避免浪费真实执行环境和复盘周期。

**触发条件**：Step 3.1 新开发的脚本写入路径后，进入本步骤。从注册表直接召回的脚本（`source = registry`）跳过本步骤（已验证过）。

**执行流程**：

```
Step 3.1 新脚本写入
    ↓
Step 3.2：静态语法检查
    ├── Python 脚本 → exec: python3 -m py_compile <script_path>
    │   返回码 = 0 → 通过，写入 task_script，进入 Step 4
    │   返回码 ≠ 0 → 截获 stderr，进入局部自愈循环
    │
    └── Shell 脚本 → exec: bash -n <script_path>
        返回码 = 0 → 通过
        返回码 ≠ 0 → 进入局部自愈循环
```

**局部自愈循环**（最多重试 3 次，超限则标记任务 failed）：
1. 将原脚本内容 + stderr 报错信息 提交给 LLM（当前 AI 上下文）进行修复
2. 重新写入脚本文件
3. 再次执行静态检查
4. 通过 → 写入 task_script，进入 Step 4
5. 第 3 次仍失败 → 将任务 `task_state = failed`，`task_result` 写入「沙盒预检失败，3 次自愈均未通过，报错：{stderr}」，进入 Step 5 评分

**放行条件**：只有通过静态检查的脚本路径，才允许写入任务 JSON 的 `task_script` 字段，进入 Step 4 真实执行。

---

### 3.1) 开发流程（技术方案 → 脚本）
1. 进入开发前**必须读取**：`references/technical-decision-reference.md`
2. 若任务涉及"发布/外部平台发布"，额外**必须读取**：`references/external-publishing-design-reference.md`
3. 若上游含 `next_batch_guidance.development_constraints`，**必须**将其作为约束条件纳入技术方案
4. 基于任务与参考内容，撰写技术方案：
   - 命名：`技术方案_v{版本号}_{date}.md`
   - 包含：业务目标 / 技术目标 / 约束（含 `{goal_web}` 平台特性）/ 三方案（A快 / B平衡 / C理想）/ 决策与取舍
   - **平台约束**：`{goal_web}` 平台操作必须通过 attach 谷歌浏览器实例（Browser Relay），脚本中使用 `get_relay_ws_url()` 获取连接
5. 按技术方案进行开发，生成可执行脚本（Python/Bash 等）
6. 自检：确认脚本逻辑与技术方案一致
7. 将脚本写入脚本注册表，**必须包含以下全部字段**：`name`、`path`、`script_description`、`score`、`score_reason`、`target_web`（填写当前 `goal_web` 实际值，不得留空）
8. 更新任务 JSON，在对应任务下新增字段：
   - `task_script_seq`：脚本序号（数组）
   - `task_script`：脚本路径（数组，与 seq 一一对应）

---

### 4) 记录执行结果（V2.0：并发调度 + 双轨日志）

#### 4.1 并发调度（DAG 执行器）

```
扫描任务 JSON，建立就绪队列：
  就绪条件：task_state = "pending" AND（depends_on = [] OR 所有前置任务 task_state = "done"）
    ↓
将就绪队列中的任务并发执行（同一批扫描周期内同时拉起）
    ↓
某任务执行完毕（done/failed）→ 立即回写 task_state 和 task_result
    ↓
重新扫描就绪队列（前置任务 done 后，其后继任务解锁为就绪态）
    ↓
重复，直到无 pending 任务
```

**blocked 标记规则**：若某任务的前置任务 `task_state = failed`，则该任务 `task_state → blocked`，`task_result = "前置任务 {task_id} 失败，本任务跳过执行"`，不进入执行队列，直接进入 Step 5 评分。

#### 4.2 执行与回写

1. 读取任务 JSON，按并发调度逻辑执行
2. 无论执行结果如何，立即将结果回写至 `tasks/{goal_web}_tasks_{batch_seq}.json` 的 `task_result`，**不得留空、不得等待外部条件**
2.5. **【core_flow 合规校验（非空时必须执行）】**：若 `runtime_core_flow` 非空，每个 task 执行完毕后，额外回写字段：
   - `flow_compliant: true`：该任务的执行路径符合 `core_flow` 中对应流程环节的要求
   - `flow_compliant: false`：执行路径偏离了 `core_flow` 约束（需在 `task_result` 中写明具体偏离点）
   - `flow_compliant: null`：`runtime_core_flow` 为空，跳过校验
3. 根据执行结果更新 `task_state`（**非此即彼，无中间态**）：
   - 任务目标达成 → `done`
   - 任务目标未达成（无论何种原因）→ `failed`，`task_result` 中写明失败现象与原因
   - 前置任务 failed → `blocked`

#### 4.3 双轨日志生成（V2.0 新增）

每次 batch 所有任务执行完毕后，**必须同时生成两份产物**：

**轨道 A：完整 Markdown 日志**（人类审计/归档用，原有逻辑不变）
- 路径：`run/{date}/{batch_seq}/运行日志_{date}_{batch_seq}.md`

**轨道 B：结构化压缩日志**（Step 6 复盘专用，V2.0 新增）
- 路径：`run/{date}/{batch_seq}/compressed_log.json`
- 内容结构：

```json
{
  "batch_seq": "008",
  "goal_web": "Producthunt",
  "date": "2026-03-21",
  "task_summary": [
    {
      "task_id": 1,
      "task": "任务名称",
      "task_state": "done",
      "source": "registry",
      "script_score": 0.95,
      "action_sequence": ["读取配置", "调用 API", "生成报告", "推送飞书"],
      "error_trace": null
    },
    {
      "task_id": 2,
      "task": "任务名称",
      "task_state": "failed",
      "source": "new",
      "script_score": 0.4,
      "action_sequence": ["读取配置", "调用 API"],
      "error_trace": "TypeError: NoneType has no attribute 'get' at line 42"
    }
  ],
  "batch_outcome": "partial_success",
  "top_error": "TypeError: NoneType has no attribute 'get'"
}
```

- **提取规则**：
  - `action_sequence`：从完整日志中提取关键动作序列（3-8 个动作词，如「打开网页 → 定位输入框 → 点击按钮」）
  - `error_trace`：只保留最底层 Exception 类型 + 报错所在行，过滤掉环境变量打印等无关输出
  - `batch_outcome`：`all_done`（全部成功）/ `partial_success`（部分成功）/ `all_failed`

> **流程铁律**
> - 失败即回写：脚本执行产生任何结果（含报错、超时、页面拦截），立即回写 `task_result = failed`，**不降级、不重试、不等待**
> - 单任务 failed 不阻断流程：`task_state = failed` 后直接进入 Step 5 评分
> - 失败原因交由 Step 6 复盘处理，由下一批次的 `carry_over_tasks` 承接重试策略
> - **compressed_log.json 必须在所有 task 回写完成后才生成**，不得提前

#### on_batch_complete 钩子（Step 4 所有 task 回写完成后触发）

```
所有 task task_state 均已回写（done/failed/blocked）
    ↓
【不再因 failed 停止】失败状态已在 Step 4 执行时回写至 task_result（含失败原因+操作路径），
Step 6 复盘将统一读取所有任务状态（包含 failed）进行归因分析，生成 carry_over_tasks 和 blacklist。
    ↓
直接读取 master_task.json 的 auto_run.remaining：
    remaining <= 0？
        → 终止，向用户输出完成摘要（含本批次 failed 任务列表）
    remaining > 0？
        → remaining -= 1，current_run += 1，写回 master_task.json
        → 自动执行 Step 5（评分）→ Step 6（复盘），生成 retro 文件
        → 更新 master_task.json：
              trigger_source = "auto_hook"
              batch_seq 递增（如 007 → 008）
        → 自动跳回 Step 1，开始下一个 batch
        → 不等待用户确认
```

> **设计原则**：失败是数据，不是中断信号。任何 task 失败只会在 task_result 中留下记录（失败原因、操作路径、错误信息），流程继续向前推进至 Step 6 复盘。复盘负责归因、生成修正指导，下一批次基于此重试。**严禁因单个 task 失败而停止整个工作流。**

**静默运行原则**：自动连续 batch 期间，每完成一个 batch 发送一条简短通知（含已完成/失败任务数量），不等待用户回复，直接开始下一个 batch。

**强制停止**：用户任意时刻说「停止」→ 将 `master_task.json` 的 `auto_run.remaining` 设为 0，当前 batch 完成后不再继续。

---

### 5) 结果评分 + 核心目标校验（V2.0：新增 OB 老化降级）
1. 读取任务 JSON，遍历所有任务：
   - `task_state = blocked`：跳过，不参与评分
   - `task_state = failed`：**不跳过，直接记录评分结果**，`script_score = 0`，`score_reason` 写入失败原因摘要（从 `task_result` 提取），交由 Step 6 复盘处理；**不因 failed 中止 Step 5 流程**
   - `task_state = done` 且 `task_result` 非空：正常评分
2. 对 `done` 任务打分（`script_score` 0~1，0.8 及格）并记录 `score_reason`
   - **绝对红线**：`task_result` 含 `Error/Exception/Traceback` → score 上限 0.5
   - **绝对红线**：`task_result` 为空或关键字段缺失 → score 上限 0.7
3. **注册表回写机制**：若 `script_score < 0.8`，必须同步将该评分回写至脚本注册表，强制覆盖或降低全局 score，防止该失败脚本下一轮被误选；**回写时同样必须确保 `target_web` 字段已填写（填写当前 `goal_web` 实际值）**
4. **（V2.0 新增）OB 脚本老化降级机制**：
   - 触发条件：该任务的 `source = registry`（从注册表召回）且 `script_score < 0.8`
   - 触发后执行以下两步：
     1. **降低权重**：在 `script_registry.json` 中找到对应记录，将 `score` 强制下调（基准：旧 score × 0.7，最低降至 0.3），`score_reason` 追加 `「[{date}] 召回执行失败，权重自动降级，需人工审查」`
     2. **追加老化标签**：在该记录中新增 `"tags": ["needs_update", "deprecated_by_{date}"]` 字段（若已有 tags 则追加，不覆盖）
   - 效果：下一轮 Step 3 检索时，该脚本因 score < 0.8 而被过滤，强制进入重新开发（Step 3.1）流程
   - 不触发条件：`source = new`（本批次新开发的脚本失败，只做常规注册表 score 回写，不走老化流程）
5. 核心目标校验：
   - 评估已完成任务集合是否足以达成 `core_goal`
   - 若不足：列出欠缺任务清单，追加回任务列表（`task_state = pending`，`task_result = null`），回到 Step 2

> 示例见：`references/step5_example.md`

---

### 6) 全局复盘与下一批次输入生成
> **必须通过 Prompt 注册表查找**复盘 Prompt，禁止自行简化或替换。

1. **读取 retro_prompt（通过注册表查找）**：
   ```
   读取 references/prompts/prompt_registry.md
     → 查找 type=复盘 AND web={goal_web} 的记录
     → 找到 → 读取该记录 path 指向的 Prompt 文件
     → 未找到 → fallback：读取 references/prompts/retro_prompt.md
   ```
2. 填充三个输入变量：
   - `{current_task_json}`：当前批次最终任务 JSON（含 `task_state` / `task_result` / `script_score` / `score_reason`）
   - `{current_run_log}`：当前批次完整运行日志（读取 `run/{date}/{batch_seq}/运行日志_*.md`）
   - `{past_3_runs_logs}`：**（V2.0 变更）** 不再读取原生 .md 日志，改读过去 3 个批次的 `compressed_log.json`（路径：`run/*/*/compressed_log.json`，按 batch_seq 倒序取最近 3 个）；若 compressed_log.json 不存在则 fallback 到原生 .md 日志
3. 执行复盘 Prompt（已通过注册表加载），按 Prompt 模板规则分析：
   - 现状评估：提取失败任务，定位根本原因
   - 历史模式识别：检查死循环，若命中则强制要求下一轮改变技术路线
   - 构建下一批次输入：步进 `batch_seq`，继承/细化 `core_goal`，生成 `blacklist` 与 `next_batch_guidance`，打包结转任务
4. 输出严格合法的 JSON，字段必须包含：
   - `batch_seq` / `goal_web` / `core_goal` / `workflow_status`
   - `core_flow`：**必须透传**，与上游保持一致（null 时写 null，非空时原样透传，不得丢失）
   - `retrospective_context`（`failed_tasks_summary` / `historical_patterns` / `lessons_learned`）
   - `next_batch_guidance`（`task_breakdown_advice` / `development_constraints` / `avoid_pitfalls` / **`blacklist`**）
   - `carry_over_tasks`
   - `flow_violations`：**【core_flow 非空时必须输出，为空/null 时省略】** 记录本批次中 `flow_compliant = false` 的任务列表，格式：
     ```json
     "flow_violations": [
       {
         "task_id": 2,
         "task": "任务名",
         "expected_flow_step": "core_flow 中要求的流程环节",
         "actual_behavior": "实际执行时偏离的具体描述",
         "root_cause": "偏离原因分析",
         "fix_suggestion": "下一批次如何修正"
       }
     ]
     ```
     若本批次无违反（所有 `flow_compliant = true`）：写 `"flow_violations": []`
   - `user_feedback`（详见下方规范，**若本批次有用户反馈则必须写入，无则省略该字段**）
   - **禁止输出任何 JSON 以外的文字或 Markdown**

#### user_feedback 字段规范

**触发条件**：用户说「把以下反馈写入 {goal_web}」/ 「加入反馈」/ 「写入用户反馈」等。

**写入目标**：当前批次的 retro 文件（`tasks/{goal_web}_retro_{batch_seq}.json`），**只写当期，不累积**。

**字段格式**：
```json
"user_feedback": {
  "priority": "HIGH",
  "date": "YYYY-MM-DD",
  "feedback": [
    "用户反馈内容1",
    "用户反馈内容2"
  ]
}
```

**字段说明**：
- `priority`：固定为 `HIGH`，无论内容如何，用户反馈永远最高优先级
- `date`：写入日期（当天）
- `feedback`：用户反馈条目数组，逐条写入，不合并、不改写原意

**下一批次读取机制**：
Step 1 读取 `branch_context` 时，若上一批次 retro 文件含 `user_feedback` 字段，**必须**：
1. 提取 `user_feedback.feedback` 数组
2. 在 Step 2 任务拆解时，将每一条 feedback 转化为显式约束或 task，优先级高于 `next_batch_guidance`
3. 在 master_task.json 的 `branch_context` 中透传 `user_feedback`，直到该批次任务全部完成为止
5. **复盘 JSON 保存路径**：
   - 主路径（Step 1 读取上游用）：`tasks/{goal_web}_retro_{batch_seq}.json`（例：`tasks/微博_retro_001.json`）
   - 归档路径（日志用）：`run/{date}/{batch_seq}/retro_output.json`（同时写入，保持日志完整性）
6. **（V2.1 新增）元学习计数器更新**：retro JSON 写入完成后，立即更新 `tasks/master_task.json` 的 `branch_context.meta_optimization`：
   - `batches_since_last_opt += 1`
   - 若 `batches_since_last_opt < 10`：继续正常流程，进入 Step 7 → 下一 Batch
   - 若 `batches_since_last_opt == 10`：**冻结引擎**，不进入下一 Batch，切入 **Step 6.5 元学习进化流**
7. 将输出 JSON 直接作为下一批次 **Step 1 读取输入** 的上游 JSON，自动触发下一轮工作流

---

### 6.5) 元学习进化流（Meta-Learning Evolution）【V2.1 新增，triggered when batches_since_last_opt == 10】

> **目标**：在完成 10 个批次后，自动审视失败模式，重写底层拆解/复盘 Prompt，实现系统方法论的版本迭代。
> **事件驱动**：由 Step 6 末尾的计数器检查触发，非 Cron，无竞态冲突风险。

#### 6.5.1 提取诊断上下文（防 Token 膨胀）

向上追溯，读取过去 **5 个批次**的 retro 文件（`tasks/{goal_web}_retro_*.json`，取最近 5 个）：

只提取以下两个字段：
- `retrospective_context.historical_patterns`
- `retrospective_context.lessons_learned`

将提取结果合并，生成一段《平台演进与系统瓶颈诊断报告》，格式：

```
【{goal_web} 平台近5批次诊断报告】
历史死循环模式：
- [来自各批次 historical_patterns 的去重合并]

核心教训：
- [来自各批次 lessons_learned 的去重合并]

高频失败根因：
- [出现 ≥ 2 次的失败类型，按频率排序]
```

#### 6.5.2 确定当前 Prompt 版本

从 `tasks/master_task.json` 读取 `branch_context.meta_optimization.prompt_iteration_seq`（如 `000`）。

从 `references/prompts/prompt_registry.md` 查找当前 `goal_web` 平台使用的 Prompt 文件路径：
- `type=任务拆解` → 当前 goal_prompt 路径
- `type=复盘` → 当前 retro_prompt 路径

读取这两个文件的完整内容，作为「待升级的当前 Prompt」。

#### 6.5.3 调用 meta_prompt 重写 Prompt（认知升级）

读取 `references/prompts/meta_prompt.md`，以其为角色框架，组装以下输入：

```
输入一：《平台演进与系统瓶颈诊断报告》（6.5.1 生成）
输入二：当前 goal_prompt 全文
输入三：当前 retro_prompt 全文
输入四：references/prompts/prompt_authoring_guide.md 中的字段规范（Schema 约束）

系统指令：
你是一个高级 Prompt 架构师，专为 {goal_web} 平台服务。
请审视这 5 轮的失败教训和死循环模式，找出当前拆解 Prompt 和复盘 Prompt 的思维盲区。
重写这两个 Prompt，强制加入针对上述失败模式的约束条款，提升对该平台规则变动和反爬机制的适应力。
输出格式必须完全遵循 prompt_authoring_guide.md 的字段规范，不得引入新字段或删除必填字段。
```

生成两份新 Prompt 全文：`new_goal_prompt` 和 `new_retro_prompt`。

#### 6.5.4 版本控制：另存为新版本（禁止覆盖）

计算新版本号：`new_seq = prompt_iteration_seq + 1`（格式三位数字，如 `001`）

**写入两个新文件**（不覆盖旧文件）：
- `references/prompts/goal_prompt_{goal_web}_v{new_seq}.md` ← 新 goal_prompt 内容
- `references/prompts/retro_prompt_{goal_web}_v{new_seq}.md` ← 新 retro_prompt 内容

**更新注册表** `references/prompts/prompt_registry.md`：
- 找到 `type=任务拆解 AND web={goal_web}` 的行 → 将 `path` 更新为新文件路径，在描述末尾追加 `[v{new_seq} auto-evolved {date}]`
- 找到 `type=复盘 AND web={goal_web}` 的行 → 同上

若注册表中无该平台记录（首次为该平台生成专属 Prompt）→ 追加新行。

#### 6.5.5 重置计数器 + 进化完成通知

更新 `tasks/master_task.json`：
```json
"meta_optimization": {
  "prompt_iteration_seq": "{new_seq}",
  "batches_since_last_opt": 0
}
```

向用户发送一条进化完成通知（不中断后续流程）：
```
🧬 {goal_web} Prompt 进化完成！
版本：v{old_seq} → v{new_seq}
核心改进：[用1-2句话总结本次重写的主要变更点]
旧版本保留在 references/prompts/ 可随时回滚
```

进化完成后，自动进入 Step 7（成功经验入库），然后继续正常的下一 Batch 流程。

#### 6.5.6 回滚机制

若下一批次执行后发现 Prompt 进化导致任务 JSON 解析严重失败（连续 2 个批次全部 failed），在 retro 的 `next_batch_guidance.development_constraints` 中加入：

```
Prompt 回滚指令：将 prompt_registry.md 中 {goal_web} 的 path 指针从 v{new_seq} 改回 v{old_seq}，
并将 master_task.json 的 prompt_iteration_seq 回滚为 {old_seq}。
```

---

### 7) 成功经验入库（Knowledge Ingestion）【V2.0 新增，在 Step 6 之后执行】

> **目标**：将高分成功路径固化为标准知识写入脚本注册表，充实知识飞轮，避免未来重复开发同类脚本。

**触发条件**：Step 6 复盘完成后，自动进入 Step 7（不需要用户触发）。

#### 7.1 筛选候选任务

从当前批次任务 JSON 中筛出满足以下全部条件的任务：
- `task_state = done`
- `script_score >= 0.8`
- `source = new`（本批次全新开发，非从注册表召回）

若无满足条件的任务 → Step 7 静默跳过，不写任何文件。

#### 7.2 长期价值评估

对每个候选任务，用以下微型 Prompt 判断其通用价值：

```
该任务路径是否满足以下条件（Yes/No/Partial）：
1. 解法不依赖特定日期/特定数据，未来同类任务可复用？
2. 核心逻辑对同平台（{goal_web}）其他批次有参考价值？
3. 与注册表已有脚本无高度重叠（相似度 < 80%）？

全部 Yes → 入库
任一 No → 跳过（记录原因）
```

#### 7.3 写入脚本注册表

满足条件的脚本，更新 `references/script_registry.json` 中对应记录，补充以下字段：
- `ingested_at`：入库日期（`YYYY-MM-DD`）
- `ingestion_reason`：入库理由（1句话，为什么认为可复用）
- `tags`：追加 `["verified", "batch_{batch_seq}"]`

> **约束**：Step 7 不产生任何新文件，只更新 `script_registry.json` 已有记录或追加新记录（若该脚本尚未注册）。注册表是唯一写入目标。

#### 7.4 Step 7 完成日志

在当前批次的 `compressed_log.json` 中追加字段：
```json
"step7_ingestion": {
  "candidates": 2,
  "ingested": 1,
  "skipped": 1,
  "skip_reason": "与已有脚本 auto_ph.py 重叠度 > 80%"
}
```

---

## Prompt 生产流程（独立章节，不干扰批次任务流程）

> 触发条件：Step 0.0 识别到意图 = Prompt 生产

### P1）确认生产参数

从用户输入提取：
- `prompt_type`：`任务拆解` 或 `复盘`
- `goal_web`：目标平台（如 `同花顺`、`东方财富`）

若任一字段缺失，询问用户后继续，不擅自猜测。

---

### P2）读取上下文（欠缺2修复）

自动收集生产所需的上下文，**不需要用户手动提供**：

```
读取 references/prompts/prompt_authoring_guide.md
  → 提取对应 prompt_type 的输入字段规范 + 输出字段规范（作为硬性 Schema）

读取 references/core_goal.json
  → 提取 goal_web 对应的 core_goal（作为业务背景）

读取最近 3 个 tasks/{goal_web}_retro_*.json
  → 提取 lessons_learned / historical_patterns / 平台特有约束
  → 作为「平台专属 Prompt 约束」注入 Lyra 的 USER INPUT
```

---

### P3）调用 meta_prompt 生产 Prompt 正文

以 `references/prompts/meta_prompt.md` 作为 Lyra 角色，组装以下三段输入：

```
1. User Requirement and Goal：
   「生产一个用于 {goal_web} 平台的 {prompt_type} Prompt。
    平台特有约束：[来自 P2 步骤提取的 retro 约束]
    核心目标：[来自 core_goal]」

2. Input JSON Schema Specification：
   [来自 prompt_authoring_guide.md 的输入字段规范]

3. Output JSON Schema Specification：
   [来自 prompt_authoring_guide.md 的输出字段规范]
```

以 DETAIL MODE 执行 Lyra 4-D 方法论（DECONSTRUCT → DIAGNOSE → DEVELOP → DELIVER），输出最终 Prompt 正文。

---

### P4）字段校验

对照 `prompt_authoring_guide.md` 校验生产出的 Prompt：
- 输入字段名 / 类型 / 默认值是否与规范一致？
- 输出 JSON 字段名 / 层级是否与规范一致？
- 若有不一致 → 自动修正后继续，不需要用户介入

---

### P5）命名 + 写入文件

命名规则：
- 任务拆解：`goal_prompt_{goal_web}.md`
- 复盘：`retro_prompt_{goal_web}.md`

写入路径：`references/prompts/{文件名}`

---

### P6）自动写入 prompt_registry.md（欠缺3修复）

在 `prompt_registry.md` 的注册表中追加一行：

```markdown
| {文件名（不含.md）} | {prompt_type} | {goal_web} | {一句话描述，含平台专属约束关键词} | `references/prompts/{文件名}` | {通用版名称} |
```

---

### P7）完成通知

向用户输出：
```
✅ Prompt 生产完成
文件：references/prompts/{文件名}
注册：prompt_registry.md 已追加记录
下次触发 {goal_web} 批次时，Step 1/Step 6 将自动调用此 Prompt
```

---

> **隔离原则**：Prompt 生产流程完全独立，不写入 master_task.json，不影响任何批次任务的 batch_seq / retro / task 文件。

---

## 输出检查清单（V2.0 已更新）
- [ ] **Step 0**：`tasks/master_task.json` 是否已生成，含 `runtime_goal_web` / `runtime_core_goal` / `runtime_core_flow` / `trigger_source` / `branch_context`
- [ ] **core_flow 读取**：是否按优先级（用户输入 > retro > core_goal.json）读取 `core_flow`，为空/null 时写 null 而非省略字段
- [ ] **Step 0**：`goal_web` 来源是否记录在 `context_source.goal_web_from`（user_input / core_goal_json / prompted）
- [ ] **Step 0**：若情况三（解析不出 web），是否已向用户询问并等待确认，而非擅自猜测
- [ ] **Step 0**：`references/hook_config.json` 是否已读取，`master_task.json` 中 `auto_run` 字段是否已初始化（`total` / `remaining` / `current_run`）
- [ ] **Step 1**：是否先读取 `references/prompts/prompt_registry.md`，按 `type=任务拆解 + web={goal_web}` 查找，未找到才 fallback 到通用 `goal_prompt.md`
- [ ] **Step 1（core_flow）**：`runtime_core_flow` 是否已从 master_task.json 读取并准备注入 Step 2
- [ ] **Step 6**：是否先读取 `references/prompts/prompt_registry.md`，按 `type=复盘 + web={goal_web}` 查找，未找到才 fallback 到通用 `retro_prompt.md`
- [ ] **Prompt 注册表**：新增平台专属 Prompt 时，是否已同步更新 `references/prompts/prompt_registry.md`
- [ ] **Prompt 生产流程**：Step 0.0 是否优先识别「Prompt 生产」意图，识别到后是否跳转至 Prompt 生产流程而非批次任务流程
- [ ] **Prompt 生产 P2**：是否自动读取 authoring_guide（Schema）+ core_goal.json（业务背景）+ 最近3个 retro（平台约束），无需用户手动提供
- [ ] **Prompt 生产 P4**：是否对照 authoring_guide 校验字段，发现不一致时自动修正
- [ ] **Prompt 生产 P6**：是否自动追加 prompt_registry.md 记录（不依赖用户手动操作）
- [ ] **隔离性**：Prompt 生产流程是否未修改 master_task.json / batch_seq / retro 等批次任务文件
- [ ] **全自动化约束**：全流程是否未向用户要求任何人工介入（attach Tab / 点击 / 确认 / 提供数据）？若任务因环境缺失失败，是否已回写 `task_state: "failed"` + 失败原因，而非停下来等待？
- [ ] **Step 0**：若 `trigger_source = auto_hook`，是否从上一个 master_task 继承 `remaining` 而非重新读取 hook_config
- [ ] **Step 4**：所有 task 完成后，是否触发 `on_batch_complete` 钩子，检查 `remaining` 并决定是否继续
- [ ] **Step 4**：有 task failed 时，是否**不中断流程**，直接继续判断 `remaining` 推进至 Step 5→6（失败状态已回写 task_result，复盘兜底）
- [ ] **Step 4**：自动连续运行时，是否在每个 batch 完成后发送简短进度通知（含失败任务数），但不等待用户回复
- [ ] 任务 JSON 是否包含全部字段（含 `goal_web` / `core_flow` / `task_script_seq` / `task_script`）
- [ ] `goal_web / core_goal / core_flow / date / batch_seq` 是否与 core_goal.json 和上游保持一致
- [ ] **Step 2（core_flow 非空）**：每个 task 是否含 `flow_step` 字段，且任务顺序是否与 `core_flow` 流程步骤严格一致
- [ ] **Step 2（core_flow 非空）**：无法执行的流程环节是否以 `task_state: blocked` 的占位任务显式表示
- [ ] **Step 4（core_flow 非空）**：每个 task 执行完毕后是否回写了 `flow_compliant` 字段（true/false/null）
- [ ] **Step 6（core_flow 非空）**：retro JSON 是否含 `flow_violations` 字段，列出所有 `flow_compliant=false` 的任务及归因
- [ ] **Step 6（core_flow 透传）**：retro JSON 是否含 `core_flow` 字段，值与上游一致（null→null，非空→原样）
- [ ] 任务 JSON 是否保存至 `tasks/{goal_web}_tasks_{batch_seq}.json`
- [ ] `task_state` 是否已明确设置（`done` / `failed`），不存在 `pending` 状态的已执行任务
- [ ] `task_result` 是否已写回（非 null）
- [ ] 若产生技术方案：是否按命名规范保存为 Markdown，且包含 `{goal_web}` 平台约束
- [ ] 脚本注册表是否已写入本批次新开发脚本的 score、script_description 与 **`target_web`**（必填，值为当前 `goal_web`）
- [ ] 若 `script_score < 0.8`：注册表中对应脚本 score 是否已降级回写，且 `target_web` 字段是否已填写
- [ ] Step 6 复盘 JSON 的 `next_batch_guidance` 是否含 `blacklist` 字段（结构化路径列表）
- [ ] 运行日志是否已生成并保存
- [ ] Step 6 复盘 JSON 是否已写入以下两个路径：
  - `tasks/{goal_web}_retro_{batch_seq}.json`（Step 1 上游读取用）
  - `run/{date}/{batch_seq}/retro_output.json`（日志归档用）
- [ ] Step 6 复盘 JSON 中是否含 `goal_web` 字段，确保下一批次可正确继承
- [ ] 若本批次有用户反馈：retro JSON 中是否含 `user_feedback` 字段，`priority` 是否为 `HIGH`，`feedback` 数组是否完整写入
- [ ] Step 1 读取上游 retro 时，若含 `user_feedback`：是否已将每条 feedback 转化为本批次任务约束（优先级高于 `next_batch_guidance`）
- [ ] Step 1 读取上游时，是否严格按 `tasks/{goal_web}_retro_*` 过滤，未跨平台读取
- [ ] 若该平台在 `tasks/` 下无历史文件：`batch_seq` 是否从 `001` 开始，且任务 JSON 已写入 `tasks/{goal_web}_tasks_001.json`

### V2.0 新增检查项

- [ ] **Step 2（DAG）**：任务 JSON 中每个任务是否均有 `depends_on` 字段（空数组或前置 ID 列表），无缺漏
- [ ] **Step 2（DAG）**：是否设计了至少一对可并发执行的无依赖任务（`depends_on: []`），而非全链式串行
- [ ] **Step 3.2（沙盒预检）**：新开发脚本是否执行了 `python3 -m py_compile` 或 `bash -n` 静态检查
- [ ] **Step 3.2（自愈）**：若检查失败，是否进入局部自愈循环（最多 3 次重试），超限后是否标记 failed 而非无限重试
- [ ] **Step 3.2（放行）**：只有通过静态检查的脚本路径，才写入 `task_script` 字段
- [ ] **Step 4（并发）**：执行引擎是否按 DAG 就绪态调度，而非按数组顺序串行执行
- [ ] **Step 4（blocked）**：前置任务 failed 时，后继任务是否标记为 `blocked`（而非 pending 或直接 failed）
- [ ] **Step 4（双轨日志）**：是否在所有 task 回写完成后，**同时**生成 `运行日志_*.md`（轨道A）和 `compressed_log.json`（轨道B）
- [ ] **Step 4（compressed_log）**：`compressed_log.json` 中 `action_sequence` 是否为关键动作序列（非原始 stdout），`error_trace` 是否只含最底层异常行
- [ ] **Step 5（source 字段）**：任务 JSON 中是否记录了 `source` 字段（`registry` 或 `new`）
- [ ] **Step 5（OB 老化）**：若 `source=registry` 且 `script_score < 0.8`，是否执行了两步降级：①注册表 score 下调至旧值×0.7 ②追加 `needs_update` / `deprecated_by_{date}` 标签
- [ ] **Step 6（压缩日志）**：`{past_3_runs_logs}` 变量是否读取的是 `compressed_log.json` 而非原生 .md（若无压缩日志则已 fallback）
- [ ] **Step 7（筛选）**：是否扫描了本批次 `source=new` + `score>=0.8` + `done` 的任务
- [ ] **Step 7（评估）**：对候选任务是否完成了通用价值三问评估（非特例性 / 平台可复用 / 无重叠）
- [ ] **Step 7（写入）**：满足条件的脚本是否在 `script_registry.json` 中追加了 `ingested_at` / `ingestion_reason` / `tags`
- [ ] **Step 7（日志）**：`compressed_log.json` 中是否含 `step7_ingestion` 字段，记录候选数 / 入库数 / 跳过原因

### V2.1 新增检查项（元学习进化）

- [ ] **Step 0.2（初始化）**：master_task.json 中是否含 `branch_context.meta_optimization` 字段（`prompt_iteration_seq` + `batches_since_last_opt`）
- [ ] **Step 0.2（继承）**：续批次时 `meta_optimization` 是否从上一个 master_task.json 继承，而非重置为 0
- [ ] **Step 0.2（跨平台隔离）**：goal_web 切换时，`meta_optimization` 是否各自独立，不互相污染
- [ ] **Step 6（计数）**：每次 Step 6 retro 写入完成后，是否执行 `batches_since_last_opt += 1` 并写回 master_task.json
- [ ] **Step 6（触发判断）**：计数器更新后，是否判断 `batches_since_last_opt == 10`，满足则切入 Step 6.5，不满足则继续正常流程
- [ ] **Step 6.5（上下文提纯）**：是否只读取近 5 批次 retro 的 `historical_patterns` + `lessons_learned` 两个字段，而非全量 retro 内容
- [ ] **Step 6.5（meta_prompt）**：是否读取了 `references/prompts/meta_prompt.md` + `references/prompts/prompt_authoring_guide.md` 作为生成约束
- [ ] **Step 6.5（版本控制）**：新 Prompt 是否以 `goal_prompt_{goal_web}_v{seq}.md` / `retro_prompt_{goal_web}_v{seq}.md` 命名另存，而非覆盖旧文件
- [ ] **Step 6.5（注册表更新）**：`prompt_registry.md` 中对应平台的 `path` 指针是否已切换到新版本文件
- [ ] **Step 6.5（计数器重置）**：进化完成后，`prompt_iteration_seq` 是否进位，`batches_since_last_opt` 是否清零
- [ ] **Step 6.5（进化通知）**：是否向用户发送了包含版本号和核心改进点的进化完成通知
- [ ] **Step 6.5（回滚条款）**：若新版本导致连续 2 批次全失败，retro 的 `development_constraints` 中是否写入了回滚指令