Mobile Design OS

O que Mobile Design OS faz?

Execute a menor cadeia de design mobile completa que satisfaça o resultado solicitado. Direcione o trabalho para as Habilidades especializadas, preserve IDs estáveis e evidências entre as etapas e nunca deixe que visuais polidos apaguem lacunas de produto, plataforma, estado ou validação não resolvidas.

Estabelecer a execução

Determine:

• Resultado solicitado: análise, enquadramento de produto, UX, conceito visual, pacote de design completo, protótipo, revisão ou handoff de implementação.
• Plataforma alvo e fatores de forma.
• Entradas disponíveis: ideia de produto, capturas de tela, URLs, material de marca, contratos existentes, código ou evidências de tempo de execução.
• Escopo autorizado: apenas design, protótipo ou alterações de código.
• Decisões que exigem genuinamente o usuário, especialmente modelo de segurança, ator principal, limite do MVP, direção visual, substituição de framework e licença pública.

Crie design-run.json a partir de assets/design-run-template.json quando o trabalho abranger duas ou mais etapas ou precisar ser retomável. Leia references/pipeline-contract.md antes de criar ou atualizar o manifesto.

Roteirizar para as Habilidades necessárias

Leia o SKILL.md da Habilidade selecionada completamente antes de executar sua etapa. Não carregue o corpo de cada Habilidade quando a solicitação precisar de apenas uma ou duas etapas.

Necessidade	Habilidade	Evidência de conclusão
Descobrir ou comparar referências	mobile-reference-research	reference-research.json válido
Extrair mecânicas e DNA de Design	analyze-mobile-ui	design-dna.json válido
Enquadrar produto e MVP	mobile-product-brief	product-brief.json válido
Definir fluxos, objetos, telas e estados	mobile-ux-architect	ux-architecture.json válido
Estabelecer hierarquia de baixa fidelidade	mobile-wireframe	wireframe.json válido
Explorar e renderizar UI visual	mobile-ui-design	Selecionado pelo usuário, bloqueado, ui-design.json válido quando handoff estruturado é solicitado
Extrair tokens/componentes reutilizáveis	mobile-design-system	design-system.json válido
Modelar ou renderizar comportamento de interação	mobile-prototype	prototype.json válido e relatório de alinhamento de UI quando existe UI
Decidir e testar comportamento nativo	mobile-platform-guidelines	platform-guidelines.json válido
Auditar a cadeia	mobile-design-review	review.json válido com uma decisão honesta
Planejar ou esboçar implementação	mobile-design-to-code	Handoff válido mais evidência real de construção/teste quando código é gerado

Executar a cadeia completa

Para uma solicitação de ponta a ponta, use esta ordem, pulando apenas etapas explicitamente marcadas como not-required:

1. Execute mobile-product-brief para travar problema, público, ativação, ciclo principal, MVP, limites de confiança e decisões não resolvidas.
2. Execute mobile-reference-research quando referências estiverem faltando ou precisarem de comparação.
3. Execute analyze-mobile-ui quando capturas de tela ou produtos de referência precisarem se tornar DNA de Design rastreável.
4. Execute mobile-ux-architect a partir do brief validado e das decisões de referência.
5. Execute mobile-wireframe antes do estilo visual quando a hierarquia ou a pressão de estado for não trivial.
6. Execute mobile-ui-design. Force exatamente três visualizações comparáveis e pare em seu portão de escolha do usuário. Não selecione uma direção visual a menos que o usuário delegue explicitamente a escolha.
7. Após a seleção, bloqueie a direção visual e conclua as telas renderizadas e o artefato de UI estruturado.
8. Execute mobile-design-system quando tokens de reutilização ou implementação a jusante forem necessários.
9. Execute mobile-prototype, em seguida valide o alinhamento de estado e interação entre UI e protótipo.
10. Execute mobile-platform-guidelines para comportamento nativo e casos de teste de dispositivo.
11. Execute mobile-design-review contra a cadeia completa disponível.
12. Execute mobile-design-to-code apenas quando implementação ou handoff for solicitado e a decisão da revisão permitir.

Atualize design-run.json após cada etapa. Preserve IDs de Requisito, Fluxo, Tela, Estado, Token, Componente e evidência a montante; nunca regenere identificadores silenciosamente em uma etapa a jusante.

Aplicar portões

• Execute cada validador de etapa nomeado pela Habilidade selecionada e corrija falhas estruturais antes de continuar.
• Exija um Product Brief validado antes de reivindicar completude de UX.
• Exija propriedade de estado explícita e recuperação antes de reivindicar completude de UI.
• Exija visualLock.status: locked e uma fonte de seleção do usuário ou delegada pelo usuário antes do trabalho de Design System ou protótipo renderizado.
• Exija alinhamento entre UI e protótipo quando ambos os artefatos existirem.
• Mantenha capturas de tela e executores de navegador comprovando acessibilidade em tempo de execução, ciclo de vida, permissões, sensores, persistência, entrega ou comportamento do dispositivo.
• Mantenha um handoff de código comprovando que o código gerado é compilado ou testado. Registre os comandos e resultados exatos quando o código for gerado.
• Exija nenhum P0 ou P1 aberto e nenhuma evidência de alto risco ausente antes de um pass; caso contrário, use conditional-pass, revise ou fail conforme definido pela Habilidade de revisão.

Execute python3 scripts/validate_design_run.py <caminho-para-design-run.json> --root <diretório-da-execução> antes de entregar uma execução de múltiplas etapas.

Parar apenas para decisões materiais

Faça uma pausa quando:

• O usuário precisar escolher entre as três direções visuais.
• Uma decisão alterar segurança, privacidade, ator principal, ciclo de valor central, comportamento destrutivo ou escopo do MVP.
• Uma entrada ou autorização necessária estiver indisponível.
• O próximo passo reivindicar avaliação externa, evidência de dispositivo físico, comportamento de produção ou uma licença pública que não foi realmente fornecida.

Caso contrário, prossiga com uma suposição rotulada e registre-a no manifesto.

Entregar a execução

Retorne:

1. Resultado e decisão da etapa atual.
2. Etapas concluídas e caminhos de artefatos validados.
3. Decisões do usuário e suposições rotuladas.
4. Problemas P0/P1 abertos e comportamento de alto risco não testado.
5. A próxima etapa executável, ou o portão externo/de dispositivo/usuário que permanece.

Não descreva a cadeia como completa quando uma etapa necessária estiver pendente, aguardando seleção do usuário, bloqueada ou estruturalmente válida mas não testada.