<!--
Fragmento compartido — Propose-step de adyacencias (Fase 13, ADR-0037)
Importable desde frontmatter de agente: `fragmentos: [_propose-step]`
Usar en orquestador-swl e implementador-swl. NO routable, NO invocable con Skill.
Ver reglas/seguridad-agentes.md y .planning/adrs/0037-propose-step-presupuesto-autonomia.md
-->

## Propose-step — proponer adyacencias, nunca actuar

Separa PROPONER de ACTUAR. Al **cerrar una tarea o fase** (no en cada turno),
evalúas las adyacencias de riesgo del cambio y las emites como **anexo
propositivo**. El anexo NUNCA bloquea ni ejecuta nada: es texto que el usuario
lee y decide si actúa.

### Cuándo correr

- Solo al cerrar una tarea o una fase, sobre el diff de ese cierre.
- Nunca en mitad de la implementación (evita ruido por turno).
- Si `SWL_PROPOSE=0`, el propose-step queda desactivado: silencio total.

### Cómo evaluar (mecanizado)

Ejecuta la lib sobre el diff de la tarea/fase:

```bash
node hooks/lib/propose-step.js --rango=HEAD~1..HEAD
```

Imprime el anexo solo si detecta ≥1 señal; silencio si no hay nada. Si la lib
no está disponible en el destino, evalúa a mano las 2 señales v1:

- **auth/PII/pagos**: el diff toca autenticación, datos personales o pagos
  (paths `auth/`, `login`, `session`; patrones `password`, `token`, `secret`,
  `jwt`, `stripe`, `pago`, `curp`, `rfc`). → Sugerir revisión de seguridad y
  tests de autorización.
- **migración de schema**: el diff toca `models/`, `migrations/`, `*.sql`, o
  contiene `ALTER/CREATE/DROP TABLE`. → Sugerir plan de rollback /
  expand-contract y verificar reversibilidad.

### Formato del anexo

Solo cuando hay señal. Una sección al final del entregable:

```
## Anexo propositivo — adyacencias de riesgo

Sugerencias, no acciones: nada se ejecuta ni se bloquea automáticamente.

- [auth-pii-pagos] <título> (<evidencia>) → <acción sugerida>
```

Las categorías que la telemetría de aceptación silenció (el usuario las ignora
de forma sostenida) no copan el anexo. La lib lo maneja con
`categoriasSilenciadasPropose`.

## Presupuesto de autonomía — proponer libre, actuar con presupuesto

Antes de **actuar** de forma autónoma, consulta el dial de autonomía en
`instintos/autonomia.yaml` (defaults = `reglas/seguridad-agentes.md`; este
fragmento NO relaja ningún control). Niveles por clase de riesgo:

| Clase | Nivel default | Qué significa |
|-------|---------------|---------------|
| lectura/análisis | `total` | Autónomo sin checkpoint. |
| cambio reversible | `con_auto_checkpoint` | Autónomo, pero registra un auto-checkpoint ANTES de actuar. |
| migración / auth / push / publish | `hitl` | Confirmación humana siempre. |

El dial sube **solo por decisión explícita del usuario**, nunca por tu
conveniencia. Un valor desconocido en el dial degrada a `hitl`.

### Auto-checkpoint (precondición de cambio reversible)

Antes de la primera acción autónoma de clase **cambio reversible** de una tarea,
registra el checkpoint mecánico:

```bash
node hooks/lib/autonomia.js --accion "<descripción corta de la acción>"
```

Registra HEAD + archivos modificados en
`.planning/user-profile/auto-checkpoints.jsonl` como evidencia de rollback (los
commits atómicos son el mecanismo real de reversibilidad). Es best-effort: no
bloquea la acción que protege.

### Reglas duras

- Proponer es siempre permitido; actuar se gobierna por el dial.
- Para clases `hitl` (migración, auth, push, publish): pausa y pide confirmación.
- Nunca degradar silenciosamente: si una adyacencia es de alto impacto, repórtala
  en el anexo aunque el dial permita actuar.
