Prompt de ejecución para Sonnet — Plan v3
Date: 2026-09-13 Uso: copiar el bloque de abajo como primer mensaje de una sesión nueva de Claude Code (Sonnet) en este repo. Está escrito para ejecutarse entrega por entrega, no todo de una vez.
Antes de arrancar, Carlos tiene que responder tres cosas (están marcadas 🟡 en el plan). Si todavía no están respondidas, se puede ejecutar F1 y F3 igual; F2 y F4 dependen de ellas.
Sos el desarrollador de este proyecto (Soterex / CIS Latam). Leé primero `CLAUDE.md` y respetá
todo lo que dice: stack cerrado (Vue 3 + Laravel 13 + Aurora, no proponer alternativas), toda
decisión de arquitectura nueva va a un ADR en `doc/architecture/`, y el estilo de comentarios y
documentación del repo (español rioplatense, explicando el PORQUÉ y no el qué).
## Qué vas a hacer
Ejecutar el **Plan v3 — Estabilización**, que está escrito en
`doc/plans/2026-09-13-plan-v3-estabilizacion.md`. Ese plan es tu fuente de verdad: tiene seis
entregas (F1 a F6), cada una con su alcance, sus archivos y su criterio de "terminado cuando".
El diagnóstico completo que le dio origen está en
`doc/informes/2026-09-13-auditoria-pre-estable.md` — leelo entero antes de tocar código. Tiene
todas las referencias file:line que vas a necesitar y, más importante, dice **qué se verificó
ejecutando algo y qué se dedujo leyendo**. No des por cierto lo segundo sin comprobarlo.
La decisión de producto sobre prefondeo está en
`doc/architecture/ADR-010-avisos-entre-capas-de-prefondeo.md`.
## Orden
1. **F1 — Datos de demostración que no envejecen.** Va primero y sola: sin ella no se puede
verificar nada de lo demás a ojo.
2. **F2 (prefondeo) y F3 (dashboard)** pueden ir en paralelo, cada una en su branch, después de F1.
3. **F4, F5 y F6** son independientes entre sí y del resto.
Una entrega por branch. No arranques la siguiente hasta terminar la anterior, salvo que sean
explícitamente paralelas.
## Cómo trabajar cada entrega
1. Releé la sección de esa entrega en el plan y armá tu lista de tareas.
2. Branch nuevo desde `main`, con nombre `feature/f1-datos-demo` (o el que corresponda).
3. Implementá. Tests **en el mismo commit** que el código que prueban, no después.
4. Corré todo lo que aplique y **pegá la salida real** en tu resumen:
- Backend: `docker exec soterex-backend-1 php artisan test` y `vendor/bin/pint --test`
- Frontend: `npm run test` y `npm run build` (el build corre `vue-tsc`, así que también valida tipos)
5. Pasá el skill `code-reviewer` sobre el diff completo de la entrega y corregí lo que marque.
Si no estás de acuerdo con un hallazgo, decí por qué en vez de aplicarlo a ciegas.
6. Commit, push del branch, y PR con `gh pr create` describiendo qué cambió y cómo se verifica.
7. Avisá en el chat con el resumen y el link del PR.
**El merge a `main` lo autoriza Carlos, siempre.** No mergees, no pushees a `staging` ni a
`production`, y no hagas nada destructivo (force-push, reset --hard, `migrate:fresh` contra algo
que no sea tu entorno local).
## Reglas que no son negociables
- **El entorno local ya está corriendo** en Docker (`docker ps` para ver los contenedores). Usá
`docker exec soterex-backend-1 ...` para artisan. No levantes servicios nuevos.
- **Ningún saldo se materializa.** Las tres capas de prefondeo se derivan sumando su ledger
(ADR-005, ADR-007). Si te tienta guardar un saldo en una columna, no lo hagas.
- **Nunca escribas `role_permissions` fuera de `RolePermission::withoutEvents()`**: la cascada
`can_write ⇒ can_read` reactiva `can_read` y rompe la pantalla Pago del Backoffice. Ya pasó una
vez (ver `RoleSeeder.php:130-134`).
- **`created_at` / `updated_at` / `last_updated_at` de `transactions` no son fillable**: asignalos y
usá `saveQuietly()`.
- **El pago valida solo la caja operativa** con módulo Caja activo (ADR-007 §2). Este plan **no**
convierte ningún aviso en bloqueo: F2 agrega avisos, no validaciones que corten.
- **Los avisos entre capas devuelven HTTP 201 con el movimiento ya creado**, no 422 (ADR-010 §1).
- **Nada de PII ni de plata en logs.** La comisión (`fee`) no se muestra en pantallas operativas
(se borra en `TransactionResource.php:24`) — no la expongas de rebote en un endpoint nuevo.
- Si una decisión no está en el plan ni se deduce por analogía directa con algo ya implementado,
**preguntá antes de decidirla vos**.
## Lo que no tenés que hacer
- No toques la integración con Soterex (sigue en mock, M5 está bloqueado por otra cosa).
- No abras la migración a Azure (descartada, ver `CLAUDE.md`).
- No rediseñes el módulo de tipo de cambio.
- No hagas la auditoría de seguridad completa (es E6 del plan v2, otra entrega): F5 cubre solo los
tres hallazgos concretos que el informe documenta.
## Cómo verificar que cada entrega sirvió (no alcanza con que los tests pasen)
- **F1:** corré `php artisan demo:reseed` **dos veces seguidas** y verificá que el estado final sea
el mismo. Después abrí el Dashboard y comprobá que los siete bloques tengan números. Pagá una
transacción de punta a punta.
- **F2:** cargá un asiento de prefondeo país por encima de lo que tiene la Holding y verificá que
el aviso aparezca **en pantalla** (no solo en el JSON), y que el asiento quede registrado igual.
Hacé lo mismo con un fondeo y con un ajuste positivo de caja.
- **F3:** abrí Dashboard y Reportes con el mismo período y verificá que los totales coincidan.
- **F4:** creá un usuario, entrá con él, comprobá que lo obligue a cambiar la contraseña, y que
pueda recuperarla sin un Admin.
- **F5:** desactivá un usuario mientras tiene la sesión abierta y verificá que quede afuera **en el
acto**, con un mensaje claro y no con la pantalla colgada.
- **F6:** entrá con un Admin acotado a un país y verificá que no vea usuarios de otro.
Contá lo que verificaste y lo que no. Si algo quedó sin probar, decilo — es más útil que un "listo"
que no se sostiene.Nota sobre por qué el prompt está escrito así
Tres cosas que el prompt hace a propósito, por si alguien lo edita después:
- No repite el plan. Apunta a los documentos en vez de copiarlos, para que no haya dos versiones de la verdad cuando el plan se ajuste.
- Distingue lo verificado de lo deducido. Buena parte del informe sale de lectura de código; si Sonnet trata todo como hecho comprobado, va a "arreglar" cosas que no están rotas.
- Pone el criterio de verificación manual arriba de los tests. Los 17 tests del dashboard pasaban mientras la pantalla mostraba todo en cero: en este proyecto ya quedó demostrado que verde no significa que funcione.