Migração

1.0.0 → 1.1.0: slash-landing passa a se chamar slash-kit

O kit mudou de nome. O comando continua slash, e o CLI, a API e os módulos não mudam. O template landing, os caminhos criar/landing/ e a expressão “landing page” também ficam como estão.

Projetos já criados seguem funcionando. Um projeto gerado antes da 1.1.0 mantém os textos antigos, com o nome slash-landing. Não há comando de migração e não é preciso refazer nada.
Projetos criados depois trazem o nome novo nos textos gerados.
Religue o comando. Se você usa o slash por um checkout com bun link, apague o link global antigo com rm ~/.bun/install/global/node_modules/slash-landing e rode bun link na raiz do checkout do slash-kit.
Implantação. Os exemplos de implantação usam /opt/slash-kit. Quem tem o kit em outro caminho na VPS só troca o caminho nos comandos.

0.x → 1.0.0

A 1.0.0 é a versão em que o blog roda com o painel em produção: banco SQLite, login real, publicação do site, mídia em disco, e-mail pelo Resend, backup e implantação com Caddy e systemd. Quase tudo o que muda para um projeto antigo vem daí.

Não há comando nem arquivo de migração. Esta página lista as mudanças que o código da tag v1.0.0 traz em relação à v0.11.0, a última 0.x com blog. Ela não é um roteiro de atualização.

O que muda

Comandos novos no CLI. slash module list e slash module add, slash backup e slash admin create passaram a existir. Os quatro só atuam em projetos blog que tenham o arquivo slash.lock. Projetos criados na v0.11.0 ou depois têm esse arquivo. Em projetos mais antigos, confira se ele existe. Sem ele, o comando recusa com a mensagem: Esta pasta não é um projeto blog do slash.
O painel deixa de ser só de memória. Na v0.11.0, todas as telas do painel usavam portas em memória. Os dados de um projeto antigo ficavam no processo e não havia banco para migrar. Na 1.0.0, os dados vão para o SQLite, em storage/db.sqlite.
Modo de produção no servidor do blog. O src/server.ts do blog ganha a subida de produção. Com NODE_ENV=production, o servidor confere as variáveis da página Variáveis de produção antes de subir.
Script start novo. O start do blog passa a ser NODE_ENV=production bun src/server.ts. Na v0.11.0 era bun src/server.ts.
Ignorado pelo git. A pasta storage/ entra no .gitignore do projeto. Ela guarda o banco, os backups e a mídia, e não deve ir para o repositório.
README do blog. O projeto novo traz um README com a operação do blog: instalação na VPS, backup e mídia. O arquivo não é copiado para projetos que já existem.
Compatibilidade dos módulos. Os módulos oficiais declaram core: ^1.0.0, e o slash module add confere esse intervalo com a versão do núcleo do projeto. Essa versão é 1.0.0 nas duas tags, então os módulos oficiais se encaixam nos projetos de v0.11.0.
slash verify. O comando mudou por dentro. slash check e slash approve não mudaram.

Os templates landing-page, one-page e multi-page não mudaram. A diferença de template está só no blog.

O que a tag não traz

Não há comando de atualização. Os comandos do CLI são create, check, approve, verify, module, backup e admin. O subcomando de module só tem list e add.
Não há arquivo de migração nem roteiro no repositório.
A tela Backup do painel só restaura um backup da mesma tag instalada. Um backup de outra tag é recusado.
Com o slash.lock do projeto, a restauração recusa um backup de versão mais nova que a instalada. Um backup de versão mais antiga é aceito pelo slash backup --restore, que prepara o banco depois de restaurar. Por isso, um backup antigo pode ser restaurado pela linha de comando, mas não pela tela.

Antes de substituir src/server.ts ou o script start de um projeto antigo, compare os arquivos com os da 1.0.0. Isso é um cuidado, não um procedimento: a tag não descreve essa troca.