Spec — DS Studio

O DS Studio é a surface de autoria da fatia F3 (design-RFC-014): um usuário cria o próprio Design System — não só uma paleta — sem escrever código, de forma determinística (mesma entrada → mesmo DS) e sem LLM. Vive no site KDS (/studio/) e evolui o Themer (specs/tools/theme-builder.kmd): o motor de cor (seed→18-role palette via HCT, override por-role, simulação de CVD, export) é reusado tal-e-qual (reuse-first — não reimplementar), e o Studio acrescenta as dimensões que fazem de um tema um DS: fork, seeds não-cor, seleção de componentes/templates/ícones/a11y, conformance, e export de manifesto + publish.

Themer × DS Studio. O Themer produz tokens de cor pra colar num app. O DS Studio produz um koder.designsystem.toml publicável (manifesto + tokens multi-linguagem + preview) — a unidade de 1ª classe do framework. O Themer segue existindo como o caminho rápido "só cores"; o Studio é o caminho completo "um DS".

1. O pipeline de autoria (6 estágios)

A sessão do Studio é um pipeline determinístico. O usuário caminha pelos estágios; o estado é compartilhado e persistido (R7). Nenhum estágio chama modelo de IA.

1. Entrada (R2) — começar de um seed (uma cor de marca) OU forkar um DS existente (verge / govbr / um preset look-only).
2. Derivar (R3) — do seed/fork, derivar as 6 famílias de token (color, shape, space, shadow, typography, motion) via o modelo seed→map→alias (design-RFC-007).
3. Selecionar (R4) — escolher o set de componentes/templates/ícones que o DS provê/override e o perfil de acessibilidade.
4. Validar (R5) — rodar o gate de conformance (AA + kind) inline; nada avança pra publicação enquanto não passar.
5. Exportar (R6) — emitir koder.designsystem.toml + tokens/ (dist design-RFC-006) + preview/ — um diretório de DS válido.
6. Publicar (R7... na verdade R8) — empacotar como kpkg design-system (specs/kpkg/format.kmd §11) e publicar no Koder Hub.

2. Requisitos normativos

R1 — Determinístico, sem LLM

A derivação SHALL ser puramente algorítmica — o mesmo par (entrada, seleção) produz byte-idêntico o mesmo manifesto + tokens. Nenhum estágio SHALL chamar um modelo de linguagem/geração. (Herda R11 do theme-builder: sem palette-math server-side; o Studio roda client-side, HCT-aware.)

Scenario: reproduzir uma sessão

• GIVEN uma URL de estado do Studio (seed/fork + seleções, R7)
• WHEN outro usuário abre a URL e exporta
• THEN o koder.designsystem.toml + tokens resultantes são idênticos aos originais.

R2 — Entrada: seed OU fork

O Studio SHALL oferecer dois modos de entrada:

• Seed — uma cor de marca (o fluxo atual do Themer), com os seed-chips curados.
• Fork — escolher um DS existente do registry (/api/v1/design-systems.json); o Studio carrega os tokens/seleções desse DS como ponto de partida editável e grava forked_from = "<slug>" na proveniência do manifesto.

Scenario: forkar o Verge

• GIVEN o usuário escolhe "Fork → verge"
• WHEN o Studio inicializa
• THEN os seeds/tokens do Verge preenchem o pipeline, editáveis, e o export registra a origem (forked_from = "verge").

R3 — Derivação das 6 famílias (não só cor)

Além da cor (delegada ao motor do Themer + themes/color-dynamic.kmd), o Studio SHALL derivar as famílias não-cor — shape (radii), space (spacing unit + escala de densidade), typography (família + escala), motion — a partir de seeds/escolhas, consistente com o modelo seed→map→alias (design-RFC-007). Cada família é editável com override, como o per-role de cor (theme-builder R5).

Scenario: densidade propaga

• GIVEN o usuário escolhe densidade "Compact"
• WHEN o Studio deriva space/shape
• THEN o preview e todos os exports refletem a escala compacta (paridade com o theme-builder R3/#193).

R4 — Seleção de componentes/templates/ícones + a11y

O Studio SHALL deixar o usuário escolher o que o DS provê: o set de componentes (specs/components/*), templates/patterns (specs/patterns/*), o set de ícones ([icons]), e o perfil de acessibilidade ([a11y].profiles — ex.: emag-3.1, forced-colors). O piso wcag-2.2-aa e o floor de locales (en-US+pt-BR) são não-removíveis (herança do manifesto). Um DS look-only deixa a seleção vazia e herda o corpus do oficial (manifesto §2).

Scenario: look-only não seleciona componentes

• GIVEN o usuário marca o DS como kind = look-only
• WHEN chega ao estágio de seleção
• THEN a seleção de componentes/templates fica desabilitada (herda do Verge) e só os tokens são autorais.

R5 — Conformance inline (gate antes de publicar)

Antes do export/publish, o Studio SHALL rodar o gate de conformance (design-RFC-014 #413): todo par de cor interativo ≥ AA e as regras por kind. Falhas aparecem inline (o par + o ratio, como no theme-builder R5/contrast-checker); um DS não-conforme SHALL não poder publicar como stable.

Scenario: accent abaixo de AA bloqueia publish

• GIVEN um DS cujo par --accent/--accent-on mede < 4.5:1
• WHEN o usuário tenta publicar
• THEN o Studio bloqueia com o par/ratio destacado e sugere o tom AA mais próximo.

R6 — Export do manifesto + tokens + preview

O Studio SHALL exportar um diretório de DS válido: koder.designsystem.toml (conforme specs/design-system/manifest.kmd, incl. [hub] se for publicar) + tokens/ (o dist multi-linguagem design-RFC-006: css/json/rust/…; Dart é legado — Flutter SUNSET) + preview/ (imagens light/dark cross-template). O export é determinístico (R1).

Scenario: export produz manifesto válido

• GIVEN uma sessão que passou no conformance (R5)
• WHEN o usuário exporta
• THEN o koder.designsystem.toml emitido valida contra manifest.kmd (o registry o aceita) e o diretório contém tokens/ + preview/.

R7 — Persistência de estado

O estado completo (modo de entrada + seeds + seleções + overrides) SHALL ser serializado na URL-hash (como o theme-builder R6), de modo que compartilhar a URL reproduz a sessão (R1). Sem conta de servidor (herança do theme-builder R10).

R8 — Publicação como kpkg design-system

Do diretório exportado (R6), o Studio SHALL oferecer publicar como kpkg design-system (specs/kpkg/format.kmd §11): deriva o kpkg.toml de [identity]+[hub], empacota e publica no Koder Hub (/design-systems/{slug}). Publicar é o handoff pro pipeline de empacotamento (design-gen #228), não uma reimplementação dele.

Scenario: publicar um DS autorado

• GIVEN um DS exportado com [hub] válido e conformance verde
• WHEN o usuário clica "Publicar no Hub"
• THEN o Studio invoca kpkg build --type design-system e o DS aparece em hub.koder.dev/design-systems/{slug}.

3. Fora de escopo (excluído limpo)

• ❌ Geração de DS por prompt de IA (o design-RFC-014 é explícito: sem LLM; determinístico). Um caminho assistido-por-IA seria RFC futura, não este spec.
• ❌ Autoria de componentes novos (o Studio compõe do corpus existente; criar um componente novo é trabalho de spec/código, não do Studio).
• ❌ Conta de servidor / marketplace social (herança do theme-builder R10; o Hub é o canal de publicação, não um feed social).
• ❌ Reimplementar o empacotamento kpkg ou o motor de cor — ambos são reusados (design-gen #228 e o Themer, respectivamente).

4. Cross-link

• tools/theme-builder.kmd — o motor de cor reusado (seed→18-role, override, CVD, export).
• design-system/manifest.kmd — o contrato do artefato de saída (koder.designsystem.toml).
• kpkg/format.kmd §11 — o tipo de pacote design-system (o alvo do publish, R8).
• themes/color-dynamic.kmd / themes/color-roles.kmd — o algoritmo/taxonomia de cor.
• design-RFC-014 — o framework (F3 = este spec; F4 = publish; F5 = catálogo).

5. Implementation tracking

Evolução multi-dia do /themer/ → /studio/ (design-gen internal/kinds/tools_themer.go → módulo de studio). Rastreada em design-gen #229.