docs: Phase v1 PR 7 — adopter docs aligned with v1 audit-skills (3 langs)

dist/.devtrail/00-governance/AGENT-RULES.md

@@ -301,11 +301,17 @@ My recommendation: [YES / NO], because:
   - <one specific reason grounded in the Charter, AILOGs, or diff>
 
 If you decide to audit:
-  Run /devtrail-audit-prompt <CHARTER-ID> and I will surface the two
-  prompts inline. Once you have the responses from the external
-  auditors saved to canonical paths, run /devtrail-audit-review
-  <CHARTER-ID> and I will calibrate them locally and merge the
-  findings into the Charter telemetry.
+  Run /devtrail-audit-prompt <CHARTER-ID> and I will write the unified
+  audit prompt to .devtrail/audits/<CHARTER-ID>/audit-prompt.md.
+  Then open one or more auditor-side CLIs (gemini-cli, claude-cli,
+  copilot-cli, codex-cli) in this repo and invoke
+  /devtrail-audit-execute <CHARTER-ID> in each — recommendation: at
+  least 2 auditors of different model families. When and only when
+  ALL auditors you commissioned have completed, return here and run
+  /devtrail-audit-review <CHARTER-ID>. I will consolidate the N
+  reports into a review.md document with verdicts, remediation plan,
+  and auditor ratings, and merge the YAML block into the Charter
+  telemetry.
 
 If you decide not to audit:
   Continue with `devtrail charter close <CHARTER-ID>` when you're
@@ -341,7 +347,7 @@ These are heuristics, not rigid rules — you are close to the context, refine t
 - The checkpoint is **never** repeated within the same Charter once the developer responds.
 - The checkpoint **does not** block any subsequent action. If the developer ignores it and runs `charter close`, close proceeds normally — there is no enforcement and there will not be (this is a permanent v0+v1 design decision; see `Propuesta/devtrail-audit-skills.md` §2.2).
 - The checkpoint is **not** counted in any quality metric. There is no "% Charters audited" KPI in `devtrail metrics` — by design, to avoid creating an incentive to inflate the audit count.
-- If the developer accepts the audit, the next two skills (`/devtrail-audit-prompt` then `/devtrail-audit-review`) carry the workflow forward.
+- If the developer accepts the audit, the workflow proceeds via three skills in sequence: `/devtrail-audit-prompt` (writes the unified prompt at the canonical path) → `/devtrail-audit-execute` × N (one per auditor-side CLI the operator opens — these run in those CLIs, not in the main agent) → `/devtrail-audit-review` (consolidates N reports inline into `.devtrail/audits/<id>/review.md` and merges the YAML into telemetry). Operators never copy/paste prompts or reports — file exchange happens via canonical paths under `.devtrail/audits/`.
 
 ---
 

dist/.devtrail/00-governance/QUICK-REFERENCE.md

@@ -213,8 +213,9 @@ Mark `review_required: true` when:
 | `/devtrail-new` | Create any document type (interactive) |
 | `/devtrail-ailog` / `/devtrail-aidec` / `/devtrail-adr` | Quick shortcuts for AILOG / AIDEC / ADR |
 | `/devtrail-mcard` / `/devtrail-sec` | Interactive flows for Model Card / SEC assessment |
-| `/devtrail-audit-prompt CHARTER-XX` *(fw-4.8.0+)* | External multi-model audit — generate prompts inline |
-| `/devtrail-audit-review CHARTER-XX` *(fw-4.8.0+)* | Calibrate audit responses + merge into Charter telemetry |
+| `/devtrail-audit-prompt CHARTER-XX` *(fw-4.8.0+, refactored in fw-4.9.0)* | External multi-model audit — write unified prompt at canonical path |
+| `/devtrail-audit-execute [CHARTER-XX]` *(fw-4.9.0+)* | Run inside an auditor CLI — read prompt, audit with tool use, write report |
+| `/devtrail-audit-review CHARTER-XX` *(fw-4.8.0+, expanded in fw-4.9.0)* | Consolidate N reports into review.md (6 sections) + merge YAML into telemetry |
 
 ---
 

dist/.devtrail/00-governance/i18n/es/AGENT-RULES.md

@@ -301,11 +301,17 @@ Mi recomendación: [SÍ / NO], porque:
   - <razón concreta basada en el Charter, AILOGs o diff>
 
 Si decides auditar:
-  Ejecuta /devtrail-audit-prompt <CHARTER-ID> y te imprimo aquí mismo
-  los dos prompts. Cuando tengas las respuestas de los auditores externos
-  guardadas en los paths canónicos, ejecuta /devtrail-audit-review
-  <CHARTER-ID> y yo calibro localmente y mergeo los findings en la
-  telemetría del Charter.
+  Ejecuta /devtrail-audit-prompt <CHARTER-ID> y yo escribo el prompt
+  unificado de auditoría en .devtrail/audits/<CHARTER-ID>/audit-prompt.md.
+  Después abre una o más CLIs auditoras (gemini-cli, claude-cli,
+  copilot-cli, codex-cli) en este repo e invoca
+  /devtrail-audit-execute <CHARTER-ID> en cada una — recomendación: al
+  menos 2 auditores de familias de modelo distintas. Cuando y solo
+  cuando TODAS las auditorías que encargaste hayan terminado, regresa
+  aquí y ejecuta /devtrail-audit-review <CHARTER-ID>. Yo consolido los
+  N reports en un documento review.md con veredictos, plan de
+  remediación y calificación de auditores, y mergeo el bloque YAML en
+  la telemetría del Charter.
 
 Si decides no auditar:
   Continúa con `devtrail charter close <CHARTER-ID>` cuando estés listo.
@@ -341,7 +347,7 @@ Son heurísticas, no reglas rígidas — estás cerca del contexto, afínalas co
 - El checkpoint **nunca** se repite dentro del mismo Charter una vez que el developer responde.
 - El checkpoint **no** bloquea ninguna acción posterior. Si el developer lo ignora y corre `charter close`, close procede normalmente — no hay enforcement y no lo habrá (decisión de diseño v0+v1 permanente; ver `Propuesta/devtrail-audit-skills.md` §2.2).
 - El checkpoint **no** se cuenta en ninguna métrica de calidad. No hay KPI "% Charters auditados" en `devtrail metrics` — por diseño, para evitar incentivos a inflar el conteo.
-- Si el developer acepta la auditoría, las siguientes dos skills (`/devtrail-audit-prompt` luego `/devtrail-audit-review`) llevan el workflow adelante.
+- Si el developer acepta la auditoría, el workflow procede vía tres skills en secuencia: `/devtrail-audit-prompt` (escribe el prompt unificado en el path canónico) → `/devtrail-audit-execute` × N (una por CLI auditora que abra el operador — estas corren en esas CLIs, no en el agente principal) → `/devtrail-audit-review` (consolida N reports inline en `.devtrail/audits/<id>/review.md` y mergea el YAML en la telemetría). Los operadores nunca copian/pegan prompts ni reports — el intercambio de archivos sucede vía paths canónicos bajo `.devtrail/audits/`.
 
 ---
 

dist/.devtrail/00-governance/i18n/es/QUICK-REFERENCE.md

@@ -188,8 +188,9 @@ Marcar `review_required: true` cuando:
 | `/devtrail-new` | Crear cualquier tipo de documento (interactivo) |
 | `/devtrail-ailog` / `/devtrail-aidec` / `/devtrail-adr` | Atajos rápidos para AILOG / AIDEC / ADR |
 | `/devtrail-mcard` / `/devtrail-sec` | Flujos interactivos para Model Card / SEC assessment |
-| `/devtrail-audit-prompt CHARTER-XX` *(fw-4.8.0+)* | Auditoría externa multi-modelo — genera prompts inline |
-| `/devtrail-audit-review CHARTER-XX` *(fw-4.8.0+)* | Calibra respuestas de auditoría + mergea en telemetría del Charter |
+| `/devtrail-audit-prompt CHARTER-XX` *(fw-4.8.0+, refactorizada en fw-4.9.0)* | Auditoría externa multi-modelo — escribe prompt unificado en path canónico |
+| `/devtrail-audit-execute [CHARTER-XX]` *(fw-4.9.0+)* | Corre en una CLI auditora — lee prompt, audita con tool use, escribe report |
+| `/devtrail-audit-review CHARTER-XX` *(fw-4.8.0+, expandida en fw-4.9.0)* | Consolida N reports en review.md (6 secciones) + mergea YAML en telemetría |
 
 ---
 

dist/.devtrail/00-governance/i18n/zh-CN/AGENT-RULES.md

@@ -300,10 +300,14 @@ confidence: high | medium | low
   - <基于 Charter、AILOGs 或 diff 的具体原因>
 
 如果决定审计：
-  运行 /devtrail-audit-prompt <CHARTER-ID>，我会在此处直接展示
-  两个 prompts。当你保存了外部审计员的回复到规范路径后，运行
-  /devtrail-audit-review <CHARTER-ID>，我会在本地校准并将
-  findings 合并到 Charter 遥测中。
+  运行 /devtrail-audit-prompt <CHARTER-ID>，我会将统一审计 prompt
+  写入 .devtrail/audits/<CHARTER-ID>/audit-prompt.md。然后在此仓库中
+  打开一个或多个审计员 CLI（gemini-cli、claude-cli、copilot-cli、
+  codex-cli），并在每个中调用 /devtrail-audit-execute <CHARTER-ID> —
+  建议：至少 2 个不同模型族的审计员。当且仅当你委托的所有审计员
+  都已完成时，返回此处并运行 /devtrail-audit-review <CHARTER-ID>。
+  我会将 N 个 reports 合并为 review.md 文档（含判决、修复计划、
+  审计员评分），并将 YAML 块合并到 Charter 遥测中。
 
 如果决定不审计：
   准备好后继续 `devtrail charter close <CHARTER-ID>`。外部审计
@@ -338,7 +342,7 @@ confidence: high | medium | low
 - 检查点在同一 Charter 内一旦 developer 回复就**永不**重复。
 - 检查点**不**阻塞任何后续操作。如果 developer 忽略它并运行 `charter close`，close 正常进行——没有强制执行，将来也不会有（这是 v0+v1 永久设计决策；见 `Propuesta/devtrail-audit-skills.md` §2.2）。
 - 检查点**不**计入任何质量度量。`devtrail metrics` 中没有"已审计 Charter 百分比"KPI——按设计，避免产生虚胖审计计数的激励。
-- 如果 developer 接受审计，接下来的两个 skills（`/devtrail-audit-prompt` 然后 `/devtrail-audit-review`）会推进工作流。
+- 如果 developer 接受审计，工作流通过三个 skills 依次推进：`/devtrail-audit-prompt`（在规范路径写入统一 prompt）→ `/devtrail-audit-execute` × N（每个操作员打开的审计员 CLI 一个 — 这些运行在那些 CLI 中，不在主代理中）→ `/devtrail-audit-review`（在 `.devtrail/audits/<id>/review.md` 中内联合并 N 个 reports 并将 YAML 合并到遥测）。操作员从不复制/粘贴 prompts 或 reports — 文件交换通过 `.devtrail/audits/` 下的规范路径进行。
 
 ---
 

dist/.devtrail/00-governance/i18n/zh-CN/QUICK-REFERENCE.md

@@ -188,8 +188,9 @@ risk_level: low | medium | high | critical
 | `/devtrail-new` | 创建任意类型文档（交互式） |
 | `/devtrail-ailog` / `/devtrail-aidec` / `/devtrail-adr` | AILOG / AIDEC / ADR 的快速快捷方式 |
 | `/devtrail-mcard` / `/devtrail-sec` | Model Card / SEC 评估的交互流程 |
-| `/devtrail-audit-prompt CHARTER-XX` *(fw-4.8.0+)* | 外部多模型审计 — 内联生成 prompts |
-| `/devtrail-audit-review CHARTER-XX` *(fw-4.8.0+)* | 校准审计响应 + 合并入 Charter 遥测 |
+| `/devtrail-audit-prompt CHARTER-XX` *(fw-4.8.0+，在 fw-4.9.0 中重构)* | 外部多模型审计 — 在规范路径写入统一 prompt |
+| `/devtrail-audit-execute [CHARTER-XX]` *(fw-4.9.0+)* | 在审计员 CLI 中运行 — 读取 prompt，使用 tool use 审计，写入 report |
+| `/devtrail-audit-review CHARTER-XX` *(fw-4.8.0+，在 fw-4.9.0 中扩展)* | 合并 N 个 reports 为 review.md（6 节）+ YAML 合并入遥测 |
 
 ---
 

docs/adopters/ADOPTION-GUIDE.md

@@ -502,8 +502,9 @@ devtrail validate
 
 From `fw-4.8.0`, when you co-implement Charters with an AI assistant in the loop (Claude Code, Gemini Code, Cursor), you can optionally run an external multi-model audit at Charter close. Two skills wrap the underlying CLI orchestration:
 
-- **`/devtrail-audit-prompt CHARTER-XX`** — generates the auditor prompts inline in the conversation, ready to paste into 2 LLM auditors of different families.
-- **`/devtrail-audit-review CHARTER-XX`** — back-half: validates the operator-saved auditor responses, runs the calibrator inline, and merges findings into the Charter telemetry directly (`external_audit:` array).
+- **`/devtrail-audit-prompt CHARTER-XX`** — writes the unified audit prompt at the canonical path `.devtrail/audits/<id>/audit-prompt.md`. Operator opens N auditor-side CLIs and runs `/devtrail-audit-execute` in each. No copy/paste.
+- **`/devtrail-audit-execute [CHARTER-XX]`** *(fw-4.9.0+)* — runs inside an auditor-side CLI (gemini-cli, claude-cli, copilot-cli, codex-cli). Reads the prompt, audits with tool use citing `path:line`, writes a report keyed on the auditor's model id.
+- **`/devtrail-audit-review CHARTER-XX`** — consolidates N reports into a six-section `review.md` (Executive summary / Scope / Per-auditor evaluation / Remediation plan P0-P4 / Discarded / Auditor ratings) and merges the `external_audit:` YAML into Charter telemetry.
 
 The agent will **proactively offer** the audit at one specific moment in the workflow — when implementation is done, drift check is clean, and `charter close` has not been invoked. Recommendation is YES/NO based on the Charter's risk surface and complexity (heuristics in `.devtrail/00-governance/AGENT-RULES.md` §12).