{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 读取

合并优先级（高优先级覆盖低优先级）：

text

用户输入（当次触发）> core_goal.json > 分支任务历史数据（retro）

---

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

日志记录规范（必须遵循）#

• 读取并遵循 references/logging.md
• 每次完整执行必须生成主日志文件，命名： 运行日志_{date}_{batch_seq}.md

---

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

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

意图识别（最优先判断）

text

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

---

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

text

用户触发 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：

text

读取 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（通过注册表查找）： text

   读取 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 均为 []

8. 任务 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）跳过本步骤（已验证过）。

执行流程：

text

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 执行器）

text

扫描任务 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 回写完成后触发）

text

所有 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（通过注册表查找）： text

   读取 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，直到该批次任务全部完成为止

4. 复盘 JSON 保存路径：

   • 主路径（Step 1 读取上游用）： tasks/{goal_web}_retro_{batch_seq}.json（例： tasks/微博_retro_001.json）
   • 归档路径（日志用）： run/{date}/{batch_seq}/retro_output.json（同时写入，保持日志完整性）

5. （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 元学习进化流

6. 将输出 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

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

text

【{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，以其为角色框架，组装以下输入：

text

输入一：《平台演进与系统瓶颈诊断报告》（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
}

向用户发送一条进化完成通知（不中断后续流程）：

text

🧬 {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 中加入：

text

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 判断其通用价值：

text

该任务路径是否满足以下条件（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修复）#

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

text

读取 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 角色，组装以下三段输入：

text

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）完成通知#

向用户输出：

text

✅ 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 中是否写入了回滚指令