Estrutura do projeto

Instalação e configuração

Antes de qualquer etapa, leia Antes de começar e Fundamentos do terminal. Abra a pasta supastack na raiz — a pasta que contém o package.json. Um checkout Mobile contém apps/mobile mais os pacotes compartilhados abaixo; o monorepo All Platforms adiciona o backend Web e o shell Desktop. Uma variável de ambiente é uma configuração nomeada armazenada num arquivo .env local ou no seu painel de hospedagem; reinicie o aplicativo após alterá-la e mantenha segredos de servidor fora dos valores EXPO_PUBLIC_.

1. Abra apps/mobile/app/_layout.tsx no editor — o layout raiz que toda tela compartilha.

2. Navegue por apps/mobile/src/ — uma pasta por área de recurso, cada uma contendo sua lógica e seus testes.

3. A partir da raiz do repositório execute corepack pnpm --filter @supastack/mobile start e abra a pré-visualização no seu dispositivo.

O aplicativo Expo é organizado como rotas que chamam módulos de recursos. As rotas ficam finas — elas renderizam telas; a lógica que chamam vive sob src/ com seus testes ao lado. Leia AGENTS.md e .ai/PROJECT_CONTEXT.md antes de mudar o comportamento; os documentos espelho .ai/ registram decisões que não são visíveis a partir de um arquivo sozinho.

apps/mobile/app/          Expo Router routes — sign-in, onboarding, invite, paywall
apps/mobile/app/(app)/    Signed-in screens — home, chat, notifications, settings, content, commerce, assistant
apps/mobile/src/          Feature modules — auth, api, purchases, offline, push, ui, theme, i18n
packages/ui-native/       Shared native view-models
packages/design-tokens/   Shared theme tokens
apps/mobile/app.config.ts Scheme and allowed-origin derivation
apps/mobile/eas.json      EAS build and submit profiles
docs/                     Runbooks incl. store submission
.agents/skills/           Task guides for coding agents

Onde cada alteração pertence

Antes de editar, decida qual pasta é dona da mudança. A regra prática: um arquivo de rota apenas renderiza; lógica reutilizável vive num módulo src/; qualquer coisa que o servidor deva decidir nunca entra no aplicativo.

• Construa seu primeiro recurso móvel

• Uma nova tela com login → apps/mobile/app/(app)/ para a rota mais apps/mobile/src/<feature>/ para sua lógica.
• Uma nova tela pré-autenticação ou independente → apps/mobile/app/ fora do grupo (app).
• Uma chamada ao backend → apps/mobile/src/api/client.ts — estenda o cliente tipado em vez de fazer fetch ad hoc.
• Um visual compartilhado entre telas → primitives de apps/mobile/src/ui/; um view-model multiplataforma → packages/ui-native/.
• Cores, espaçamento e valores escuro/claro → apps/mobile/src/theme/ apoiado por packages/design-tokens/.
• Uma nova chave de tradução → os quatro catálogos sob apps/mobile/src/i18n/.
• Qualquer coisa do lado do servidor — dados, permissões, chamadas de provedores → o repositório do backend Web, que é um checkout separado para compras somente Mobile.

Fluxo de implementação

Comece no arquivo de rota, siga o módulo de recurso que ele renderiza, depois a chamada do cliente API — o servidor decide a propriedade; o aplicativo nunca a re-deriva. O skill add-a-mobile-screen em .agents/skills/ percorre esta mesma ordem.

Execute os testes do pacote e a verificação de tipos depois de editar um pacote compartilhado ou o cliente API; o cliente deve manter o mesmo contrato que o backend atende.

Verificação e resolução de problemas

Se expo start relatar um módulo faltante, execute o comando de instalação a partir da raiz do repositório — a pasta do aplicativo sozinha não consegue resolver pacotes do workspace. Se uma tela aparecer sem estilo, verifique se ela compõe primitives de src/ui em vez de elementos brutos com cores embutidas no código.

corepack pnpm --filter @supastack/mobile test
corepack pnpm --filter @supastack/mobile typecheck