Visão de produto¶

Garantora substitui a fiança tradicional por uma garantia onerosa administrada por software: a garantidora (tenant) analisa o crédito e emite a garantia junto com a imobiliária parceira, cobra mensalmente — direto ou pela imobiliária, conforme a cláusula da parceria —, acerta o mês com cada parceira, e paga o sinistro quando o inquilino não paga o aluguel. Ver o glossário para os termos e o modelo de entidades, e as regras de negócio para o que o sistema faz hoje.

Estágio do produto — em produção, com cliente¶

Desde a spec 0028 o Garantora roda em https://app.garantora.com.br/ (ver ../architecture/deployment.md), e todo deploy publica uma versão com nota de novidades (spec 0043). Desde outubro de 2026 há cliente: a TXC Garantia opera na produção com usuários reais, tendo a imobiliária Solar Imóveis como parceira. É o contrato da TXC, em ../contratos/, que serviu de referência para o modelo de domínio; e é a planilha de cobrança e pagamento da Solar, em ../financeiro/, que as specs 0054 (o resumo do mês por tipo e canal) e 0055 (o acerto com a imobiliária) trouxeram para dentro do produto.

Isto muda o cálculo de risco. A ADR-0001 registrou que, sem base instalada, quebrar contrato de API e rodar migration destrutiva eram baratos. Com cliente, a premissa dela deixou de valer: migration precisa preservar o dado que está lá, e mudança de contrato passa a ser avaliada pelo efeito em quem usa. A ADR em si ainda não foi revista — a decisão formal que a substitui está a confirmar.

Onde está a distância entre negócio e código¶

O roadmap é o documento que registra essa distância — processo por processo, o que está implementado, parcial ou ausente, com arquivo:linha para conferir, e o plano de entregas por incremento. Esta página não repete o quadro dele, para não haver duas versões envelhecendo em ritmos diferentes.

Em uma frase, no momento desta revisão: o fechamento de parceria está coberto; o fechamento de garantia está coberto da análise de crédito até a cobrança mensal e o acerto com a imobiliária, faltando emissão de boleto e assinatura eletrônica; o sinistro não existe — é o maior vazio do produto e o que justifica a próxima etapa do roadmap.

Para o que já foi construído, a fonte precisa é ../specifications/index.md, cada spec com a jornada, as regras de negócio, os critérios de aceite e o registro do que divergiu na implementação. Para o que foi corrigido, ../fixes/index.md.

Como uma ideia de produto vira código¶

Desde 2026-10-15 o ciclo de trabalho é conduzido pelo plugin Superpowers; o que o repositório acrescenta é onde o trabalho fica registrado (spec e plano em docs/specifications/, defeito em docs/fixes/) e a régua da revisão (as rubricas de .claude/rubrics/). O deploy continua sendo o skill /ship.

flowchart LR
    A["Necessidade identificada"] -->|"brainstorming"| B["Specification\n(docs/specifications/NNNN/)"]
    B -->|"revisão pelas rubricas"| C{"Aprovada?"}
    C -->|"não"| B
    C -->|"sim"| P["writing-plans\n(plan.md)"]
    P --> E["apps/api"]
    E --> F["apps/web"]
    F --> G["apps/e2e"]
    G --> H["/ship\n(produção)"]

    I["Defeito observado"] -->|"systematic-debugging"| J["Fix\n(docs/fixes/)"]
    J --> L["teste vermelho → correção → verde"]
    L --> H

    M["Ajuste pequeno"] -->|"mudança direta"| N["verifica → commita"]
    N --> H

A ordem api → web → e2e reflete que o contrato desce da API — ver ../architecture/containers.md.