Plano y Programa de Genesis
El Plano y el Programa son explicaciones mantenidas, no pruebas, propiedad ni un modelo semántico exhaustivo.
Plano
genesis/blueprint.md es una descripción breve, cohesiva y no técnica de lo que el producto debe hacer. Prefiere la intención explícita del usuario. No menciones frameworks, paquetes, rutas, esquemas, archivos fuente, planes de implementación, pruebas ni arquitectura privada.
Actualiza el Plano después de la implementación solo cuando el cambio añade, elimina o altera intencionadamente el comportamiento observable del producto. Nunca conviertas un accidente, error, decisión de diseño privada o ambigüedad en intención del producto.
Programa
Organiza el Programa en directorios legibles; la pertenencia se declara solo en genesis/subsystems.md, independientemente de los nombres de directorio:
genesis/program/billing/invoices.md
genesis/program/authentication/sessions.md
Crea un módulo por cada operación pública significativa proporcionada por un subsistema, independientemente del lenguaje o la estructura de archivos fuente. Las operaciones públicas incluyen funciones o métodos exportados, acciones de API, comandos, operaciones de UI y otros puntos de entrada observables. No reflejes archivos fuente ni documentes cada helper.
Cada módulo contiene:
# Nombre de límite legible
Una breve explicación de por qué existe el límite.
## Fuentes
- Principal: `ruta/exacta/creada/principal/archivo`
- `ruta/exacta/creada/secundaria/archivo`
## Contrato público
Entradas, salidas, efectos, fallos y garantías significativos.
Todo módulo requiere exactamente un bullet - Principal: de fuente. Elige la fuente principal explícitamente como el lugar para empezar a leer la implementación; no necesita ser un punto de entrada ejecutable. Debe pertenecer al subsistema propietario del módulo, respetando propietarios de directorio anidados más específicos. Otras Fuentes pueden citar librerías compartidas en otros subsistemas. Nunca infieras el archivo principal a partir del orden de la lista de fuentes, importaciones o nombres de archivo. Al conciliar módulos antiguos, inspecciona el fuente y marca el ancla explícitamente; la indexación no asigna una por ti.
Una sección opcional ## Mapa de implementación puede nombrar solo helpers privados o costuras que ayuden materialmente a un agente futuro a cambiar, rastrear o depurar la operación. Es informativa, no una garantía pública. Las pruebas son evidencia y nunca Fuentes de implementación.
Prefiere menos módulos y más claros. Elimina explicaciones obsoletas y duplicadas. Un fuente puede soportar varias operaciones; los archivos helper y de pegamento pueden no aparecer en ningún módulo del Programa.
Límites de tarea
El llamante determina si esto es descripción inicial, renovación completa del Programa, reconciliación posterior al cambio enfocada, trabajo solo en el Plano o revisión de solo lectura. Respeta el límite de edición del llamante. Reporta la ambigüedad en lugar de inventar intención.
Subsistemas
Mantén genesis/subsystems.md junto con el Programa en trabajos de descripción y renovación. El trabajo solo en el Plano no cambia el mapa; la revisión sigue siendo de solo lectura. El mapa es la autoridad de asociación creada, pero las responsabilidades y referencias a tablas siguen siendo explicaciones falibles del código fuente de la aplicación y el esquema.
Usa esta gramática exacta de versión cero:
# Subsistemas
## `forms` Formularios
Es propietario del renderizado reutilizable de formularios, validación y captura de envíos.
### Fuente
- Directorio `packages/forms`
### Programa
- `genesis/program/forms/render.md`
### Datos propios
- Tabla `database` `default` `form_definitions`
### Datos usados
- Nada.
Usa un id estable en minúsculas con guiones y un título humano por subsistema. Cada entrada necesita prosa de responsabilidad y las secciones Programa, Datos propios y Datos usados. La prosa de responsabilidad es la explicación completa del subsistema, no un título de mapa. Explica su propósito, alcance, partes importantes y colaboración con otros propietarios. Conserva las descripciones existentes sustanciales; no las reemplaces con etiquetas de una línea para adaptarse a una visualización. Un consumidor puede acortar la vista previa mostrada. Los directorios simples de soporte pueden necesitar solo una explicación breve.
La sección Fuente requerida contiene exactamente una entrada - Directorio con una ruta entre acentos graves: un directorio canónico relativo al proyecto, con . permitido para la raíz del proyecto. Cada subsistema tiene una raíz de directorio; nunca declares raíces dispersas o múltiples. Las reglas de directorio padre apilado descubren raíces de subsistema por defecto, pero no son exhaustivas. Un agente puede reconocer y declarar otra raíz en otro lugar a partir de la responsabilidad real y la evidencia del fuente. La declaración creada persiste a través de la indexación ordinaria. El mapa creado es la lista de propietarios canónica una vez que está listo; las raíces apiladas son pistas de adopción y nunca crean propietarios adicionales ni dividen un límite creado. Cubre cada fuente indexada, usando un propietario raíz del proyecto para los archivos de soporte restantes si es necesario. Los componentes de UI y el código del Motor pueden compartir una raíz; la proyección de UI no cambia la propiedad. Las secciones vacías dicen - Nada.; un mapa vacío nuevo contiene solo # Subsistemas y - Nada.. Cada módulo del Programa pertenece exactamente a un subsistema. Los nombres de directorio del Programa no asignan propiedad. Las Fuentes pueden citar librerías de otro subsistema sin dar a la operación o implementación dos propietarios. No uses globs, operaciones duplicadas ni propietarios de tabla duplicados.
Al regenerar o dividir deliberadamente el mapa, reconcilia las explicaciones con los nuevos propietarios de directorio. Transfiere la prosa de responsabilidad aplicable y las asignaciones explícitas del Programa juntas, conservando los ids estables donde el límite no ha cambiado. Revisa la fuente principal requerida de cada Programa con respecto a su propietario actual, incluyendo propietarios anidados; las referencias a librerías conservan su propia propiedad. Usa las declaraciones actuales en lugar de nombres codificados, estructura de directorios o lista en caché de un consumidor anterior. Inspecciona subsistemas y Programa y resuelve la pertenencia faltante/duplicada y los anclajes principales inválidos antes de reclamar finalización.
Una identidad de tabla son tres valores separados entre acentos graves exactos: el id del recurso Stack declarado, el esquema y la tabla. default significa el esquema por defecto del recurso; usa un esquema explícito donde sea aplicable. Nunca registres un nombre de base de datos de host, credencial, expresión SQL o valor de entorno. Datos usados referencia una tabla propiedad de otro subsistema declarado. Un subsistema puede poseer datos sin operaciones de Programa, o operaciones sin datos. Lee el esquema/migraciones reales antes de asignar propiedad; reporta incertidumbre en lugar de inventar asociaciones.
Mantén genesis/subsystems.md en el mismo turno de implementación cuando un cambio añade, elimina o cambia una responsabilidad de subsistema, pertenencia a Programa o propiedad/uso de datos. Lee el mapa antes de cambiar código relacionado. Reutiliza subsistemas existentes a menos que una responsabilidad distinta esté evidenciada. Declara cada módulo del Programa exactamente una vez; las carpetas no determinan la pertenencia. Mantén las referencias a tablas basadas en esquemas/migraciones; Genesis no inspecciona bases de datos. Los cambios de helpers privados no necesitan edición del mapa si estas asociaciones permanecen sin cambios.
Si genesis/subsystems.md falta, o está vacío en una aplicación explicada existente, créalo a partir del fuente real, el esquema y el Programa existente antes de la implementación. Esto es adopción explicativa ordinaria, no un bloqueo ni una razón para pedir permiso de nuevo. Conserva el Programa y el fuente existentes; inspecciona las responsabilidades relevantes y completa el mapa verdadero más pequeño. La inicialización puede crear el archivo vacío, pero solo el agente crea su significado.