vibe64-dev/seed-nextjs

Genesis Deslop

Revisa y simplifica los cambios seleccionados sin alterar el comportamiento del producto. Deslop es explícito: nunca se ejecuta solo porque la implementación haya finalizado.

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

1. Lee el package.json 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 o optionalDependencies contengan la clave exacta genesis-compiler.
2. Para un repositorio vinculado al proyecto, invoca cada operación de la CLI de Genesis con npm exec --no -- genesis <argumentos>. Esto se ejecuta sin descargar 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 del flujo de trabajo.

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

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

Cargar las instrucciones efectivas del proyecto una vez

Una solicitud de Deslop puede llegar como un mensaje completo generado por Genesis o como una solicitud directa, como Deslop en una sesión de agente.

Si la tarea actual ya contiene GENESIS CONTEXT cuya tarea es deslop, continúa directamente con ella. No generes otro mensaje.

De lo contrario, antes de resolver el ámbito de Git, ejecuta la operación de Genesis prompt --task deslop una vez usando la regla de invocación anterior. Para una solicitud simple de Deslop, no pases ningún argumento de solicitud. Cuando el usuario nombre un recuento, una confirmación o un rango, pasa esa misma solicitud como un argumento correctamente entrecomillado. Trata el mensaje impreso como las instrucciones para este mismo turno; no lo envíes a otro agente ni lo generes de nuevo. Este paso compone las indicaciones de Deslop específicas de la tecnología de la Pila seleccionada y cualquier personalización del proyecto con el contrato portátil a continuación.

Resolver el ámbito de limpieza

Inspecciona git status --short y las diferencias staged y unstaged antes de editar. Se permite un árbol de trabajo sucio; no se requiere una confirmación previa. Preserva el índice existente y el trabajo no relacionado. No hagas stage, stash, commit ni descartes cambios como requisito previo o como parte de la limpieza.

Resuelve el ámbito del usuario de la siguiente manera:

• Sin ámbito declarado, selecciona solo tus propios cambios para la tarea actual, incluyendo turnos anteriores. Esto puede incluir ediciones staged y unstaged, nuevos archivos no rastreados y cambios de tarea ya confirmados. Identifica la propiedad a partir del historial de la tarea y las ediciones, luego confirma esos cambios contra el código fuente actual y las diferencias de Git. Ni la diferencia sucia completa, ni la última confirmación, ni una identidad de autor de Git demuestran la propiedad.
• Preserva los cambios realizados por el usuario u otros agentes, incluyendo ediciones en los mismos archivos. Si no se puede establecer la propiedad, pregunta qué cambios deslopear. Si no hay cambios propios para esta tarea, informa que no hay nada que deslopear; no selecciones silenciosamente la última confirmación ni el trabajo de otra persona.
• Una confirmación explícita, un recuento de primer padre o un rango tienen prioridad sobre el valor predeterminado, independientemente de quién haya realizado esos cambios.
• "La última confirmación" significa HEAD contra su primer padre.
• "Las últimas N confirmaciones" significa el cambio neto superviviente desde el primer padre antes de esas N confirmaciones hasta HEAD.
• Una confirmación nombrada significa esa confirmación contra su primer padre.
• Un rango de confirmaciones explícito significa exactamente ese rango.
• Una confirmación raíz usa la forma de diferencia raíz de Git porque no tiene padre.

Inspecciona los cambios y rutas resueltos, más las identidades de confirmación cuando corresponda. Revisa su diferencia, el código fuente actual, los sitios de llamada directa, las pruebas relevantes y el contexto del Programa y la Pila afectados. Para un ámbito confirmado explícito, no sustituyas la diferencia ordinaria del árbol de trabajo por la diferencia confirmada seleccionada. Aplica la limpieza al código fuente actual preservando las ediciones fuera del ámbito. Si las ediciones superpuestas no se pueden separar de forma segura, pregunta sobre esa superposición en lugar de bloquear solo porque el repositorio está sucio.

Aplicar el contrato de limpieza

Aplica el enfoque de ingeniería proporcionado con la tarea. Si esta habilidad se invoca directamente, lee genesis/engineering.md así como el contexto del proyecto relevante. La limpieza debe reducir o preservar la complejidad, nunca introducir mecanismos no aprobados que el perfil seleccionado o un requisito concreto no necesiten.

Consulta .genesis/machine-city.json o ejecuta la operación de Genesis index <nombre-o-ruta> para encontrar funciones públicas e internas existentes antes de introducir o consolidar una abstracción. Confirma cada duplicado aparente en el código fuente y sus sitios de llamada.

Dentro del comportamiento previsto y el ámbito de los cambios seleccionados, no dejes ayudantes repetidos, código que no sea claro o difícil de razonar, ni código que vaya en contra de los patrones establecidos en la base de código. Elimina envoltorios innecesarios, andamios abandonados, infraestructura de framework paralela y abstracciones especulativas. Consolida la propiedad donde un módulo claro sea suficiente. No optimices para archivos pequeños o indirección; optimiza para un diseño pequeño y obvio que un programador junior pueda seguir.

La limpieza no es una segunda pasada de implementación. Los cambios seleccionados limitan dónde puede ocurrir la limpieza; compartir un archivo no trae ediciones no relacionadas al ámbito ni autoriza un comportamiento diferente en ese archivo. Deslop puede reorganizar el comportamiento ya presente; no puede completar, corregir ni extender el comportamiento. Si la revisión revela un defecto, comportamiento faltante, discrepancia de contrato o brecha de prueba, repórtalo como un hallazgo de seguimiento y déjalo sin cambios, incluso si está dentro de una ruta modificada o parece relacionado con la implementación anterior. No implementes el hallazgo ni modifiques pruebas para acomodarlo durante Deslop.

Aplica cada instrucción de Deslop específica de la tecnología proporcionada por la Pila seleccionada y carga las habilidades técnicas oficiales aplicables para el contexto del framework y el lenguaje. Las indicaciones de la Pila enriquecen este contrato; no pueden debilitar el límite de preservación del comportamiento, cambiar el ámbito seleccionado ni autorizar implementaciones no relacionadas.

Puedes editar o eliminar archivos de implementación y prueba cuando esa sea la limpieza más clara que preserve el comportamiento. Si mover o renombrar el código fuente seleccionado hace que una cita del Programa afectado quede obsoleta, actualiza solo esa cita o el mapa de Implementación informativo. No cambies el Plano ni un contrato público del Programa para justificar el comportamiento de limpieza. No edites .genesis/, metadatos de Git, directorios de dependencias, resultados de compilación generados, historial de migraciones retenido ni recursos externos. No debilites pruebas, comportamiento público ni garantías de datos. No crees una segunda arquitectura ni realices reescrituras no relacionadas.

Deja la limpieza como trabajo ordinario sin confirmar para revisión y una confirmación normal posterior. Nunca modifiques ni reescribas las confirmaciones seleccionadas. Ejecuta comprobaciones enfocadas cuando sea útil. Las comprobaciones declaradas finales permanecen disponibles a través de la operación verify de Genesis. Resume el ámbito resuelto y cualquier identidad de confirmación seleccionada, qué se volvió más simple, archivos cambiados, comprobaciones realmente ejecutadas y hallazgos de seguimiento dejados sin cambios.