Fronteiras e projeto gerado

Esta página tem duas partes. A primeira diz o que cada camada do repo pode importar, e quais testes impedem o contrário. A segunda diz o que o create copia para o projeto gerado e o que o slash.lock guarda. A visão geral das pastas está em Arquitetura.

Quem pode importar quem

As regras ficam em architecture.test.ts, na raiz do repo (architecture.test.ts:6). Elas rodam em todo bun test; o comentário do arquivo diz que levam menos de um segundo. As linhas sem prefixo desta página são do slash-kit na tag v1.1.0.

Camada	Pode importar	Não pode importar
ui/	Tudo, menos o que a coluna seguinte lista	cli/, templates/, panel/, modules/ e o slash-ssg (architecture.test.ts:23, :104-113)
ui/sections/, ui/document/, ui/core/	Tudo, menos o que a coluna seguinte lista	ui/panel/ (architecture.test.ts:167, :170-180)
ui/ (código de produção)	Tudo em ui/, exceto a galeria	ui/gallery/ e os *.gallery.ts, nem direto nem por imports transitivos. Só a galeria, os *.gallery.ts e os testes podem importá-la (architecture.test.ts:209-248)
panel/	Tudo, menos o que a coluna seguinte lista	modules/, porque os módulos entram pelo contrato e pelas portas (architecture.test.ts:159-166)
Driver de banco (bun:sqlite, pg, o SQL do Bun)	Só em panel/adapters/sql/ e em tests/*sqlite*.test.ts	Qualquer outro arquivo (architecture.test.ts:1070-1091)
modules/<id>/	panel/contract/, ui/ e a própria pasta	Outro módulo e o resto de panel/. Os testes do módulo também podem usar panel/testing/ e panel/adapters/memory/ (architecture.test.ts:183-207)
modules/ (arquivos soltos)	Só modules/catalog.ts, que não importa nenhum modules/<id>	Qualquer outro arquivo solto em modules/ (architecture.test.ts:184-185, :187-197)
templates/blog/files/	ui/, panel/ports/content-source e o próprio template	O resto de panel/, cli/ e outro template. A raiz de composição (src/server.ts e o teste dele) pode importar as cópias de panel/ e modules/ (architecture.test.ts:134-158)

Outras regras do mesmo arquivo cuidam do estilo e da segurança:

• Cor literal só em ui/theme/base.ts (architecture.test.ts:355). Os demais arquivos usam var(--…).
• Largura fixa (px, rem e similares) é proibida em width, min-width, max-width, inline-size, flex-basis e na base de flex, fora de ui/grid/ e de ui/core/media.module.css (architecture.test.ts:327-330, :1365).
• unsafeHtml só no arquivo listado em UNSAFE_HTML_ALLOWED, hoje ui/document/gtm.ts (architecture.test.ts:491).
• @keyframes não aparece em CSS Module (architecture.test.ts:2049).
• Testes seguem o padrão AAA, com // Arrange, // Act e // Assert (architecture.test.ts:2130).
• Typecheck cobre panel/ e modules/ (architecture.test.ts:2289).

O que o create copia

O comando slash create (cli/commands/create.ts) monta o projeto nesta ordem:

1. Base. Clona o slash-ssg no tag v0.0.6 (cli/config.ts:2), pelo endereço SSH de cli/config.ts:1. Se o clone falha, tenta uma constante fixa do código (cli/config.ts:4), que só existe na máquina de quem mantém o slash-kit. Para os demais, o clone precisa de rede e de chave SSH; veja Instalação (create.ts:124-137). A pasta .git do clone é removida (create.ts:238).
2. Camadas. Aplica as camadas do template, e do modelo se houver. Cada camada remove os caminhos da base listados em manifest.remove (cli/overlay.ts:160-161), copia files/, ajusta package.json e .gitignore e acrescenta às listas de src/architecture.test.ts (cli/overlay.ts:159-175).
3. ui/. Copia ui/ para src/ui/, sem testes, galerias (gallery/, *.gallery.ts, *.gallery.module.css), nem __fixtures__, nem *.module.css.d.ts (create.ts:20-21, :24-29, :240-241). Grava src/ui/VERSION, com a tag e o commit do checkout (create.ts:30).
4. Fontes. Copia só os .woff2 e o OFL.txt de ui/theme/fonts/ para public/fonts/ (create.ts:140-145, :242).
5. Painel e módulos. Só no template blog: copia panel/ para src/panel/ com os testes (create.ts:208), instala os módulos em src/modules/<id>/ e gera o src/modules/index.ts (cli/install.ts:42-66, create.ts:209). Sem --modules, entram todos os módulos do catálogo (create.ts:295, "all"). Grava o slash.lock (create.ts:210) e o modelo inicial no content/snapshot.json (create.ts:222-227, :245). Grava também a pasta deploy/ com três exemplos: um bloco do Caddy, uma unit do systemd e um arquivo de ambiente (create.ts:246; cli/deploy.ts:24, :91). Os arquivos são exemplos: o operador os copia para o servidor e preenche os valores. Veja VPS e variáveis.
6. Git. Roda bun install, git init -b main, core.hooksPath .githooks e o commit inicial (create.ts:248-252).
7. Repositório. Com --github, cria o repositório privado e envia o primeiro push sem os hooks (create.ts:176-199).

O create recusa a operação se as pastas de origem têm mudanças não commitadas: ui/ e templates/ em todo template, e panel/ e modules/ no blog. Sem isso, o VERSION não diria a verdade (create.ts:98-115). A tag gravada é a última tag do checkout (git describe --tags, create.ts:94-96), e o commit é o HEAD (create.ts:116-118).

O architecture.test.ts do projeto

O slash-ssg é o gerador de site estático sobre o qual todo projeto é montado: o create clona esse repositório no tag v0.0.6 e aplica por cima as camadas do template (cli/config.ts:2). As linhas marcadas ssg:N são do arquivo src/architecture.test.ts desse repositório, na tag v0.0.6, antes dos ajustes do template. Para ler o arquivo, dentro do repositório do slash-ssg, rode git show v0.0.6:src/architecture.test.ts. Esses números não batem com o src/architecture.test.ts do projeto gerado, que recebe linhas nas listas (cli/overlay.ts:99-110).

O projeto gerado não recebe o architecture.test.ts do repo. Ele recebe o do slash-ssg, no tag v0.0.6, com as listas do template preenchidas (cli/overlay.ts:9-15, :99-110, :150-153). As camadas são estas:

Camada	Pode importar (ssg:40-48)
atoms	components/atoms/ e SHARED
molecules	atoms, molecules e SHARED
organisms	atoms, molecules, organisms, islands e SHARED
templates	atoms, molecules, organisms, templates e SHARED
components	components, islands e SHARED
pages	components, pages, islands, src/data/ e SHARED
islands	components, islands e SHARED, sem valores de src/data/ (regra 4)

SHARED é a lista de pastas que qualquer camada pode importar (ssg:30-37). Cada template acrescenta a dele: o landing põe src/ui/, src/ui-host e src/theme (templates/landing-page/manifest.ts:92), e o blog põe src/ui/, src/panel/ e src/modules/ (templates/blog/manifest.ts:41). As camadas de atomic design são opcionais e valem quando a pasta existe (ssg:15). Um arquivo fora de todas as camadas, como os de src/panel/, não tem matriz (ssg:186-199).

Além da matriz, o teste do projeto confere:

• Valores de src/data/ só em pages, routes.ts, scripts e data (regra 2, ssg:603).
• pages não importam atoms nem molecules (regra 3, ssg:614).
• Cor literal só em src/tokens.module.css e nos temas (regra 5, ssg:640; COLOR_FILES em ssg:54).
• unsafeHtml só nos arquivos listados (regra 6, ssg:652).
• Nada de @ts-ignore, as any ou : any, e todo @ts-expect-error com justificativa (regra 7, ssg:663).
• Testes no padrão AAA (regra 8, ssg:674).
• Arquivos de dados registrados em allContent (regra 10, ssg:685).
• Nada de @keyframes em CSS Module (regra 9, ssg:700).

O teste do repo, que impede panel/ de importar modules/, não é copiado. Essa fronteira é verificada no repo do slash-kit, não no projeto gerado.

As listas de cada template

As listas se acumulam: cada camada acrescenta as suas e o blog herda as do landing. Os números são as linhas dos manifestos no repo do slash-kit.

Lista	Landing (templates/landing-page/manifest.ts)	Blog acrescenta (templates/blog/manifest.ts)
SHARED	src/ui/, src/ui-host, src/theme (:92)	src/panel/ e src/modules/ (:41)
COLOR_FILES	src/theme.ts, src/ui/theme/base.ts, src/ui/theme/theme.ts, src/ui/theme/contrast.ts (:94)	Nada (:42)
UNSAFE_HTML_ALLOWED	src/ui/document/gtm.ts (:95)	Nada (:43)
DATA_INFRA	src/data/origin.ts (:96)	Nada (:44)
LEGACY	src/site.ts (:98)	Nada

LEGACY isenta arquivos das regras de camada, dados, cor e AAA (ssg:12). A própria lista só pode diminuir (ssg:581).

O slash.lock

Só o template blog tem slash.lock (create.ts:210, dentro de copyPanelAndModules). Ele registra de onde vieram as pastas copiadas e a versão de cada módulo instalado (cli/lock.ts:9-13):

Campo	O que guarda
ui	tag e commit do checkout de onde ui/ foi copiada (cli/lock.ts:16-18)
panel	tag e commit de panel/. Na criação, são os mesmos de ui (cli/lock.ts:18)
modules.<id>	tag, commit e version de cada módulo instalado. A version vem do catálogo (cli/lock.ts:17)

As chaves são gravadas em ordem alfabética, então o mesmo lock sempre tem os mesmos bytes (cli/lock.ts:21-33).

Quem usa o arquivo:

• slash module list mostra os módulos instalados a partir de modules (cli/commands/module.ts:26-27). Os demais aparecem como disponíveis.
• slash module add confere o núcleo, copia o módulo e grava a entrada nova com o commit atual de modules/ (cli/commands/module.ts:125-137). Por isso, depois de um add, modules pode ter commit diferente de ui e panel.
• slash admin e slash backup só conferem que a pasta é um projeto blog (cli/commands/admin.ts:42, cli/commands/backup.ts:46).

Se o arquivo falta, não é JSON válido ou um campo tem outro tipo, o comando para com uma mensagem que diz o que corrigir (cli/lock.ts:50-78).