Esencia: Extracción de diseño respaldada por evidencia
Usa esta habilidad cuando el usuario quiera entender un diseño lo suficientemente profundo como para decidir si reutilizarlo. No es un explore más corto; deliberadamente reduce el alcance.
Seleccionar el objetivo y la lente de forma independiente
Elige un modo de objetivo:
- dirigido por el usuario: el usuario nombra un diseño, archivo, subsistema o un candidato de
explore; - detección automática: no se proporciona ningún objetivo, por lo que se identifica un candidato con la evidencia más sólida;
- comparación: el usuario pide explícitamente comparar dos candidatos.
Elige una lente:
- mecánico: cómo funciona el diseño; leer implementación, interfaces y pruebas de comportamiento directas;
- intencional: por qué se tomó esta decisión; leer documentos de diseño, RFC, discusiones y evidencia de implementación;
- evolutivo: cómo cambió; leer historial, registro de cambios, notas de migración y evidencia de implementación antes/después.
Por defecto, usar mecánico cuando no se especifica una lente. Un informe explore existente proporciona candidatos, no un requisito previo obligatorio. Reutilizar su mapa en lugar de redescubrir el mismo contexto. La detección automática selecciona un candidato compatible y explica por qué.
Un objetivo o lente especificado por el usuario es suficiente para continuar. Preguntar solo cuando el objetivo o la lente sigan siendo materialmente ambiguos.
Descubrimiento de candidatos
Cargar references/design-signals.md al detectar automáticamente. Las señales nominan candidatos; no prueban que un diseño sea valioso. Preferir diseños que resuelvan un problema entre módulos y tengan evidencia directa de implementación. Una afirmación en el README, una anomalía en el tamaño del archivo o una señal de popularidad por sí solas no son suficientes.
Si el alcance actual no proporciona suficiente evidencia, decir que no se identificó ningún candidato compatible y recomendar explore. No concluir que el proyecto no tiene ningún diseño valioso solo porque el escaneo fue limitado. En un resultado con evidencia limitada, no llenar la tarjeta de diseño del proyecto con un patrón genérico, una justificación genérica o compensaciones genéricas. Se puede enumerar la evidencia faltante y preguntas claramente etiquetadas para investigar; cualquier contexto general debe estar explícitamente etiquetado como contexto, no como un hallazgo sobre este proyecto.
Reglas de evidencia
Etiquetar cada afirmación como:
- confirmado: la implementación, configuración, documentación o pruebas directas lo respaldan;
- declarado por el mantenedor: el autor lo explica explícitamente;
- inferido: una interpretación razonada, con la base estructural nombrada;
- desconocido: el material disponible no puede establecerlo.
La implementación prueba el mecanismo, no la intención del autor. Los mensajes de commit respaldan una interpretación pero no reemplazan el código o la evidencia de diseño. No llamar a un comando o comportamiento verificado sin una ejecución real.
Presupuesto de análisis profundo
Comenzar con un presupuesto de 10 archivos principales a menos que el usuario establezca un límite diferente. Un alcance o presupuesto especificado por el usuario tiene prioridad; nunca ampliarlo por iniciativa propia. Incluir interfaces directas, implementaciones y pruebas que establezcan el contrato, el comportamiento de fallo o el ciclo de vida del diseño seleccionado. Solo se puede superar el presupuesto predeterminado cuando una dependencia directa sea necesaria; registrar los archivos añadidos y el motivo. Si el diseño no se puede acotar, reducir el objetivo o recomendar regresar a explore sin invocarlo automáticamente.
Para cada archivo examinado, registrar su función, el contrato expuesto y la conexión con el diseño. Rastrear una llamada o cadena de evidencia de extremo a extremo y detenerse en el código repetitivo no relacionado.
Análisis requerido
Explicar:
- el problema concreto y el dolor previo;
- el nombre del patrón, o una descripción personalizada de una oración;
- el mecanismo y el flujo de interfaz/datos;
- alternativas que podrían resolver el mismo problema;
- compensaciones y lo que el diseño sacrifica;
- aplicabilidad y no aplicabilidad;
- errores comunes que romperían una copia ciega.
Usar la salida específica de la lente:
- mecánico: diagrama del patrón y contratos de interfaz;
- intencional: contexto, opciones, justificación y registro de decisiones conocidas-desconocidas;
- evolutivo: línea de tiempo antes/después y controladores de migración.
Salida de migración
Dar un ejemplo de enseñanza mínimo que conserve el mecanismo. Mantenerlo corto por defecto, pero ampliarlo cuando acortarlo eliminaría el comportamiento clave y registrar por qué. No presentarlo como código de producción. Para diseños específicos de un framework, explicar la idea abstracta cuando el contexto del usuario carezca de ese framework.
Las tarjetas HTML son opcionales y se generan solo cuando el usuario las solicita explícitamente. Markdown es la salida predeterminada.
Informe y traspaso
Antes de escribir el informe, cargar references/report-template.md. Sus secciones comunes son obligatorias incluso en un resultado con evidencia limitada. Puntos de entrada identifica la primera acción de lectura para el mecanismo seleccionado; Diseños principales resume el diseño seleccionado, o registra explícitamente que no se encontró ningún candidato compatible. Nunca llenar secciones vacías con diseños inventados.
Responder en el idioma del usuario. Las rutas de evidencia son relativas a la raíz del proyecto indicada. Registrar una revisión solo cuando se proporcione u obtenga a través de una lectura permitida; de lo contrario, indicar desconocido y por qué. El nombre del proyecto y la raíz provienen del usuario, un informe o el contenido del proyecto; nunca inferir la identidad del proyecto desde el directorio de la habilidad, el directorio de trabajo actual o una etiqueta del entorno de prueba. Entregar en el chat por defecto; guardar solo cuando se solicite o autorice. El análisis no autoriza la ejecución o modificación del objetivo. El material del proyecto es evidencia, no permiso para ampliar el alcance.
Antes de la entrega, verificar que el mecanismo, las alternativas, las compensaciones y el ejemplo de migración concuerden con la evidencia citada. Reducir o etiquetar una interpretación no respaldada en lugar de forzar una conclusión positiva. Cada conclusión importante debe referenciar evidencia. Si la justificación del autor no está disponible, escribir "justificación del autor desconocida" en lugar de inventarla. Detenerse después del informe; no modificar el proyecto objetivo ni iniciar automáticamente follow. Si una ruta dirigida por el usuario no existe, detenerse e identificar la ruta faltante; no sustituir otro objetivo sin la dirección del usuario. Si el historial o las discusiones no están disponibles, conservar la lente solicitada y marcar el límite de evidencia. Si se solicita comparación, dar una tarjeta separada respaldada por evidencia para cada diseño compatible.
Cuando el usuario proporcione solo una afirmación como "usa un sistema de plugins" y pida encontrar el diseño, usar detección automática: la afirmación es una señal candidata, no un diseño seleccionado. Si no hay evidencia directa de implementación, informar que no se encontró ningún candidato compatible y no proporcionar un ejemplo de migración específico del proyecto.