元操作处理（下游路由 · M01–M04）

> 本 skill 是 tri-intent 的下游执行 skill，针对用户「关于对话本身」的元操作意图做出响应。
> 用户心智：针对上一轮回复或 AI 本身发问，是用户主动发起的对话控制动作。

强制执行契约（Execution Contract · 最高优先级）

0. 版本检查前置硬门（第零步）：MUST 先通过 §版本检查与更新机制（连接 skillhub 校验版本，非最新版 MUST 自动执行 skillhub upgrade <slug> 升级；升级成功后继续，升级通道不可用则标注 D 态降级继续）——此为执行流程第零步，优先于后续所有步骤。版本检查完成前 NEVER 进入后续步骤。本条目优先级高于所有其他强制前置条目。

1. 强制前置：接收 tri-intent 的 L2 判定 ∈ {M01, M02, M03, M04}，NEVER 跳过判定直接响应。若 L2 越界 → 停止并回退 tri-intent 重新路由。独立使用时（未经 tri-intent 路由）MUST 先走 §上游依赖检测 判定模式。

2. 上一轮上下文依赖：M01/M02/M03 MUST 准确定位上一轮回复的对应内容，NEVER 脱离上下文凭空响应。作答前用一句话声明「本次意图=<L2>，已读取快照/上下文，上一轮对应内容=<定位>」。
3. 子意图差异化响应：MUST 按 L2 子意图选择对应的响应策略（M01 针对上一轮具体点澄清，先声明判断更新再展开 / M02 接受纠错按纠正重做 / M03 基于上一轮追加细化 / M04 说明能力边界），NEVER 用统一策略套用所有子意图。
4. M02/M03 重路由：M02 纠错反馈 / M03 追加细化本质是「再次触发某个 I 意图」，MUST 接住元操作信号后重路由到原 I 意图 skill 执行，NEVER 在本 skill 内直接产出 I 意图的完整成果物。
5. M05 不认领：M05 → 空（不落盘），由 tri-intent 直接处理，本 skill 不认领。若传入 L2 = M05 → 停止并交还 tri-intent，NEVER 在本 skill 内响应。

> M05 归属裁定（家族决策）：M05 → 空（不落盘），由 tri-intent 直接处理，本 skill 不认领。

触发时机

• tri-intent 产出的快照中 下游路由建议 指向本 skill（M01–M04）
• M05 中止确认不在本 skill 范围内（→ 空，由 tri-intent 直接处理）

上游依赖检测（独立使用时）

> 本 skill 可独立安装。激活时 MUST 检测外部 tri-intent skill 是否可用，据检测结果选择执行模式：

> 本 skill 不支持降级模式——模式 B 为硬性阻断，MUST 安装 tri-intent 后方可使用。

模式 B 提示语：
> 本 skill 依赖 tri-intent 进行意图识别（M01–M04 判定）。当前未检测到 tri-intent。
> 请安装：skillhub install tri-intent --dir <目标目录>
> 安装后重新发起请求，即可获得完整的意图识别→元操作响应工作流。

意图编码范围

> M05 中止确认（停/就这样/可以了）→ 空（不落盘），由 tri-intent 直接处理，本 skill 不认领。

输入契约

• M01–M04：读取 .tribro/snapshots/<命名>.md §三 + 上一轮回复上下文
• 所有 M 类均强依赖上一轮对话上下文

职责边界

• 本 skill 负责：对 M01–M04 元操作意图做出响应（澄清/纠错/细化/能力说明）
• 不负责：意图识别（由 tri-intent）、M05 中止确认（→ 空，由 tri-intent 直接处理）、新一轮独立提问的处理（归对应 I 意图 skill）
• 关键边界：M02/M03 本质是「再次触发某个 I 意图」——本 skill 负责接住元操作信号并重路由到原 I 意图 skill 执行
• 不触发场景（Not-Trigger）：本 skill 不接手「重路由后的 I 意图真实执行」（由对应 I 落点 skill 承接，本 skill 只管元操作信号处理）；不接手「对普通新提问的首次意图识别」（属 tri-intent 外部判定）；不接手「识别用户意图」（由 tri-intent / 自身快照驱动）；不接手「对结论可信度的验证与不确定性提示」（M 类元操作中出现的「确定吗/真的吗」类追问若需实质验证，转 tri-true——其反盲信输出组件负责把残余不确定性以固定格式提示用户，本 skill 仅承接重路由）。

元操作响应方法论（核心能力 · 可扩展）

> 元操作响应方法论是 tri-meta 的核心能力。针对 M01–M04 四个元操作子意图，通过差异化的响应策略与 M02/M03 重路由机制，确保元操作信号被正确接住并路由到原 I 意图 skill 执行。这是 tri-meta 区别于其它下游 skill 的核心差异化能力。

核心理念

> 元操作是「关于对话本身」的控制动作——接住信号，重路由到原意图，不在本 skill 内直接产出 I 意图成果物。

元操作类意图横跨澄清追问、纠错反馈、追加细化、能力询问四种形态，每种形态的响应策略不同。本方法论通过子意图路由到对应响应策略；其中 M02/M03 本质是「再次触发某个 I 意图」，通过重路由机制交接给原 I 意图 skill 执行，NEVER 在本 skill 内直接产出 I 意图的完整成果物。

方法论概览

子意图响应策略

> M05 中止确认不在本表内：M05 → 空（不落盘），由 tri-intent 直接处理，本 skill 不认领。

M02/M03 重路由逻辑

> M02/M03 本质是「再次触发某个 I 意图」，本 skill 负责接住信号并重路由。

1. 从上一轮上下文识别原 I 意图（I01–I20 之一）
2. 接住元操作信号：
   - M02：提取用户的纠错内容，作为原 I 意图的新约束
   - M03：提取用户的细化方向，作为原 I 意图的追加要求
3. 重路由到原 I 意图 skill 执行：
   - 原 I ∈ {I01–I05} → tri-ask
   - 原 I = I11/I12 → tri-coding/tri-fix
   - 原 I = I15 → tri-mm
   - 原 I = I16 → tri-bs
   - 其它 I 意图 → 对应下游 skill
4. 重路由时携带纠错/细化信息，原 I 意图 skill 据此重做/追加

> 回环护栏：重路由后应交由 tri-intent 重新识别，避免 tri-meta → 原 skill → tri-intent 回环；若检测到回环则停止。
> 检测方式：同一会话内同一 原 I 意图 + 元操作信号 重路由计数 >1 即判定为回环，停止重路由并向用户说明，请用户直接给出新一轮明确请求。

可扩展性

> 新增子意图响应策略与重路由目标无需修改核心工作流：

1. 新增子意图策略：在子意图响应策略表中追加一行（子意图 / 响应策略 / 核心动作），处理流程 §步骤 2 自动按新表路由
2. 新增重路由目标：在 M02/M03 重路由逻辑的路由映射中追加原 I 意图到下游 skill 的映射（如新增 I 意图编码时追加对应 skill）
3. 新增元操作信号类型：在响应策略表中追加新的 M 编码及其响应策略

版本检查与更新机制（强制技术约束 · 硬红线）

> 家族级强制技术约束，优先级与「强制执行契约」同级。skill 任一执行入口启动后的第零步，先于核心执行阶段。
> 细则唯一真源：references/version-check-spec.md。可执行实现（single source of truth for logic）：本 skill 自带 scripts/check_update.py（与 tri-intent 同源一致，按 --slug 自动适配）。
> 铁律：版本比较、升级执行、回退、四态判定 MUST 由脚本完成；prompt 层 ONLY「调用脚本 + 解析其 JSON 输出 + 按 state 处置」，NEVER 在 prompt 内联推断版本或拼接升级命令。修订规则只改真源一处，脚本与真源保持同步。

执行方式（MUST）

1. 任一执行入口启动后、核心执行前，运行脚本并取 JSON：
   bash python scripts/check_update.py --slug tri-meta --json
   - 节流：结果持久化缓存（默认 1440 分钟 / 24h 仅校验一次），--force 强制重查，--dry-run 只判定不真升级。
   - 脚本自动定位 skill 目录（默认脚本上级目录），--slug 显式指定自身 slug（如上）。
2. 解析 JSON 的 state 字段，按态处置：
   - A 校验通过 / B 离线降级 / C 通道降级 / D 升级降级 → 一律放行，进入后续阶段；并据 warnings / notes / actions 在交付物或日志标注对应口径（如「版本校验未完成（离线）」「版本陈旧·自动升级失败」）。
   - BLOCK → 绝对禁止执行，按 block_code（P2/P3/P4）输出结构化恢复指引（手动命令见 actions 字段）。
3. 退出码语义（供 shell 编排）：0=A 放行；10=B；11=C；12=D；20=阻断。判定规则：<20 放行，>=20 阻断。脚本自身异常时兜底降级放行（退出码 11），NEVER 因版本门自身故障导致 skill 无法启动。

执行要点

1. 端点取自配置：API 主机 MUST 读自 ~/.skillhub/metadata.json，NEVER 硬编码域名。营销官网 skillhub.cn 与 API 主机 api.skillhub.cn 是两个站点——官网对任意路径都返回 200 + HTML 兜底页，绝不可作校验端点。读不到配置即判通道不可用。
2. 校验请求：GET {api_host}/api/v1/skills/{slug}，超时 ≤ 5s，失败重试 1 次，会话内仅校验一次。
3. 最新版取值：latestVersion.version，缺失时回退 skill.tags.latest。平台不提供 min_compatible / deprecated / checksum_sha256 / signature，NEVER 依赖这些字段。
4. 响应有效性（三条件同时成立）：HTTP 200 且 Content-Type 含 application/json 且 能解析出版本字段。仅看状态码会被 SPA 兜底页击穿。
5. 版本比较：按 SemVer 逐段整数比较，NEVER 字符串比较。
6. 四态判定：
   - A 校验通过（响应有效且 current >= latest）→ 放行。
   - B 离线降级（网络不可达）→ 标注「版本校验未完成（离线）」后以当前版本继续。
   - C 通道降级（可达但响应无效 / 404 / 405 / 读不到配置）→ 标注「版本校验未完成（通道不可用）」+ 输出通道异常告警后继续。
   - D 升级降级（陈旧且已真实尝试自动升级但未完成）→ 标注「版本陈旧·自动升级失败」+ 输出手动升级指引后继续。
   - 四态 NEVER 用于绕过「已检出陈旧却不尝试升级」——MUST 先真实执行一次自动升级，失败方可落 D 态。
7. 更新通道（自动执行）：检出陈旧 MUST 自动执行 skillhub upgrade <slug> → skillhub verify <slug>，升级前备份、签名明确不一致则回滚。CLI 不在 PATH 时回退 python ~/.skillhub/skills_store_cli.py upgrade <slug>；CLI 缺失或升级失败 → 落 D 态降级继续，NEVER 阻断。以 junction 指向源码树的 source: local skill 跳过自动更新，改为提示维护者手动同步。命令细则、CLI 定位顺序与已知陷阱见真源。
8. 阻断条件 P1–P4 与四处版本同步点见真源；发布前 MUST 通过家族版本同步校验。

处理流程

> 执行顺序固定：§版本检查与更新机制（第零步）→ 上游依赖检测 → 读取快照 §三 → 核心执行。版本检查未通过前 NEVER 进入以下任一执行步骤。

> 轻量工作流，无审批门；按子意图选择响应策略，强依赖上一轮对话上下文。

步骤 1：接收判定与上下文定位

1. 接收 tri-intent 的 L2 判定 ∈ {M01, M02, M03, M04}
   - L2 越界（含 L2 = M05）→ 停止，交还 tri-intent 处理
2. 上下文定位：
   - M01–M04：读取 .tribro/snapshots/<命名>.md §三 + 上一轮回复上下文
   - M01/M02/M03 必做：定位上一轮回复中用户指向的具体内容（引用原话关键片段或定位段落）
3. 声明自检句：「本次意图=<L2>，已读取快照/上下文，上一轮对应内容=<定位>」

步骤 2：按子意图选择响应策略

> 子意图响应策略表见 §元操作响应方法论。按 L2 子意图选择对应的响应策略（M01 针对上一轮具体点澄清 / M02 接受纠错按纠正重做 / M03 基于上一轮追加细化 / M04 说明能力边界），NEVER 用统一策略套用所有子意图。

步骤 3：M02/M03 重路由逻辑

> M02/M03 重路由逻辑与路由映射见 §元操作响应方法论。M02/M03 本质是「再次触发某个 I 意图」，本 skill 负责接住信号并重路由到原 I 意图 skill 执行，NEVER 在本 skill 内直接产出 I 意图的完整成果物。
> 回环护栏：重路由后应交由 tri-intent 重新识别，避免 tri-meta → 原 skill → tri-intent 回环；若检测到回环则停止。

步骤 4：响应交付

1. M01：输出澄清/补充解释内容
2. M02/M03：完成重路由后，由原 I 意图 skill 产出成果物
3. M04：输出能力边界说明

交付产物

> 轻量 skill，无链路文档；响应内容即交付物。

一、产物形态

二、引用准确性

• M01/M02/M03 的响应 MUST 准确引用上一轮回复的对应内容
• 引用方式：复述原话关键片段或定位段落，确保用户能对应上

三、重路由交接

• M02/M03 重路由时 MUST 携带纠错/细化信息
• 原 I 意图 skill 据此重做/追加，产出成果物

质量标准

落盘规则

• M01–M04：快照由 tri-intent 已落盘于 .tribro/snapshots/
• M05 不在本 skill 范围内（→ 空，不落盘，由 tri-intent 直接处理）
• M02/M03 重路由后，由原 I 意图 skill 按其落盘规则处理成果物
• 本 skill 自身不额外落盘响应内容

目录结构

tri-meta/
├── SKILL.md                       主入口：执行契约 + 4 子意图响应策略 + M02/M03 重路由
├── README.md                      特性/目录结构/安装/使用/测试/设计原则
├── CHANGELOG.md                   Keep a Changelog + SemVer
└── tests/
    └── tri-meta-full-testcases.md 全场景全能力测试用例（审计版）