pumuki 6.3.113 → 6.3.115

package/core/facts/extractHeuristicFacts.ts

@@ -401,10 +401,6 @@ const astDetectorRegistry: ReadonlyArray<ASTDetectorRegistryEntry> = [
   { detect: TS.hasSetTimeoutStringCallback, ruleId: 'heuristics.ts.set-timeout-string.ast', code: 'HEURISTICS_SET_TIMEOUT_STRING_AST', message: 'AST heuristic detected setTimeout with a string callback.' },
   { detect: TS.hasSetIntervalStringCallback, ruleId: 'heuristics.ts.set-interval-string.ast', code: 'HEURISTICS_SET_INTERVAL_STRING_AST', message: 'AST heuristic detected setInterval with a string callback.' },
   { detect: TS.hasAsyncPromiseExecutor, ruleId: 'heuristics.ts.new-promise-async.ast', code: 'HEURISTICS_NEW_PROMISE_ASYNC_AST', message: 'AST heuristic detected async Promise executor usage.' },
-  { detect: TS.hasMagicNumberLiteral, locateLines: TS.findMagicNumberLiteralLines, ruleId: 'heuristics.ts.magic-number.ast', code: 'HEURISTICS_MAGIC_NUMBER_AST', message: 'AST heuristic detected magic number usage.' },
-  { detect: TS.hasProductionMockArtifactUsage, locateLines: TS.findProductionMockArtifactUsageLines, ruleId: 'heuristics.ts.production-mock-artifact.ast', code: 'HEURISTICS_PRODUCTION_MOCK_ARTIFACT_AST', message: 'AST heuristic detected test doubles imported or required in production backend code.' },
-  { detect: TS.hasAnemicDomainModel, locateLines: TS.findAnemicDomainModelLines, ruleId: 'heuristics.ts.anemic-domain-model.ast', code: 'HEURISTICS_ANEMIC_DOMAIN_MODEL_AST', message: 'AST heuristic detected an anemic domain model.' },
-  { detect: TS.hasControllerBusinessLogic, locateLines: TS.findControllerBusinessLogicLines, ruleId: 'heuristics.ts.controller-business-logic.ast', code: 'HEURISTICS_CONTROLLER_BUSINESS_LOGIC_AST', message: 'AST heuristic detected business logic inside a controller.' },
   { detect: TS.hasWithStatement, ruleId: 'heuristics.ts.with-statement.ast', code: 'HEURISTICS_WITH_STATEMENT_AST', message: 'AST heuristic detected with-statement usage.' },
   { detect: TS.hasDeleteOperator, ruleId: 'heuristics.ts.delete-operator.ast', code: 'HEURISTICS_DELETE_OPERATOR_AST', message: 'AST heuristic detected delete-operator usage.' },
   { detect: TS.hasDebuggerStatement, ruleId: 'heuristics.ts.debugger.ast', code: 'HEURISTICS_DEBUGGER_AST', message: 'AST heuristic detected debugger statement usage.' },

package/core/rules/presets/heuristics/typescript.test.ts

@@ -3,7 +3,7 @@ import test from 'node:test';
 import { typescriptRules } from './typescript';
 
 test('typescriptRules define reglas heurísticas locked para plataforma generic', () => {
-  assert.equal(typescriptRules.length, 23);
+  assert.equal(typescriptRules.length, 19);
 
   const ids = typescriptRules.map((rule) => rule.id);
   assert.deepEqual(ids, [
@@ -16,10 +16,6 @@ test('typescriptRules define reglas heurísticas locked para plataforma generic'
     'heuristics.ts.set-timeout-string.ast',
     'heuristics.ts.set-interval-string.ast',
     'heuristics.ts.new-promise-async.ast',
-    'heuristics.ts.magic-number.ast',
-    'heuristics.ts.production-mock-artifact.ast',
-    'heuristics.ts.anemic-domain-model.ast',
-    'heuristics.ts.controller-business-logic.ast',
     'heuristics.ts.with-statement.ast',
     'heuristics.ts.delete-operator.ast',
     'heuristics.ts.debugger.ast',
@@ -37,22 +33,6 @@ test('typescriptRules define reglas heurísticas locked para plataforma generic'
     byId.get('heuristics.ts.empty-catch.ast')?.then.code,
     'HEURISTICS_EMPTY_CATCH_AST'
   );
-  assert.equal(
-    byId.get('heuristics.ts.magic-number.ast')?.then.code,
-    'HEURISTICS_MAGIC_NUMBER_AST'
-  );
-  assert.equal(
-    byId.get('heuristics.ts.production-mock-artifact.ast')?.then.code,
-    'HEURISTICS_PRODUCTION_MOCK_ARTIFACT_AST'
-  );
-  assert.equal(
-    byId.get('heuristics.ts.anemic-domain-model.ast')?.then.code,
-    'HEURISTICS_ANEMIC_DOMAIN_MODEL_AST'
-  );
-  assert.equal(
-    byId.get('heuristics.ts.controller-business-logic.ast')?.then.code,
-    'HEURISTICS_CONTROLLER_BUSINESS_LOGIC_AST'
-  );
   assert.equal(
     byId.get('heuristics.ts.debugger.ast')?.then.code,
     'HEURISTICS_DEBUGGER_AST'

package/core/rules/presets/heuristics/typescript.ts

@@ -163,78 +163,6 @@ export const typescriptRules: RuleSet = [
       code: 'HEURISTICS_NEW_PROMISE_ASYNC_AST',
     },
   },
-  {
-    id: 'heuristics.ts.magic-number.ast',
-    description: 'Detects repeated magic number usage in TypeScript/TSX production files.',
-    severity: 'WARN',
-    platform: 'generic',
-    locked: true,
-    when: {
-      kind: 'Heuristic',
-      where: {
-        ruleId: 'heuristics.ts.magic-number.ast',
-      },
-    },
-    then: {
-      kind: 'Finding',
-      message: 'AST heuristic detected magic number usage.',
-      code: 'HEURISTICS_MAGIC_NUMBER_AST',
-    },
-  },
-  {
-    id: 'heuristics.ts.production-mock-artifact.ast',
-    description: 'Detects imports or requires of mocks/fakes/spies/stubs in TypeScript/TSX runtime code.',
-    severity: 'WARN',
-    platform: 'generic',
-    locked: true,
-    when: {
-      kind: 'Heuristic',
-      where: {
-        ruleId: 'heuristics.ts.production-mock-artifact.ast',
-      },
-    },
-    then: {
-      kind: 'Finding',
-      message: 'AST heuristic detected test doubles imported or required in production backend code.',
-      code: 'HEURISTICS_PRODUCTION_MOCK_ARTIFACT_AST',
-    },
-  },
-  {
-    id: 'heuristics.ts.anemic-domain-model.ast',
-    description: 'Detects domain classes with only constructor/getters/setters and no behavior.',
-    severity: 'WARN',
-    platform: 'generic',
-    locked: true,
-    when: {
-      kind: 'Heuristic',
-      where: {
-        ruleId: 'heuristics.ts.anemic-domain-model.ast',
-      },
-    },
-    then: {
-      kind: 'Finding',
-      message: 'AST heuristic detected an anemic domain model.',
-      code: 'HEURISTICS_ANEMIC_DOMAIN_MODEL_AST',
-    },
-  },
-  {
-    id: 'heuristics.ts.controller-business-logic.ast',
-    description: 'Detects controller handlers with branching or business flow in TypeScript backend code.',
-    severity: 'WARN',
-    platform: 'generic',
-    locked: true,
-    when: {
-      kind: 'Heuristic',
-      where: {
-        ruleId: 'heuristics.ts.controller-business-logic.ast',
-      },
-    },
-    then: {
-      kind: 'Finding',
-      message: 'AST heuristic detected business logic inside a controller.',
-      code: 'HEURISTICS_CONTROLLER_BUSINESS_LOGIC_AST',
-    },
-  },
   {
     id: 'heuristics.ts.with-statement.ast',
     description: 'Detects with-statement usage in TypeScript/TSX production files.',

package/docs/README.md

@@ -4,6 +4,10 @@ Mapa corto y humano de la documentación oficial de Pumuki.
 
 ## Si buscas algo concreto
 
+- Quiero la **intención de producto canónica** (qué debe cumplir Pumuki en cualquier repo, sin repetir manifiesto en cada sesión):
+  - `docs/product/USAGE.md` (sección **Product intent**)
+- Quiero **auditar todo el árbol trackeado** desde CLI (no solo staged):
+  - `docs/product/USAGE.md` (sección **Full-repository audit**), comando `pumuki audit`
 - Quiero límites del producto, perfil de adopción y comandos mínimos (sin leer todo el README largo):
   - `README.md` (secciones **Qué NO es Pumuki**, **Rutas de adopción**, **Comandos esenciales**)
 - Quiero instalar y arrancar Pumuki en un repo consumidor:
@@ -34,13 +38,13 @@ Mapa corto y humano de la documentación oficial de Pumuki.
 - Quiero runbooks de validación:
   - `docs/validation/README.md`
   - `docs/validation/ios-avdlee-parity-matrix.md`
+  - Smoke de superficie CLI + hooks (`npm run smoke:pumuki-surface`, opcional consumidor / bins instalados: ver `docs/validation/README.md`)
+  - Barra local sin Actions: `npm run -s validation:local-merge-bar` (ver `docs/validation/README.md` § GitHub Actions y cuota)
 
 - Quiero saber en qué estamos ahora:
-  - `PUMUKI-RESET-MASTER-PLAN.md` en la raíz del repo como artefacto operativo local y única fuente viva del tracking interno
-- Quiero contexto histórico o materiales de seguimiento retirados:
-  - Referencia histórica: `docs/tracking/plan-activo-de-trabajo.md`
-  - Quiero el seguimiento del curso Stack My Architecture (Pumuki), iniciativa formativa aparte del espejo operativo:
-  - Curso Stack My Architecture: `docs/tracking/plan-curso-pumuki-stack-my-architecture.md`
+  - `docs/tracking/plan-activo-de-trabajo.md`
+- Quiero el seguimiento del curso Stack My Architecture (Pumuki), iniciativa formativa aparte del espejo operativo:
+  - `docs/tracking/plan-curso-pumuki-stack-my-architecture.md`
 
 ## Estructura oficial
 
@@ -67,10 +71,10 @@ Mapa corto y humano de la documentación oficial de Pumuki.
   - Skills vendorizadas que el repo usa como contrato local.
 
 - `docs/tracking/`
-  - Material histórico o formativo; no actúa como backlog vivo del producto.
-  - Fuente viva del tracking interno: `PUMUKI-RESET-MASTER-PLAN.md` en la raíz del repo.
-  - Documento retirado: `docs/tracking/plan-activo-de-trabajo.md`.
-  - Material del curso: `docs/tracking/plan-curso-pumuki-stack-my-architecture.md`.
+  - Seguimiento permitido y solo el imprescindible.
+  - Espejo operativo de producto y consumidores: `docs/tracking/plan-activo-de-trabajo.md` (unica fuente de verdad para ese ambito).
+  - Curso Pumuki (Stack My Architecture): diseño pedagógico + seguimiento de entrega en `docs/tracking/plan-curso-pumuki-stack-my-architecture.md` (no sustituye al plan activo).
+  - Regla hard: solo puede existir una tarea `🚧` en cada documento de seguimiento que lo use.
 
 ## Fuera de `docs/`
 

package/docs/codex-skills/backend-enterprise-rules.md

@@ -250,13 +250,13 @@ const { data } = await supabase
 
 ### Anti-patterns a EVITAR:
 ❌ **God classes** - Servicios con >500 líneas
+❌ **Anemic domain models** - Entidades solo con getters/setters
 ❌ **Magic numbers** - Usar constantes con nombres descriptivos
-❌ **Mocks en producción** - Usar fakes/spies de test; en runtime productivo, solo adaptadores y datos reales
-❌ **Anemic domain models** - Entidades con comportamiento, no solo getters/setters
-❌ **Lógica en controllers** - Mover lógica de negocio a casos de uso/servicios
 ❌ **Callback hell** - Usar async/await
 ❌ **Hardcoded values** - Config en variables de entorno
+❌ **Mocks en producción** - Solo datos reales
 ❌ **try-catch silenciosos** - Siempre loggear o propagar (AST: common.error.empty_catch)
+❌ **Lógica en controllers** - Mover a servicios/use cases
 
 ### Principio fundamental:
 ✅ **"Measure twice, cut once"** - Planificar arquitectura, dependencias y flujo de datos antes de implementar. Analizar impacto en BD, caché y performance.

package/docs/operations/RELEASE_NOTES.md

@@ -6,11 +6,48 @@ This file keeps only the operational highlights and rollout notes that matter wh
 
 ## 2026-04 (CLI stability and macOS notifications)
 
-### 2026-04-23 (v6.3.113)
+### 2026-04-24 (v6.3.115)
 
-- **Tracking canónico accionable en `status` / `doctor`:** cuando el runtime está bloqueado, la salida visible ya incluye `issues` y contexto suficiente para no depender de grep manual.
-- **Stage visible coherente con la evidencia:** `governanceNextAction.stage` deja de ser un valor forzado y sigue el `snapshot_stage` real cuando existe.
-- **Remediación reproducible:** la recomendación de alineación ahora apunta al runtime diagnosticado del consumer, no a una versión comodín.
+- **`issues` canónicos también para `WARN`:** `status` y `doctor` ya no dejan `issues=[]` cuando la evidencia operativa real está en atención (`WARN`) pero aún no bloquea el gate.
+- **Cierre útil de `PUMUKI-INC-084` en la línea publicada:** el consumer puede automatizar tanto estados `BLOCK` como `WARN` sin recombinar `attention_codes` y `human_summary_preview` por su cuenta.
+- **`postinstall` vuelve a ser instalable en consumers reales:** la release evita el ciclo en `repoState` que rompía `npm install pumuki@6.3.114`.
+- **Rollout recomendado:** publicar `pumuki@6.3.115`, repin inmediato en `RuralGo` y revalidar `status --json` / `doctor --json` comprobando que la evidencia `WARN` ya aparece dentro de `issues`.
+
+### 2026-04-22 (v6.3.108)
+
+- **MCP enterprise visible desde la baseline publicada:** la línea `main` deja de exigir opt-in adicional para exponer `ai_gate_check`, `pre_flight_check` y `auto_execute_ai_start` en el catálogo enterprise.
+- **Menos gap entre governance y flujo real del editor/agente:** cuando `status`/`doctor` ya están bloqueando, el consumer pasa a ver antes la misma capa MCP que materializa el enforcement perceptible de `PRE_WRITE`.
+- **Rollout recomendado:** publicar `pumuki@6.3.108`, repin inmediato en `RuralGo` y revalidar `status`, `doctor` y el arranque MCP/agentic sobre un repo con `PUMUKI-INC-079` reportada.
+
+### 2026-04-22 (v6.3.107)
+
+- **Sesión SDD expirada sin semántica ambigua:** la línea publicada deja de diagnosticar sesiones vencidas como `active=true` con `valid=false`; ahora las proyecta como inactivas y mantiene la señal de expiración con `remainingSeconds=0`.
+- **Refresh reproducible de sesiones caducadas:** si el `changeId` sigue siendo válido, `session --refresh` vuelve a servir para recuperar la sesión sin exigir un `session --open` innecesario.
+- **Rollout recomendado:** publicar `pumuki@6.3.107`, repin inmediato en `RuralGo` y revalidar `sdd validate --stage=PRE_WRITE --json` comprobando que `status.session.active=false`, `valid=false` y que la remediación siga permitiendo refresh sobre el mismo `changeId`.
+
+### 2026-04-22 (v6.3.106)
+
+- **Cierre útil del literal residual en RuralGo:** `sdd validate --stage=PRE_WRITE --json` ya no recomienda activar SDD con `pumuki@latest`; devuelve el mismo runtime versionado que está diagnosticando.
+- **Guía de sesión SDD alineada:** `session --refresh` y `session --open` quedan versionados para evitar drift en repos consumidores.
+- **Rollout recomendado:** publicar `pumuki@6.3.106`, repin inmediato en `RuralGo` y revalidar `sdd validate --stage=PRE_WRITE --json` comprobando `activation_command` fijo a `6.3.106`.
+
+### 2026-04-22 (v6.3.105)
+
+- **Remediación reproducible en la línea publicada:** las rutas bloqueantes de `PRE_WRITE` dejan de sugerir `pumuki@latest` y fijan la versión efectiva del runtime al construir `next_action.command`.
+- **Cobertura MCP alineada:** `auto_execute_ai_start` devuelve las mismas remediaciones versionadas que `sdd validate` para evidence invalid/stale, `active_rule_ids` vacío y policy reconcile estricto.
+- **Rollout recomendado:** publicar `pumuki@6.3.105`, repin inmediato en `RuralGo` y revalidar el command contract de `PRE_WRITE` en `sdd validate`, `auto_execute_ai_start` y hooks reales.
+
+### 2026-04-22 (v6.3.104)
+
+- **RuralGo hub-aware diagnostics:** `TRACKING_CANONICAL_IN_PROGRESS_INVALID` pasa a enriquecer su mensaje usando `docs/RURALGO_SEGUIMIENTO.md` cuando ese hub es el board canónico del consumer.
+- **Compatibilidad con tablas del hub:** el parser reconoce filas `| 🚧 | TASK_ID |` y las devuelve como entradas activas accionables.
+- **Rollout recomendado:** publicar `pumuki@6.3.104`, repin inmediato en `RuralGo` y revalidar `status` / `doctor` / `pumuki-pre-write` con doble fila `🚧` temporal en el hub canónico.
+
+### 2026-04-22 (v6.3.103)
+
+- **Tracking canónico accionable:** `status`, `doctor` y el gate repo-policy enriquecen `TRACKING_CANONICAL_IN_PROGRESS_INVALID` con referencias a las entradas activas detectadas en el board del consumer.
+- **PRE_WRITE menos ambiguo:** cuando un warning de higiene de worktree convive con un bloqueo duro, el runtime imprime `warning-summary` separado del `block-summary`.
+- **Rollout recomendado:** publicar `pumuki@6.3.103`, repin inmediato en `RuralGo` y revalidar `status` / `doctor` / `git commit` sobre un board con varias filas `🚧 reported activo`.
 
 ### 2026-04-22 (v6.3.102)
 

package/docs/product/API_REFERENCE.md

@@ -174,7 +174,7 @@ Interpretation contract:
 - `consumerInstalled`: version installed in the consumer repository.
 - `lifecycleInstalled`: version recorded in managed lifecycle metadata.
 - `driftWarning`: compact human-readable explanation when those values diverge.
-- `alignmentCommand`: exact remediation command to align dependency and lifecycle state with the current runtime version. When the consumer repo declares a Node runtime via `volta`, `.nvmrc`, or `package.json.engines.node`, this command prepends the matching runtime switch before the Pumuki install step.
+- `alignmentCommand`: exact remediation command to align dependency and lifecycle state with the current runtime version.
 - `pathExecutionHazard`: boolean flag raised when the repo root contains the platform `PATH` delimiter and `npx/npm exec` can fail to resolve `pumuki`.
 - `pathExecutionWarning`: compact warning explaining why `PATH` resolution is unsafe in that repo.
 - `pathExecutionWorkaroundCommand`: safe local-node entrypoint to use when `pathExecutionHazard=true`.

package/docs/product/HOW_IT_WORKS.md

@@ -51,6 +51,12 @@ Pipeline:
 
 Policy source: `integrations/gate/stagePolicies.ts`.
 
+### `pumuki audit` (full tracked tree)
+
+The lifecycle command **`pumuki audit`** runs `runPlatformGate` with **`GateScope` = `repo`**: facts come from **`git ls-files`** filtered by the default code extensions, using the working tree contents of those paths. It is **not** the same as the `PRE_COMMIT` hook, which uses **`staged`** scope only.
+
+JSON output includes how many **untracked** paths would have matched those extensions (`untracked_matching_extensions_count`); they are still excluded from facts unless you use a different scope (for example consumer menu options that include unstaged paths).
+
 ## Main runtime components
 
 - `integrations/git/runPlatformGate.ts`

package/docs/product/INSTALLATION.md

@@ -51,7 +51,7 @@ If both commands pass, the workspace is ready.
 npm install --save-exact pumuki
 ```
 
-The package `postinstall` runs **`pumuki install` only** (Git hooks + lifecycle wiring). Hooks chain **`pumuki-pre-write`** then **`pumuki-pre-commit`** / **`pumuki-pre-push`** (IDE-agnostic). When missing, **`.pumuki/adapter.json`** is created with hook + **MCP stdio** command lines (any MCP client can use them). It does **not** write IDE-specific files; use step 2 or `pumuki install --with-mcp --agent=<name>` for that.
+The package `postinstall` runs baseline **`pumuki install`** by default (Git hooks + lifecycle wiring + **solo** **`.pumuki/adapter.json`**: hooks + **MCP stdio** command lines). MCP wiring is now opt-in: set `PUMUKI_POSTINSTALL_WITH_MCP=1` or `PUMUKI_POSTINSTALL_MCP_AGENT=repo|cursor|claude|codex` to add adapter/client wiring in postinstall. Eso es **agnóstico de IDE/CLI/extensión**: cualquier cliente MCP puede leer esas líneas o enlazarlas manualmente. En cada `npm install` que actualice `pumuki` (repin), el adapter se **fusiona** (`json-merge`) para no pisar claves propias del consumidor. Opt out del bloque MCP+wiring: `PUMUKI_POSTINSTALL_SKIP_MCP=1`. Ficheros propios de un IDE (p. ej. `.cursor/mcp.json`, `.claude/settings.json`): **`pumuki install --with-mcp --agent=cursor|claude|codex`** a mano o **`PUMUKI_POSTINSTALL_MCP_AGENT=cursor`** (u otro agente soportado) si quieres que el postinstall también los escriba.
 
 ### 2) Bootstrap managed lifecycle (recommended single command)
 

package/docs/product/USAGE.md

@@ -19,6 +19,25 @@ Stack My Architecture (optional training hub; includes the dedicated Pumuki cour
 - Public static site: `https://stack-my-architecture-hub.vercel.app/pumuki/`
 - Initiative tracking in this repo: `docs/tracking/plan-curso-pumuki-stack-my-architecture.md`
 
+## Product intent (canonical)
+
+This section is the **single owner-authored contract** for what Pumuki must optimize for across consumers. Agents and contributors should treat it as **source of truth** for expectations so the product owner does not have to restate it in every session.
+
+1. **Repo-agnostic governance** — The same deterministic pipeline (`Facts → Rules → Gate → evidence`) must behave coherently in **any** Git consumer repository. Success is not measured by a specific downstream repo name.
+
+2. **Honest scope** — “What was audited” must always be explicit:
+   - Hook stages use **Git-defined scopes** (for example `PRE_COMMIT` is **staged** only; see the table [Gate stages and policies](#gate-stages-and-policies)).
+   - Full-tree style evaluation uses **tracked files** resolved via Git (`git ls-files`) with the configured extension set; **untracked** paths are out of scope unless a feature explicitly documents otherwise.
+   - Do not equate “pre-commit blocked me” with “the whole codebase was audited”.
+
+3. **Signal over noise** — Findings should reflect **real risk** for the active platforms in that repo. Heuristic multi-platform activation must not drown single-stack repos; set **`PUMUKI_PIN_PLATFORMS`** to a comma-separated subset (`ios`, `android`, `backend`, `frontend`) to restrict which detected platforms are kept for rule loading (unknown tokens are ignored).
+
+4. **Upgrade hygiene** — After bumping the `pumuki` package version, consumers that keep `.pumuki/policy-as-code.json` under version control must **refresh signatures** with `pumuki policy reconcile` (use `--apply` when appropriate). A `POLICY_AS_CODE_SIGNATURE_MISMATCH` from an **stale contract** is not the same class of problem as a code violation.
+
+5. **Product-shaped UX** — **`pumuki audit`** is the canonical CLI for “audit the tracked codebase in this repo” (see [Full-repository audit](#full-repository-audit-cli)). Hooks still use **staged** or **range** scopes per stage; do not confuse them.
+
+If this section conflicts with a one-off chat instruction, **this section wins** unless the product owner explicitly updates it here.
+
 ## Prerequisites
 
 - Node.js `>=18`
@@ -43,6 +62,20 @@ npm ci
 
 Policy source: `integrations/gate/stagePolicies.ts`.
 
+## Full-repository audit (CLI)
+
+Use **`pumuki audit`** when you want the gate to evaluate **all Git-tracked** source files under the default extension set (see `DEFAULT_FACT_FILE_EXTENSIONS` in `integrations/git/runPlatformGateFacts.ts`), not only the staged diff.
+
+```bash
+pumuki audit [--stage=PRE_COMMIT|PRE_PUSH|CI] [--engine] [--json]
+```
+
+- **`--stage`**: policy thresholds for that stage (default **`PRE_COMMIT`**). `PRE_WRITE` is not supported here. Aliases from SDD (`GREEN`, `REFACTOR`, `CLOSE`) work the same as for `pumuki sdd validate`.
+- **`--engine`**: run with `audit_mode=engine` and AST heuristics widened (aligned with the consumer menu “engine” path). Default is **`gate`** (strict enforcement semantics).
+- **`--json`**: machine-readable payload including `files_scanned`, `untracked_matching_extensions_count` (untracked paths that match the extension filter are **not** scanned), and `policy_reconcile_hint` for signature drift.
+
+Platform noise control: set **`PUMUKI_PIN_PLATFORMS`** (comma-separated) before running, e.g. `export PUMUKI_PIN_PLATFORMS=frontend` in a TS-only UI repo.
+
 Coverage guardrail:
 
 - In `PRE_COMMIT`, `PRE_PUSH` and `CI`, Pumuki requires complete rule evaluation coverage.
@@ -130,7 +163,10 @@ Use `A` to switch to `Advanced` mode (full options), and `C` to return to `Consu
 Advanced mode options include short inline contextual help.
 Consumer mode is now a minimal read-only shell:
 
-- `1/2/3/4` are the canonical read-only gate flows
+- `1/2/3/4` are the canonical gate flows with **consumer preflight** before evaluation (labels state scope and PRE_COMMIT vs PRE_PUSH).
+- `11/12/13/14` run the **engine** with **no preflight**: staged only, unstaged only (index→working tree + untracked), full working tree under **PRE_COMMIT**, or **all tracked files** (full repo). They write `.ai_evidence.json` on **PRE_COMMIT** engine runs like other menu audits.
+- After each successful evidence read, the menu prints a **second panel** (“Classic evidence view”) with **ANSI-colored** enterprise/legacy severity counts, optional **platform** rows from `snapshot.platforms`, and a longer ranked violation list. Disable with `PUMUKI_MENU_VINTAGE_REPORT=0`.
+- Options **2** and **4** (PRE_PUSH): if outcome is **PASS** or **WARN**, a short hint explains that a **tracked** `.ai_evidence.json` may **not** be rewritten on disk; use `PUMUKI_PRE_PUSH_ALWAYS_WRITE_TRACKED_EVIDENCE=1` for local debugging.
 - `8` exports the same evidence snapshot in markdown form
 - `5/6/7/9` remain available only as `Legacy Read-Only Diagnostics`
 
@@ -249,9 +285,9 @@ Stage mapping:
 If a scope is empty, the menu prints an explicit operational hint (`Scope vacío`), so `PASS` with zero findings is distinguishable from a clean repository scan.
 
 System notifications (macOS) can be enabled from advanced menu option `31` (persisted in `.pumuki/system-notifications.json`).
-On non-macOS platforms, the same payloads are written to **stderr** by default (visible in the terminal) because there is no native banner API. Set `PUMUKI_DISABLE_STDERR_NOTIFICATIONS=1` to silence that path (delivery reports `unsupported-platform` on those OSes). On macOS, set `PUMUKI_NOTIFICATION_STDERR_MIRROR=1` to duplicate **any** notification payload to stderr in addition to the system notification. For **`gate.blocked`** specifically, stderr mirroring is **on by default** when the macOS path reports success (so a failed push/commit still prints a `[pumuki]` block in the terminal even if the banner does not appear); disable only that default with `PUMUKI_DISABLE_GATE_BLOCKED_STDERR_MIRROR=1`. The **blocked modal** (Swift floating / AppleScript) with **Desactivar / Silenciar 30 min / Mantener activas** is **on by default** whenever notifications are enabled and `blockedDialogEnabled` is omitted in `.pumuki/system-notifications.json`. Turn it off with `"blockedDialogEnabled": false` or `PUMUKI_MACOS_BLOCKED_DIALOG=0`. Ensure the terminal app is allowed to show notifications in **System Settings → Notifications**.
-Blocked notifications now use a native Swift floating modal (bottom-right) by default, with AppleScript fallback.
-Override mode with `PUMUKI_MACOS_BLOCKED_DIALOG_MODE=auto|swift-floating|applescript`.
+On non-macOS platforms, the same payloads are written to **stderr** by default (visible in the terminal) because there is no native banner API. Set `PUMUKI_DISABLE_STDERR_NOTIFICATIONS=1` to silence that path (delivery reports `unsupported-platform` on those OSes). On macOS, set `PUMUKI_NOTIFICATION_STDERR_MIRROR=1` to duplicate **any** notification payload to stderr in addition to the system notification. For **`gate.blocked`** specifically, stderr mirroring is **on by default** when the macOS path reports success (so a failed push/commit still prints a `[pumuki]` block in the terminal even if the banner does not appear); disable only that default with `PUMUKI_DISABLE_GATE_BLOCKED_STDERR_MIRROR=1`. The **blocked modal** (Swift **`NSAlert`** modal dialog / AppleScript) with **Desactivar / Silenciar 30 min / Mantener activas** is **on by default** whenever notifications are enabled and `blockedDialogEnabled` is omitted in `.pumuki/system-notifications.json`. Turn it off with `"blockedDialogEnabled": false` or `PUMUKI_MACOS_BLOCKED_DIALOG=0`. **`gate.blocked`** now emits **both** the Notification Center banner (`osascript`) **and** the interactive modal by default, so consumers (e.g. hooks in other repos) still get a visible banner if the modal cannot attach to a GUI session. To restore the previous “modal only” behaviour and suppress the duplicate banner, set `PUMUKI_MACOS_GATE_BLOCKED_BANNER_DEDUPE=1`. If you see **no** notifications at all: confirm `PUMUKI_DISABLE_SYSTEM_NOTIFICATIONS` is unset, delete or fix `.pumuki/system-notifications.json` (absent file defaults to enabled), and ensure the terminal app is allowed to show notifications in **System Settings → Notifications**.
+Blocked notifications use a **Swift-compiled helper** that shows an **`NSAlert`** (reliable button hit-testing) by default, with AppleScript fallback if `swift` fails.
+Override mode with `PUMUKI_MACOS_BLOCKED_DIALOG_MODE=auto|swift-floating|applescript` (the `swift-floating` name is kept for compatibility; the Swift path is alert-based).
 Custom skills import is available in advanced menu option `33` (writes `/.pumuki/custom-rules.json`).
 Menu-driven audits apply SDD guardrails with the same strict semantics as stage runners (no bypass).
 
@@ -403,7 +439,7 @@ How to read it:
 - `lifecycleInstalled`: version persisted in managed lifecycle state.
 - `source`: source chosen to compute `effective`.
 - `driftWarning`: compact explanation when those values diverge.
-- `alignmentCommand`: exact command to align consumer dependency and lifecycle state with the current runtime. If the consumer declares Node via `volta`, `.nvmrc`, or `package.json.engines.node`, the command prepends the matching runtime switch before the Pumuki install step.
+- `alignmentCommand`: exact command to align consumer dependency and lifecycle state with the current runtime.
 - `pathExecutionHazard`: tells you whether the repo root itself can break `PATH`-based execution.
 - `pathExecutionWarning`: compact explanation of that hazard.
 - `pathExecutionWorkaroundCommand`: safe local-node entrypoint to use when `PATH` execution is unsafe.
@@ -575,6 +611,7 @@ OpenSpec integration behavior:
 - SDD/OpenSpec enforcement invokes the CLI only from **`{repo}/node_modules/.bin/openspec`** (no fallback to a generic `openspec` on `PATH`).
 - `pumuki install` auto-bootstraps OpenSpec (`@fission-ai/openspec`) when missing/incompatible and scaffolds `openspec/` project baseline when absent.
 - `pumuki install --with-mcp` adds adapter/MCP wiring bootstrap and prints MCP health summary on completion.
+- The **`pumuki` package `postinstall`** runs baseline `pumuki install` from the consumer root (hooks + **`.pumuki/adapter.json`** con comandos MCP stdio, **sin** rutas de IDE). MCP wiring is opt-in via `PUMUKI_POSTINSTALL_WITH_MCP=1` or `PUMUKI_POSTINSTALL_MCP_AGENT=repo|cursor|claude|codex`. Repins refrescan ese contrato de forma **independiente de Cursor/CLI/extensión**. Disable MCP wiring en postinstall: `PUMUKI_POSTINSTALL_SKIP_MCP=1`. Escribir también ficheros de IDE en postinstall: `PUMUKI_POSTINSTALL_MCP_AGENT=cursor|claude|codex` (ver `docs/product/INSTALLATION.md`).
 - `pumuki update --latest` migrates legacy `openspec` package to `@fission-ai/openspec` before hook reinstall.
 
 Safety rule:

package/docs/tracking/plan-curso-pumuki-stack-my-architecture.md

@@ -1,29 +1,25 @@
-# Seguimiento — Curso Pumuki (Stack My Architecture)
+# Diseño pedagógico y seguimiento — Curso Pumuki (Stack My Architecture)
 
-Iniciativa formativa: quinto curso del ecosistema Stack My Architecture. **No** sustituye la fuente viva del tracking interno del producto (`PUMUKI-RESET-MASTER-PLAN.md` en la raíz del repo) y **no** actúa como backlog operativo de Pumuki.
+Este documento define **qué debe aprender una persona**, **en qué orden**, **cómo se comprueba** y **qué confusiones hay que romper**. El seguimiento de repos y build va **al final**; no sustituye el diseño.
 
-## Leyenda
+No sustituye el espejo de producto en [`plan-activo-de-trabajo.md`](./plan-activo-de-trabajo.md).
 
-- ✅ Cerrado
-- 🚧 En construccion (maximo 1)
+## Leyenda operativa
+
+- ✅ Entregado en repo curso + coherente con USAGE/INSTALLATION
+- 🚧 Única tarea activa (máx. 1)
 - ⏳ Pendiente
 - ⛔ Bloqueado
 
-## Regla de uso
+---
 
-- Solo puede existir **una** tarea `🚧` a la vez en este documento.
-- Actualizar estados al cerrar fases o al desbloquear dependencias.
-- Repos objetivo: `stack-my-architecture-pumuki` (curso), `stack-my-architecture-hub` (publicación), enlaces en `stack-my-architecture-governance` y `stack-my-architecture-SDD`.
-- Producto de referencia: repo `ast-intelligence-hooks` (paquete npm `pumuki`). Documentación canónica: `README.md`, `docs/product/USAGE.md`, `docs/product/INSTALLATION.md`.
+## 1. Para quién es y qué problema resuelve
 
-## Contexto
+**Quién:** desarrollador o tech lead que debe **vivir** con hooks, CI y (a veces) agentes; no auditor de slides.
 
-- **Objetivo:** curso dedicado a Pumuki como capa de enforcement (`Facts → Rules → Gate → evidencia v2.1`) en repos reales, sin re-enseñar OpenSpec ni ADR (remite a cursos SDD y Governance).
-- **`courseId` propuesto:** `stack-my-architecture-pumuki` (alinear con hub y progress sync).
-- **Versión mínima `pumuki` (MVP):** `>= 6.3.71` (ajustar al publicar el curso si hay release posterior).
-- **Lab de práctica:** variante o fork de **GovernanceKit** (Governance) o **HelpdeskSDD** (SDD); documentado en `00-preparacion/02-lab-governancekit-helpdesksdd.md` del repo del curso.
+**Problema:** en la práctica mezcla *SDD*, *gate*, *MCP*, *evidencia* y *menú*; cuando algo bloquea no sabe **qué capa** falló ni **qué comando** la inspecciona.
 
-## Estado actual
+**Éxito del curso:** tras cerrarlo, en un repo real puede (1) nombrar el **stage** y el **scope** de un fallo, (2) leer **`.ai_evidence.json`** y relacionarlo con stderr, (3) distinguir **enforcement** (hooks/CI) de **lectura/agente** (MCP), (4) ejecutar el **flujo SDD mínimo** sin confundirlo con “arreglar reglas”, (5) instalar, actualizar o **retirar** Pumuki sin dejar hooks huérfanos.
 
 - **Cierre local y release gate:** `build-hub.sh --mode strict` + smoke runtime en verde.
 - **Origen en GitHub:** el repo **`stack-my-architecture-hub`** tiene en **`main`** la carpeta estática **`pumuki/`** y el pipeline `build-hub` que la genera (sincronizado con remoto; despliegue a producción con el workflow cuando toque).
@@ -32,31 +28,91 @@ Iniciativa formativa: quinto curso del ecosistema Stack My Architecture. **No**
 - **Publicación Vercel:** deploy del proyecto `stack-my-architecture-hub` con verificación de rutas contra el alias **`https://stack-my-architecture-hub.vercel.app`** (incluye `/pumuki/` → 200). El script `publish-architecture-stack.sh` infiere la base desde `Aliased:` (o `SMA_PUBLISH_VERIFY_BASE_URL`) y escribe **`.runtime/publish-verify-base.url`** para alinear `post-deploy-checks.sh` con la URL verificada (localmente o cuando Actions vuelva a estar disponible).
 - Si **`https://architecture-stack.vercel.app`** debe exponer el mismo árbol estático que el hub, sincroniza proyecto/CNAME según tu setup (nota emitida por el script al publicar).
 
-## Prioridad ordenada (fases y tareas)
-
-| Fase | Task | Estado | Notas |
-|------|------|--------|--------|
-| 0 | Crear repo `stack-my-architecture-pumuki` + README + estructura carpetas | ✅ | Repo bajo `stack-my-architecture/stack-my-architecture-pumuki` |
-| 0 | Definir `courseId` y versión mínima `pumuki` | ✅ | `stack-my-architecture-pumuki`, `>= 6.3.71` |
-| 0 | Elegir proyecto lab (GovernanceKit vs HelpdeskSDD) | ✅ | Documentado en preparación del curso |
-| 1 | Redactar roadmap semanal/módulos (`01-roadmap/`) | ✅ | |
-| 1 | Módulos 1–7 MVP (lecciones + enlaces USAGE/README Pumuki) | ✅ | `02-modulos/` + referencias npm/docs producto |
-| 2 | Integración hub: ruta `/pumuki` + `build-hub.sh` + launcher | ✅ | `stack-hub --course pumuki`, assets desde ios parcheados |
-| 2 | Assistant `courseId` + smoke | ✅ | `_hub-platform.js`, `hub-app.js`, README hub + ejemplo curl |
-| 3 | Enlaces desde Governance y SDD | ✅ | Semana 8 checkpoint + SDD semana 8 |
-| 3 | (Opcional) Anexo iOS/Android Arquitecto/Maestría | ✅ | `00-core-mobile/04-calidad-pr-ready.md` iOS y Android |
-| 4 | Scripts validación curso + primera publicación | ✅ | Curso: validate + check-links; hub: publish strict + `/pumuki/` 200 en alias hub |
-
-## Criterios de cierre por fase
-
-- **Fase 0:** repo clonable, README con prerequisitos y convenciones, scripts mínimos ejecutables.
-- **Fase 1:** siete módulos enlazados a docs oficiales Pumuki; roadmap con orden de lectura.
-- **Fase 2:** `build-hub` genera ruta servible; `stack-hub --course pumuki` documentado.
-- **Fase 3:** enlaces mergeados en repos Governance y SDD (y opcional iOS/Android).
-- **Fase 4:** checklist publicación + versión `pumuki` fijada en lecciones y CHANGELOG del curso.
-
-## Auditoría y release (Fase 4)
-
-- Ejecutar en el repo del curso: `scripts/validate-course-structure.py`, `scripts/check-links.py`.
-- Publicación hub: modo `strict` en `Hub Production Release Gate`; verificación de rutas incluye `/pumuki/` en `publish-architecture-stack.sh`.
-- Tras cada release npm relevante de Pumuki, revisar versión mínima en `00-preparacion/` y en este plan.
+Si eso no se cumple, el curso falla aunque el HTML sea bonito.
+
+---
+
+## 2. Modelo mental único (todo el curso orbita aquí)
+
+Una sola frase que el alumno debe poder repetir:
+
+**Hechos del diff/código → reglas efectivas → decisión del gate por stage → registro en evidencia v2.1.**
+
+Todo lo demás (menú, MCP, notificaciones, `doctor`) es **acceso** a ese mismo pipeline o **comodidad**; no es un segundo producto.
+
+---
+
+## 3. Confusiones que el material debe desmontar de forma explícita
+
+Cada unidad del curso debe tener al menos un párrafo “**no confundas**” o un mini escenario:
+
+| Confusión típica | Verdad operativa |
+|------------------|------------------|
+| “Sin MCP no hay Pumuki” | Los **hooks y CI** son el enforcement; MCP es **opcional** para IDE/agente. |
+| “SDD es lo mismo que el gate” | SDD/OpenSpec gobierna el **cambio**; el gate evalúa **código + política + evidencia** en un **scope** concreto. |
+| “`openspec` en el PATH basta” | Pumuki usa OpenSpec **repo-local** (`node_modules/.bin`). |
+| “PRE_COMMIT limpio ⇒ push seguro” | **PRE_PUSH** mira otro **scope** (`upstream..HEAD`). |
+| “El menú es la fuente de verdad” | El menú **orquesta** diagnósticos; la fuente de verdad es **policy + stage + evidencia**. |
+| “Borrar el paquete limpia el repo” | `npm uninstall pumuki` **no** quita hooks/lifecycle; hace falta **`pumuki remove`** / flujo documentado. |
+
+Si el Markdown del curso no nombra estas líneas, el plan pedagógico sigue vacío aunque haya tablas de check.
+
+---
+
+## 4. Secuencia didáctica (orden de primera lectura)
+
+El repo del curso incluye la **columna vertebral en prosa** `00-preparacion/03-recorrido-cero-a-cien-pumuki.md` (0→100 % sin saltos) y el **proyecto guiado** `02-modulos/13-proyecto-guiado-de-la-a-la-z.md` (fases A–M con criterios de hecho). Esta tabla U0–U10 sigue siendo el contrato de **outcomes**; esas piezas son el **relato** y el **laboratorio** que los materializan.
+
+El **mapa completo** (`00-mapa-completo-del-producto.md`) es **referencia** para quien ya perdió el hilo; la **primera pasada** debe seguir esta secuencia para no cargar conceptos antes de tiempo.
+
+| Orden | Unidad | Objetivo observable (el alumno demuestra…) | Actividad mínima en lab | Criterio de dominio |
+|-------|--------|---------------------------------------------|-------------------------|----------------------|
+| U0 | Preparación + versión + lab | Que existe documentación canónica y un repo donde ensayar | Abrir USAGE e INSTALLATION; fijar versión mínima `pumuki` | Explica en una frase dónde miente un “funciona en mi máquina” sin `doctor` |
+| U1 | Contrato + stages + cobertura | Qué pregunta **cada** stage y qué es `unevaluated_rule_ids` | Un `pre-commit` / `pre-push` y leer evidencia | Predice scope antes de ejecutar y acierta al comparar con JSON |
+| U2 | Instalación y primer verde | Postinstall, `bootstrap` vs `install`, `pathExecutionHazard` | `doctor --json` antes/después de un cambio reversible | Usa `alignmentCommand` o workaround sin improvisar |
+| U3 | Ciclo de vida completo | Diferencia `npm uninstall`, `pumuki uninstall`, `pumuki remove`, `update --latest` | Simular retirada en rama de prueba | Lista qué queda en disco tras cada comando |
+| U4 | Evidencia | Dónde se escribe, cuándo **no** se reescribe (PRE_PUSH trackeado), restage PRE_COMMIT | Diff de `.ai_evidence.json` entre stages | Explica un caso “hook modificó archivo” sin pánico |
+| U5 | Menú interactivo | Consumer vs Advanced; 1–4/8/9; matrix; variables UI | Correr `pumuki-framework` y una opción de cada familia | Enlaza opción de menú con **stage** y **scope** equivalentes |
+| U6 | MCP | Evidence vs enterprise; HTTP vs stdio; recibo PRE_WRITE | Levantar o inspeccionar config en `.pumuki/adapter.json` | Explica por qué el gate puede pasar con MCP caído |
+| U7 | SDD/OpenSpec | Flujo diario: `sdd status`, `session`, `validate`; catálogo de códigos | Abrir sesión de cambio y validar un stage | Clasifica un JSON de bloqueo en “falta OpenSpec” vs “falta sesión” |
+| U8 | Notificaciones y watch | macOS vs stderr; `system-notifications.json`; anti-spam de `watch` | Una sesión `watch --once` o documentada | Elige variable correcta para silenciar o espejar |
+| U9 | Perfiles, Governance, monorepo | Cuándo bajar de enterprise; prefijos de scope; parity | (Según perfil del equipo) | Justifica un perfil sin autoboicot |
+| U10 | Cierre | Checklist operativa propia del equipo | Checklist escrita a partir del curso | Puede enseñar el modelo mental §2 a otra persona en 3 minutos |
+
+**Regla:** ninguna fila U1–U10 puede considerarse “hecha” solo con un enlace a USAGE; debe existir **narrativa + comando + actividad + criterio** en el Markdown del curso.
+
+---
+
+## 5. Qué el curso no debe intentar (límites)
+
+- Sustituir el curso **SDD** (OpenSpec, Kanban del cambio) ni el **Governance** (AGENTS, cultura): solo **enganchar** Pumuki a ellos.
+- Sustituir tests de producto, revisión humana ni criterios de negocio.
+- Prometer “cero lectura de USAGE”: USAGE sigue siendo norma; el curso debe **enseñar** lo mismo con **menor fricción**, no duplicar mal.
+
+---
+
+## 6. Estado de entrega en el repo (operativo, subordinado al §4)
+
+| Unidad §4 | Estado en `stack-my-architecture-pumuki` |
+|-----------|-------------------------------------------|
+| U0–U2 | ✅ Base + módulo 2; ciclo de vida **completo** en **08** |
+| U3 | ✅ `02-modulos/08-ciclo-de-vida-install-uninstall-actualizacion.md` |
+| U4 | ✅ `02-modulos/09-evidencia-por-stage-y-ai-evidence-json.md` |
+| U5 | ✅ `02-modulos/10-menu-interactivo-matrix-y-preflight.md` |
+| U6 | ✅ `02-modulos/11-mcp-enforcement-vs-lectura-agente.md` |
+| U7 | ✅ Módulo **04** ampliado (§4.6–4.8 + criterio dominio) |
+| U8 | ✅ `02-modulos/12-notificaciones-macos-stderr-y-watch.md` |
+| U9–U10 | ✅ Revisar checklist **07** frente a criterios §4 en próxima iteración |
+
+| Task | Estado |
+|------|--------|
+| Implementar U3–U8 en `.md` + `FILE_ORDER` + validación | ✅ |
+| CHANGELOG curso + rebuild HTML + sync hub local | ✅ (incl. CSS lectura **0.3.1**) |
+| Push hub + deploy Vercel (ver curso en prod) | 🚧 |
+
+---
+
+## 7. Auditoría técnica (no confundir con evaluación del alumno)
+
+- `python3 scripts/validate-course-structure.py` y `check-links.py` en repo curso.
+- Publicación hub según tu script; URL `/pumuki/` 200.

package/docs/validation/README.md

@@ -14,9 +14,11 @@ Este directorio contiene solo documentación estable de validación y runbooks o
 
 ## Estado de seguimiento
 
-- `docs/validation/` no gobierna backlog.
-- La única fuente viva del tracking interno es `PUMUKI-RESET-MASTER-PLAN.md` en la raíz del repo.
-- `docs/tracking/plan-activo-de-trabajo.md` queda retirado como espejo operativo y solo conserva valor histórico.
+- Única fuente de seguimiento: `docs/tracking/plan-activo-de-trabajo.md`
+
+## GitHub Actions y cuota
+
+Si la organización **no tiene minutos útiles** de Actions, los workflows bajo `.github/workflows/` **no bloquean** el flujo de merge ni sustituyen la evidencia: la barra operativa es **local** — comando único recomendado: **`npm run -s validation:local-merge-bar`** (`typecheck` + `validation:pumuki-surface-smoke` + `npm test`). Complementos habituales: hooks Pumuki, `validation:tracking-single-active`, etc. Alineado con `docs/tracking/plan-activo-de-trabajo.md`.
 
 ## Política de higiene
 
@@ -32,3 +34,4 @@ Este directorio contiene solo documentación estable de validación y runbooks o
 - Higiene hard del worktree propio: `npm run -s validation:self-worktree-hygiene`
 - Suite contractual enterprise: `npm run -s validation:contract-suite:enterprise`
 - Verificación de plan activo único + higiene hard del worktree propio: `npm run -s validation:tracking-single-active`
+- **Smoke de superficie Pumuki** (~29 filas: CLI, `doctor`/`status`, `audit` (varios stages), `watch` (repo + staged), `loop`, `adapter` dry-run repo+codex, `analytics`, `policy` normal+`--strict`, `sdd status`+`validate` por stage, hooks): desde la raíz de **este** repo, `npm run -s smoke:pumuki-surface` (alias: `npm run -s validation:pumuki-surface-smoke`). Tests del resolver y del exit 2 sin `node_modules/pumuki`: `npx --yes tsx@4.21.0 --test scripts/__tests__/pumuki-full-surface-smoke-lib.test.ts scripts/__tests__/pumuki-full-surface-smoke-exit2.test.ts`. Opcional sobre un consumidor con **bins del tree pumuki** (gate en el cwd del consumidor): `PUMUKI_SMOKE_REPO_ROOT=/ruta/abs/al/consumer npm run -s smoke:pumuki-surface`. Para validar **exactamente lo instalado** en `node_modules/pumuki` del consumidor: `PUMUKI_SMOKE_REPO_ROOT=/ruta/abs/al/consumer PUMUKI_SMOKE_BIN_STRATEGY=installed npm run -s smoke:pumuki-surface`, o `PUMUKI_SMOKE_REPO_ROOT=/ruta/abs/al/consumer npm run -s smoke:pumuki-surface-installed`. Ver interpretación de exit codes al final del informe impreso.

package/integrations/config/skillsDetectorRegistry.ts

@@ -174,30 +174,6 @@ const registryByRuleId: Record<string, SkillsDetectorBinding> = {
   'skills.backend.no-god-classes': heuristicDetector('typescript.god-class', [
     'heuristics.ts.god-class-large-class.ast',
   ]),
-  'skills.backend.guideline.backend.callback-hell-usar-async-await': heuristicDetector(
-    'typescript.new-promise-async',
-    ['heuristics.ts.new-promise-async.ast']
-  ),
-  'skills.backend.guideline.backend.try-catch-silenciosos-siempre-loggear-o-propagar':
-    heuristicDetector('typescript.empty-catch', ['heuristics.ts.empty-catch.ast']),
-  'skills.backend.guideline.backend.hardcoded-values-config-en-variables-de-entorno':
-    heuristicDetector('typescript.hardcoded-secret-token', [
-      'heuristics.ts.hardcoded-secret-token.ast',
-    ]),
-  'skills.backend.guideline.backend.magic-numbers-usar-constantes-con-nombres-descriptivos':
-    heuristicDetector('typescript.magic-number', ['heuristics.ts.magic-number.ast']),
-  'skills.backend.guideline.backend.mocks-en-produccion-usar-fakes-spies-de-test':
-    heuristicDetector('typescript.production-mock-artifact', [
-      'heuristics.ts.production-mock-artifact.ast',
-    ]),
-  'skills.backend.guideline.backend.anemic-domain-models-entidades-con-comportamiento':
-    heuristicDetector('typescript.anemic-domain-model', [
-      'heuristics.ts.anemic-domain-model.ast',
-    ]),
-  'skills.backend.guideline.backend.logica-en-controllers-mover-logica-de-negocio-a-casos-de-uso-servicios':
-    heuristicDetector('typescript.controller-business-logic', [
-      'heuristics.ts.controller-business-logic.ast',
-    ]),
   'skills.frontend.no-empty-catch': heuristicDetector('typescript.empty-catch', [
     'heuristics.ts.empty-catch.ast',
   ]),