r3xsean/processo-de-design

Processo de design

O usuário define a direção e o gosto. Os modelos julgam a execução: se a tarefa pode ser feita, se os números são verdadeiros, se algo quebra, esconde ou engana. Uma pontuação, um conselho ou consenso entre modelos nunca escolhe entre direções, as mescla ou anula uma decisão registrada.

Se o projeto tiver sua própria skill de design, siga-a; ela pode encaminhá-lo de volta para esta skill em alguma fase.

Os arquivos do projeto

Em docs/design/, a menos que o AGENTS.md do projeto nomeie outro local para estes arquivos:

• product-brief.md: a verdade do produto. Quem o usa, o que cada superfície deve permitir que eles façam (sua pergunta principal e modo: Operar, Ler ou Persuadir), dados e estados, cópia e limites de confiança. Se o projeto já tiver um PRODUCT.md, o brief referencia ele em vez de repeti-lo.
• DESIGN.md: as decisões do usuário, exceções, telas de referência aprovadas e o registro de reações. Uma decisão registrada supera sua preferência. Onde nenhuma decisão estiver registrada, a aparência está em aberto; a interface atual é evidência, não uma decisão.
• harness.md: como as telas e protótipos são executados e capturados: comandos, cenários, viewports, os aplicativos concorrentes, para onde as capturas vão.
• runs/<AAAA-MM-DD-nome>/run.md: a pergunta de uma execução, o que está fixo e em aberto, limites conhecidos, membros do conselho e alvo, a chave de postura, o resultado.

Os modelos para todos os quatro estão em templates/. Se algum dos três primeiros arquivos estiver faltando, inicialize primeiro. Cada execução, incluindo uma que ignore a inicialização, começa seu próprio run.md. Capturas, manifestos, registros de descobertas e planilhas de variação vão para a pasta ignorada pelo git que harness.md nomeia. Os pacotes do conselho vão para fora do repositório, na pasta de rascunho ou temporária da sessão.

As próprias regras do projeto substituem esta skill: seu AGENTS.md sobre dependências, servidores de desenvolvimento e o que é commitado. Quando a execução precisar de algo que essas regras proíbam ou reservem para discussão, pergunte ao usuário antes de fazer.

Fluxo

• Nova UI: inicialização → exploração → o usuário escolhe → refinamento → conselho → aprovar uma referência → retenção → envio pelo caminho de lançamento do projeto.
• UI existente: inicialização → conselho → aprovar → enviar. Quando o usuário quiser mudanças visíveis primeiro, refine antes do conselho.

Entre na fase que a solicitação nomear; um ajuste estreito entra no refinamento.

Fase	Leia primeiro
Inicialização	references/bootstrap.md, depois references/harness-contract.md para cada capacidade que a execução precisar
Exploração	references/explore.md
Refinamento	references/refine.md, e references/craft.md antes da primeira edição de UI
Conselho	references/council.md
Usando outra skill de design	references/integrations.md, antes de invocá-la

Membros do conselho. Quando a execução chegar ao conselho, pergunte ao usuário no início quem faz parte dele (o modelo e o esforço de raciocínio de cada membro), a menos que eles já os tenham nomeado. Sugira membros de diferentes provedores. Registre os membros em run.md e use exatamente esses durante toda a execução. Se um membro estiver indisponível, diga; nunca substitua um.

Aprovar uma referência. Apenas as palavras do usuário aprovam uma tela; pontuações nunca substituem. Copie suas capturas para docs/design/references/ e liste-as em Telas de referência no DESIGN.md, dizendo para o que cada uma é a referência.

Retenção. Após a primeira referência aprovada, um agente novo projeta uma superfície que ainda não foi projetada, a partir desta skill, dos arquivos do projeto e do harness apenas, e lista cada ponto onde teve que adivinhar. Mostre o resultado ao usuário. Corrija cada adivinhação no arquivo que deveria ter respondido a ela, ou registre-a em run.md como em aberto. Feito quando o usuário tiver reagido e cada adivinhação estiver corrigida ou registrada.

Registrar reações

Sempre que o usuário reagir a um design, em qualquer fase:

1. Adicione uma linha ao registro de reações do DESIGN.md por reação: data (UTC), superfície e viewport, qual design e execução de captura, as palavras do usuário citadas exatamente, tipo, escopo, status observado.
   • Tipo: gostei (manter), não gostei (mudar) ou defeito (uma tarefa falhou ou algo quebrou; adicione também ao registro de descobertas). Uma reação pode gostar de uma parte e não gostar de outra; nomeie cada parte. Um recurso ainda não construído não é uma reação: liste-o sob limites conhecidos em run.md.
   • Escopo é o que o usuário declarou: este elemento, esta superfície ou em todo o site. Se não declarou nenhum, é o elemento. Nunca o amplie por conta própria.
   • O que você mudou em resposta vai para o registro de descobertas, não na linha.
2. Promova uma linha para Decisões quando o usuário a declarar de forma geral. Quando a mesma reação ocorrer em uma segunda superfície, pergunte se ela se aplica de forma geral e promova apenas se sim. Marque a linha como promovida com um link.
3. Quando uma reação contradisser uma decisão, pergunte qual vence, então edite ou remova a decisão antiga e marque as linhas perdedoras como substituída.

Feito quando cada reação tem uma linha e cada promoção cita a declaração geral do usuário ou seu sim.

Privacidade

Capturas usam dados de fixture, dados de semente ou uma conta demo, nunca a própria conta do usuário ou registros de pessoas reais. Nada que mostre dados pessoais ou conteúdo adulto vai para um pacote do conselho, uma captura de referência ou um commit.