← Volver a los proyectos

entifix

Un framework de TypeScript para aplicaciones guiadas por entidades sobre Effect, de los metadatos a los repositorios y los controles de React.

Resumen

entifix es un framework de entidades para TypeScript: una entidad se describe una vez, y esa misma descripción guía el repositorio que la almacena, la ruta que la sirve, la tabla que la lista y el formulario que la edita.

Se extrajo de un marketplace que lo impulsó durante un año, así que su código está probado; lo nuevo es su empaquetado en niveles independientes, cada uno adoptable sin los superiores.

Patrones

  • Entidades descritas una vez

    Los metadatos de una entidad —sus miembros, tipos, vínculos y qué se puede filtrar— guían su repositorio, sus rutas, sus tablas y sus formularios.

  • Construido sobre Effect

    Los casos de uso, repositorios y servicios son programas de Effect, así que los errores, las dependencias y los recursos están tipados en lugar de supuestos.

  • Un contrato de niveles

    Seis niveles, de independiente a pruebas. Un paquete depende solo de su nivel o de los inferiores, y una verificación rompe el build cuando un vínculo viola la regla.

  • Una costura que configura el anfitrión

    El framework no lee archivos: catálogos, permisos y validación de tokens entran como valores, así que la aplicación los decide y el framework sigue siendo genérico.

  • Ejemplos como prueba

    Cada ejemplo toma un corte distinto de los niveles, lo que demuestra que un nivel puede adoptarse sin los superiores.

Estructura de archivos

  • packages/
    • ts/Paquetes independientes del framework: core, business, los adaptadores y los kits de pruebas.
      • core/Entidades, metadatos, vínculos y el caso de uso de carga: nivel 1.
    • react/Controles de React y la integración que los conecta con las entidades.
    • next/El shell de Next.js y su i18n.
    • effect/
      • service-shell/El shell de servicio de Effect que sirve entidades por HTTP.
    • style/Tokens de diseño: nivel 0, no depende de nada.
  • examples/Ejemplos mínimo, de servicio y de workspace, cada uno con su e2e.
  • tools/
    • tiers/El contrato de niveles, verificado contra el árbol.
  • docs/
    • adr/Los registros de decisiones.

Decisiones de arquitectura

Cada decisión importante queda registrada, con el síntoma que debe llevar a un lector —o a un agente— a leerla antes de romper la regla.

Los registros están escritos en inglés.

Cómo guían el trabajo los registros

Personas y agentes leen los mismos registros. Cada uno nombra el síntoma que debería llevar a alguien hasta él, para que una regla se encuentre antes de romperla, no después.

  1. 1DecidirUna decisión costosa de deshacer, o fácil de romper sin querer, recibe un registro numerado.
  2. 2RegistrarSu encabezado tiene un estado, una fecha, un área y una línea Read when: el síntoma que debería traer de vuelta a quien lee.
  3. 3SeñalarEl CLAUDE.md del repositorio envía cada sesión de un agente a docs/adr, cuyo README indexa los registros.
  4. 4ReconocerCuando una tarea se topa con un síntoma — una verificación que falla, un build extraño — el agente encuentra el registro cuyo Read when lo nombra, y sigue su regla.
  5. 5EvolucionarUn dato que cambia se corrige en su lugar, en una línea Revised. Una decisión que ya no vale recibe un registro nuevo que la reemplaza. Nada se borra.

Los registros de abajo se copian de cada repositorio con un script, y la CI de este repositorio falla cuando una copia se aparta de su registro.

Anatomía de un registro: el encabezado del ADR 0004, el más reciente con una línea Read when.
  1. # 4. The examples are the composability proof, and one of them gates every pull requestUn número que nunca cambia, y la decisión en una línea. El README los lista.
  2. - Status: AcceptedEn qué estado está. Un registro reemplazado se queda, y nombra el que lo reemplazó.
  3. - Date: 2026-09-16Cuándo se decidió. Una corrección posterior agrega abajo una línea Revised, con su propia fecha.
  4. - Area: testingLa parte del sistema que gobierna.
  5. - Read when: adding an example, adding an e2e journey, putting an entity class inside a Next application, or wondering why a verb declared with `@useCase()` never appears on screen — entity classes need SWC's 2022-03 decorators, which Next's own compiler cannot provideContra lo que un agente compara: el síntoma que encontraría, no el tema.
  1. 0001The tier contract, and the seam a host configures acrossAceptada

    0001The tier contract, and the seam a host configures across

    Leer cuandoadding a package, adding a dependency between two, deciding whether something is public API, or about to bake a host's value into framework code — a downward edge can still be illegal, and the seam takes values rather than paths

    La decisión

    • i18n is T2, not T0.
    • testing-* is T5, above everything.
    • A downward edge can still be illegal.
    • The subpath is not decoration — it is the part that works.
    • An exemption is named one at a time, with its reason on the line.

    Aceptadaplatform

    Leer el registro →
  2. 0002entifix is MIT, and the trigger that would freeze that choiceAceptada
  3. 0003Releasing without a credential, and the version a commit is allowed to cutAceptada
  4. 0004The examples are the composability proof, and one of them gates every pull requestAceptada