r3xsean/design-process

Proceso de diseño

El usuario decide la dirección y el gusto. Los modelos juzgan la ejecución: si la tarea se puede realizar, si los números son correctos, si algo se rompe, se oculta o engaña. Una puntuación, un consejo o un consenso del modelo nunca elige entre direcciones, las fusiona o anula una decisión registrada.

Si el proyecto tiene su propia habilidad de diseño, síguela; puede enviarte de vuelta aquí para una fase.

Los archivos del proyecto

En docs/design/, a menos que el archivo AGENTS.md del proyecto indique otro lugar para estos archivos:

• product-brief.md: la verdad del producto. Quién lo usa, qué debe permitir hacer cada superficie (su pregunta principal y modo: Operar, Leer o Persuadir), datos y estados, copia y límites de confianza. Si el proyecto ya tiene un PRODUCT.md, el resumen enlaza a él en lugar de repetirlo.
• DESIGN.md: las decisiones del usuario, excepciones, pantallas de referencia aprobadas y el registro de reacciones. Una decisión registrada gana sobre tu preferencia. Donde no hay ninguna registrada, el aspecto está abierto; la interfaz actual es evidencia, no una decisión.
• harness.md: cómo se ejecutan y capturan las pantallas y prototipos: comandos, escenarios, viewports, las aplicaciones de la competencia, dónde van las capturas.
• runs/<AAAA-MM-DD-nombre>/run.md: la pregunta de una ejecución, qué está fijo y qué está abierto, límites conocidos, miembros del consejo y objetivo, la clave de postura, el resultado.

Las plantillas para los cuatro están en templates/. Si falta alguno de los primeros tres archivos, primero haz el bootstrap. Cada ejecución, incluso una que omita el bootstrap, inicia su propio run.md. Las capturas, manifiestos, registros de hallazgos y hojas de variantes van en la carpeta ignorada por git que nombra harness.md. Los paquetes del consejo van fuera del repositorio, en el bloc de notas o carpeta temporal de la sesión.

Las reglas propias del proyecto prevalecen sobre esta habilidad: su AGENTS.md sobre dependencias, servidores de desarrollo y qué se confirma. Cuando la ejecución necesite algo que esas reglas prohíban o reserven para discusión, pregúntale al usuario antes de hacerlo.

Flujo

• Interfaz nueva: bootstrap → explorar → el usuario elige → refinar → consejo → aprobar una referencia → retención → enviar a través de la ruta de implementación del proyecto.
• Interfaz existente: bootstrap → consejo → aprobar → enviar. Cuando el usuario quiere cambios visibles primero, refina antes del consejo.

Ingresa en la fase que indique la solicitud; un ajuste pequeño ingresa en refinar.

Fase	Leer primero
Bootstrap	references/bootstrap.md, luego references/harness-contract.md para cada capacidad que necesite la ejecución
Explorar	references/explore.md
Refinar	references/refine.md, y references/craft.md antes de la primera edición de la interfaz
Consejo	references/council.md
Usar otra habilidad de diseño	references/integrations.md, antes de invocarla

Miembros del consejo. Cuando la ejecución llegue al consejo, pregúntale al usuario al inicio quiénes participan (el modelo y el esfuerzo de razonamiento de cada miembro), a menos que ya los haya nombrado. Sugiere miembros de diferentes proveedores. Registra los miembros en run.md y úsalos exactamente para toda la ejecución. Si un miembro no está disponible, dilo; nunca lo sustituyas.

Aprobar una referencia. Solo las palabras del usuario aprueban una pantalla; las puntuaciones nunca la reemplazan. Copia sus capturas a docs/design/references/ y listalas en Pantallas de referencia en DESIGN.md, indicando para qué es referencia cada una.

Retención. Después de la primera referencia aprobada, un agente nuevo diseña una superficie que aún no se ha diseñado, usando solo esta habilidad, los archivos del proyecto y el harness, y enumera cada punto donde tuvo que adivinar. Muéstrale el resultado al usuario. Corrige cada suposición en el archivo que debería haberla respondido, o regístrala en run.md como abierta. Termina cuando el usuario haya reaccionado y cada suposición esté corregida o registrada.

Registrar reacciones

Cada vez que el usuario reaccione a un diseño, en cualquier fase:

1. Agrega una fila al registro de reacciones de DESIGN.md por cada reacción: fecha (UTC), superficie y viewport, qué diseño y ejecución de captura, las palabras del usuario citadas exactamente, tipo, alcance, estado observado.
   • Tipo: me gusta (conservarlo), no me gusta (cambiarlo) o defecto (una tarea falló o algo se rompió; agrégalo también al registro de hallazgos). Una reacción puede gustar de una parte y no gustar de otra; nombra cada parte. Una característica aún no construida no es una reacción: listala bajo límites conocidos en run.md.
   • Alcance es lo que el usuario indicó: este elemento, este tipo de superficie, o en todo el sitio. Si no indicó ninguno, es el elemento. Nunca lo amplíes por tu cuenta.
   • Lo que cambiaste como respuesta va en el registro de hallazgos, no en la fila.
2. Promueve una fila a Decisiones cuando el usuario lo indique de manera general. Cuando la misma reacción se repite en una segunda superficie, pregunta si aplica de manera general y promueve solo si responde que sí. Marca la fila como promovida con un enlace.
3. Cuando una reacción contradice una decisión, pregunta cuál gana, luego edita o elimina la decisión anterior y marca las filas perdedoras como reemplazada.

Termina cuando cada reacción tenga una fila y cada promoción cite la declaración general del usuario o su respuesta afirmativa.

Privacidad

Las capturas utilizan datos de prueba, datos semilla o una cuenta de demostración, nunca la cuenta propia del usuario ni registros de personas reales. Nada que muestre datos personales o contenido para adultos va en un paquete del consejo, una captura de referencia o una confirmación.