Prompt para arrancar un proyecto nuevo sobre platform-core

Este es el prompt que se le da a un agente (Claude Code u otro) cuando ya existe un spec de negocio en el working directory y hay que arrancar el proyecto desde cero consumiendo dev.echotechs.core:*. Está armado a partir de dos ejecuciones reales de este proceso (sistema-documental, sistema-hotel) — las cuatro preguntas de decisión y el pedido de library-followups.md no son genéricos, son los puntos donde esos dos proyectos realmente se ramificaron o encontraron gaps.

Voy a construir un proyecto nuevo consumiendo platform-core (dev.echotechs.core:*). El spec de negocio
ya existe en este working directory: <NOMBRE-DEL-ARCHIVO-SPEC>.md — leelo primero, completo.

Antes de escribir código, leé la documentación de platform-core para entender qué ya viene resuelto y
qué patrones seguir:
- El repo del core está en: /Users/vicrenlopez/Developer/Echotechs/echotechs-core
- Empezá por docs-site/docs/intro.md (qué módulos existen, stack fijado, convención de configuración)
- docs-site/docs/quickstart.md — el flujo completo verificado end-to-end contra infra real
- docs-site/docs/backend/*.md — un doc por módulo core-* que vayas a usar (core-auth, core-authz,
  core-web, core-persistence, core-storage, core-workflow, core-notifications, core-reporting,
  core-config); cada uno tiene su propia sección de troubleshooting con síntomas reales encontrados
  por proyectos anteriores
- docs-site/docs/frontend/index.md — si el spec incluye frontend, qué traen los cuatro paquetes
  @echotechs/* y create-echotechs-app
- docs-site/docs/infra-coolify.md — guía paso a paso para levantar la infra (Postgres, OpenFGA, MinIO,
  Mailpit, backend, frontend) en Coolify vía API, con cada trampa ya documentada (dominios, redes,
  variables de entorno, Dockerfiles)

Seguí la misma disciplina que los proyectos anteriores sobre este core (sistema-documental,
sistema-hotel): todo el código en inglés desde el día uno (paquetes, clases, campos, tablas, endpoints)
aunque el spec y este chat sean en español; cada decisión técnica que tomes y que no sea obvia desde el
spec queda anotada con su motivo (comentario o en un CLAUDE.md de la sesión); las partes del spec que no
vas a implementar en esta versión quedan marcadas como tales, no simplemente omitidas.

Antes de escribir código de infraestructura o dominio, decidí y decime (o preguntame si hace falta mi
input):
1. Si core-auth se reutiliza tal cual o necesita extenderse — depende de si un usuario de este dominio
   pertenece a una sola organización o a varias a la vez (ver intro.md/core-auth.md para el criterio).
2. El modelo de autorización. **Cedar es el motor default** (en proceso): los roles de negocio viven en
   `rolesCsv` y se proyectan como `principal.roles`, y los permisos son políticas Cedar (las del classpath +
   las que crees por la API de admin). OpenFGA queda disponible con `echotechs.authz.engine=openfga` si el
   dominio prefiere un store de relaciones externo. Definí los roles/permisos y si hace falta algo más fino
   que el catálogo base — ver [`core-authz`](backend/core-authz.md).
3. Postgres vs. Oracle si aplica alguna restricción del cliente.
4. Si hay pasarela de pago, integraciones externas, o alcance fuera de lo que platform-core resuelve de
   fábrica.

Si algo del spec choca con un patrón que la documentación del core marca como resuelto de una forma
específica, señalalo explícitamente en vez de improvisar una solución paralela — probablemente ya hay
un módulo o una convención que lo cubre.

Si en el camino encontrás un gap real en platform-core (una API que falta, un bug, algo que el spec
necesita y el core no ofrece limpiamente), documentalo en un library-followups.md en la raíz de este
proyecto — el gap, por qué surge acá, y la API que propondrías — en vez de trabajarlo por fuera en
silencio. Cuando el core publique el fix, volvé a ese archivo y actualizalo.

Al desplegar: seguí infra-coolify.md al pie de la letra, especialmente las "cinco reglas de oro" y la
sección de errores comunes — casi todo lo que puede fallar en silencio (CORS por perfil, cookies
host-only entre subdominios, redes de Docker, dominios de servicios) ya está documentado ahí con síntoma
y arreglo.

Por qué está armado así

• Apunta a intro.md primero, no a los docs de módulos individuales — evita que el agente lea de más documentación de módulos que quizás ni vaya a usar.
• Las cuatro preguntas de decisión son la bifurcación temprana que en la práctica más importó: core-auth tal cual vs. extendido fue la diferencia estructural real entre sistema-documental (usuario multi-organización, necesitó User/UserOrganization propios) y sistema-hotel (usuario de una sola organización, core-auth de fábrica sin tocar).
• El pedido explícito de library-followups.md existe porque así se originó, por ejemplo, AuthCookieProperties.domain (spec de cookies cross-subdominio) — el mecanismo real por el que el core mejora es un downstream real encontrando el gap y proponiendo la API, no anticipación de mantenedor.
• No incluye credenciales ni UUIDs de infraestructura de ningún proyecto existente — es para un proyecto nuevo, con su propia infra desde cero (ver infra-coolify para ese paso).