> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Processo de Release

> Fluxo atual de release e verificação para contribuidores e mantenedores.

# Processo de Release

Esta página descreve o fluxo de release atual do repositório, não um pipeline idealizado de estado futuro.

## Modelo de entrega atual

* Pull requests são a unidade de entrega.
* O GitHub Actions é a fonte de verdade para as verificações do repositório.
* `apps/web`, `apps/app` e `apps/api` são implantados via Vercel na postura alpha atual.
* `apps/worker` é implantado por meio de um deployment no estilo Railway.
* Tags semver são usadas para releases deliberados.
* O `buildVersion` em runtime é distinto da versão de release semver.

## Verificações padrão atuais

O repositório valida:

* lint
* lint de docs
* higiene de docs
* desvio (drift) da especificação OpenAPI
* higiene de release
* build de docs
* typecheck
* testes
* build

Workflows adicionais de hardening, como revisão de dependências e CodeQL, existem, mas podem depender do plano/configuração do repositório.

## Política de trem de release

Até a fase alpha, o Switchbord usa **semver de trem de release**:

* patch para correções, correções de documentação e higiene de release
* minor para ondas coerentes de capacidade
* major apenas para a semântica estável de `1.0.0`

Não crie uma versão minor para cada PR. Uma versão deve explicar um estado coerente do repositório.

## Etapas obrigatórias de release

Para todo release deliberado:

1. Atualize o `package.json` para a versão pretendida.
2. Atualize o `CHANGELOG.md` com `## vX.Y.Z` e datas factuais respaldadas pelo git.
3. Atualize o MDX do changelog público na web, se o release for voltado ao cliente.
4. Atualize a documentação Mintlify para qualquer feature visível ao usuário ou mudança de comportamento operacional.
5. Execute:
   ```bash theme={null}
   pnpm release:hygiene
   pnpm lint
   pnpm --filter docs docs:hygiene
   pnpm typecheck
   pnpm test
   pnpm build
   ```
6. Faça o merge do PR de release.
7. Marque exatamente a mesma versão com tag:
   ```bash theme={null}
   pnpm release:tag
   pnpm release:tag:push
   ```
8. Confirme que o GitHub Release foi criado para a tag correspondente.

## Marcação retroativa de tags históricas

Versões históricas da fase alpha, antes desta política, não foram marcadas com tags de forma consistente. Não fabrique tags.

Se a marcação retroativa for necessária antes da fase alpha:

1. Identifique o commit exato que representava aquele estado de release.
2. Verifique o `package.json` e o `CHANGELOG.md` naquele commit.
3. Crie a tag histórica apenas se a evidência for inequívoca.
4. Prefira iniciar a correspondência estrita no próximo trem de release se o limite histórico não estiver claro.

## Orientação para contribuidores

* Não assuma que uma feature está pronta para release apenas porque ela builda localmente.
* Se sua mudança altera o comportamento em runtime, atualize tanto a documentação Mintlify quanto a documentação operacional do repositório que descreve o mesmo contrato.
* Se sua mudança afeta o estado público de marketing, atualize o changelog da web ou declare explicitamente por que não, no corpo do PR.
* Se uma data de changelog não for respaldada por `git log` ou `gh pr view`, não faça o commit dela.
* Se uma mudança exigir novos gates de CI, documente isso como um follow-up explícito em vez de sugerir que já existe.

## Hardening planejado

Estas são adições esperadas, mas devem ser descritas como planejadas até estarem ativas no CI:

* builds de container para runtimes de longa duração
* validação de migrações
* verificações de ambiente mais estritas
* política de promoção de ambiente de release

## Leia a seguir

* [Versionamento](/pt-BR/contributing/versioning)
* [CI/CD](/pt-BR/operations/cicd)
* [Fluxo de Contribuição](/pt-BR/contributing/workflow)