vibe64-dev/seed-nextjs

Trabajo en proyectos Genesis

Genesis es un compañero de explicación y verificación. No reemplaza el código base, las pruebas, la revisión Git ni el agente de codificación.

Establecer la dirección de un nuevo producto

Para un nuevo proyecto cuyo Blueprint aún no establece la dirección del producto, no investigues tecnología ni crees código fuente hasta que el usuario haya dejado claro qué se está construyendo, quién o qué lo usará o invocará, y el primer resultado útil observable. Pregunta solo las preguntas de alto impacto no resueltas. Una respuesta confirma solo lo que responde explícitamente; la confirmación del Stack no es la intención del producto.

Una vez clara la dirección del producto, elige el camino de implementación más pequeño posible a través de la guía tecnológica seleccionada, o la documentación tecnológica autorizada cuando el catálogo no tenga coincidencia, y lee solo lo que ese camino requiera. No investigues alternativas, clonas repositorios tecnológicos completos, inspecciones internas de paquetes no relacionados, ni delegues investigación a menos que un fallo concreto requiera una investigación exacta.

Ejecutar comandos de Genesis

Resuelve la invocación antes de ejecutar la primera operación de Genesis. No uses una operación de Genesis ni genesis --version como una sonda de disponibilidad.

1. Lee el package.json de la raíz del repositorio. Trata a Genesis como vinculado al proyecto solo cuando el name de ese manifiesto sea genesis-compiler, o sus dependencies, devDependencies u optionalDependencies contengan la clave exacta genesis-compiler.
2. Para un repositorio vinculado al proyecto, invoca cada operación CLI de Genesis con npm exec --no -- genesis <argumentos>. Esto se ejecuta sin obtener otro paquete. Si el paquete declarado no está instalado, informa que las dependencias del proyecto no están preparadas; no recurras a otra versión de Genesis.
3. De lo contrario, no intentes npm exec. Ejecuta command -v genesis (o el equivalente de búsqueda en PATH del shell actual). Cuando resuelva un ejecutable, invoca genesis <argumentos> directamente.
4. Cuando ninguna fuente esté disponible, detente e informa que Genesis no está disponible. Nunca instales ni actualices Genesis solo para satisfacer una instrucción de flujo de trabajo.

La resolución exitosa de la invocación es rutinaria. No narres si Genesis está vinculado al proyecto o en el PATH, y nunca describas el uso directo del PATH como un recurso alternativo. Menciona cómo se seleccionó la invocación solo cuando la resolución falla o el usuario lo pregunta explícitamente.

Sigue el enfoque de Colaboración configurado para las actualizaciones dirigidas al usuario, incluyendo su profundidad técnica y longitud de respuesta. Informa el progreso concreto, los hallazgos o los bloqueos; no anuncies que estás siguiendo una guía.

Resolver elecciones tecnológicas explícitas

Antes de la investigación tecnológica externa o la implementación, cuando el usuario mencione explícitamente una tecnología, framework, lenguaje o base de datos que no esté seleccionado:

1. Ejecuta la operación stack list de Genesis como la primera acción tecnológica.
2. Si un componente del catálogo coincide exactamente con la elección, pregunta: "<Tecnología> está disponible en Genesis. ¿Te gustaría que la agregue a este proyecto y prepare la aplicación con su guía oficial?" No ejecutes stack add <pieza...> sin esa confirmación.
3. Si se confirma, agrega el componente, deja que Genesis aplique su cierre de dependencias declarado y sincroniza cualquier Agent Skill autoritativo declarado por ese componente. Sigue el aviso de preparación devuelto por stack add en la misma tarea: haz que cada contrato de proyecto materializado sea verdadero o reemplaza una sección completa con la realidad basada en evidencia. Luego ejecuta context ., o la ruta fuente relevante una vez que exista el código fuente, carga el skill instalado aplicable si está presente, y sigue esa guía tecnológica para preparar las dependencias reales del proyecto. Nunca infieras un comando de instalación a partir de un id de componente.
4. Si se rechaza, continúa sin agregar el componente ni preguntar de nuevo. Si ningún componente del catálogo coincide, no inventes uno; continúa normalmente usando la documentación autorizada de esa tecnología.

Establecer contexto

1. Lee genesis/blueprint.md para la intención no técnica del producto.
2. Lee genesis/engineering.md para el perfil de ingeniería seleccionado y cualquier requisito específico del proyecto.
3. Lee genesis/stack.md para la composición técnica seleccionada, los recursos y los comandos de verificación.
4. Localiza la fuente involucrada en la solicitud.
5. Ejecuta la operación index <nombre-o-ruta> de Genesis antes de agregar una función auxiliar u operación pública. Reutiliza una función existente cuando ya posee el comportamiento.
6. Ejecuta la operación context <ruta...> de Genesis para las explicaciones relevantes del Program y el contexto seleccionado del Stack.
7. Carga los skills tecnológicos aplicables desde .agents/skills/ o desde el catálogo de skills instalado del propio agente.

Para la primera selección de Stack de una aplicación existente, inspecciona sus comandos reales de configuración, compilación y salida antes de aceptar propuestas de componentes materializados. Un componente seleccionado describe su fundamento actual; no migra en silencio código fuente antiguo. Cuando los comandos existentes difieran, mantén la implementación sin cambios y reemplaza la operación consumidora completa de propiedad del proyecto (por ejemplo, ## Configuración del espacio de trabajo o ## Salidas de un host). Genesis trata esas secciones como texto opaco; el consumidor nombrado por sí solo posee su significado y ejecución. No afirmes que una receta propuesta es utilizable hasta que coincida con la fuente.

El Program es una explicación concisa y falible. Sus Fuentes y mapas opcionales de Implementación ayudan a la navegación, pero nunca sustituyen la lectura del código, las pruebas y el comportamiento en tiempo de ejecución.

.genesis/machine-city.json es un mapa detallado derivado de archivos/funciones. .genesis/program-city.json es un mapa derivado más simple de subsistemas/operaciones. Ninguno es autoridad o prueba; ambos están en .gitignore y pueden ser regenerados con la operación index de Genesis.

Implementar trabajo local ordinario

• Aplica el enfoque de ingeniería efectivo proporcionado por Genesis. Cada cambio debe ser fácil de razonar y ser la implementación objetivo más pequeña que cumpla completamente con los requisitos conocidos. No sobreingenieríes ni compliques, y no agregues abstracciones, capas, dependencias, infraestructura, rutas de compatibilidad, patrones distribuidos, criptografía u otra maquinaria avanzada especulativa.
• Cuando un requisito concreto haga necesaria una complejidad material, detente antes de escribirla. Explica por qué el diseño directo es insuficiente y la complejidad añadida más pequeña propuesta, luego pide al usuario que apruebe o aclare la compensación. Nunca anules en silencio el enfoque de ingeniería.
• Trabaja directamente en el árbol Git actual y deja las ediciones útiles visibles en el diff ordinario.
• Mantén el Blueprint y los módulos del Program afectados alineados en este mismo turno cuando la implementación cambie intencionalmente el comportamiento observable del producto. La reestructuración privada puede requerir solo Fuentes corregidas o un mapa informativo de Implementación, y puede no requerir ninguna edición explicativa. Mantén las declaraciones exactas de propiedad del consumidor, como ## Salidas de un host, alineadas cuando la implementación cambie intencionalmente los comandos o capacidades correspondientes. Registra solo metadatos de capacidad y nombres de variables de entorno allí, nunca valores o secretos; no infieras ni ejecutes la sección como comportamiento de Genesis. Trata .genesis/ como datos de navegación derivados reemplazables, no como intención de producto redactada.
• Sigue las costuras de proyecto y tecnología establecidas en lugar de crear marcos paralelos, capas de persistencia, transportes, validadores o sistemas UI.
• Nunca inventes valores de recursos externos no disponibles ni pases nombres literales de variables de entorno como datos. Informa el recurso faltante y preserva el trabajo útil.
• Mantén la implementación directa y cohesiva. Aplica cualquier guía posterior al cambio del Stack proporcionada antes de informar la finalización; es parte de este turno de implementación, no una solicitud de otro turno del agente. Ejecuta verificaciones enfocadas cuando sea útil.

Verificar e informar

Durante la implementación, selecciona las verificaciones relevantes para el cambio. Ejecuta las verificaciones finales declaradas por el Stack a través de Genesis verify cuando sea requerido por la política de verificación del proyecto o la solicitud del usuario, después de que exista el sustrato del espacio de trabajo de la tecnología seleccionada. Finalizar un elemento o reanudar una sesión no requiere por sí mismo una ejecución de verificación amplia. Mantén la salida completa en artefactos locales, preserva el estado de salida y lee los resúmenes y los fragmentos de fallos relevantes antes de expandir los registros. No debilites las afirmaciones ni omitas la cobertura requerida para ahorrar tiempo o tokens. Un resultado no configurado significa que el espacio de trabajo o las verificaciones declaradas aún no existen; no es una verificación fallida. Antes de informar la finalización, compara el comportamiento observable solicitado, las entradas y recursos requeridos, las operaciones del proyecto declaradas y la evidencia enfocada con lo que realmente existe. Informa los archivos cambiados, las verificaciones realmente realizadas, cualquier cosa no probada y cualquier cosa que aún requiera atención. Nunca afirmes que una verificación no ejecutada pasó o que las verificaciones aprobadas prueban todo el producto.

Mantenimiento de subsistemas

Mantén genesis/subsystems.md en el mismo turno de implementación cuando un cambio agregue, elimine o cambie una responsabilidad de subsistema, pertenencia al Program o propiedad/uso de datos. Lee el mapa antes de cambiar el código relacionado. Reutiliza los subsistemas existentes a menos que se evidencie una responsabilidad distinta. Requiere un Directorio Fuente por subsistema y declara cada módulo del Program exactamente una vez; los nombres de las carpetas del Program no determinan la pertenencia. Mantén las referencias de tablas basadas en esquemas/migraciones; Genesis no inspecciona bases de datos. Los cambios auxiliares privados no necesitan edición del mapa cuando estas asociaciones permanecen sin cambios.

Si falta genesis/subsystems.md, o está vacío en una aplicación explicada existente, créalo a partir de la fuente real, el esquema y el Program existente antes de la implementación. Esto es una adopción explicativa ordinaria, no un bloqueo o una razón para pedir permiso de nuevo. Preserva el Program y la 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 escribe su significado.