# Arquitetura da camada Web

## Princípio: isolamento em relação ao Quest

A camada Web foi introduzida de forma **isolada** e **compatível** com o projeto existente:

- **Nenhum ficheiro** em `Assets/Presentation/Quest/`, `Assets/Core/` (tipos Quest), nem em AppSession/SceneRouter foi alterado de forma destrutiva para esta etapa.
- A Web vive em **namespaces próprios** (`EventsAppQuest.Web.*`) e em pastas dedicadas (`Assets/Web/`).
- A comunicação futura Quest → Web será feita por **mapeamento conceptual** (ex.: preencher um `SessionRecord` a partir de um payload exportado pela Quest), sem acoplar a lógica Quest à Web.

## Estrutura de pastas

```
Assets/Web/
├── Core/           # Enums e tipos base da web (LeadStatus, OpportunityStage, etc.)
├── Domain/         # Modelos de domínio web (WebLead, SalesOpportunity, ProposalRecord, SessionRecord, FollowUpTask)
├── Application/    # Serviços e repositórios mock (sem backend real)
└── Presentation/   # Views, dashboard, controladores de UI web
```

- **Core**: enums e eventualmente DTOs ou contratos partilhados só pela Web.
- **Domain**: entidades da web (CRM, pipeline, sessão). `SessionRecord` inclui campos que espelham conceptualmente o resultado de uma sessão Quest.
- **Application**: interfaces de repositório/serviço e implementações mock (listas em memória).
- **Presentation**: cena(s) e componentes de UI (WebDashboard, listas, vistas mock).

## Dependências

- A Web pode referenciar **apenas** o que for estritamente necessário do projeto (ex.: Unity, eventualmente nomes de cenas para navegação). Não referencia tipos internos da Quest (ex.: `QuestPresentationSession`, `QuestCommercialOutcome`) para evitar acoplamento.
- O **mapeamento** de resultado Quest → SessionRecord será feito, quando existir, numa camada de aplicação (ex.: serviço que recebe um DTO ou payload e preenche SessionRecord), sem o Quest depender da Web.

## Fluxo de dados (futuro)

1. **Quest**: sessão termina; gera export payload / handoff (já existente).
2. **Ponte** (não implementada nesta etapa): um serviço ou fluxo recebe o payload e cria/actualiza um `SessionRecord` na Web (por API, fila, ou chamada interna).
3. **Web**: o comercial vê sessões, oportunidades, leads e follow-ups; os dados de SessionRecord (SessionId, RecommendedProposalId, FinalDecisionState, SuggestedNextAction, FollowUpPriority, etc.) vêm do passo 2.

Na etapa 64, o passo 2 não existe; os SessionRecords são apenas **mock** com valores de exemplo.

## Cenas e navegação

- A camada Web pode ter uma cena própria (ex.: `WebDashboard`) ou uma vista inicial integrada numa cena existente, sem alterar o fluxo Bootstrap → Main → QuestPresentation.
- A entrada na Web (botão "Abrir Web" ou similar) pode ser opcional na Main; o fluxo Quest continua a funcionar independentemente.
