product-playbook 1.2.10 → 1.2.12

package/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "product-playbook",
   "description": "MUST use when user wants to plan or strategize a product/feature. 22 PM frameworks, 6 modes, multi-language, from idea to dev handoff",
-  "version": "1.2.5",
+  "version": "1.2.12",
   "author": {
     "name": "Charles Chen"
   },

package/README.md

@@ -504,6 +504,57 @@ Two follow-on fixes from PR #9 code review:
 
 **Mirrored to 5 i18n locales** (zh-TW, zh-CN, ja, es, ko).
 
+### Iteration 8: Closed-Loop Self-Correction Pipeline (v1.2.14)
+
+Stage 1 (Sprint 1) made failures *visible*. Stage 2 (manual) confirmed the pattern: critical / warning failures could be flipped by adding **Hard Gate blocks** (rule + FAIL examples + ✅ examples) to the relevant reference file, then mirroring to 5 i18n. Iteration 8 automates that loop end-to-end and ships the result.
+
+**The pipeline that now exists** (each step is a script under `scripts/` exposed as an `npm run` entrypoint):
+
+```
+[manual eval run]
+       ↓
+eval-results.behavioral.json
+       ↓
+scripts/eval-debt-report.py        ← failure → file attribution (no LLM)
+       ↓ per-file fix backlog
+scripts/patch-proposer.py          ← LLM proposes Hard Gate diff (dry-run default)
+       ↓ EN diff for human review
+references/*.md updated by hand-applied diff
+       ↓
+scripts/i18n-mirror-apply.py       ← LLM propagates EN change to 5 langs (dry-run default)
+       ↓ 5-language diffs
+i18n/*/references/*.md updated by --apply
+       ↓
+scripts/i18n-drift-report.py       ← deterministic detector (no LLM) verifies sync
+       ↓ exit 0 = clean
+[manual eval re-run]
+       ↓
+scripts/eval-lift-report.py        ← per-expectation delta + score-vs-real-lift attribution
+```
+
+Two LLM-using tools (`patch-proposer`, `i18n-mirror-apply`) are dry-run by default with `--max N` blast-radius caps and `--apply` gates so the human stays in the loop on every write.
+
+**Orchestrated by `scripts/loop-tick.py`** (`npm run loop:tick`): one command chains Stage 1 → Stage 2 → Stage 3 → Stage 4 (debt report → patch propose → i18n mirror → drift verify), respecting each script's dry-run / `--apply` semantics. The orchestrator never runs an eval itself — that boundary stays manual per the no-CI-auto-eval policy. Each tick appends one record to `docs/loop-history.jsonl` (before-summary, patches proposed/applied, mirrors applied, drift_after, convergence note), so subsequent ticks can detect stalls (`net_lift < +5` for 2 consecutive ticks with unchanged patch count ⇒ stall warning suggesting EVAL_ATTRIBUTION review). Tick exits 0 normally, 1 on subprocess failure, 2 when there's nothing to do (converged — zero criticals in input eval).
+
+**CI policy** changed in tandem: `eval-gate.yml` is now `workflow_dispatch` only (the 2026-05-28 incident where auto-run on PR + push silently exhausted the maintainer's 5-hour subscription quota during Stage 2.3 smoke testing was the trigger). A new lightweight `i18n-drift-check.yml` *does* auto-fire on PR / push touching `references/` or `i18n/` because the detector is deterministic Python with no API calls — notification-only, never blocks merge.
+
+**Numbers from the post-closed-loop local run** (2026-05-29, `--runs 1`, full 12-eval suite, score artifact at [`docs/post-closed-loop-eval-2026-05-29.md`](./docs/post-closed-loop-eval-2026-05-29.md), lift attribution at [`docs/eval-lift-closed-loop.md`](./docs/eval-lift-closed-loop.md)):
+
+| Run | Coverage | Expectations Passing | Critical Failures | Warning Failures | Aggregate Score |
+|---|---|---|---|---|---|
+| Sprint 1 baseline (2026-05-28) | 4 evals (partial) | 13 / 33 (39 %) | 6 | 14 | 0 / `at-risk` |
+| **Post-closed-loop (2026-05-29)** | **12 evals (full)** | **69 / 82 (84 %)** | **5** | **6** | **0 / `at-risk`** |
+
+Aggregate score is capped at 0 in both runs (cumulative severity deductions exceed the 100-point budget), but the underlying movement is dramatic. On the **4 evals shared with the Sprint 1 baseline** (apples-to-apples, 31 paired expectations):
+
+- **17 improved** (fail → pass), including 4 of the Stage 2 critical backlog: 3-layer JTBD, B2B buyer-vs-user separation, Discovery-scope guardrails, B2B organization-level Jobs
+- **2 regressed** — both on `eval-subagent-premortem` category coverage; LLM variance on `--runs 1` that `--runs 3` majority vote is expected to wash out
+- **Net hard lift: +95 points** (gain +125, loss −30)
+
+The 8 evals added to coverage (51 new expectations) close the visibility gap; only `eval-mode-selection`, `eval-security-awareness`, `eval-context-bootstrap`, and `eval-subagent-premortem` still hold the 5 remaining critical failures. Those are the next round's `patch-proposer` targets.
+
+**Mirrored to 5 i18n locales.**
+
 ---
 
 ## 🧪 Development & Evals
@@ -512,7 +563,9 @@ The `evals/` directory ships two complementary test suites and a deterministic s
 
 **Local (free, recommended):** run the same scripts with the `claude` CLI authenticated via your Claude Pro/Max subscription (`claude login` once). No API key, no marginal cost. The eval system is designed to be run locally before each release.
 
-**CI (optional, no extra billing):** `.github/workflows/eval-gate.yml` will run both suites on every PR and on every push to `main` that changes `package.json`, then report the score to the workflow Job Summary. It **never blocks merge or publish** — the maintainer decides whether to act on regressions. CI runs on your Claude Pro/Max subscription (no API key, no per-token cost): one-time setup is `claude setup-token` locally, then add the printed token as repo secret `CLAUDE_CODE_OAUTH_TOKEN`. Without the secret, eval jobs **skip cleanly** (gray ⏭️) instead of failing red.
+**CI (manual trigger only, no extra billing):** `.github/workflows/eval-gate.yml` runs both suites on `workflow_dispatch` — Actions UI → "Eval Report" → "Run workflow", or `gh workflow run eval-gate.yml --ref <branch>`. Auto-trigger on PR / push was removed in Iteration 8 because each run consumes a 5-hour-rolling slice of subscription quota (see the 2026-05-28 incident in the Iteration 8 notes). It **never blocks merge or publish** — the maintainer decides whether to act on regressions. CI runs on your Claude Pro/Max subscription (no API key, no per-token cost): one-time setup is `claude setup-token` locally, then add the printed token as repo secret `CLAUDE_CODE_OAUTH_TOKEN`. Without the secret, eval jobs **skip cleanly** (gray ⏭️) instead of failing red.
+
+A separate lightweight workflow, `.github/workflows/i18n-drift-check.yml`, *does* auto-fire on every PR / push touching `references/` or `i18n/` because the underlying detector is deterministic Python with no API calls. It posts a Job Summary on every run and a PR comment only when critical drift is present. Notification-only, never blocks merge.
 
 ### Running locally
 

package/README.zh-CN.md

@@ -506,6 +506,55 @@ PR #9 review 之后的两个跟进修正：
 
 **已同步至 5 个 i18n 语系**（zh-TW、zh-CN、ja、es、ko）。
 
+### Iteration 8：Closed-Loop 自我修正 pipeline（v1.2.14）
+
+Stage 1（Sprint 1）让失败**可见**。Stage 2（手动）验证了模式：critical / warning 失败可以靠在对应 reference 加上 **Hard Gate 区块**（规则 + FAIL 范例 + ✅ 范例）然后镜像到 5 i18n 来翻过去。Iteration 8 把这个回圈端到端自动化并 ship 结果。
+
+**现在存在的 pipeline**（每一步都是 `scripts/` 下的 script，以 `npm run` 形式暴露）：
+
+```
+[手动 eval run]
+       ↓
+eval-results.behavioral.json
+       ↓
+scripts/eval-debt-report.py        ← 失败 → 文件归属（无 LLM）
+       ↓ 每个文件的修补 backlog
+scripts/patch-proposer.py          ← LLM 提案 Hard Gate diff（预设 dry-run）
+       ↓ EN diff 等人工 review
+references/*.md 由人类审查后套用 diff
+       ↓
+scripts/i18n-mirror-apply.py       ← LLM 把 EN 变动传到 5 语（预设 dry-run）
+       ↓ 5 语 diff
+i18n/*/references/*.md 由 --apply 写回
+       ↓
+scripts/i18n-drift-report.py       ← 确定性 detector（无 LLM）验证同步
+       ↓ exit 0 = 干净
+[手动 eval 重跑]
+       ↓
+scripts/eval-lift-report.py        ← per-expectation delta + 分数 vs 真实 lift 归因
+```
+
+两个用 LLM 的工具（`patch-proposer`、`i18n-mirror-apply`）预设都是 dry-run，搭配 `--max N` 爆炸半径上限与 `--apply` 写档闸门，确保每次写入都有人在回圈内。
+
+**CI 政策**同步调整：`eval-gate.yml` 改成 `workflow_dispatch` only（2026-05-28 的事件 —— auto-run on PR + push 在 Stage 2.3 smoke 测试时悄悄烧光维护者的 5 小时滚动 subscription 配额 —— 是触发点）。一个新的轻量 workflow `i18n-drift-check.yml` *依然*在 PR / push 动到 `references/` 或 `i18n/` 时 auto-fire，因为 detector 是确定性 Python 没有 API 呼叫 —— 通知模式，永不阻塞 merge。
+
+**Closed-loop 跑出来的数字**（本机 run，2026-05-29，`--runs 1`，完整 12 eval，分数 artifact [`docs/post-closed-loop-eval-2026-05-29.md`](./docs/post-closed-loop-eval-2026-05-29.md)，lift 归因 [`docs/eval-lift-closed-loop.md`](./docs/eval-lift-closed-loop.md)）：
+
+| Run | 覆盖 | Expectation 通过 | Critical | Warning | 汇总分数 |
+|---|---|---|---|---|---|
+| Sprint 1 baseline（2026-05-28） | 4 eval（局部） | 13 / 33（39 %） | 6 | 14 | 0 / `at-risk` |
+| **Closed-loop 之后（2026-05-29）** | **12 eval（完整）** | **69 / 82（84 %）** | **5** | **6** | **0 / `at-risk`** |
+
+两轮的汇总分数都压在 0（累积严重度扣分都超过 100 点预算），但底层的移动很剧烈。在跟 Sprint 1 baseline **共享的 4 个 eval**（apples-to-apples，31 paired expectation）：
+
+- **17 improved**（fail → pass），含 4 个 Stage 2 critical backlog：三层 JTBD、B2B buyer-vs-user 分离、Discovery scope 守备、B2B 组织层 Jobs
+- **2 regressed** —— 都在 `eval-subagent-premortem` 的 category coverage；`--runs 1` 的 LLM variance，`--runs 3` majority vote 预期会洗掉
+- **Net hard lift: +95 点**（gain +125、loss −30）
+
+新加入覆盖的 8 个 eval（51 个 expectation）补上可见度缺口；只剩 `eval-mode-selection`、`eval-security-awareness`、`eval-context-bootstrap`、`eval-subagent-premortem` 还挂着 5 个 critical。那些就是下一轮 `patch-proposer` 的目标。
+
+**5 个 i18n 语系同步。**
+
 ---
 
 ## 🧪 开发与评测

package/README.zh-TW.md

@@ -505,6 +505,55 @@ PR #9 review 之後的兩個跟進修正:
 
 **5 個 i18n 語系同步**(zh-TW、zh-CN、ja、es、ko)。
 
+### Iteration 8:Closed-Loop 自我修正 pipeline(v1.2.14)
+
+Stage 1(Sprint 1)讓失敗**可見**。Stage 2(手動)驗證了模式:critical / warning 失敗可以靠在對應 reference 加上 **Hard Gate 區塊**(規則 + FAIL 範例 + ✅ 範例)然後鏡像到 5 i18n 來翻過去。Iteration 8 把這個迴圈端到端自動化並 ship 結果。
+
+**現在存在的 pipeline**(每一步都是 `scripts/` 下的 script,以 `npm run` 形式暴露):
+
+```
+[手動 eval run]
+       ↓
+eval-results.behavioral.json
+       ↓
+scripts/eval-debt-report.py        ← 失敗 → 檔案歸屬(無 LLM)
+       ↓ 每個檔案的修補 backlog
+scripts/patch-proposer.py          ← LLM 提案 Hard Gate diff(預設 dry-run)
+       ↓ EN diff 等人工 review
+references/*.md 由人類審查後套用 diff
+       ↓
+scripts/i18n-mirror-apply.py       ← LLM 把 EN 變動傳到 5 語(預設 dry-run)
+       ↓ 5 語 diff
+i18n/*/references/*.md 由 --apply 寫回
+       ↓
+scripts/i18n-drift-report.py       ← 確定性 detector(無 LLM)驗證同步
+       ↓ exit 0 = 乾淨
+[手動 eval 重跑]
+       ↓
+scripts/eval-lift-report.py        ← per-expectation delta + 分數 vs 真實 lift 歸因
+```
+
+兩個用 LLM 的工具(`patch-proposer`、`i18n-mirror-apply`)預設都是 dry-run,搭配 `--max N` 爆炸半徑上限與 `--apply` 寫檔閘門,確保每次寫入都有人在迴圈內。
+
+**CI 政策**同步調整:`eval-gate.yml` 改成 `workflow_dispatch` only(2026-05-28 的事件 — auto-run on PR + push 在 Stage 2.3 smoke 測試時悄悄燒光維護者的 5 小時滾動 subscription 配額 — 是觸發點)。一個新的輕量 workflow `i18n-drift-check.yml` *依然*在 PR / push 動到 `references/` 或 `i18n/` 時 auto-fire,因為 detector 是確定性 Python 沒有 API 呼叫 — 通知模式,永不阻塞 merge。
+
+**Closed-loop 跑出來的數字**(本機 run,2026-05-29,`--runs 1`,完整 12 eval,分數 artifact [`docs/post-closed-loop-eval-2026-05-29.md`](./docs/post-closed-loop-eval-2026-05-29.md),lift 歸因 [`docs/eval-lift-closed-loop.md`](./docs/eval-lift-closed-loop.md)):
+
+| Run | 覆蓋 | Expectation 通過 | Critical | Warning | 彙總分數 |
+|---|---|---|---|---|---|
+| Sprint 1 baseline(2026-05-28) | 4 eval(局部) | 13 / 33(39 %) | 6 | 14 | 0 / `at-risk` |
+| **Closed-loop 之後(2026-05-29)** | **12 eval(完整)** | **69 / 82(84 %)** | **5** | **6** | **0 / `at-risk`** |
+
+兩輪的彙總分數都壓在 0(累積嚴重度扣分都超過 100 點預算),但底層的移動很劇烈。在跟 Sprint 1 baseline **共享的 4 個 eval**(apples-to-apples,31 paired expectation):
+
+- **17 improved**(fail → pass),含 4 個 Stage 2 critical backlog:三層 JTBD、B2B buyer-vs-user 分離、Discovery scope 守備、B2B 組織層 Jobs
+- **2 regressed** — 都在 `eval-subagent-premortem` 的 category coverage;`--runs 1` 的 LLM variance,`--runs 3` majority vote 預期會洗掉
+- **Net hard lift: +95 點**(gain +125、loss −30)
+
+新加入覆蓋的 8 個 eval(51 個 expectation)補上可見度缺口;只剩 `eval-mode-selection`、`eval-security-awareness`、`eval-context-bootstrap`、`eval-subagent-premortem` 還掛著 5 個 critical。那些就是下一輪 `patch-proposer` 的目標。
+
+**5 個 i18n 語系同步。**
+
 ---
 
 ## 🧪 開發與評測

package/SKILL.md

@@ -69,6 +69,20 @@ When a Quick trigger fires, your reply opens with: *"Detected '[trigger phrase]'
 
 **Neutrality rule (applies to Step 1b only):** when no Quick trigger matched and you DO show the menu, present all 6 modes. You may add a short note like *"based on what you described, options 1 and 2 might fit best"* — but you must **NOT** close the menu by recommending exactly one mode ("I'd recommend Quick Mode"). Mode choice is the user's, not yours.
 
+**All six modes enumerated by name in the menu (Hard Gate)**: Whenever you present the mode-selection menu — Step 1b, or any time the user asks "what are my options?" / "which modes are there?" / "what modes do you have?" — you MUST list all six canonical modes individually, each by its own name on its own numbered line or table row: 🚀 Quick, 📦 Full, 🔄 Revision, ✏️ Custom, ⚡ Build, 🔧 Feature Extension. Collapsing any subset into a summary phrase counts as not listing them. Omitting any of the six FAILs; inventing modes outside the canonical six also FAILs.
+
+❌ FAIL examples (anti-patterns the eval judge would reject):
+- "1. 🚀 Quick Mode  2. 📦 Full Mode — plus four other modes available depending on your needs." (only two named; the rest collapsed)
+- "我推薦 Quick 或 Full 模式，其餘四種模式可依需求選擇。" (names two, hides the other four behind "其餘四種模式")
+- A menu listing Quick, Full, Revision, Custom, Build but silently dropping 🔧 Feature Extension (missing one of the six fails)
+- "Pick from Quick, Full, or one of the advanced modes." (Revision / Custom / Build / Feature Extension never named)
+- Adding a 7th invented mode such as "Growth Mode" or "Scale Mode" alongside the six (inventing extras fails)
+
+✅ PASS examples (concrete patterns that satisfy the expectation):
+- A numbered list 1–6 naming 🚀 Quick, 📦 Full, 🔄 Revision, ✏️ Custom, ⚡ Build, 🔧 Feature Extension, each on its own line with its one-line descriptor (exactly the Step 1b menu above)
+- A 6-row table with columns `Mode | What it's for`, one row per canonical mode, none omitted
+- "Here are all six modes: 1) 🚀 Quick … 2) 📦 Full … 3) 🔄 Revision … 4) ✏️ Custom … 5) ⚡ Build … 6) 🔧 Feature Extension …" — every mode spelled out before any recommendation note
+
 **Step 2 — Confirm product type and audience** (after mode confirmed):
 
 ```
@@ -264,4 +278,4 @@ Display at the very top of every response:
 ▶️ S2: [Step Name] (in progress)
 ⬜ S3: [Step Name] (pending)
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
+```

package/agents/pre-mortem-runner.md

@@ -54,6 +54,20 @@ Good = metric + timing + quantity + causal mechanism. Bad = a hedge.
 
 ## Five failure categories — minimum 2 scenarios per category for completeness
 
+**Per-category quota with five live categories (Hard Gate)**: The `scenarios` list MUST contain ≥15 entries AND ≥2 entries in EVERY one of the five `category` enums — `product_ux`, `market_demand`, `team_execution`, `operational`, AND `external`. A category counts as covered ONLY if it has its own ≥2 standalone scenario objects with their own `id` and `failure_story`; a category mentioned merely as a clause inside another category's scenario (e.g. naming "GDPR" inside an `operational` security scenario, or noting "a competitor might react" inside a `product_ux` story) does NOT count toward that category's quota. Before returning, count entries per `category` value and confirm `external` specifically is not 0 or 1 — `external` is the category most often dropped and is non-optional.
+
+❌ FAIL examples (anti-patterns the eval judge would reject):
+- 15 scenarios where `market_demand` has only F8 (one entry) and `team_execution` has only F16 (one entry) — three categories under quota even though the total hits 15.
+- Zero standalone `external` scenarios, with the only outside-world risk being "GDPR compliance surfaces" buried as a sub-clause inside an `operational` security scenario F6 — `external` reads as 0.
+- Loading 11 scenarios into `product_ux` + `operational` and treating "demand" and "external" as one-line afterthoughts to reach the count.
+- A scenario tagged `category: external` whose `failure_story` is actually about an internal onboarding flow — mislabelling to fake coverage.
+
+✅ PASS examples (concrete patterns that satisfy the expectation):
+- ≥2 distinct `external` scenarios as their own objects, e.g. F13 "Apple's iOS 19 privacy API removes the device-ID we key attribution on, so paid acquisition ROAS becomes unmeasurable within one OS-update cycle" AND F14 "an incumbent bundles our core feature into their free tier in Q3, collapsing standalone willingness-to-pay".
+- A pre-return tally line in `summary_for_main_agent` reasoning: product_ux=4, market_demand=3, team_execution=3, operational=3, external=2 → all ≥2, total 15.
+- `market_demand` carrying its own ≥2 objects (e.g. "switching cost exceeds new-value delta for the SMB segment" AND "the job is episodic — fires twice a year — so no retention loop forms") rather than a single demand scenario.
+- `team_execution` with ≥2 standalone objects (e.g. "key-person dependency: the one engineer holding the matching-algorithm context leaves in month 5" AND "PM bandwidth is the decision bottleneck, so GTM and eng ship to divergent mental models").
+
 ### A. Product / UX
 
 JTBD not delivered, or delivered non-habitually:
@@ -175,5 +189,6 @@ All narrative content (failure stories, leading indicators, summaries, questions
 4. Build Mode: ≥3 scenarios grounded in real architecture evidence?
 5. `priority_three` actually highest likelihood × impact (not most dramatic-sounding)?
 6. `pre_launch_experiments` cheap enough to actually run (not six-month studies)?
+7. Per-category tally taken — `product_ux`, `market_demand`, `team_execution`, `operational`, `external` each ≥2 standalone scenario objects (not sub-clauses), with `external` explicitly confirmed not 0 or 1?
 
-A pre-mortem listing 15 generic risks without leading indicators is theatre. 8 specific scenarios each with a monitorable indicator is real risk management. Prefer the latter even if it means missing "15+" — but try for 15 with quality first.
+A pre-mortem listing 15 generic risks without leading indicators is theatre. 8 specific scenarios each with a monitorable indicator is real risk management. Prefer the latter even if it means missing "15+" — but try for 15 with quality first.

package/i18n/es/SKILL.md

@@ -29,8 +29,8 @@ Detecta el idioma del primer mensaje del usuario y cambia silenciosamente:
 - 繁體中文 → `i18n/zh-TW/SKILL.md`
 - 日本語 → `i18n/ja/SKILL.md`
 - 简体中文 → `i18n/zh-CN/SKILL.md`
-- 한국어 → `i18n/ko/SKILL.md`
 - Español → continúa con este archivo
+- 한국어 → `i18n/ko/SKILL.md`
 
 También cambia si el usuario solicita explícitamente un idioma (p.ej., "please use English"). NO pidas confirmación. NO menciones el cambio.
 
@@ -40,9 +40,26 @@ También cambia si el usuario solicita explícitamente un idioma (p.ej., "please
 
 Usa **confirmación progresiva** — evita volcar todas las opciones. Si el usuario ya especificó, aplica directamente.
 
-**Paso 1 — Confirmar modo** (siempre preguntar a menos que ya esté especificado):
+**Paso 1 — Confirmar modo**
+
+**Paso 1a — Triggers rápidos (verificar PRIMERO; auto-aplicar el modo coincidente sin mostrar el menú):**
+
+Escanea el primer mensaje del usuario en busca de estas frases o paráfrasis cercanas. Si ALGUNA coincide, salta el menú por completo y entra al modo coincidente en S1 inmediatamente.
+
+| Frase trigger (o paráfrasis cercana) | Modo auto-aplicado |
+|---|---|
+| "validar idea rápido", "30 min dirección", "verificación rápida" | 🚀 Rápido |
+| "plan de producto completo", "planificación integral", "hacer todo el proceso" | 📦 Completo |
+| "ya sé qué construir", "saltar discovery", "directo al MVP" | ⚡ Build |
+| "renovar mi producto", "optimizar existente", "rediseñar nuestra app" | 🔄 Revisión |
+| **"agregar una feature", "feature para producto existente", "planificar esta feature", "construir feature [X] para nuestra app"** | 🔧 Extensión de Feature |
+| "pre-mortem", "qué podría salir mal", "encontrar modos de fallo" | enrutar a `pre-mortem-runner` según el Protocolo de Despacho de Especialistas |
 
-> Selecciona un modo (número o nombre), o solo describe tu producto y te recomendaré:
+Cuando se active un trigger rápido, tu respuesta abre con: *"Detecté '[frase trigger]' — entrando a [Modo] en S1."* NO presentes el menú de 6 modos. Procede al Paso 2 de confirmación de tipo de producto (o directamente al S1 del modo si el tipo de producto ya está implícito).
+
+**Paso 1b — Menú (solo si NINGÚN trigger rápido coincidió):**
+
+> Selecciona un modo (número o nombre) — elige el que coincida con tu situación. Si no estás seguro, describe brevemente tu producto y lo reduciré a **dos candidatos** para que elijas entre ellos (nunca solo uno).
 > 1. 🚀 **Modo Rápido** — 3 pasos, ~30 min (JTBD → PR-FAQ → North Star)
 > 2. 📦 **Modo Completo** — 9–11 pasos, documento de planificación integral
 > 3. 🔄 **Modo Revisión** — 6–8 pasos, optimizar producto existente
@@ -50,12 +67,21 @@ Usa **confirmación progresiva** — evita volcar todas las opciones. Si el usua
 > 5. ⚡ **Modo Build** — 7 pasos, salta Discovery, directo a solución
 > 6. 🔧 **Modo Extensión de Feature** — 4 pasos, agregar funcionalidad a producto existente
 
-Triggers rápidos (auto-aplican el modo correspondiente):
-- "validar idea rápido" / "30 min dirección" → Quick
-- "plan de producto completo" → Full
-- "ya sé lo que construir" → Build
-- "renovar mi producto" / "optimizar" → Revision
-- "agregar funcionalidad" / "feature a producto existente" → Feature Extension
+**Regla de neutralidad (aplica solo al Paso 1b):** cuando ningún trigger rápido coincidió y SÍ muestras el menú, presenta los 6 modos. Puedes añadir una nota corta como *"según lo que describiste, las opciones 1 y 2 podrían encajar mejor"* — pero NO debes cerrar el menú recomendando exactamente un modo ("Recomiendo el Modo Rápido"). La elección de modo es del usuario, no tuya.
+
+**Los seis modos enumerados por nombre en el menú (Hard Gate)**: Siempre que presentes el menú de selección de modo — Paso 1b, o cada vez que el usuario pregunte "¿cuáles son mis opciones?" / "¿qué modos hay?" / "¿qué modos tienes?" — DEBES listar los seis modos canónicos individualmente, cada uno por su propio nombre en su propia línea numerada o fila de tabla: 🚀 Rápido, 📦 Completo, 🔄 Revisión, ✏️ Personalizado, ⚡ Build, 🔧 Extensión de Feature. Colapsar cualquier subconjunto en una frase resumen cuenta como no listarlos. Omitir cualquiera de los seis FALLA (FAIL); inventar modos fuera de los seis canónicos también FALLA (FAIL).
+
+❌ Ejemplos de FAIL (anti-patrones que el juez de eval rechazaría):
+- "1. 🚀 Modo Rápido  2. 📦 Modo Completo — más otros cuatro modos disponibles según tus necesidades." (solo dos nombrados; el resto colapsado)
+- "Recomiendo el modo Rápido o Completo, los otros cuatro modos se pueden elegir según necesidad." (nombra dos, esconde los otros cuatro tras "los otros cuatro modos")
+- Un menú que lista Rápido, Completo, Revisión, Personalizado, Build pero silenciosamente omite 🔧 Extensión de Feature (faltar uno de los seis falla)
+- "Elige entre Rápido, Completo, o uno de los modos avanzados." (Revisión / Personalizado / Build / Extensión de Feature nunca nombrados)
+- Añadir un 7º modo inventado como "Modo Growth" o "Modo Scale" junto a los seis (inventar extras falla)
+
+✅ Ejemplos de PASS (patrones concretos que satisfacen la expectativa):
+- Una lista numerada 1–6 nombrando 🚀 Rápido, 📦 Completo, 🔄 Revisión, ✏️ Personalizado, ⚡ Build, 🔧 Extensión de Feature, cada uno en su propia línea con su descriptor de una línea (exactamente el menú del Paso 1b arriba)
+- Una tabla de 6 filas con columnas `Modo | Para qué sirve`, una fila por modo canónico, ninguno omitido
+- "Aquí están los seis modos: 1) 🚀 Rápido … 2) 📦 Completo … 3) 🔄 Revisión … 4) ✏️ Personalizado … 5) ⚡ Build … 6) 🔧 Extensión de Feature …" — cada modo deletreado antes de cualquier nota de recomendación
 
 **Paso 2 — Confirmar tipo de producto y audiencia** (tras confirmar modo):
 
@@ -95,7 +121,7 @@ Tras confirmar el modo, lee el archivo de reglas del modo correspondiente para l
 | Tipo de producto confirmado | `rules-product-type.md` (ajustes B2B/B2C) |
 | Modo tiene pasos Optional | `rules-optional-trigger.md` (triggers + bundle Persona-Journey + Punto de Decisión de Fase) |
 | Lectura/escritura de contexto de producto | `rules-context.md` |
-| A punto de delegar en un sub-agente especialista (discovery / strategy-critic / pre-mortem-runner) — cargar en la primera consideración de dispatch en cualquier modo | `rules-subagent-dispatch.md` |
+| A punto de delegar en un sub-agente especialista (discovery / strategy-critic / pre-mortem-runner) — cargar en la primera consideración de dispatch en cualquier modo, O inmediatamente cuando el usuario pega un artefacto con forma de estrategia / persona / JTBD y pide crítica/revisión (incluso fuera del paso canónico) | `rules-subagent-dispatch.md` |
 | Usuario pide lista de frameworks / comandos complementarios | `rules-commands.md` |
 | Usuario sube archivo | `rules-file-integration.md` |
 | Usuario dice pausar/guardar/continuar | `rules-progress.md` |
@@ -154,7 +180,67 @@ Otras reglas:
 3. **No omitir pasos** — sigue la secuencia del modo; no saltes porque "el usuario probablemente solo quiere el resultado final".
 4. **Handoff de dev solo tras completar todo** — "iniciar desarrollo" / "generar paquete de handoff" requiere todos los pasos ✅. Solicitudes a mitad del proceso reciben: *"Estamos en S[X]/S[Y]. Recomiendo completar los pasos restantes. ¿Continuar, o proceder al progreso actual?"*
 5. **El indicador de progreso es la fuente única de verdad** — completitud = todos los pasos ✅ en el indicador; no inferir.
-6. **Las autoevaluaciones de calidad deben revelar problemas** — tras cada paso, ejecuta la checklist inline (en tu archivo de reglas de modo) o carga `rules-quality-review.md`. La checklist NO DEBE tener todos los ítems ✅; si todos pasan, identifica proactivamente "el aspecto más débil de este output" y explica cómo fortalecerlo.
+6. **Las autoevaluaciones de calidad deben revelar problemas** — tras cada paso, DEBES cargar `references/rules-quality-review.md` y seguir su protocolo exactamente. El bloque "Format" en ese archivo es autoritativo (solo marcadores ✅/❌, sin sustitutos ⚠️/parcial/en blanco, cada ❌ incluye impacto downstream). Los archivos de reglas de modo NO contienen una checklist inline sustituta — `rules-quality-review.md` es la fuente única de verdad. La checklist NO DEBE tener todos los ítems ✅; si todos pasan, baja el listón y vuelve a revisar hasta que surja al menos un ❌ en una brecha de contenido sustantiva.
+7. **Los sub-agentes especialistas deben ser despachados, no simulados inline** — cuando se activen las condiciones de trigger en la tabla de abajo, DEBES invocar al especialista vía la herramienta Task con el `subagent_type` coincidente. Ejecutar la crítica/discovery inline tú mismo falla el contrato (los especialistas existen precisamente porque contexto separado = output de mayor calidad). Ver `## 🤝 Protocolo de Despacho de Especialistas` abajo.
+
+---
+
+## 🤝 Protocolo de Despacho de Especialistas (siempre verificar antes de responder)
+
+Tres sub-agentes especialistas viven en contextos aislados: `strategy-critic`, `discovery-specialist`, `pre-mortem-runner`. Su valor proviene del contexto enfocado — ejecutar su trabajo inline en el agente principal lo diluye.
+
+**Tabla de triggers de despacho** (cualquier fila coincide → despachar inmediatamente, incluso a mitad de modo, incluso fuera del paso canónico):
+
+| Trigger | Especialista | Mensaje de ejemplo del usuario |
+|---|---|---|
+| El usuario pega un artefacto de estrategia ("nuestra misión es…", "nuestra estrategia es…", Strategy Blocks, Rumelt kernel, DHM, Empowered Teams charter) Y pide revisión/crítica/feedback | `strategy-critic` | "Revisa esta estrategia: 'Nuestra misión es deleitar a los clientes…'" |
+| Trabajo de Persona / JTBD / OST / Journey Map / Continuous Discovery | `discovery-specialist` | Full Mode S2-S6, Build Mode S2, cualquier paso Custom que seleccione discovery |
+| El usuario pregunta "qué podría salir mal" / pre-mortem / análisis de riesgo | `pre-mortem-runner` | "Haz un pre-mortem de este MVP", o Full Mode S10 / Build Mode S4 |
+
+### Forma de respuesta requerida cuando se activa un trigger
+
+Cuando cualquier fila coincide, tu respuesta DEBE estructurarse como exactamente estas tres partes, en orden. Ninguna otra forma es aceptable — sin prosa, sin menú de modos, sin indicador de progreso, y sin análisis inline antes de la llamada a Task.
+
+**Parte 1 — primera línea del output, verbatim** (reemplaza `{specialist}` con el nombre del especialista coincidente):
+
+> Dispatching to `{specialist}` subagent via Task tool with `subagent_type={specialist}`.
+
+**Parte 2 — inmediatamente llama a la herramienta Task**:
+
+```
+Task(
+  subagent_type="{specialist}",
+  description="<short 2-3 word summary>",
+  prompt="<paste the user's original prompt verbatim, then add a final line: 'Reply in [user's working language].'>"
+)
+```
+
+**Parte 3 — después de que el especialista devuelva YAML**, integra `three_questions_to_ask_the_writer` (strategy-critic) / `open_questions` (discovery) / `priority_three` + `pre_launch_experiments` (pre-mortem) **verbatim** en tu respuesta. No suavices, no parafrasees, no omitas.
+
+### Anti-patrones (cada uno es un fallo de contrato)
+
+- ❌ Producir una Persona / JTBD / crítica / pre-mortem tú mismo antes de la llamada a Task — incluso parcialmente, incluso "para calentar".
+- ❌ Escribir prosa, un menú de modos, o un indicador de progreso antes del marcador de despacho.
+- ❌ Saltarse la llamada a Task porque "ya sabes la respuesta". El contexto enfocado del especialista produce output de calidad materialmente superior a la que puedes inline.
+- ❌ Parafrasear el marcador de despacho. La forma de la primera línea es verbatim.
+
+**Excepción genuina de falso positivo**: si el prompt no tiene conexión real con el alcance de un especialista (p.ej., el usuario menciona "JTBD" solo para preguntar qué significa el acrónimo), indícalo en una frase corta y procede sin despachar. En caso de duda, despacha — la respuesta `status: out_of_scope` del sub-agente rebota limpiamente las solicitudes no coincidentes de vuelta a ti.
+
+### Fallback de referencia cuando el despacho Task no está disponible
+
+Algunos entornos no pueden despachar sub-agentes (notablemente runs headless `claude -p`, algunos harnesses MCP, y ciertos contextos de eval CI). En esos entornos la herramienta `Task` está ausente o inerte, así que el despacho anterior colapsará inline silenciosamente. Para prevenir el colapso de contenido, **antes de producir output inline para cualquier fila de trigger coincidente, DEBES leer los archivos de referencia correspondientes y tratar sus Hard Gates como propios**:
+
+| Especialista (si el despacho falla / no está disponible) | Archivos de referencia a leer PRIMERO, luego satisfacer Hard Gates inline |
+|---|---|
+| `discovery-specialist` | `references/02a-persona.md` (estructura de Persona + Hard Gate de Comprador/Usuario B2B + vocabulario de Priorización B2B) Y `references/02b-jtbd.md` (JTBD de 3 capas + Hard Gates de Jobs a Nivel Org B2B) Y `references/rules-quality-review.md` (formato de marcadores ✅/❌ + Hard Gate de ≥1 ❌). Añade `references/02c-ost-journey.md` si la solicitud incluye OST o Journey Map. |
+| `strategy-critic` | `references/01-strategy.md` (diagnóstico de Rumelt + formato de crítica de tres preguntas) Y `references/rules-quality-review.md` |
+| `pre-mortem-runner` | `references/04-develop.md` (sección Pre-mortem — 15+ escenarios en 5 categorías + formato de indicador líder) Y `references/rules-quality-review.md` |
+
+**La autoevaluación de calidad siempre es requerida.** Siempre que el prompt del usuario pida una autoevaluación de calidad, checklist, o crítica de fin de paso — o siempre que estés a punto de emitir output de fin de paso de cualquier tipo — DEBES haber leído `references/rules-quality-review.md` y seguir su formato exacto de marcadores `✅`/`❌` con al menos un `❌` en una brecha de contenido sustantiva. Esto es innegociable independientemente de si se intentó el despacho o de si se usó la ruta de fallback.
+
+Esto **no** es licencia para saltar el despacho cuando SÍ está disponible. El orden es: (1) intentar despacho; (2) si la herramienta Task no está disponible o la llamada no puede completarse, leer las referencias listadas y producir output de grado especialista inline; (3) cita que usaste el fallback inline en una nota corta al final ("Fallback inline usado — despacho Task no disponible en este entorno."). Las referencias anteriores incorporan los mismos Hard Gates que el especialista habría aplicado, así que seguirlas fielmente cierra la brecha de calidad.
+
+Plantillas completas de invocación por trigger: `references/rules-subagent-dispatch.md`. Un hook `UserPromptSubmit` (`hooks/user-prompt-detect-specialist-dispatch.py`) también aplica este protocolo en la capa del harness — su recordatorio y esta sección son duplicados intencionales para que la regla sea imposible de pasar por alto.
 
 ---
 
@@ -192,4 +278,4 @@ Mostrar en la parte superior de cada respuesta:
 ▶️ S2: [Nombre del Paso] (en progreso)
 ⬜ S3: [Nombre del Paso] (pendiente)
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
+```

package/i18n/es/references/02a-persona.md

@@ -11,7 +11,7 @@ Cuando el orchestrator recibe el pedido de ejecutar trabajo de Descubrimiento (P
 
 Si los hallazgos de Descubrimiento sugieren fuertemente un artefacto downstream (ej. el análisis JTBD revela un ángulo de positioning claro), regístralo como una **open question o next-step pointer de una línea** al final — pero **NO produzcas el artefacto en sí**. La siguiente etapa tiene su propio step dedicado.
 
-Ejemplo no aceptable: terminar un análisis JTBD con una tabla RICE poblada, una lista de scope de MVP, o un párrafo "Recommended Positioning" — incluso si todas las otras sub-secciones de Descubrimiento están correctas, esta salida FALLA este Hard Gate.
+Ejemplo no aceptable: terminar un análisis JTBD con una tabla RICE poblada, una lista de scope de MVP, o un párrafo "Recommended Positioning" — incluso si todas las otras sub-secciones de Descubrimiento están correctas, esta salida FAIL este Hard Gate.
 
 ---
 
@@ -34,7 +34,7 @@ Regla del Hard Gate:
 - Si son la misma persona (raro — usualmente herramientas fundador-led o B2B de un solo dueño), explicá en una oración por qué el buyer también es el user diario en este escenario específico.
 - Cross-link entre las dos Personas: notá dónde el criterio de evaluación del Buyer depende de lo que el User realmente hace a diario (ej. "el criterio de audit-readiness del Buyer depende de que el User complete el formulario el mismo día y no en lote").
 
-Ejemplo no aceptable: producir una sola Persona ("HR Manager") que fusiona aprobar presupuesto Y completar formularios diarios — dos Jobs distintos forzados en un arquetipo borroso. Esa salida FALLA este Hard Gate.
+Ejemplo no aceptable: producir una sola Persona ("HR Manager") que fusiona aprobar presupuesto Y completar formularios diarios — dos Jobs distintos forzados en un arquetipo borroso. Esa salida FAIL este Hard Gate.
 
 ```
 | Campo | Persona 1: [Apodo] | Persona 2: [Apodo] | Persona 3: [Apodo] |
@@ -62,7 +62,7 @@ Para **productos B2B con múltiples user personas**, el reasoning DEBE referenci
 - **Budget authority** — quién controla la línea de presupuesto; relevante cuando buyer ≠ user y los criterios del buyer dominan la decisión inicial del deal
 - **Audit / compliance pressure ownership** — el rol de quién está en juego cuando aparecen hallazgos de auditoría; las personas presionadas por compliance suelen dominar la priorización en segmentos B2B regulados
 
-Un reasoning puro de "Persona X la usa más" o "Persona Y tiene más usuarios" FALLA este Hard Gate para productos B2B. La frecuencia es necesaria pero nunca suficiente — el switching B2B es impulsado por presión organizacional, no por tasas de uso individual.
+Un reasoning puro de "Persona X la usa más" o "Persona Y tiene más usuarios" FAIL este Hard Gate para productos B2B. La frecuencia es necesaria pero nunca suficiente — el switching B2B es impulsado por presión organizacional, no por tasas de uso individual.
 
 Para **productos B2C**, el reasoning debe referenciar al menos uno de: switching-trigger ownership, diferencial de severidad JTBD, network-effect seeding, o diferencial de willingness-to-pay. El reasoning puramente por frecuencia también falla para B2C.
 
@@ -96,4 +96,4 @@ Si el usuario sube archivos durante esta etapa, Claude los integra según estas
 | Contenido Subido | Integrar En | Acción de Integración |
 |-----------------|-------------|----------------------|
 | Transcripciones de entrevistas de usuario / transcripciones de audio | 1.1 Persona + 1.3 JTBD | Extraer: contexto del usuario → campos de Persona; puntos de dolor + enfoque actual → preguntas de profundización JTBD; reacciones emocionales → Jobs emocionales/sociales |
-| Reporte de investigación de usuarios (PDF) | 1.1 + 1.2 + 1.3 | Extraer datos cuantitativos (proporciones de segmentos de usuarios) al tamaño de Persona; extraer insights cualitativos a JTBD |
+| Reporte de investigación de usuarios (PDF) | 1.1 + 1.2 + 1.3 | Extraer datos cuantitativos (proporciones de segmentos de usuarios) al tamaño de Persona; extraer insights cualitativos a JTBD |

package/i18n/es/references/02b-jtbd.md

@@ -32,7 +32,18 @@ Ejemplo: **Cuando** está comparando opciones de hipoteca a altas horas de la no
 
 **Tabla de Análisis de Cuatro Tipos JTBD:**
 
-Cada celda (Persona 1 / Persona 2) DEBE contener una oración JTBD completa de tres cláusulas. Las frases descriptivas sin la estructura "Cuando / quiero / para que" no son aceptables.
+Cada celda (Persona 1 / Persona 2) DEBE contener una oración JTBD completa de tres cláusulas. **Frases cortas como "Sentir que sigo cumpliendo conmigo mismo", "registrar entrenamientos a diario", "seguir el progreso fácilmente" todas FAIL el Hard Gate.** Usá el ejemplo desarrollado de abajo como la forma literal — cada celda debe leerse como una oración con `When …, I want to …, so …`.
+
+Ejemplo desarrollado (rastreador de hábitos de fitness B2C, una sola Persona — replicá esta forma para cada celda):
+
+| Tipo JTBD | Definición | Persona: Profesional Ocupado |
+|-----------|------------|-----------|
+| Job Funcional | Completar una tarea específica o lograr un objetivo funcional | **Cuando** llego a casa después de un largo día de trabajo y tengo 20 minutos antes de mi próximo compromiso, **quiero** registrar el entrenamiento que acabo de hacer y ver qué se recomienda a continuación, **para que** pueda mantener la racha sin gastar energía mental planificando. |
+| Job Emocional | Cómo se sienten o quieren sentirse | **Cuando** me pierdo un entrenamiento planificado dos días seguidos, **quiero** sentir que sigo en el camino en lugar de empezar de cero, **para que** no caiga en la espiral de todo-o-nada que mata mi consistencia. |
+| Job Social | Cómo quieren ser percibidos por otros | **Cuando** un amigo me pregunta cómo va mi entrenamiento, **quiero** mostrar un registro limpio de actividad reciente, **para que** se me vea como alguien que cumple los compromisos consigo mismo. |
+| Contexto del Job | Bajo qué circunstancias necesitan realizar este trabajo | **Cuando** mi agenda es volátil a lo largo de la semana (reuniones tempranas, llamadas nocturnas), **quiero** encajar entrenamientos en ventanas de 15–45 minutos donde sea que caigan, **para que** el entrenamiento se adapte a mi vida en lugar de competir con ella. |
+
+Tabla vacía (llená cada celda con oraciones completas `When …, I want to …, so …` — NO la acortes a frases):
 
 ```
 | Tipo JTBD | Definición | Persona 1 (debe usar la forma completa "Cuando … quiero … para que …") | Persona 2 (igual) |
@@ -63,7 +74,7 @@ Claude debe autoevaluar después de producir el output JTBD (cada ítem debe mar
 - [ ] ¿Se enfoca en un solo trabajo central? (No tres trabajos metidos en una sola oración)
 - [ ] ¿Puede usarse para evaluar "¿Esta solución realmente aborda este trabajo?"
 - [ ] ¿Incluye "soluciones alternativas actuales" y "brecha"? (Brecha = oportunidad)
-- [ ] ¿La P5 de la Profundización alcanza motivación emocional / identidad profesional / miedo psicológico? (No solo descripciones funcionales)
+- [ ] ¿La P5 de la Profundización **usa explícitamente al menos una palabra del vocabulario canónico** (`fear`, `anxiety`, `shame`, `worry`, `dread`, `self-doubt`, `sense of loss`, `threat to identity`, `embarrassment`, `guilt`)? Paráfrasis consecuenciales como "credibilidad en riesgo" o "reputación dañada" FAIL este ítem — son consecuencias, no la emoción sentida.
 
 **Reglas de Ejecución (Hard Gate):**
 - Debe marcar cada ítem ✅ o ❌ — listas [ ] en blanco o ✅ sin explicación no están permitidas
@@ -78,7 +89,7 @@ Claude debe autoevaluar después de producir el output JTBD (cada ítem debe mar
 
 #### Análisis de Jobs a Nivel Organizacional (Hard Gate — cubrir al menos 2 niveles)
 
-Un análisis JTBD B2B que se queda puramente al nivel de usuario individual FALLA este gate. Los Jobs a nivel organizacional (auditoría de cumplimiento, flujos de aprobación cross-departamentales, control de costos, alineación de políticas de headcount, integridad de pista de auditoría) son necesidades que existen más allá de la tarea diaria de cualquier usuario individual y rutinariamente dominan las decisiones de switching B2B. La tabla de abajo DEBE producirse y al menos 2 de los 3 niveles DEBEN contener Jobs específicos de B2B (no enunciados genéricos de productividad).
+Un análisis JTBD B2B que se queda puramente al nivel de usuario individual FAILS este gate. Los Jobs a nivel organizacional (auditoría de cumplimiento, flujos de aprobación cross-departamentales, control de costos, alineación de políticas de headcount, integridad de pista de auditoría) son necesidades que existen más allá de la tarea diaria de cualquier usuario individual y rutinariamente dominan las decisiones de switching B2B. La tabla de abajo DEBE producirse y al menos 2 de los 3 niveles DEBEN contener Jobs específicos de B2B (no enunciados genéricos de productividad).
 
 | Nivel | Descripción | Ejemplos |
 |-------|-------------|----------|
@@ -94,13 +105,25 @@ El comprador de un producto B2B (firma el contrato, controla el presupuesto) y e
 - Si buyer = user (raro — usualmente herramientas fundador-led), explicá en una oración por qué en este escenario específico el tomador de decisiones también es el usuario diario — no lo asumas silenciosamente.
 - Ejemplo no aceptable: producir una sola Persona ("HR Manager") que fusiona la autoridad de aprobar presupuesto Y el llenado diario de formularios. Eso colapsa dos Jobs distintos en un rol borroso y el análisis no puede impulsar decisiones de producto.
 
-#### Cinco Preguntas de Profundización — Versión Mejorada B2B
+#### Cinco Preguntas de Profundización — Versión Mejorada B2B (Hard Gate)
+
+**Hard Gate — la P5 DEBE usar explícitamente al menos una palabra del siguiente vocabulario canónico**: `fear` (miedo), `anxiety` (ansiedad), `shame` (vergüenza), `worry` (preocupación), `dread` (pavor), `self-doubt` (auto-duda), `sense of loss` (sensación de pérdida), `threat to identity` (amenaza a la identidad), `embarrassment` (bochorno), `guilt` (culpa). Paráfrasis funcionales/consecuenciales como "credibilidad en riesgo", "reputación dañada", "métrica cae", "usuarios churnean", "pierde confianza", "impacto en la carrera" FAIL este gate aunque describan stakes B2B reales — son *consecuencias*, no la *emoción sentida* de la cual el persona quiere *alejarse*.
+
+Una P5 que describe la motivación más profunda del persona solo en lenguaje funcional FALLA el contrato de Descubrimiento: el propósito entero de la P5 es hacer aflorar el *miedo/ansiedad sentido* que impulsa el switching — los resultados puramente funcionales pueden resolverse con herramientas incrementalmente mejores, pero es el fear/anxiety sentido lo que hace que un buyer B2B supere la inercia organizacional y firme un nuevo contrato.
+
+**Ejemplos válidos** (cada uno contiene una palabra del vocabulario canónico):
+- ✅ Identidad profesional: "Ella **teme (fears)** verse incompetente frente al liderazgo cuando este reporte representa la credibilidad de su departamento"
+- ✅ Motivación emocional: "Él carga una **ansiedad (anxiety)** silenciosa de que sus reportes directos descubran que en realidad no tiene un control firme de los números"
+- ✅ Miedo psicológico: "Su mayor **pavor (dread)** es que el auditor encuentre una brecha en el proceso — ya le llamaron la atención una vez, y la **vergüenza (shame)** de un segundo incidente marcaría su expediente para siempre"
+- ✅ Amenaza a la identidad: "Él siente una **amenaza a la identidad (threat to identity)** cuando consultores externos explican mejor que él las métricas de su propio equipo frente a la junta"
+
+**Ejemplos no válidos** (funcional/consecuencial, sin vocabulario canónico):
+- ❌ "Necesita una mejor herramienta para mejorar la eficiencia" (funcional)
+- ❌ "Su credibilidad con el liderazgo está en riesgo" (consecuencia, no emoción sentida)
+- ❌ "Podría perder su trabajo si este reporte está mal" (resultado, no emoción — ¿qué *siente* sobre esa posibilidad?)
+- ❌ "Su reputación en la organización se vería afectada" (consecuencia — reemplazar con `embarrassment`, `shame`, o `dread`)
 
-**La P5 debe alcanzar al menos uno de los siguientes niveles** (ejemplos):
-- ✅ Identidad profesional: "Tiene miedo de verse incompetente frente al liderazgo, porque este reporte representa la credibilidad de su departamento"
-- ✅ Motivación emocional: "Quiere demostrar a sus reportes directos que tiene un control firme de los números"
-- ✅ Miedo psicológico: "Su mayor miedo es que el auditor encuentre una brecha en el proceso — ya le llamaron la atención una vez"
-- ❌ Ejemplo fallido: "Necesita una mejor herramienta para mejorar la eficiencia" (se queda a nivel funcional)
+Si la motivación más profunda del persona genuinamente no mapea a ninguna palabra del vocabulario canónico después de un análisis honesto, marcá el ítem P5 de la Checklist de Calidad JTBD como `❌` con la explicación "La P5 actualmente vive a nivel de consecuencia; se necesita una pregunta más de entrevista que sondee la emoción sentida" — no parafrasees la lista de vocabulario para hacer aparecer una marca de verificación.
 
 #### Análisis de Alternativas Competitivas (Obligatorio)
 
@@ -146,4 +169,4 @@ Si el usuario sube archivos durante esta fase, Claude los integra de la siguient
 | Contenido Subido | Integrar En | Acción de Integración |
 |-----------------|-------------|----------------------|
 | Transcripciones de entrevistas / texto de grabaciones | 1.1 Persona + 1.3 JTBD | Extraer: contexto del usuario → campos de Persona; puntos de dolor + soluciones alternativas actuales → Cinco Preguntas de Profundización JTBD; reacciones emocionales → Jobs Emocionales / Sociales |
-| Capturas de pantalla de apps competidoras | 1.3 JTBD (soluciones alternativas actuales) | Identificar como "alternativa actual" del usuario, analizar soluciones improvisadas y brechas |
+| Capturas de pantalla de apps competidoras | 1.3 JTBD (soluciones alternativas actuales) | Identificar como "alternativa actual" del usuario, analizar soluciones improvisadas y brechas |

package/i18n/es/references/04a-prfaq.md

@@ -62,6 +62,20 @@ Claude debe marcar cada ítem ✅ o ❌ después de producir el PR-FAQ; ítems
 
 **Fórmula**: Comienza con la experiencia del usuario / escenario específico → luego di "Esto es posible gracias a [mecanismo del producto]" para introducir la funcionalidad.
 
+**Auto-verificación (obligatorio antes de enviar)**: lee en voz alta la primera oración de tu propio párrafo de Solución. Si el sujeto es el nombre del producto o "el sistema" / "la app" / "los usuarios pueden", **reescríbela**. El sujeto debe ser un actor específico (persona nombrada, rol, o pronombre que se refiere a un usuario) haciendo algo o experimentando un momento.
+
+---
+
+### 📍 Requisitos del Párrafo Inicial (Lead)
+
+El párrafo inicial (Aha Moment) debe contener LOS TRES:
+
+1. Un **actor nombrado o específico por rol** ("Alex", "Chef López", "el gerente de cocina de un bistró de 30 asientos") — nunca "los usuarios" de forma genérica.
+2. Un **tiempo / lugar / detonante concreto** ("el viernes por la tarde", "después del ajetreo del almuerzo", "antes del fin de semana").
+3. **Al menos 2 números específicos** — cantidades, duraciones, montos en dólares, porcentajes. "En 30 segundos", "para 3 escenarios de prestamistas", "$2,400/mes", "ventana de preparación de 20 minutos". Los números vagos ("unos minutos", "varias opciones") FAIL este requisito.
+
+Un lead que tiene el actor + escenario pero sin números concretos se lee como texto publicitario — el comunicado de prensa se supone que debe hacer visible un resultado específico, no aspiracional.
+
 ---
 
 ### ❓ Estándar de Preguntas Incisivas en FAQ
@@ -76,6 +90,24 @@ Requisitos de formato de respuesta:
 ✅ Patrón de respuesta correcto:
 > "Excel absolutamente puede rastrear números, y los chefs ya saben cómo usarlo. El problema es que cada fin de semana los cálculos necesitan rehacerse — re-ingresar, re-convertir — y la hora que toma no es porque alguien sea malo con las hojas de cálculo, es porque el problema realmente es así de complejo. MealPrep no te ahorra habilidades de Excel — te ahorra la carga mental de empezar desde cero cada vez."
 
+---
+
+### 🧪 Requisitos del FAQ Interno
+
+Por separado del FAQ Externo (de cara al cliente), produce una sección de **FAQ Interno** con al menos:
+
+**P: ¿Cuál es la suposición más riesgosa en este PR-FAQ? Si es falsa, ¿qué mata al producto?**
+R: Nombra UNA suposición específica (no una lista). Ejemplos de respuestas bien formadas:
+- "Asumimos que los gerentes de cocina confiarán en las órdenes de compra autogeneradas sin verificación manual. Si no lo hacen (porque errores de inventario pasados les costaron dinero), revisarán cada línea dos veces y nuestra propuesta de valor de 'ahorra 1 hora' colapsa a 'ahorra 5 minutos'."
+- "Asumimos que las fotos de las publicaciones contienen suficiente resolución para extraer los metros cuadrados de forma confiable. Si el OCR basado en imágenes falla en más del 20% de las publicaciones, la experiencia central de 'captura y listo' se rompe."
+
+**P: ¿Cuál es el experimento más pequeño que invalidaría esta suposición?**
+R: Una prueba concreta previa al lanzamiento — entrevistar a N usuarios, hacer un smoke-test de una landing page con un objetivo de conversión X, correr un piloto interno de 2 semanas, etc. **Genérico como "rastrearemos el engagement" o "observaremos la retención" FAILS este requisito** — esos miden el éxito después del lanzamiento, no la invalidación antes del compromiso.
+
+El FAQ Interno no es para clientes. Existe para que el equipo se obligue a nombrar qué podría matar al producto ANTES de construirlo.
+
+---
+
 **Ejemplo (producto ficticio — App de Calculadora de Hipotecas):**
 
 ```
@@ -97,9 +129,12 @@ a altas horas de la noche, no hay herramienta conveniente — así que la gente
 hoja de Excel o simplemente se rinde.
 
 **Descripción de la Solución**:
-MortgageSnap te permite capturar cualquier publicación de propiedad, extrae automáticamente los datos clave,
-compara instantáneamente opciones entre prestamistas, y genera un reporte compartible para que tu familia
-pueda discutir junta.
+Ahora, Alex dedica 3 minutos en vez de 3 noches para saber qué es realmente accesible. Captura una
+publicación en su teléfono, ve los pagos mensuales para tres escenarios de prestamistas aparecer en
+30 segundos, y comparte una sola pantalla con su esposa — de modo que la conversación pasa de "creo
+que podemos pagarlo" a "aquí están los tres números que deberíamos discutir." Esto funciona porque
+MortgageSnap extrae automáticamente el precio y los metros cuadrados de la imagen de la publicación,
+y luego obtiene ofertas de tasas en vivo de prestamistas asociados.
 
 **Cita del Cliente**:
 "Finalmente no tengo que esperar a que el banco me devuelva la llamada a medianoche. Tres minutos y puedo
@@ -111,4 +146,4 @@ R: Las calculadoras existentes requieren que ingreses tasas de interés, plazos
 parámetros, pero la mayoría de los compradores primerizos ni siquiera conocen esos números.
 La diferencia de MortgageSnap es que obtiene automáticamente ofertas reales de varios prestamistas —
 todo lo que necesitas proporcionar es el precio y tu enganche.
-```
+```