Pular para o conteúdo principal

Status: Approved · v2 · SPEC-DOMAIN-TERRITORY-001

depends_on: SPEC-DOMAIN-BASE-001

used_by: IS-MVP-02.2, IS-MVP-03.3, IS-MVP-04.1

Território e vocabulário regional

Hierarquia territorial oficial e adaptação de termos sem fragmentar o modelo técnico.

Objetivo e limites

Esta especificação define o comportamento canônico do domínio Território e vocabulário regional no RaizFC. Ela deve ser consultada antes de alterar contratos, mocks, endpoints, telas, permissões ou Increment Specifications relacionados.

Incluído no MVP

  • Hierarquia Estado → Município → Distrito → Bairro/Quebrada.
  • Distrito obrigatório para usuários e entidades.
  • Neighborhood opcional e subordinado ao distrito.
  • Vocabulário regional resolvido por prioridade.
  • Páginas públicas agregadoras de distrito e bairro.

Fora do MVP

  • Geofencing.
  • Mapas e raio por coordenadas.
  • Gestão autônoma de bairro.
  • Carteira e patrocínio de bairro.

Atores e responsabilidades

AtorResponsabilidade
UsuárioEscolhe distrito e opcionalmente bairro/quebrada.
GestorDefine território das entidades que cria.
OperaçãoMantém cadastros oficiais e resolve duplicidades.
VisitanteDescobre entidades e rankings por território.

Conceitos canônicos

District

Base oficial do produto; exemplo São Mateus.

Neighborhood

Bairro, quebrada ou comunidade conforme UI regional.

Vocabulary Profile

Conjunto de labels aplicável por usuário, distrito, município, estado ou padrão.

Territory Reference

Resumo com state, city, district e neighborhood usado em DTOs públicos.

Invariantes

  • Todo usuário ativo possui districtId.
  • Toda entidade pública do MVP possui districtId.
  • Neighborhood sempre pertence a exatamente um distrito.
  • Time só pode se associar a neighborhoods do próprio distrito.
  • Vocabulário altera labels, nunca IDs ou entidades técnicas.
  • Neighborhood não possui gestores, carteira nem patrocinadores no MVP.

Estados

EstadoSignificadoVisibilidade/efeito
activeTerritório utilizávelAparece em seleção e busca.
inactiveNão aceita novas associaçõesHistórico continua visível.
mergedDuplicado incorporado a outroRotas redirecionam para destino.

Transições permitidas

OrigemAçãoDestinoAutoridadeEfeitos
activedeactivateinactiveOperaçãoImpede novos vínculos.
active/inactivemergemergedOperaçãoReatribui referências e mantém alias.

Permissões

Permission keyQuem recebe por padrãoAção protegidaAuditoria
territory.readPúblicoListar e descobrirNão
territory.manageCatalogOperaçãoCriar/editar/mesclar territóriosSim

Fluxos funcionais

Seleção de distrito

  1. Cliente lista estados e municípios.
  2. Usuário busca ou navega até distrito.
  3. Backend valida distrito ativo.
  4. Preferências e entidades usam o ID canônico.

Resolução de vocabulário

  1. Cliente informa contexto autenticado ou localização da página.
  2. Servidor resolve override do usuário.
  3. Se ausente, aplica distrito, município, estado e padrão nessa ordem.
  4. Retorna labels como Bairro, Quebrada ou Comunidade sem mudar Neighborhood.

Criação de neighborhood

  1. Operação ou fluxo moderado propõe nome dentro de distrito.
  2. Sistema normaliza slug e detecta similaridade.
  3. Se aprovado, cria página agregadora pública.

Casos-limite e erros

CenárioComportamento esperadoCódigo/estado
Neighborhood de outro distrito em timeRejeitar atualizaçãoNEIGHBORHOOD_DISTRICT_MISMATCH
Distrito inativoImpedir novas associaçõesDISTRICT_INACTIVE
Território duplicadoRedirecionar e usar ID canônicoTERRITORY_MERGED
Vocabulário ausenteUsar labels padrão

Privacidade e exposição pública

  • Distrito é público em perfis e entidades conforme regras do domínio.
  • Endereço detalhado é opcional e possui visibilidade própria.
  • Neighborhood não deve inferir endereço exato de usuário.

Notificações e auditoria

  • Mesclagem territorial pode gerar aviso a gestores afetados.
  • Mudança de distrito de entidade crítica deve entrar em audit log.

API relacionada

MétodoRotaAcessoFinalidade
GET/api/v1/territory/statesPúblicoListar estados
GET/api/v1/territory/citiesPúblicoListar municípios
GET/api/v1/territory/districtsPúblicoListar/buscar distritos
GET/api/v1/territory/neighborhoodsPúblicoListar bairros/quebradas
GET/api/v1/territory/vocabulary/resolvePúblico/opcionalResolver labels
GET/api/v1/districts/:slugPúblicoPágina/dados de distrito
GET/api/v1/neighborhoods/:slugPúblicoPágina/dados de bairro

Contratos compartilhados

  • StateDto
  • CityDto
  • DistrictDto
  • NeighborhoodDto
  • TerritoryReferenceDto
  • VocabularyDto
  • ResolveVocabularyResponse

Requisitos de UX

  • Seletores suportam busca textual.
  • UI exibe label regional, mas rotas e código mantêm district/neighborhood.
  • Páginas territoriais destacam times, jogos, campeonatos, torcidas, ranking e serviços locais.
  • Mudança de distrito em entidade existente exige confirmação por impacto.

Comportamento dos mocks

  • Seed principal em São Paulo → São Paulo → São Mateus, com neighborhoods previsíveis.
  • Cenário de território inativo e merged.
  • Vocabulary scenario com label Quebrada.

Critérios de aceite

  • Distrito obrigatório em onboarding e criação de entidades.
  • Neighborhood incompatível é rejeitado.
  • Vocabulário regional não altera contratos.
  • Páginas territoriais funcionam sem login.

Testes obrigatórios

  • Hierarquia e filtros.
  • Validação de mesmo distrito.
  • Resolução de vocabulário por prioridade.
  • Redirecionamento de merged.

Pós-MVP

  • Busca por raio.
  • Mapas.
  • Sugestão por GPS.
  • Governança comunitária avançada.

Decisões registradas

  • Antigo conceito de comunidade/quebrada é Neighborhood.
  • Distrito é a base oficial e obrigatória.
  • Neighborhood não é entidade gerenciável no MVP.

Machine summary

spec: SPEC-DOMAIN-TERRITORY-001
domain: Território e vocabulário regional
must_preserve:
- Todo usuário ativo possui districtId.
- Toda entidade pública do MVP possui districtId.
- Neighborhood sempre pertence a exatamente um distrito.
- Time só pode se associar a neighborhoods do próprio distrito.
- Vocabulário altera labels, nunca IDs ou entidades técnicas.
- Neighborhood não possui gestores, carteira nem patrocinadores no MVP.
touches:
- contracts
- mocks
- api
- frontend
- backend
- tests
- documentation