Paquetes frontend @echotechs/*

:::danger Ninguno de estos paquetes existe todavía Los cuatro paquetes @echotechs/* de la sección 3 del spec, y el scaffolder create-echotechs-app de la 3.5, no están implementados. No hay código frontend en este repositorio. :::

Qué se verificó

Búsqueda hecha sobre el repositorio completo, incluido todo el historial de git en todas las ramas:

Búsqueda	Resultado
Archivos package.json	Ninguno
Archivos .ts / .tsx	Ninguno
git log --all --diff-filter=A sobre esos patrones	Nunca se commiteó ninguno
Referencias a create-echotechs-app	Sólo en platform-core-spec.md
Referencias a @echotechs/	Sólo en platform-core-spec.md y en dos comentarios Javadoc del backend

Las dos menciones en el backend son comentarios que describen el flujo que el widget debería consumir, no código que lo integre:

• core-storage/src/main/java/dev/echotechs/core/storage/FileStorageService.java — "El flujo de subida que maneja @echotechs/upload-widget (sección 3.4)"
• core-storage/src/main/java/dev/echotechs/core/storage/web/FileStorageController.java — la misma referencia sobre los endpoints

Como la regla de esta documentación es no documentar nada que no se pueda verificar leyendo el código real, no hay páginas de API para estos paquetes: cualquier firma que apareciera acá sería inventada.

Lo que el spec diseña

Para referencia, esto es lo que la sección 3 de platform-core-spec.md propone. Es diseño, no documentación de algo que exista.

@echotechs/api-client (spec 3.1)

Cliente generado automáticamente desde el OpenAPI que expone platform-core, con openapi-generator u orval, regenerado en cada cambio de contrato, incluyendo interceptores de refresh automático.

:::warning Bloqueado por una dependencia que tampoco existe Este paquete se genera desde el spec OpenAPI del backend. Ese spec no se produce hoy: springdoc-openapi (spec 1.8) no está implementado en core-web — no hay dependencia, ni configuración, ni endpoints /v3/api-docs o /docs. Hasta que exista, no hay fuente desde la cual generar el cliente, y tampoco es posible el contract testing de la sección 4.4. :::

@echotechs/auth-web (spec 3.2)

Hooks useAuth(), useTenant() y usePermission(relation, objectType, objectId), más guards de rutas. El tercero consultaría a core-authz para decidir si renderizar un botón o una sección, reflejando en el frontend el mismo modelo de OpenFGA del backend.

Nota sobre viabilidad: los endpoints de core-auth que estos hooks consumirían sí existen y funcionan (/api/auth/login, /refresh, /logout, /logout-all) — ver core-auth. En cambio usePermission necesitaría un endpoint de check que core-authz no expone: hoy FgaService es sólo una API Java interna, sin ningún controller que la publique por HTTP.

@echotechs/ui-kit (spec 3.3)

Componentes base — tablas, modales, botonería, sidebar, KPIs, badges — con theming configurable por proyecto. Es la dependencia que menciona la sección 1.9 del spec para la pantalla de edición de core-config, que por lo tanto tampoco existe.

@echotechs/upload-widget (spec 3.4)

Componente de subida que habla directo con core-storage: pide URL prefirmada, sube, confirma.

Este es el paquete con la base backend más completa: el flujo de tres pasos está implementado y verificado contra MinIO real. Los endpoints que consumiría, ya disponibles:

Método	Ruta	Body / respuesta
POST	/api/storage/files	{resourceType, resourceId, fileName, contentType} → {fileId, uploadUrl, expiresAt}
POST	/api/storage/files/{fileId}/confirm	→ FileDescriptor
GET	/api/storage/files/{fileId}/download-url	→ {downloadUrl, expiresAt}
DELETE	/api/storage/files/{fileId}	→ 204

Detalles del contrato real que un widget tendría que respetar, extraídos de FileStorageIntegrationTest: el PUT a uploadUrl tiene que mandar el mismo Content-Type que se declaró al iniciar la subida, y la confirmación falla con 409 UPLOAD_NOT_FOUND si se llama antes de que el PUT haya terminado.

create-echotechs-app (spec 3.5)

CLI o repo-template que scaffolds un proyecto nuevo con los cuatro paquetes integrados, routing base y estructura de carpetas estándar. Ver Quickstart para el camino manual equivalente que sí funciona hoy.

Testing frontend (spec 4.5)

Tampoco existe: no hay configuración de Vitest, React Testing Library ni Playwright en el repositorio. La única parte de la sección 4 del spec que está implementada en CI es la del backend (.github/workflows/test.yml y .github/workflows/fga-model-test.yml).

Orden sugerido para desbloquear esto

Derivado de las dependencias reales entre las piezas, no del spec:

1. springdoc-openapi en core-web — desbloquea @echotechs/api-client y el contract testing.
2. Un endpoint de check en core-authz — desbloquea usePermission en @echotechs/auth-web.
3. @echotechs/upload-widget — es el que menos backend nuevo necesita; el flujo ya está completo.
4. @echotechs/ui-kit — desbloquea la pantalla de administración de core-config.