claude-code-arcane 2.1.0 → 2.3.0

package/rules/freelance-guardrails.md

@@ -0,0 +1,53 @@
+# Freelance Guardrails (marketplaces y clientes directos)
+
+Buscar empleo es gratis: aplicás a 40 puestos y solo perdés tiempo. Freelancear no. Cada propuesta cuesta algo, cada contrato malo toca tu reputación, y cada "¿me agregás esto rapidito?" sin cobrar sale de tu bolsillo.
+
+Estas cuatro reglas existen porque los tres recursos que se gastan (plata, reputación, tiempo no facturado) no se recuperan.
+
+**El costo de postularse tiene nombre distinto en cada plataforma** y las reglas valen igual: Connects en Upwork, bids en Freelancer.com, y en outreach directo son las horas que ponés en escribir la propuesta. Donde abajo diga Connects, leé "lo que te cuesta postularte".
+
+Las rutas son relativas al career workspace (`./career-workspace/` o env `CAREER_WORKSPACE`).
+
+## 1. Postularse cuesta plata: no se gasta sin screen
+
+Nunca redactar una propuesta para una oferta cuyo cliente no pasó `/client-screen`, ni para una que quedó bajo el umbral de score.
+
+Si el usuario quiere postularse igual a una que falló el screen, se puede - **pero se le dice qué falló y se registra en la nota**. Un pago sin verificar que nadie nombró es una postulación tirada, y peor: es la propuesta que sí te contestan y termina en disputa.
+
+## 2. La reputación se protege rechazando
+
+Ganar un contrato no siempre es bueno. Casi toda plataforma calcula un puntaje sobre contratos cerrados (en Upwork es el Job Success Score) donde un cliente insatisfecho pesa más que dos contentos, y con clientes directos el equivalente son las referencias que no vas a poder pedir. Un contrato con alcance difuso, presupuesto irrealista o cliente sin historial es **riesgo de reputación**, no una oportunidad.
+
+Cuando el screen marca riesgo alto, la recomendación por defecto es no postularse. Decir "no" es una acción del pipeline, no una ausencia de acción.
+
+## 3. Nada se cotiza abajo del piso
+
+Todo bid pasa por el piso declarado en `01-Perfiles/` (tarifa mínima aceptable). El piso es **neto**, después de la comisión de la plataforma: si se queda un 10%, un piso de 40 USD/h exige bidear 45. Con cliente directo la comisión es cero, pero el piso sigue siendo neto de impuestos y de las horas no facturables.
+
+Si el usuario todavía no fijó un piso, `/freelance-scan market` da la mediana de lo que cobran otros con su perfil. Es un punto de partida, no el piso: el piso lo define su costo de vida, no el mercado.
+
+Alcance nuevo, precio nuevo. Ninguna propuesta ni contrato se amplía sin cotizarlo: si el trabajo extra no entra en un change order con número, no entra.
+
+## 4. El envío siempre lo hace el usuario
+
+Ninguna skill de este perfil envía una propuesta, acepta un contrato ni gasta el presupuesto de postulaciones. Se redacta, se revisa, se muestra, y el usuario copia y manda.
+
+Esto no es prudencia nuestra: **la API de Upwork no tiene mutation para postularse ni para gastar Connects**, justamente para frenar bots de auto-bidding, y las demás plataformas prohíben el envío automatizado en sus términos. Ninguna skill debe pretender lo contrario, y una que lo intentara estaría violando los ToS además de esta regla.
+
+El corolario para las **fuentes**: ninguna skill del perfil puede depender de credenciales que cada usuario tenga que conseguir por su cuenta. Este perfil lo instala cualquiera, y una fuente con API key aprobada a mano funciona para uno y está rota para el resto. Las fuentes automáticas son públicas y sin key (ver `skills/freelance-scan/references/platforms.md`); lo demás se pega a mano.
+
+## La estructura no la sostiene este archivo
+
+Una regla sin columna derecha es una intención.
+
+| Regla | Qué la hace cumplir |
+|---|---|
+| Screen antes de gastar en postularse | `/freelance-proposal` exige la nota de screen; sin ella, pregunta y no redacta |
+| Rechazar por riesgo de reputación | `/client-screen` emite veredicto explícito; el agente `client-screener` es adversarial por diseño |
+| Piso de tarifa | `/freelance-proposal` lee el piso del perfil y falla ruidoso si el bid queda abajo; `/freelance-scan market` da la referencia de mercado |
+| Alcance nuevo, precio nuevo | `/freelance-pipeline` detecta drift de alcance en contratos activos y pide change order |
+| Envío manual | Ningún script del perfil escribe a una plataforma: `freelance_search.py` solo lee, y no hay otro |
+
+## Registro
+
+Toda decisión de no postularse se registra igual que una postulación: nota en `03-Aplicaciones/` con `estado: descartado` y el motivo en `## Notas`. Los descartes son la mitad de los datos que `/freelance-pipeline` necesita para decirte si tu criterio de selección funciona.

package/rules/gamedev/audio-code.md

@@ -0,0 +1,45 @@
+---
+paths:
+  - "src/audio/**"
+---
+
+# Audio Code Rules
+
+- NEVER hardcode asset paths or clip references in gameplay code — post middleware events by name/ID
+- Gameplay code MUST NOT call `Play()`/`PlayOneShot()` directly — raise an audio event, let the audio layer resolve it
+- Concurrency limits (max instances, priority, cooldown) MUST be declared in data, never enforced with ad-hoc counters in gameplay
+- Use delta time for ALL fades, ducking ramps and RTPC interpolation (frame-rate independence)
+- NO static singletons for audio state — inject the audio service
+- Every RTPC/parameter driven from gameplay must be normalized and clamped at the boundary before it reaches the middleware
+- Voice budget is a hard limit: define max simultaneous voices per category and drop by priority, never let it grow unbounded
+- Audio must degrade silently — a missing bank or failed event NEVER throws into the gameplay frame
+- Keep the audio update off the render-critical path; audio work budget is 5-10% of frame time
+- Reference the audio bible section each event implements in code comments
+
+## Examples
+
+**Correct** (event-driven, data-declared):
+
+```csharp
+// Gameplay raises intent; the audio layer owns resolution and limits.
+audioService.Post(AudioEvent.PlayerFootstep, transform.position);
+
+float wetness = Mathf.Clamp01(surface.Wetness);       // clamped at the boundary
+audioService.SetParameter(AudioParam.SurfaceWetness, wetness);
+
+// Fade driven by delta time, not frame count.
+currentVolume = Mathf.MoveTowards(currentVolume, targetVolume, fadeRate * Time.deltaTime);
+```
+
+**Incorrect** (hardcoded, direct, frame-dependent):
+
+```csharp
+AudioSource.PlayClipAtPoint(
+    Resources.Load<AudioClip>("SFX/footstep_concrete_01"),  // VIOLATION: hardcoded path
+    transform.position);                                     // VIOLATION: direct playback from gameplay
+
+AudioManager.Instance.Play("footstep");   // VIOLATION: static singleton
+
+currentVolume -= 0.02f;                   // VIOLATION: no delta time
+audioService.SetParameter(AudioParam.SurfaceWetness, rawSensorValue);  // VIOLATION: unclamped
+```

package/skills/adaptive-music/SKILL.md

@@ -0,0 +1,171 @@
+---
+name: adaptive-music
+description: "Musica interactiva para juegos: layering vertical, re-secuenciacion horizontal, stingers, reglas de transicion con sync points, y mapeo de estados de gameplay a musica. Usar para: musica adaptativa, sistema de musica dinamica, transiciones musicales, combat music."
+category: "audio"
+argument-hint: "[design|layers|transitions|stingers|map]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit
+---
+# adaptive-music — Sistemas de Música Interactiva
+
+Diseña el sistema que decide **qué música suena cuándo** y **cómo pasa de un estado a otro sin que se escuche la costura**.
+
+Esta skill diseña el sistema. El material musical lo escribe `/music-composition`; la implementación en middleware la baja `/middleware-integration`.
+
+## Cuándo usar
+
+- Cuando la música tiene que responder a gameplay y no alcanza con reproducir un track
+- Cuando las transiciones entre estados (exploración → combate → victoria) suenan a corte
+- Cuando el loop fatiga y necesitás variación estructural, no otro track
+- Antes de que el compositor escriba una nota: el sistema condiciona cómo se compone
+
+## Modos
+
+| Modo | Qué hace |
+|---|---|
+| `design` | El sistema completo: eje dominante, capas/segmentos, matriz, stingers, parámetros |
+| `layers` | Solo la arquitectura vertical: qué capas, qué rol, qué restricción compositiva |
+| `transitions` | Solo la matriz de transiciones con sync points y segmentos de transición |
+| `stingers` | Solo los stingers: armonía, sincronización, cooldown |
+| `map` | Solo la tabla estado de gameplay → música, con triggers e histéresis |
+
+## Input
+
+1. Leer audio bible, sección 2 (emotional targets por game state) y 6 (music direction). Si no existe, avisar y ofrecer `/audio-bible`
+2. Listar los estados de gameplay reales — del código o del GDD, no inventados
+3. Preguntar al usuario: middleware target (Wwise / FMOD / engine nativo / sin definir), budget de memoria para música, y si hay material compuesto o se parte de cero
+
+---
+
+## Los dos ejes
+
+Todo sistema de música adaptativa es una combinación de estos dos. Elegir cuál domina es la primera decisión.
+
+### Vertical — layering
+
+Un mismo bloque temporal, capas que entran y salen. Todas suenan sincronizadas porque comparten grid y armonía.
+
+- **Fuerte en:** respuesta inmediata a parámetros continuos (proximidad de enemigo, salud, intensidad de combate)
+- **Débil en:** cambiar de material. Todo suena a la misma pieza
+- **Costo:** memoria (N stems simultáneos) y una restricción compositiva real — cada capa debe funcionar sola y en toda combinación
+
+### Horizontal — re-secuenciación
+
+Segmentos distintos que se concatenan según reglas, con transiciones en puntos musicalmente válidos.
+
+- **Fuerte en:** cambiar de material y de forma; estructura no repetitiva
+- **Débil en:** respuesta inmediata. La transición espera el sync point
+- **Costo:** latencia de respuesta (hasta un compás o más) y complejidad de reglas
+
+**Recomendación:** vertical para intensidad continua, horizontal para cambios de estado discretos. La mayoría de los juegos necesitan los dos: capas dentro de cada segmento, re-secuenciación entre segmentos.
+
+---
+
+## Sync points — dónde se puede cortar
+
+Una transición suena bien o mal según **dónde** ocurre, no según el crossfade. De más responsivo a más musical:
+
+| Sync point | Latencia | Cuándo usarlo |
+|---|---|---|
+| **Inmediato** | 0 | Emergencias (muerte del jugador). Suena a corte, y a veces eso está bien |
+| **Siguiente beat** | hasta 1 beat | Reacción rápida que igual respeta el pulso |
+| **Siguiente compás (bar)** | hasta 1 compás | El default sano para la mayoría de los casos |
+| **Siguiente grid** | variable | Cuando definís una grilla más gruesa (2 o 4 compases) |
+| **Exit cue** | hasta el fin del segmento | Máxima musicalidad, máxima latencia |
+| **Entry cue del destino** | — | Define desde dónde arranca el segmento destino |
+
+**Segmento de transición** — un fragmento corto que se inserta entre origen y destino. Resuelve los saltos que ningún sync point salva: cambio de tonalidad, de tempo o de métrica. Es la herramienta que más mejora un sistema y la que menos se usa.
+
+En Wwise esto es la Transition Matrix del Music Switch Container: origen × destino, con Exit Cue del origen, Entry Cue del destino, fade in/out, y segmento de transición opcional. En FMOD el equivalente son transition regions y transition timelines. El concepto es el mismo; la nomenclatura cambia.
+
+---
+
+## Stingers
+
+Frases cortas que se superponen sin interrumpir la música de fondo, sincronizadas al grid para que no suenen encima del tiempo equivocado.
+
+- Uso: eventos puntuales que merecen puntuación musical — descubrimiento, kill, item raro, fallo
+- **Deben compartir armonía con el material de fondo**, o sonar deliberadamente disonantes. Un stinger en la tonalidad equivocada es el error más audible del sistema
+- Sincronizar a beat o compás, nunca inmediato
+- Definir cooldown: dos stingers superpuestos suenan a error
+- Si el fondo modula, el stinger necesita versiones por tonalidad o tiene que ser tonalmente neutro (percusión, cluster, ruido)
+
+---
+
+## Diseño del mapeo
+
+El entregable central: la tabla estado → música.
+
+| Estado de gameplay | Trigger | Segmento / capas | Sync point | Notas |
+|---|---|---|---|---|
+| Explore calm | default | bed + pulse | bar | loop indefinido |
+| Explore alert | enemigo a <30 m | + harmony | beat | vuelve a calm con 5 s de histéresis |
+| Combat | combate iniciado | segmento combat, todas las capas | bar | |
+| Combat low health | HP < 25% | + intensity, filtro | beat | |
+| Victory | combate resuelto | stinger + segmento victory | exit cue | one-shot, vuelve a explore |
+| Death | HP = 0 | inmediato, corte | inmediato | |
+
+**Parámetros continuos** aparte: qué RTPC/parámetro maneja qué, con rango normalizado y curva.
+
+| Parámetro | Rango | Controla | Curva |
+|---|---|---|---|
+| `combat_intensity` | 0-1 | volumen de capa intensity | log |
+| `player_health` | 0-1 | filtro low-pass sobre el bus música | lineal |
+
+---
+
+## Histéresis — el detalle que rompe los sistemas
+
+Un estado que se calcula por umbral (`enemigo a <30 m`) va a oscilar cuando el jugador camine en el borde. El resultado es música entrando y saliendo cada segundo.
+
+Toda transición basada en umbral necesita:
+- **Umbrales distintos por dirección** — entra a 30 m, sale a 40 m
+- **Tiempo mínimo en estado** — no se puede salir antes de N segundos
+- **Debounce del trigger** — la condición tiene que sostenerse antes de contar
+
+Sin esto, el sistema funciona en el editor y falla con un jugador real.
+
+---
+
+## Enfoques generativos
+
+Cuando la variación por capas y segmentos no alcanza:
+
+- **Selección estocástica de capas/segmentos** — la variación sale de qué combinación suena. El más barato y controlable; empezar acá siempre
+- **Cadenas de Markov** — melodía estocástica entrenada sobre material propio. Preserva idioma, no genera estructura
+- **L-systems / gramáticas recursivas** — generan estructura jerárquica por reescritura de reglas. Complemento de Markov, que no tiene forma
+- **Restricciones armónicas** — capa de validación sobre lo generado: el generador propone, las reglas de función y voice leading filtran
+
+La generación de notas en tiempo real tiene un techo de calidad y un riesgo de que suene mal en producción que la selección de material pregrabado no tiene. Justificar antes de ir por ahí.
+
+---
+
+## Proceso
+
+1. **Listar estados reales** del gameplay, con sus triggers exactos
+2. **Elegir el eje dominante** (vertical / horizontal / mixto) y justificarlo contra el budget
+3. **Definir capas o segmentos** y la restricción compositiva que impone al compositor
+4. **Llenar la matriz de transiciones** con sync points, y marcar dónde hace falta segmento de transición
+5. **Definir stingers** con su armonía y cooldown
+6. **Definir parámetros continuos** con rango y curva
+7. **Agregar histéresis** a toda transición por umbral
+8. **Presentar** al usuario y preguntar "¿Escribo el diseño a `<path>`?" antes de usar Write
+
+---
+
+## Verdict
+
+- **READY** — la matriz está completa, todo umbral tiene histéresis, los stingers tienen armonía definida, y el compositor sabe qué restricción respetar
+- **CONCERNS** — el diseño existe pero hay transiciones sin sync point, umbrales sin histéresis, o el budget de memoria no se verificó contra el número de stems
+- **BLOCKED** — los estados de gameplay no están definidos, o no hay dirección musical de la cual derivar los emotional targets
+
+## Anti-patterns
+
+> → Read references/anti-patterns.md
+
+## Next steps
+
+- `/music-composition` para escribir el material respetando las restricciones de capas
+- `/middleware-integration` para implementar la matriz en Wwise/FMOD
+- `/audio-mix` para el ducking entre música y diálogo
+- `/audio-audit` para verificar memoria y voice count del sistema en runtime

package/skills/adaptive-music/references/anti-patterns.md

@@ -0,0 +1,53 @@
+# Música Adaptativa — Anti-patterns
+
+## Crossfade como única transición
+
+Fundir dos piezas en tonalidades o tempos distintos suena a error, no a transición. El crossfade solo funciona si el material comparte armonía y grid. Si no, hace falta sync point + segmento de transición.
+
+## Transiciones inmediatas por default
+
+Cortar al instante es responsivo y musicalmente destructivo. Reservarlo para muerte del jugador y cortes deliberados. El default sano es siguiente compás.
+
+## Umbrales sin histéresis
+
+El caso clásico: el jugador camina en el borde de un radio de detección y la música de combate entra y sale seis veces en diez segundos. Umbrales asimétricos + tiempo mínimo en estado + debounce. Siempre.
+
+## Capas que dependen entre sí
+
+Si la capa de melodía se escribió asumiendo que la de armonía suena, al quitar la armonía la melodía queda flotando sin contexto. Cada capa tiene que funcionar sola y con cualquier subconjunto de las de abajo.
+
+## Stingers en la tonalidad equivocada
+
+El error más audible del sistema. Si el fondo modula y el stinger es tonal y fijo, va a chocar. Versiones por tonalidad, o stingers tonalmente neutros.
+
+## Stingers sin cooldown
+
+Cinco kills en dos segundos disparan cinco stingers superpuestos. Suena a bug.
+
+## Contar los stems y no la memoria
+
+Ocho stems estéreo a 48 kHz sonando simultáneos es mucho más que "ocho archivos". Si van descomprimidos en memoria, el número crece rápido. Verificar el budget antes de comprometer la arquitectura vertical.
+
+## Diseñar el sistema después de componer
+
+Si el compositor entregó una pieza lineal de tres minutos con clímax, convertirla en capas es imposible sin rehacerla. El sistema se diseña primero y define la restricción compositiva.
+
+## Un estado por situación
+
+Veinte estados de música para veinte situaciones de gameplay produce una matriz de transiciones de 400 celdas que nadie va a autorear bien. Agrupar situaciones por emotional target: la mayoría de los juegos vive bien con 4-6 estados.
+
+## Loop que cierra con cadencia auténtica
+
+Cada vuelta suena a arranque forzado. Cerrar abierto: semicadencia, pedal, cadencia plagal.
+
+## Música ocupando el rango del diálogo
+
+Si el arreglo vive en 500 Hz-2 kHz y hay VO, uno de los dos pierde, y el ducking agresivo se escucha. Se resuelve en el arreglo, no en el mix.
+
+## Ignorar el estado inicial y el retorno
+
+Se diseña explore → combat con cuidado y se olvida combat → explore. El retorno es la transición que el jugador escucha más veces.
+
+## Probar solo en el editor
+
+El editor de middleware permite disparar estados a mano, en el orden correcto, sin ruido. El jugador real dispara transiciones en secuencias imposibles. Probar con gameplay, no con botones.

package/skills/audio-audit/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: audio-audit
+description: "Auditoria de audio: voice count, CPU, memoria, streaming, compliance de loudness (ASWG-R001), conformidad de assets contra spec y checklist por plataforma. Usar para: QA de audio, performance de audio, verificar loudness, revisar assets, pre-certificacion."
+category: "audio"
+argument-hint: "[full | perf | loudness | assets | platform]"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Write, Edit, Bash
+---
+# audio-audit — QA y Compliance de Audio
+
+Verifica que el audio del proyecto cumple: performance dentro del presupuesto, assets conformes al spec, y loudness dentro del target de plataforma.
+
+## Cuándo usar
+
+- Antes de una milestone o de certificación
+- El audio se corta, se satura o come demasiado CPU
+- Verificar assets entregados por un contractor
+- Auditar loudness para cumplir requisitos de plataforma
+- Después de integrar un sistema nuevo, para medir su costo real
+
+## Input
+
+1. Leer audio bible (sección 8, standards) y los specs de `/audio-spec`
+2. Determinar plataformas target, y cuál es la más baja
+3. Preguntar al usuario: alcance (`full` / solo perf / solo loudness / solo assets) y si hay captura de profiler disponible
+
+---
+
+## 1. Performance
+
+**Presupuesto:** el audio dispone del **5-10% del frame time**. A 60 fps el frame son 16.6 ms, así que el audio tiene ~0.8-1.7 ms. A 90 fps (VR) el frame son ~11 ms y el margen es menor.
+
+| Métrica | Cómo se mide | Verdict |
+|---|---|---|
+| **CPU de audio** | Profiler del middleware, en gameplay real | FAIL si supera el 10% del frame sostenido |
+| **Voces activas** | Pico vs límite configurado | CONCERNS si el pico toca el límite; FAIL si hay descartes de sonidos de prioridad alta |
+| **Memoria de audio** | Por bank y total, vs budget del proyecto | FAIL si supera el budget en la plataforma más baja |
+| **Accesos de streaming** | Contador de streaming del profiler | CONCERNS si hay starvation |
+| **Game objects registrados** | Contador, medido a lo largo de una sesión larga | FAIL si crece monótonamente (leak) |
+
+**Medir en gameplay real, no en el editor.** El editor dispara eventos en orden, uno por vez, sin ruido. El jugador produce combinaciones que nadie planificó. Y medir en la **plataforma más baja** del target: el presupuesto que cierra en PC no dice nada de un handheld.
+
+**El leak de game objects es el hallazgo más frecuente.** Si el contador de objetos registrados crece durante una sesión de dos horas y nunca baja, hay des-registros faltantes. Se ve solo en sesiones largas.
+
+### Costos de referencia
+
+Para saber si un número medido es razonable:
+
+| Operación | Costo esperado por fuente |
+|---|---|
+| Convolución HRTF (512 taps) | ~2 ms |
+| Encode ambisónico | ~0.1 ms |
+| Decode ambisónico a binaural | ~1 ms total |
+| Footstep procedural | ~1-2 ms |
+| Síntesis de viento | ~0.5 ms/frame |
+| Panning + atenuación | despreciable |
+
+Si lo medido se desvía mucho del esperado, la causa suele ser configuración (más taps, más fuentes espacializadas de las previstas) antes que el motor.
+
+## 2. Loudness
+
+Referencia de industria en juegos: **ASWG-R001** (Sony), la única especificación publicada por una plataforma mayor.
+
+| Contexto | Loudness promedio | True peak máximo |
+|---|---|---|
+| Consola / home | **−23 LUFS** (±2) | **−1 dBTP** |
+| Portable / handheld | **−18 LUFS** | −1 dBTP |
+
+**Cómo medir bien:**
+
+- Se mide el **programa completo en gameplay representativo**, no un asset aislado. Medir un `.wav` no dice nada sobre cumplimiento
+- Sesión de duración suficiente para promediar: al menos varios minutos cubriendo exploración, combate y diálogo
+- Medir el **true peak**, no el peak de sample: la codificación lossy puede generar picos por encima del valor medido en PCM
+- **Confirmar el target vigente** de cada plataforma antes de certificación. Las recomendaciones se revisan — el promedio de ASWG también se citó como −24 LKFS, así que no confiar en un número memorizado
+
+**Verdict:** COMPLIANT dentro del target con su tolerancia; NON-COMPLIANT fuera, o con true peak por encima de −1 dBTP.
+
+## 3. Conformidad de assets
+
+Verificación mecánica contra los standards del bible. Esto se automatiza:
+
+| Chequeo | Falla típica |
+|---|---|
+| Sample rate | Mezcla de 44.1 y 48 kHz en el mismo proyecto |
+| Bit depth | 24-bit donde el pipeline espera 16 |
+| Canales | Estéreo en un asset que se usa como fuente 3D mono |
+| Naming | No sigue el patrón; rompe batch y automatización de banks |
+| DC offset | Produce clicks al concatenar |
+| Silencio al inicio | Retrasa el ataque; se percibe como lag |
+| Clipping | Picos a 0 dBFS en el asset crudo |
+| Duración vs spec | Fuera del rango especificado |
+| Loudness por categoría | Assets de la misma categoría con niveles dispares |
+
+**Fuente 3D en estéreo es el hallazgo más común y el más silencioso:** el middleware la trata distinto o la colapsa, y la localización espacial se degrada sin que nadie vea un error.
+
+La skill trae el verificador: `scripts/check_assets.py`, stdlib-only (módulo `wave`), recursivo sobre una carpeta.
+
+```bash
+python skills/audio-audit/scripts/check_assets.py assets/audio \
+  --rate 48000 --bits 16 --mono-3d --naming '^(sfx|vo|mus)_'
+```
+
+Chequea sample rate, bit depth, canales, naming, clipping, DC offset, silencio inicial, archivos vacíos o silenciosos, y avisa cuando el sample rate obliga a un resampleo costoso. Emite `[FAIL]` / `[WARN]` / `[SKIP]` por hallazgo y cierra con COMPLIANT / CONCERNS / NON-COMPLIANT; exit code 1 solo si hay FAIL, para usarlo en CI.
+
+Lo que necesita una herramienta externa (loudness integrado, análisis espectral) se reporta como `[SKIP]` en vez de abortar la corrida.
+
+## 4. Checklist por plataforma
+
+| Ítem | Aplica a |
+|---|---|
+| Loudness dentro del target del contexto | Todas |
+| True peak ≤ −1 dBTP | Todas |
+| Manejo de interrupciones (llamada, alarma) | Móvil |
+| Manejo de cambio de ruta (auriculares) | Móvil, consola |
+| Respeto del switch de silencio | iOS |
+| Comportamiento en background | Móvil |
+| Mezcla con audio de terceros | Móvil |
+| Audio no rompe al perder foco | Todas |
+| Memoria dentro del budget de la plataforma | Todas |
+| Se puede mutear todo desde opciones | Todas |
+| Controles separados: música / SFX / voz / UI | Todas |
+| Información crítica no exclusivamente por audio | Todas (accesibilidad) |
+| Subtítulos para todo el diálogo | Todas (accesibilidad) |
+
+El comportamiento en background y el switch de silencio en iOS son causas concretas de rechazo de store, no recomendaciones.
+
+---
+
+## Proceso
+
+1. **Determinar el alcance** y la plataforma más baja del target
+2. **Capturar** con el profiler del middleware en gameplay representativo, no en el editor
+3. **Medir performance** contra el presupuesto y comparar con los costos de referencia
+4. **Medir loudness** del programa completo, con true peak
+5. **Verificar assets** contra los standards, automatizado si el volumen lo justifica
+6. **Recorrer el checklist** de plataforma
+7. **Reportar** con severidad por hallazgo y, si el usuario lo pide, preguntar "¿Escribo el reporte a `<path>`?" antes de usar Write
+
+### Formato del reporte
+
+Por hallazgo: qué se midió, valor medido, valor esperado, severidad, y dónde está el problema. Un hallazgo sin número medido no es un hallazgo, es una impresión.
+
+---
+
+## Verdict
+
+Global, y por sección:
+
+- **COMPLIANT** — performance dentro del presupuesto en la plataforma más baja, loudness dentro del target, assets conformes, checklist completo
+- **CONCERNS** — hay desvíos que no bloquean: pico de voces tocando el límite, assets con naming inconsistente, loudness en el borde de la tolerancia
+- **NON-COMPLIANT** — CPU o memoria fuera de presupuesto, loudness fuera del target, leak de game objects, o un ítem de checklist que es causa de rechazo de plataforma
+
+Un NON-COMPLIANT en cualquier sección bloquea certificación.
+
+## Anti-patterns
+
+> → Read references/anti-patterns.md
+
+## Next steps
+
+- `/spatial-audio` si el costo de espacialización está fuera de presupuesto
+- `/audio-mix` si el problema es loudness o balance entre categorías
+- `/middleware-integration` si hay leaks, banks mal organizados o descartes de voces
+- `/procedural-audio` si la memoria no cierra por cantidad de samples

package/skills/audio-audit/references/anti-patterns.md

@@ -0,0 +1,65 @@
+# Audio Audit — Anti-patterns
+
+## Medir en el editor
+
+El editor dispara eventos en orden, uno por vez, sin ruido de fondo. El jugador produce combinaciones que nadie planificó. Las mediciones del editor no predicen nada.
+
+## Medir en la plataforma más alta
+
+El presupuesto cierra cómodo en PC y revienta en el handheld. La auditoría se hace contra el piso del target.
+
+## Medir loudness de un asset
+
+Los targets de LUFS son del programa completo en gameplay representativo. Medir un `.wav` no dice nada sobre cumplimiento.
+
+## Sesión de medición demasiado corta
+
+Treinta segundos de exploración tranquila da un LUFS que no representa el juego. La medición tiene que cubrir exploración, combate y diálogo.
+
+## Confiar en un target memorizado
+
+Las recomendaciones de plataforma se revisan. Confirmar el vigente antes de certificación.
+
+## Medir peak de sample en vez de true peak
+
+Un mix que llega a 0 dBFS en PCM puede generar picos por encima al codificarse en lossy. El −1 dBTP existe justamente por eso.
+
+## No buscar leaks
+
+El contador de game objects registrados que crece durante dos horas y nunca baja es el hallazgo más frecuente, y solo se ve en sesiones largas. Una prueba de cinco minutos no lo encuentra.
+
+## Aceptar el pico de voces al límite
+
+Si el pico toca el límite configurado, cualquier situación un poco peor empieza a descartar sonidos. Y si lo que se descarta es feedback de la acción del jugador, el juego se siente roto sin ningún error visible.
+
+## Ignorar qué se descarta
+
+El número de descartes por sí solo no dice nada. Lo que importa es la prioridad de lo descartado: perder un ambiente lejano está bien, perder el disparo del jugador no.
+
+## Fuente 3D en estéreo
+
+El hallazgo más silencioso: el middleware la colapsa o la trata distinto, y la localización espacial se degrada sin que aparezca ningún error. Verificar canales por categoría de uso.
+
+## Mezcla de sample rates
+
+44.1 y 48 kHz en el mismo proyecto obliga a resampleo en runtime, que cuesta CPU y puede introducir artefactos. Un solo sample rate por proyecto.
+
+## Silencio al inicio del asset
+
+Retrasa el ataque y se percibe como lag de input, aunque el código responda instantáneo. Se detecta automáticamente y casi nunca se busca.
+
+## Hallazgo sin número
+
+"El audio suena saturado" no es un hallazgo. Qué se midió, valor medido, valor esperado, dónde. Sin eso, nadie puede arreglarlo ni verificar que se arregló.
+
+## Auditar a mano miles de assets
+
+La conformidad de sample rate, canales, naming y duración es mecánica: se automatiza. La inspección manual de 4.000 archivos garantiza que algo se pase por alto.
+
+## Fallar cuando falta una herramienta externa
+
+Si el chequeo profundo necesita una herramienta que no está instalada, reportar `[SKIP]` y seguir. Abortar la auditoría entera por una dependencia opcional deja al usuario sin los chequeos que sí se podían correr.
+
+## Dejar el checklist de plataforma para el final
+
+El comportamiento en background y el switch de silencio en iOS son causas concretas de rechazo. Descubrirlos en certificación cuesta una release.