feat(sprint-1.5): rediseño visual PDF ROI + identidad InQ (Etapas 4-7)

- Header/footer compartidos con paleta InQ naranja en los 3 PDFs (Etapa 4)
- Layout híbrido portrait+landscape en PDFs Actual/Automatizado:
  página 2 landscape para diagrama BPMN heatmap (Etapa 5)
- Página 1 PDF ROI rediseñada: header denso, banner narrativo, KPI Hero
  con gradiente naranja→magenta, grid 2×2 de KPIs secundarios, Top 3
  actividades por ahorro (Etapa 6)
- Páginas 2-5 PDF ROI con identidad InQ: tabla con paleta naranja,
  análisis del ahorro, nota metodológica, trayectoria del ahorro
  acumulado con gráfico SVG nativo (Etapa 7)
- 500 tests verdes (+ 34 tests nuevos del Sprint 1.5)
- BACKLOG.md, TECH_DEBT.md, OBSERVATIONS.md: sistema de planificación
  reemplaza TODO.md

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

methodology/PATTERNS.md

@@ -276,6 +276,52 @@ Las decisiones arquitectónicas importantes se registran como ADR (Architectural
 
 ---
 
+### D.4 Permisos del agente versionados en `.claude/`
+**Estado:** propuesto · **Deriva de:** Principios 4 y 5
+
+Las decisiones sobre qué comandos puede ejecutar el agente sin consultar al humano se versionan en archivos de configuración del repo. Esto evita dos extremos: la fricción de aprobar cada comando manualmente, y el bypass total que abre la puerta a acciones no intencionadas.
+
+**Estructura recomendada:**
+
+```
+repo/
+└── .claude/
+    ├── settings.json          ← commitable: deny patterns críticos
+    └── settings.local.json    ← gitignored: allow personales del dev
+```
+
+**Reglas:**
+
+1. **`settings.json` es del proyecto** — contiene patrones `deny` (comandos peligrosos prohibidos para todos: `rm -rf /`, `git push --force`, `npm publish`, etc.). Se comitea al repo.
+
+2. **`settings.local.json` es del desarrollador** — contiene patrones `allow` personales (cada uno decide qué comandos pre-aprueba). Va en `.gitignore`. Cuando un dev nuevo arranca, **debe construir su propio** archivo siguiendo el template, no copiar el de otro.
+
+3. **El equipo hereda las protecciones, no las preferencias** — los `deny` son compartidos, los `allow` son individuales.
+
+**Por qué:**
+- La fricción de aprobar cada `npm install` destruye el flow de trabajo
+- Pero el bypass total elimina los puntos de control donde se detectan acciones no intencionadas
+- La gobernanza está en clasificar comandos por riesgo, no en aprobar todo o aprobar nada
+
+**Indicador de aplicación correcta:**
+- En cada sesión de Claude Code, los comandos rutinarios pasan sin pedir aprobación
+- Los comandos no rutinarios siguen pidiendo aprobación (es bueno — ahí prestás atención)
+- Si un comando peligroso aparece, está bloqueado por `deny` o pide aprobación explícita
+
+**Indicador de violación:**
+- El dev usa `--dangerously-skip-permissions` rutinariamente
+- El archivo `settings.json` contiene `allow` que deberían ser personales (paga la complejidad de mantenerlo sincronizado entre devs)
+- No hay archivo de configuración y cada dev aprueba todo manualmente cada vez (fricción crónica, señal de que falta este patrón)
+
+**Template:** ver `methodology/TEMPLATES/CLAUDE_PERMISSIONS_TEMPLATE.md`.
+
+**Relación con otros patrones:**
+- Complementa **B.4** (reglas no negociables en CLAUDE.md) — pero B.4 es sobre comportamiento del agente, D.4 es sobre permisos del sistema operativo
+- Refuerza **Principio 5** (humano director) — sin permisos configurados, el dev se vuelve operador de aprobación
+
+**Casos reales que valida:**
+- InQ ROI: el director identificó fatiga de aprobación después de ~30 etapas. Configurar permisos eliminó la fricción sin perder gobernanza.
+
 ## Categoría E — Comunicación humano ↔ agente
 
 ### E.1 Separar lo validado de lo asumido