diff --git a/scoreodonto/arquitetura.md b/scoreodonto/arquitetura.md
index e6f4553..79c792c 100644
--- a/scoreodonto/arquitetura.md
+++ b/scoreodonto/arquitetura.md
@@ -5,10 +5,12 @@ Este documento dita as regras exclusivas e as portas da arquitetura do **ScoreOd
 
 ## 🚀 Stack Tecnológica e Portas de Rede
 
-- **Frontend:** Next.js (React)
+- **Frontend:** React + Vite + TypeScript + Tailwind
   - Porta de Produção/Dev: `3013`
-- **Backend:** Node.js + Prisma ORM
+- **Backend:** Node.js + pg (Nativo)
   - Porta de Produção/Dev: `8018`
+  - > [!IMPORTANT]
+    > **NÃO UTILIZE ORM (Prisma/Sequelize)**. Toda a persistência deve ser feita via driver nativo `pg` para máxima performance e controle de queries.
 - **Banco de Dados (VPS 3):** PostgreSQL 18
   - Porta Padrão: `5432`
   - Banco de Dados Isolado: `scoreodonto`
@@ -19,44 +21,35 @@ Este documento dita as regras exclusivas e as portas da arquitetura do **ScoreOd
   - Domínio: `scoreodonto.com`
 
 ## 🔄 Fluxo de Deploy Contínuo e Versionamento (+1)
-O webhook do ScoreOdonto deve rodar de forma isolada do NewWhats.
+O webhook do ScoreOdonto roda de forma isolada na VPS 4.
 - **Webhook Listener Port (VPS 4):** `9002`
 - O webhook escuta na porta 9002 e dispara o script de build/deploy exclusivo (`deploy-prod-scoreodonto.sh`).
 
-### 📦 Regra Obrigatória de Incremento de Versão (Build Bump)
-Para garantir que o histórico de deploys (`deploys.json`) e o contador de builds (`version.json`) avancem automaticamente a cada alteração no sistema, os Agentes SRE DEVEM OBRIGATORIAMENTE garantir que:
+### 📦 Regra de Incremento de Versão (Host-Side Bump)
+Diferente do Clube67, o versionamento do ScoreOdonto ocorre no **Host (VPS 4)** antes do processo de rsync/build.
 
-1. O script `update-version.js` esteja configurado na raiz do projeto ScoreOdonto.
-2. No arquivo `frontend/package.json`, o comando de compilação DEVE ser estritamente configurado para rodar o versionador antes do build do framework:
-   ```json
-   "scripts": {
-     "build": "node ../update-version.js && next build"
-   }
-   ```
-> [!TIP]
-> Sem a chamada `node ../update-version.js` antes do comando de build, o sistema de versionamento não fará a contagem e a versão exibida na interface ficará congelada.
-
-### 🐳 Regra de Contexto Docker e Comportamento do Git
-Para que o Docker consiga executar o script `update-version.js` (que fica na raiz) durante a compilação do frontend, os Agentes DEVEM OBRIGATORIAMENTE seguir esta arquitetura de container:
-
-1. O **Build Context** no `docker-compose.yml` deve apontar para a raiz do projeto (`context: .`), e não apenas `./frontend`.
-2. O `Dockerfile` do frontend deve copiar a raiz para `/app/` e definir `WORKDIR /app/frontend`.
+1. O script `update-version.js` está localizado em `/home/deploy/stack/scoreodonto.com/update-version.js`.
+2. Este script é executado pelo pipeline de deploy (`deploy-prod-scoreodonto.sh`).
+3. O script incrementa o `version.json`, gera o `deploys.json` e realiza um commit automático no Git com a tag `[version-bump]`.
 
 > [!WARNING]
-> **COMPORTAMENTO DE VERSIONAMENTO EM CONTAINER**
-> Durante o `docker compose build`, o script `update-version.js` incrementa o contador e altera os arquivos estáticos **dentro do ambiente isolado do container**. Isso significa que a nova versão (ex: V1.0.4) aparecerá perfeitamente na interface web em produção.
-> 
-> Contudo, como a alteração ocorre dentro do container, os arquivos no repositório Git não são modificados. Para lançamentos de versões maiores fixadas (ex: `V1.1.0` ou `V2.0.0`), o desenvolvedor deve editar o arquivo base manualmente no VSCode e realizar o commit.
+> **NÃO ADICIONE O UPDATE-VERSION AO PACKAGE.JSON**
+> No ScoreOdonto, o arquivo `frontend/package.json` deve conter apenas `"build": "vite build"`. 
+> Adicionar `node ../update-version.js &&` ao script de build dentro do Docker fará com que a versão seja incrementada em um ambiente efêmero e não persista no Git, resultando em versões congeladas ou duplicadas na interface.
+
+### 🐳 Arquitetura de Container (Stateless Build)
+Como a versão já vem incrementada e persistida do Host via rsync, o Docker apenas compila o que recebe:
+
+1. O **Build Context** no `docker-compose.yml` aponta para a raiz do projeto (`context: .`).
+2. O `Dockerfile` do frontend realiza o `vite build` de forma limpa.
 
 ## 🤖 Fluxo de Auto-Cura (Self-Healing) com Grafana/Gitea
-Para automatizar a geração de Issues no repositório `ruicesar/scoreodonto.com` quando ocorrerem falhas em produção (VPS 1), os Agentes/Administradores devem configurar as regras no Grafana estritamente desta forma:
+Para automatizar a geração de Issues no repositório `ruicesar/scoreodonto.com` quando ocorrerem falhas em produção (VPS 1):
 
-1. Acesse o **Grafana** (Painel Central).
-2. Vá em **Alerting** -> **Alert rules** e crie uma nova regra de alerta (ex: `sum(rate({container="scoreodontocom-scoreodonto-backend-1"} |= "error" [5m])) > 0`).
-3. Na seção de **Labels (Custom Labels)**, é OBRIGATÓRIO adicionar:
-   * **Chave:** `repo`
-   * **Valor:** `scoreodonto.com`
-4. Na seção **Notifications**, garanta que o alerta está roteado para o Contact Point `Gitea-Bridge`.
+1. **Grafana (Painel Central):** Regras de alerta configuradas com a tag `repo="scoreodonto.com"`.
+2. **Gitea-Bridge (VPS 1):** Escuta na porta **9091** e faz o POST na API do Gitea.
 
 > [!IMPORTANT]
-> A tag `repo="scoreodonto.com"` é vital. A Gitea-Bridge multi-tenant na VPS 1 lerá essa tag dinamicamente e fará o POST na API do Gitea criando a Issue de Auto-Cura automaticamente no repositório correto. Sem essa tag, a bridge tentará abrir no repositório padrão.
+> **Diferenciação de Portas:**
+> *   **9002:** Webhook de Deploy (VPS 4).
+> *   **9091:** Bridge de Auto-Cura (VPS 1).