Xinvtech/mobile-design-os

Mobile Design OS

Ejecuta la cadena de diseño móvil más pequeña y completa que cumpla con el resultado solicitado. Enruta el trabajo a las habilidades especializadas, conserva los IDs estables y la evidencia entre etapas, y nunca permitas que los visuales pulidos borren los vacíos no resueltos de producto, plataforma, estado o validación.

Establecer la ejecución

Determina:

• Resultado solicitado: análisis, encuadre de producto, UX, concepto visual, paquete de diseño completo, prototipo, revisión o traspaso a implementación.
• Plataforma objetivo y factores de forma.
• Entradas disponibles: idea de producto, capturas de pantalla, URLs, material de marca, contratos existentes, código o evidencia de ejecución.
• Alcance autorizado: solo diseño, prototipo o cambios de código.
• Decisiones que realmente requieren al usuario, especialmente modelo de seguridad, actor principal, límite del MVP, dirección visual, anulación del framework y licencia pública.

Crea design-run.json a partir de assets/design-run-template.json cuando el trabajo abarque dos o más etapas o deba ser reanudable. Lee references/pipeline-contract.md antes de crear o actualizar el manifiesto.

Enrutar a las habilidades requeridas

Lee el SKILL.md de la habilidad seleccionada por completo antes de ejecutar su etapa. No cargues el cuerpo de cada habilidad cuando la solicitud solo necesite una o dos etapas.

Necesidad	Habilidad	Evidencia de finalización
Descubrir o comparar referencias	mobile-reference-research	reference-research.json válido
Extraer mecánicas y ADN de diseño	analyze-mobile-ui	design-dna.json válido
Enmarcar producto y MVP	mobile-product-brief	product-brief.json válido
Definir flujos, objetos, pantallas y estados	mobile-ux-architect	ux-architecture.json válido
Establecer jerarquía de baja fidelidad	mobile-wireframe	wireframe.json válido
Explorar y renderizar UI visual	mobile-ui-design	ui-design.json válido, seleccionado por el usuario y bloqueado cuando se solicita un traspaso estructurado
Extraer tokens/componentes reutilizables	mobile-design-system	design-system.json válido
Modelar o renderizar comportamiento interactivo	mobile-prototype	prototype.json válido e informe de alineación de UI cuando existe la UI
Decidir y probar comportamiento nativo	mobile-platform-guidelines	platform-guidelines.json válido
Auditar la cadena	mobile-design-review	review.json válido con una decisión honesta
Planificar o estructurar la implementación	mobile-design-to-code	Traspaso válido más evidencia de compilación/pruebas real cuando se genera código

Ejecutar la cadena completa

Para una solicitud de extremo a extremo, usa este orden saltando solo las etapas marcadas explícitamente como no-requerido:

1. Ejecuta mobile-product-brief para fijar problema, audiencia, activación, ciclo principal, MVP, límites de confianza y decisiones no resueltas.
2. Ejecuta mobile-reference-research cuando falten referencias o necesiten comparación.
3. Ejecuta analyze-mobile-ui cuando las capturas de pantalla o productos de referencia deban convertirse en ADN de diseño rastreable.
4. Ejecuta mobile-ux-architect a partir del brief validado y las decisiones de referencia.
5. Ejecuta mobile-wireframe antes del estilo visual cuando la jerarquía o la presión de estado no sean triviales.
6. Ejecuta mobile-ui-design. Exige exactamente tres vistas previas comparables y detente en su puerta de elección del usuario. No selecciones una dirección visual a menos que el usuario delegue explícitamente la elección.
7. Después de la selección, bloquea la dirección visual y completa las pantallas renderizadas y el artefacto de UI estructurado.
8. Ejecuta mobile-design-system cuando se necesiten tokens de reutilización o implementación posteriores.
9. Ejecuta mobile-prototype, luego valida la alineación de estado e interacción entre la UI y el prototipo.
10. Ejecuta mobile-platform-guidelines para comportamiento nativo y casos de prueba de dispositivo.
11. Ejecuta mobile-design-review contra la cadena completa disponible.
12. Ejecuta mobile-design-to-code solo cuando se solicite implementación o traspaso y la decisión de revisión lo permita.

Actualiza design-run.json después de cada etapa. Conserva los IDs de Requisito, Flujo, Pantalla, Estado, Token, Componente y evidencia de las etapas anteriores; nunca regeneres identificadores silenciosamente en una etapa posterior.

Aplicar puertas de control

• Ejecuta cada validador de etapa nombrado por la habilidad seleccionada y corrige fallos estructurales antes de continuar.
• Exige un Product Brief validado antes de afirmar completitud de UX.
• Exige propiedad de estado explícita y recuperación antes de afirmar completitud de UI.
• Exige visualLock.status: locked y una fuente de selección del usuario o delegada por este antes de trabajar en el Sistema de Diseño o prototipo renderizado.
• Exige alineación UI-prototipo cuando ambos artefactos existan.
• Mantén capturas de pantalla y ejecutores de navegador alejados de probar accesibilidad en tiempo de ejecución, ciclo de vida, permisos, sensores, persistencia, entrega o comportamiento del dispositivo.
• Mantén un traspaso de código alejado de probar que el código generado compila o se prueba. Registra los comandos y resultados exactos cuando se genere código.
• Exige que no haya P0 o P1 abiertos y que no falte evidencia de alto riesgo antes de un pass; de lo contrario, usa conditional-pass, revise o fail según lo definido por la habilidad de revisión.

Ejecuta python3 scripts/validate_design_run.py <ruta-a-design-run.json> --root <directorio-de-ejecucion> antes de entregar una ejecución de múltiples etapas.

Detenerse solo ante decisiones materiales

Pausa cuando:

• El usuario deba elegir entre las tres direcciones visuales.
• Una decisión cambie seguridad, privacidad, actor principal, ciclo de valor principal, comportamiento destructivo o alcance del MVP.
• Una entrada requerida o autorización no esté disponible.
• El siguiente paso pretenda afirmar evaluación externa, evidencia de dispositivo físico, comportamiento de producción o una licencia pública que realmente no se haya proporcionado.

De lo contrario, continúa con una suposición etiquetada y regístrala en el manifiesto.

Entregar la ejecución

Devuelve:

1. Resultado y decisión de la etapa actual.
2. Etapas completadas y rutas de artefactos validados.
3. Decisiones del usuario y suposiciones etiquetadas.
4. Problemas P0/P1 abiertos y comportamiento de alto riesgo no probado.
5. La siguiente etapa ejecutable, o la puerta externa/de dispositivo/usuario que permanece.

No describas la cadena como completa cuando una etapa requerida esté pendiente, esperando selección del usuario, bloqueada o estructuralmente válida pero no probada.