操作执行（下游路由 · I14）

> 本 skill 是 tri-intent 的下游执行 skill，依据快照 snapshot.md §三 结构化结论直接执行，不再重新识别意图。
> 用户心智：把 AI 当执行者，期望真实「跑起来」产生副作用。

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

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

1. 强制前置：收到 tri-intent 快照且 下游路由建议 指向本 skill，MUST 先读取快照 §三，再按操作执行工作流推进，NEVER 跳过直接调用工具。核心铁律：没有分级判定的操作不执行——不可逆操作跳过确认门即失控。 独立使用时（未经 tri-intent 路由）MUST 先走 §上游依赖检测 判定模式。

2. 操作分级 + 确认门 + 结果返回（硬性规则）：I14 涉及真实副作用，MUST 严格按「解析 → 校验 → 分级 → 确认门 → 执行 → 返回」串行推进：
   - 操作解析：从快照 §三 解析操作对象、参数、目标工具，形成操作清单。
   - 参数校验：校验参数完整性（缺失则回退 clarify）与合法性（不合法则中止并报告）。
   - 操作分级：据 §安全约束的操作分级标准判定每个操作的等级（L0 只读 / L1 可逆 / L2 不可逆 / L3 高风险）。
   - 确认门（L2/L3 操作）：等级为「不可逆」或「高风险」的操作 MUST 先向用户列出操作清单 + 影响范围 + 不可逆说明，待用户明确确认后方可执行，NEVER 默默执行高风险操作。等级为「只读」或「可逆」的操作可直接执行。
   - 执行：确认通过后调用工具执行；执行失败返回原始错误，不擅自重试不可逆操作（可逆操作可有限重试）。
   - 结果返回：返回操作结果（成功/失败状态 + 工具原始回执）；L2/L3 操作附确认记录。
   - 完整链路：解析 → 校验 → 分级 → 确认门（L2/L3）→ 执行 → 返回结果。L2/L3 操作未通过确认门则中止，不得跳门执行。
3. 最小化原则（门禁规则）：进入执行阶段前 MUST 校验操作范围是否最小化——只执行 任务要点 范围内的操作，不执行未明确授权的附加操作。若执行中发现需扩大操作范围，MUST 向用户说明并确认，NEVER 默默扩大范围。
4. 职责边界：本 skill 负责「读取快照 → 解析操作 → 参数校验 → 分级判定 → 确认门 → 执行 → 返回结果」全链路。意图识别（由 tri-intent）、出方案不执行（由 tri-plan）、编码开发（由 tri-coding）不属于本 skill。
5. 自检：作答前用一句话声明「本次意图=I14，已读取快照，操作等级=<L0/L1/L2/L3>，确认门状态=<待确认/已通过/不适用>」，若与上述规则冲突则停止并纠正。

> 若快照 澄清门状态 = 待澄清，本 skill 不应激活，先走 clarify-gate。

触发时机

• tri-intent 产出的快照中 下游路由建议 指向本 skill
• 意图编码范围：I14 操作执行（默认操作执行子类）
• L3 让渡：I14 存在 L3 子类，命中以下语义时 MUST 让渡对应 skill，本 skill 不接管——
• 工作流编排（编排/串联/调度流程）→ tri-workflow
• loop / domain 创建（知识库 loop 启动、substrate bootstrap）→ tri-loop
• sdlc 全生命周期（L3_子意图 = sdlc，端到端项目交付）→ tri-sdlc

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

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

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

模式 B 提示语：
> 本 skill 依赖 tri-intent 进行意图识别与输入校验。当前未检测到 tri-intent。
> 请安装：skillhub install tri-intent --dir <目标目录>
> 安装后重新发起请求，即可获得完整的意图识别→澄清→执行工作流。

输入契约

读取 .tribro/snapshots/<命名>.md 的 §三 结构化结论区：

职责边界

• 本 skill 负责：依据快照结论，对 I14 意图调用工具真实执行动作并返回结果
• 不负责：意图识别（由 tri-intent）、出方案不执行（由 tri-plan）、编码开发（由 tri-coding）、内容文本产出（由 tri-content）
• 关键边界：本 skill「真实执行产生副作用」——只读查询直接执行，不可逆/高风险操作必须经确认门；绝不跳过确认门执行高风险操作
• 与 tri-plan 的协作：tri-plan 产出的任务清单中标注「建议执行 skill=tri-action」的任务，由本 skill 读取并执行
• L3 让渡边界：I14 有 L3 子类分流，本 skill 只处理默认的 L14 操作执行（单次带副作用的动作，如下单/设提醒/发消息/调 API）：

> 命中 L3 子类却路由到本 skill 时，MUST 停止并回退 tri-intent 重新路由，NEVER 越界接管。

• 不触发场景（Not-Trigger）：本 skill 不接手「规划拆解 / 决策建议」（转 tri-plan / tri-ask，本 skill 只执行带副作用的动作）；不接手「编码实现 / 调试」（属 tri-coding / tri-fix）；不接手「长期运行的知识域/循环体」（属 tri-loop，I14 loop 子类）；不接手「识别用户意图」（由 tri-intent / 自身快照驱动）。

操作安全分级方法论（核心能力 · 可扩展）

> 操作安全分级方法论是 tri-action 的核心能力。通过 4 级操作分类（L0 只读 / L1 可逆 / L2 不可逆 / L3 高风险）将每个操作映射到对应确认要求，确保高风险操作有确认、低风险操作不阻塞。这是 tri-action 区别于其它下游 skill 的核心差异化能力。

方法论原理

操作执行类意图横跨只读查询、可逆操作、不可逆操作、高风险操作四种风险等级，统一处理策略无法兼顾安全与效率。本方法论通过分级标准将每个操作映射到对应确认要求（无需确认 / 需确认），以「分级判定 → 确认门 → 执行」链路确保高风险操作有确认门拦截、低风险操作直接执行不阻塞。

方法论概览

> 分级标准表与确认门流程见 §安全约束。处理流程 §步骤 4 据此表判定操作等级，步骤 5 据等级决定是否触发确认门。

可扩展性

1. 新增操作等级：在方法论概览表中追加一行（等级 / 风险特征 / 确认要求 / 失败处理 / 示例），§安全约束 分级标准表自动对齐
2. 新增确认要求维度：在现有「操作清单+影响范围」基础上追加确认维度（如「回滚方案」「监控指标」），确认门流程自动对齐
3. 新增失败处理策略：在方法论概览的失败处理列中追加策略，§执行失败处理表自动对齐

安全约束（最高优先级）

> I14 涉及真实副作用，必须遵守用户全局约束：高风险操作执行前必须向用户确认。本节定义操作分级标准与确认流程。

操作分级标准

确认门流程（L2/L3 操作）

1. 列出操作清单：操作对象 + 操作动作 + 参数 + 目标工具
2. 说明影响范围：受影响的资源/用户/系统
3. 标注不可逆性：明确操作不可撤销
4. 风险评估（L3）：可能的失败后果与影响面
5. 等待用户确认：用户明确同意 → 执行；用户拒绝/修改 → 据反馈调整或中止

执行失败处理

> 铁律：不可逆/高风险操作失败后 NEVER 自动重试——重试可能导致重复副作用（如重复扣款、重复发送）。

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

> 家族级强制技术约束，优先级与「强制执行契约」同级。skill 任一执行入口启动后的第零步，先于核心执行阶段。
> 细则唯一真源：tri-forge/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-action --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 通过 python tri-forge/scripts/sync_registry.py --check。

处理流程

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

> 基于「解析 → 校验 → 分级 → 确认门 → 执行 → 返回」的安全执行链路，确保操作可追溯、高风险操作有确认。

tri-intent 快照 §三 (I14)
        │
        ▼
  操作解析
  · 从快照解析操作对象/参数/目标工具
  · 形成操作清单
        │
        ▼
  参数校验
  · 完整性：缺失则回退 clarify
  · 合法性：不合法则中止并报告
        │
        ▼
  操作分级（据 §安全约束 分级标准）
  · L0 只读 / L1 可逆 / L2 不可逆 / L3 高风险
        │
        ├── L0/L1 ──→ 直接执行
        │
        └── L2/L3 ──→ 确认门
                          │
                     门·操作确认 ──拒绝/修改──→ 据反馈调整或中止
                          │确认通过
                          ▼
                    执行（调用工具）
        │
        ▼
  结果返回
  · 成功/失败状态 + 工具原始回执
  · L2/L3 附确认记录
  · 失败按等级处理（L2/L3 不擅自重试）
        │
        ▼
  交付（操作结果）

阶段速查表

操作对象解析细则

> 参数缺失 MUST 回退 tri-intent 的 clarify-gate 补充；参数不合法 MUST 中止并报告原因，NEVER 臆测参数。

交付产物

一、文件命名规范

沿用 tri-intent 快照命名：<问题类型>_<日期>_<时间>_<会话ID>

• 示例：I14_20250211_143022_6a5c037d

二、存放目录

.tribro/                    # 若不存在则先创建
├── snapshots/              tri-intent 产出（已存在）
│   └── <命名>.md
└── actions/                tri-action 链路文档
    └── <命名>/
        ├── result.md         # 操作结果（最终交付物）
        └── (confirm-log.md)  # 高风险操作确认记录（L2/L3 时）

三、产物清单

四、产物结构规格

产物结构见 templates/result.md 与 templates/confirm-log.md，本 skill 仅消费其字段。

五、质量标准

落盘规则

• 快照由 tri-intent 已落盘于 .tribro/snapshots/
• 本 skill 操作结果落盘于 .tribro/actions/<命名>/
• 高风险操作（L2/L3）MUST 留痕：确认记录（confirm-log.md）与操作结果（result.md）一同落盘，便于审计追溯
• L0/L1 操作结果落盘但可不附确认记录
• 操作日志可覆盖更新（以最新一轮为准），但确认记录一经落盘不得修改（审计完整性）

防篡改机制（confirm-log.md）

> 确认记录是高风险操作审计的核心证据，MUST 具备防篡改能力。

• 哈希附加：confirm-log.md 落盘时计算正文（不含哈希行）SHA-256，以 <!-- HASH:sha256:<hash_value> --> 作为最后一行写入
• 审计验证：审计时去掉哈希行重算并与记录值比对——一致即未被篡改
• 不可篡改性：任何正文修改都会导致哈希不匹配，从而被审计发现

> 详见 scripts/hash_confirm.py，用法：python scripts/hash_confirm.py <file> [--verify <hash>]

目录结构

tri-action/
├── SKILL.md              # 主入口：操作执行工作流定义 + 操作安全分级方法论 + 操作分级标准 + 确认门
├── README.md             # skill 简介与使用说明
├── CHANGELOG.md          # 版本变更历史
├── scripts/              # 确定性逻辑脚本
│   └── hash_confirm.py   # confirm-log.md SHA-256 防篡改哈希计算/校验
├── templates/            # 链路文档模板
│   ├── result.md         # 操作结果模板
│   └── confirm-log.md    # 高风险操作确认记录模板（L2/L3）
└── tests/                # 测试用例
    └── tri-action-full-testcases.md   # 全场景全能力测试用例