Adapta os exemplos do guia e dos fluxos para Angular + BaaS

.agents/workflows/architecture.md

@@ -9,8 +9,8 @@ Você é o entrevistador técnico. O aluno é o Arquiteto: **ele decide; você a
 ## Regras da conversa
 
 - **Uma decisão por vez**, com as opções que a disciplina permite e o custo de cada uma — mas quem escolhe é ele.
-- **Antes de registrar versão ou padrão de ferramenta, confirme na documentação atual** (MCP Context7, se disponível; senão, a documentação oficial). Sua memória de treino desatualiza — foi assim que se descobriu que os geradores atuais de Angular e NestJS entregam Vitest, não Jest. Versão registrada sem conferência é retrabalho no setup.
-- Detalhe de história (DTO específico, tela, máquina de estados) **não entra**: nasce na spec de cada história.
+- **Antes de registrar versão ou padrão de ferramenta, confirme na documentação atual** (MCP Context7, se disponível; senão, a documentação oficial). Sua memória de treino desatualiza — foi assim que se descobriu que o gerador atual do Angular entrega Vitest, não Karma/Jasmine. Versão registrada sem conferência é retrabalho no setup.
+- Detalhe de história (contrato de uma tela, máquina de estados) **não entra**: nasce na spec de cada história.
 - O documento e o futuro `package.json` contam a mesma história: dependência que não estiver aqui não entra no projeto.
 
 ## Passo 0 — Pré-condições
@@ -21,23 +21,23 @@ Você é o entrevistador técnico. O aluno é o Arquiteto: **ele decide; você a
 
 ## Passo 1 — As decisões, uma por vez
 
-1. **Frontend** — apresente as opções que as *Regras da disciplina* permitem. Registre a versão e grave no documento **só o bloco de padrões da stack escolhida**, partindo destes (o aluno ratifica ou ajusta):
+1. **Frontend** — a ficha fixa o framework; o que se decide aqui é a **linha da versão** (ex.: "Angular 20+") e os padrões de código. **Registre a linha, nunca o número exato** (`20.3.1` vive no `package.json` — versão em prosa envelhece em silêncio e o agente confia no texto). Grave no documento o bloco de padrões da stack, partindo destes (o aluno ratifica ou ajusta):
    - **Angular:** componentes standalone (padrão atual — não se escreve `standalone: true`), signals para estado, `@if`/`@for`/`@switch` (não `*ngIf`/`*ngFor`), `input()`/`output()` como funções, `inject()` (não injeção por construtor), lazy loading por rota de feature.
    - **React:** componentes de função com hooks (sem classes), estado do servidor separado do estado de UI, roteamento com lazy loading por rota, componentes de página distintos de componentes reutilizáveis.
    - **Vue:** Composition API com `<script setup>` (não Options API), `ref`/`computed` para estado, roteamento com lazy loading por rota, props e emits tipados.
 
    Independente da escolha, registre também a **regra da camada de dados**, que vale para as três: componente não fala com o servidor — todo acesso à API passa por uma camada de repositório/serviço; mudança de contrato mexe só nessa camada, nunca nas telas.
-2. **Backend e banco** — o que a ficha fixa, registre como está; o que ela deixa livre, decida aqui (versões, banco local via Docker, provedor do banco em nuvem — respeitando as recomendações e vetos da ficha).
+2. **Fonte de dados, por fase** — o que a ficha fixa, registre como está; o que ela deixa livre, decida aqui: onde vive o `db.json` do json-server no MVP, qual BaaS entra na E3 e como a troca é absorvida pelos Services.
 3. **Testes** — a ferramenta em cada app e os **comandos exatos** para rodar suíte e lint.
-4. **Estrutura do monorepo** — `apps/api`, `apps/web`, e a organização interna de cada um.
+4. **Estrutura do projeto** — a casca de monorepo `apps/web` (o app Angular) e `apps/api` (**vazia**, reservada para uma API real futura; o setup não gera nada nela), e a organização interna de `apps/web/src/app/`: `core/` (Services de dados, guards, interceptors), `shared/` (componentes burros, pipes) e `features/` (uma pasta por domínio), com a regra de dependência entre elas.
 5. **Glossário técnico** — termos do PRD (PT) → entidades (EN) com atributos principais. Dados e código em inglês, interface em português — meio a meio é o que produz `listaPedidos`.
 6. **Diagrama ER (Mermaid)** — as entidades e relações, incluindo as que o **escopo mínimo da ficha** exige.
 7. **Padrões estruturais cobrados pelos IDs** — percorra o `docs/checklist.md` e, para **cada ID que exige um padrão de código ou de infraestrutura** (camadas, validação de entrada, autenticação, formato de resposta e erro, segredos, integrações), declare o padrão explicitamente no documento. É esta declaração que os revisores vão usar como critério fixo.
-8. **O contrato da API é a documentação viva** — se a ficha exige documentação de API interativa (OpenAPI/Swagger), declare-a como o contrato: gerada do código e servida pela própria API, com o frontend derivando os contratos dela. O `architecture.md` **não mantém tabela de endpoints à mão** (apodreceria e viraria mentira), e o arquivo gerado (ex.: `swagger.json`) **não é commitado** — cópia no repo desatualiza; a fonte é o endpoint vivo.
+8. **O contrato dos dados** — declare onde ele mora: no MVP, a forma do `db.json` do json-server; na migração, o schema do BaaS. Este documento guarda o **modelo** (glossário e ER), não a lista de endpoints à mão — ela apodrece. Registre também que a troca de fonte de dados atinge **só os Services** (§ camada de dados).
 
 ## Passo 2 — A garantia do setup
 
-Antes de fechar, confira que o documento declara **explicitamente** as quatro coisas que o Passo 0 do `/utf-setup` exige: framework do backend, framework do frontend, estrutura de pastas do monorepo e como rodar os testes. O que estiver implícito, torne explícito agora — é mais barato do que o setup parar depois.
+Antes de fechar, confira que o documento declara **explicitamente** as quatro coisas que o Passo 0 do `/utf-setup` exige: framework do frontend (versão e padrões), a fonte de dados de cada fase, a estrutura de pastas do projeto e como rodar os testes. O que estiver implícito, torne explícito agora — é mais barato do que o setup parar depois.
 
 ## Passo 3 — Conferência e portão
 
@@ -48,5 +48,5 @@ Antes de fechar, confira que o documento declara **explicitamente** as quatro co
 
 - Escolher stack pelo aluno, ou aceitar dependência "porque a IA conhece".
 - Copiar regra de negócio do PRD para cá — aqui é o *onde mora*, não o *o quê*.
-- DTOs de endpoints específicos, rotas de tela, fluxos de uma história — isso é spec.
+- Contratos de telas específicas, fluxos de uma história — isso é spec.
 - Gerar código ou rodar o setup — o setup tem comando próprio.

.agents/workflows/setup.md

@@ -15,10 +15,10 @@ que foi decidida. O que não estiver escrito lá, você pergunta; não escolhe.
 ## Passo 0 — Pré-condições (PARE se qualquer uma falhar)
 
 1. `docs/prd.md` e `docs/architecture.md` existem e declaram: o framework do backend,
-   o framework do frontend, a estrutura de pastas do monorepo e como rodar os testes.
+   o framework do frontend, a fonte de dados, a estrutura de pastas e como rodar os testes.
    Se algum desses quatro estiver ausente ou ambíguo, **PARE** e diga o que falta —
    setup com stack adivinhada é retrabalho garantido.
-2. As pastas de app previstas no `architecture.md` (ex.: `apps/web`, `apps/api`)
+2. As pastas de app previstas no `architecture.md` (ex.: `apps/web`)
    **não existem** ou estão vazias. Se já existirem com conteúdo, **PARE**: o setup
    roda uma vez, e rodá-lo de novo por cima é destrutivo.
 3. Você está na `develop`, limpa e atualizada (se a `develop` ainda não existe, crie-a a partir da `main` e publique: `git switch -c develop && git push -u origin develop` — o Gitflow da ficha exige as duas).
@@ -35,12 +35,19 @@ git switch -c setup-projeto
 
 Nenhum arquivo é criado antes da branch existir. No Gitflow, `main` e `develop` são bloqueadas — a branch do setup nasce da `develop` e volta para ela por PR.
 
-## Passo 2 — Os apps, pelos geradores oficiais
+## Passo 2 — O app, pelo gerador oficial
 
-Gere cada app com o gerador oficial da stack declarada no `architecture.md`
-(ex.: `@nestjs/cli` para NestJS, `ng new` para Angular, `create-vite` para React/Vue),
+Gere o app com o gerador oficial da stack declarada no `architecture.md`
+(`ng new` para Angular, mais `ng add` para o que o documento declarar — PWA, framework CSS),
 dentro da estrutura de pastas que o documento descreve.
 
+- **A casca do monorepo é só estrutura.** Se o documento prevê `apps/web` e
+  `apps/api`, gere o app em `apps/web` e **crie `apps/api/` vazia**, com um
+  `README.md` de uma linha dizendo que ela está reservada para uma API própria,
+  se um dia existir. **Não gere backend nenhum** — nem scaffold, nem
+  `package.json`, nem dependência. Pasta reservada é lugar guardado; scaffold
+  morto é código que ninguém mantém e que o agente lê como se existisse.
+
 - **Antes de rodar, confirme na documentação atual** (MCP Context7, se
   disponível) a versão corrente de cada CLI e sua compatibilidade com o Node
   instalado — gerador desatualizado ou incompatível descoberto no meio do passo
@@ -57,8 +64,7 @@ dentro da estrutura de pastas que o documento descreve.
 1. `.gitignore` da raiz cobrindo `node_modules/`, artefatos de build (`dist/`,
    `build/`, `.angular/`, `coverage/`) e `.env` — **antes do primeiro
    `git add`**. Confira o que os geradores deixaram: com `--skip-git`, alguns
-   (ex.: NestJS) não criam `.gitignore` próprio — não é esquecimento, o da
-   raiz cobre todos os apps. Valide com `git status --short`: se aparecerem
+   não criam `.gitignore` próprio — não é esquecimento, o da raiz cobre o projeto. Valide com `git status --short`: se aparecerem
    milhares de arquivos, o ignore não cobriu algo. (A IDE mostrar uma
    avalanche de untracked **entre** a geração e este passo é normal — ela
    some aqui.)
@@ -71,9 +77,10 @@ dentro da estrutura de pastas que o documento descreve.
    Sem isso, um repositório tocado em Windows e Linux reescreve todos os arquivos a
    cada troca de máquina, e o diff de qualquer PR vira ruído.
 
-3. `package.json` com os scripts descritos no `architecture.md` (ex.: `start`,
-   `api`, `test`). Se o documento traz os scripts prontos, copie-os literalmente.
-   Dois casos desta disciplina:
+3. `package.json` da raiz com os scripts de orquestração descritos no
+   `architecture.md` (ex.: `start`, `api`, `test`) — é ele que poupa o aluno de
+   entrar em `apps/web` a cada comando. Se o documento traz os scripts prontos,
+   copie-os literalmente. Dois casos desta disciplina:
    - **json-server declarado para o MVP:** adicione a dependência, o script
      (`"api": "json-server db.json"` ou equivalente) e um `db.json` **vazio de
      negócio** (`{}`) — as entidades chegam pelas histórias, nunca pelo setup.

.cursor/commands/utf-setup.md

@@ -1,5 +1,5 @@
 ---
-description: Gera a estrutura inicial do monorepo a partir do docs/architecture.md. Roda uma vez, antes da primeira Issue. Task de manutenção — sem spec.
+description: Gera a estrutura inicial do projeto a partir do docs/architecture.md. Roda uma vez, antes da primeira Issue. Task de manutenção — sem spec.
 ---
 
 Leia `.agents/workflows/setup.md` e execute-o integralmente.

.opencode/command/utf-setup.md

@@ -1,5 +1,5 @@
 ---
-description: Gera a estrutura inicial do monorepo a partir do docs/architecture.md. Roda uma vez, antes da primeira Issue. Task de manutenção — sem spec.
+description: Gera a estrutura inicial do projeto a partir do docs/architecture.md. Roda uma vez, antes da primeira Issue. Task de manutenção — sem spec.
 ---
 
 Leia `.agents/workflows/setup.md` e execute-o integralmente.

docs/architecture.md

@@ -76,10 +76,19 @@
 ├── README.md              # a vitrine, na estrutura exigida pela ficha
 ├── docs/                  # prd.md, este arquivo, design-tokens.md, checklist.md e guias
 ├── specs/                 # uma pasta por história implementada
-└── src/                   # o app Angular ([preencher no /utf-setup])
+└── apps/
+    ├── web/               # o app Angular — package.json próprio
+    └── api/               # reservada para uma API real, se um dia existir
 ```
 
-### Organização interna do app (feature-driven)
+> 📌 **Por que `apps/` com duas pastas se só uma tem código.** Nesta disciplina os
+> dados vêm do json-server e depois do BaaS: não há backend para escrever. Mas a
+> casca do monorepo custa nada agora e evita mover o projeto inteiro no dia em que
+> uma API própria fizer sentido. **`apps/api/` nasce vazia, e continua vazia** — o
+> setup não gera backend nenhum; ela só guarda o lugar (e o `db.json` do
+> json-server, se o documento assim declarar).
+
+### Organização interna do app (`apps/web/src/app/` — feature-driven)
 
 [decidido na entrevista: `core/` (singletons: guards, interceptors, services de
 dados), `shared/` (componentes burros, pipes), `features/` (uma pasta por