# Addendum — Pivot de Requisitos (confirmado com AMIMAK)

> Este documento substitui, nos pontos abaixo, as decisões D1–D3 do
> `01-DECISOES-E-AMBIGUIDADES.md` original. Mantém-se o resto (D4–D9) tal
> como estava.

## Contexto real (esclarecido pelo cliente)

- A **AMIMAK SA.** é uma imobiliária: tem imóveis próprios e também gere
  imóveis em nome de terceiros (ex: um proprietário contrata a AMIMAK para
  gerir/manter o seu imóvel).
- Os imóveis estão alocados a **inquilinos/ocupantes** — empresas ou
  pessoas singulares.
- A manutenção é feita por uma **equipa interna** da AMIMAK (não
  prestadores externos como caso principal — só excepcionalmente, ex:
  elevadores).
- Pedidos de manutenção podem ser abertos **pelo cliente (inquilino)** via
  portal, ou **pela própria AMIMAK** internamente.
- **Sem módulo de chat/comunicação tipo WhatsApp** — o workflow de estados
  + notificações (email/push) é suficiente.
- **Sem isolamento multi-org partilhado**: cada instalação serve uma única
  empresa gestora (a AMIMAK, ou no futuro outra imobiliária que compre o
  produto) — mas cada venda futura é uma **instalação nova e independente**,
  não um tenant adicional na mesma base de dados.
- **White-label obrigatório**: nome da empresa, logótipo, moeda, cores —
  tudo configurável, nada hardcoded.

## R1. Multi-tenancy removida — passa a ser Single-Tenant + White-Label

**Decisão revista:** elimina-se `organizations` como tabela de isolamento
multi-tenant, `TenantScope`, `BelongsToOrganization` e o middleware
`SetCurrentOrganization`. Uma instalação = uma empresa gestora.

Em vez disso:

- `config/company.php` (+ tabela `settings` para o que for editável em
  runtime pelo Admin): nome da empresa, NUIT, logótipo, moeda por omissão,
  timezone, cabeçalho de numeração de documentos (`WO-{seq}`,
  `INV-{seq}`), etc. **Nunca strings da AMIMAK no código-fonte.**
- Isto elimina de uma vez toda a complexidade de scoping por
  `organization_id`, os testes de cross-tenant, e simplifica imenso o
  código — sem perder a possibilidade de vender a outra imobiliária,
  porque essa venda é sempre uma instalação nova (`git clone` + `.env`
  próprio + BD própria).

## R2. Nova entidade central: `Client`

Substitui o papel que antes seria "organização externa". Representa quem
ocupa/arrenda/possui um imóvel gerido pela empresa, sem ser da equipa
interna.

```
clients
- id
- type            EMPRESA | SINGULAR
- name            (nome da empresa OU nome da pessoa)
- tax_number       (NUIT ou BI/NUIT pessoal)
- email
- phone
- status           ACTIVE | INACTIVE
```

Um `Client` pode ter **múltiplos utilizadores de portal** (ex: uma empresa
inquilina pode ter 2-3 pessoas com login), por isso existe `client_users`
tal como antes existia `organization_users` — mas agora só define quem tem
acesso ao portal daquele cliente, não isolamento de dados.

## R3. `users` — internos vs. portal

Um único model `User`, distinguido por:

- **Utilizador interno** (`client_id IS NULL`): equipa da AMIMAK — roles
  Admin, Property Manager, Maintenance Manager, Technician, Finance,
  Approver.
- **Utilizador de portal** (`client_id` preenchido): inquilino/ocupante —
  role `Requester` fixo, sem acesso a nada fora do que está ligado ao seu
  `client_id`.

A autorização de um utilizador de portal não passa por `organization_id`
(já não existe) — passa por: **este pedido/imóvel está ligado ao meu
`client_id` através de uma `property_relationship` activa?**

## R4. `property_relationships` passa a apontar para `Client`

```
property_relationships
- property_id
- client_id                  (em vez de organization_id)
- relationship_type          OWNER | TENANT | OCCUPANT | ...
- ...
```

Se o imóvel é próprio da AMIMAK, simplesmente **não existe** uma relação
`OWNER` externa — a ausência de relação `OWNER` significa "é da empresa
gestora". Se o imóvel é gerido em nome de terceiros, existe uma relação
`OWNER` apontando ao `Client` proprietário.

## R5. Técnicos internos por omissão

`technicians.service_provider_id` passa a **nullable**, e adiciona-se
`is_internal boolean default true`. O caso principal é técnico interno
ligado directamente a um `User` (`technicians.user_id`). `service_providers`
mantém-se no schema para o caso excepcional (elevadores, etc.) mas deixa
de ser o fluxo central.

## R6. Origem do pedido

`maintenance_requests.origin` passa a `CLIENT_PORTAL | INTERNAL | PREVENTIVE`
em vez de `MANUAL | PREVENTIVE | IOT`, reflectindo quem pode abrir um
pedido: o cliente via portal, ou a equipa AMIMAK internamente (ronda,
inspecção, etc.).

## Testes que mudam

`docs/06-ESTRATEGIA-TESTES.md` — os testes de "cross-tenant" tornam-se
testes de **"cross-client"**: um utilizador de portal do Cliente A nunca
pode ver/alterar pedidos ou imóveis ligados ao Cliente B, mesmo adivinhando
IDs. A equipa interna da AMIMAK continua a ver tudo (não há isolamento
entre a equipa interna e os dados — só entre clientes de portal).