9. Decisões tomadas — gate de 2026-08-15

As seis perguntas da v0.1 foram respondidas pelo Rafael na mesma sessão. Registro formal, com o verbatim onde ele decide e o que cada decisão obriga:

D1 — Ordem das fases: FUNDAÇÃO PRIMEIRO. Verbatim: "acho que fundação primeiro" + "podemos seguir a ordem que preferir". Vale a sequência F7.1 → F7.2 → F7.3 → F7.4 → F7.5 → F7.6 → F7.7 do §8. Racional declarado: as decisões D2/D3/D4 mudam a FORMA de todo artefato futuro — produzir telas antes seria construir com o vocabulário velho e refazer depois; e a renomeação da D3 custa ~14 caminhos de suíte hoje contra o dobro daqui a três fases. Alternativa descartada: puxar F7.4 (Kanban) para frente, considerada caso o fluxo de obra fosse a dor imediata — não é.

D2 — CP2 vai de SEIS para SETE tipos de bloco. APROVADO. Entra trilha (agrupador vertical transparente: coluna de Kanban, raia de gantt, faixa de pessoa da carga), mais duas exceções escritas (B1 canvas interativo · B3 feed invertido/C33) e uma regra de relação (B4 split com resizer). Executa-se por supersede formal do CP2 na F7.1. Alternativa descartada: coluna de Kanban como exceção dentro de "peça" — rejeitada porque trilha não tem superfície (nem fundo, nem raio, nem separação), e chamar de peça algo que não se separa do canvas esvazia a definição de peça.

D3 — Renomeação BANCADA × TELA. APROVADO. banco-*.html = catálogo de estados de componente (o mesmo componente repetido em todos os estados, fora de contexto de uso; é o que as suítes medem). tela-*.html = caso de uso montado (dados plausíveis, cada componente uma vez no papel dele; é o que o gate visual julga e a suite-composicao mede). Régua de uso: pergunta sobre COMPORTAMENTO de um componente → bancada; pergunta sobre se a TELA está boa → tela. Fecha de carona a dívida P1 (esquema de caminho das suítes), aberta desde o marco v1.4 e que já cobrou preço duas vezes na sessão de 2026-08-15.

D4 — CONTAINER QUERIES NOMEADAS como lei do DS. APROVADO ("se vc acha que é o melhor caminho, concordo"). Fato que sustenta: o ClickUp tem 60+ container queries nomeadas contra 54 media queries, e a barra de ferramentas sozinha tem sete pontos de quebra do próprio container (§5.1, MEDIDO). Consequência declarada, que é cara e precisa estar escrita: muda como cada preview e cada suíte de render medem — simular largura de janela deixa de valer como prova; a prova passa a ser redimensionar o CONTAINER. As suítes de render existentes precisam de guarda nova (F7.7).

D5 — Fronteiras. Whiteboard (A21) e mapa mental (A22) FORA do DS; verbatim: "são funcionalidades que podem ser ampliadas depois, e não vejo necessidade ser prevista no DS". Chat (A23) DENTRO, e a razão amplia o escopo do sistema inteiro: "vamos ter construção de app de chat, mesmo que não fique dentro do ERP (…) estamos criando DS para suprir templates, blocos que padronizam o uso para qualquer tipo de criação, site, app, ERP ou qualquer coisa." Consequência de método: o DS não é "o DS do ERP" — é o sistema de qualquer produto SEED, e todo arquétipo deve ser julgado por essa régua, não pela de um ERP só.

D6 — Campos de domínio (medida/monetário C9, duração C10): COMPONENTE PRÓPRIO. APROVADO ("sigo sua recomendação", 2026-08-15). A pergunta da v0.1 não estava clara e foi reformulada. Componente próprio = seção nova no canônico, com anatomia, estados, tokens, código e testes — o comportamento fica garantido, ao custo de mais superfície para manter. Variante documentada = subseção dentro do §5 Número — custo baixo, com o risco de que o que a spec não fixar seja re-decidido por quem implementa (origem de drift). Recomendação registrada: componente próprio para medida/monetário e duração (regra de domínio real: casas decimais fixas por unidade, sufixo travado kWp/kWh/R$, teclado numérico em pointer: coarse, alinhamento à direita em mono pelo PN21d, validação de faixa), variante para os demais. Executa-se na F7.5 como seções novas do canônico (numeração a definir na fase), com anatomia, estados, tokens, código e testes — a mesma régua dos §1–§45. Alternativa descartada: variante dentro do §5 Número — rejeitada porque o volume de regra (casas por unidade, sufixo travado, teclado, alinhamento mono, faixa) não cabe em subseção sem deixar lacuna para quem implementa decidir sozinho, que é a origem medida do drift (§10b.1 do estudo ClickUp).