docs: README e CHANGELOG cobrindo vínculo por Entidade (1.4.0) + link da doc de API

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CHANGELOG.md

@@ -4,6 +4,16 @@ Todas as mudanças relevantes deste plugin são documentadas aqui.
 O formato segue [Keep a Changelog](https://keepachangelog.com/pt-BR/1.0.0/)
 e o versionamento segue [SemVer](https://semver.org/lang/pt-BR/).
 
+## [1.4.0]
+
+### Adicionado
+- Vínculo **Entidade GLPI → Projeto Redmine** (1:1, match exato, sem herança de árvore), via aba Redmine em Administração → Entidades — para clientes de suporte recorrente cujos chamados nascem na entidade, sem projeto.
+- Documentação de API para desenvolvedores (`docs/API.md`).
+
+### Alterado
+- Resolução do projeto Redmine no hook passa a considerar, além do projeto vinculado, a **entidade** do chamado como fallback.
+- Templates do tab generalizados (`owner_field`/`owner_id`) para reuso entre Projeto e Entidade.
+
 ## [1.3.0]
 
 ### Adicionado

README.md

@@ -13,7 +13,8 @@ Equipes que **executam o atendimento no GLPI** mas **gerenciam projetos e horas
 ## Como funciona
 
 ```
-Projeto GLPI ───(vínculo manual na aba "Redmine")──▶ Projeto Redmine
+Projeto GLPI  ──(vínculo na aba "Redmine")──▶ Projeto Redmine   ┐
+Entidade GLPI ──(vínculo na aba "Redmine")──▶ Projeto Redmine   ┘ (1:1)
 
 Chamado GLPI ──────────────────────────────────────▶ 1 ISSUE no Redmine
   • título   = título do chamado
@@ -27,6 +28,7 @@ TicketTask "Feito" ────────────────────
   • comentário = descrição da tarefa
 ```
 
+- **Dois pontos de vínculo**: o chamado é direcionado ao projeto Redmine pelo **Projeto** GLPI ao qual está ligado **ou**, na ausência de projeto, pela **Entidade** do chamado (clientes de suporte recorrente). Sem vínculo (projeto nem entidade), nada é enviado.
 - **Uma issue por chamado**: o chamado nasce e "morre" no GLPI; para o Redmine importam as **horas** e o **andamento**.
 - **Tempo só sobe quando a tarefa é concluída** (`Feito`): enquanto não concluída, fica apenas no GLPI.
 - **Autores corretos**: a issue é criada como o **técnico atribuído** e cada lançamento de tempo como o **técnico que o registrou**, usando *impersonation* do Redmine — não tudo como "admin".
@@ -34,6 +36,7 @@ TicketTask "Feito" ────────────────────
 ## Funcionalidades
 
 - ✅ Vínculo de Projeto GLPI ↔ Projeto Redmine (criar novo ou vincular existente), com módulos, subprojeto e visibilidade.
+- ✅ Vínculo de **Entidade GLPI ↔ Projeto Redmine** (1:1) — para clientes de suporte recorrente que abrem chamados sem projeto.
 - ✅ Criação automática de **issues** a partir dos chamados, com valores padrão (tracker, prioridade, atividade) e **categoria por projeto**.
 - ✅ Lançamento automático de **tempo** das tarefas concluídas (idempotente — sem duplicar).
 - ✅ **Mapa de status** Chamado GLPI → Status Redmine, totalmente configurável.
@@ -67,20 +70,34 @@ Acesse **Configurar → Plugins → Redmine Integration**:
 4. **Mapa de status** — para cada status de chamado do GLPI, escolha o status correspondente no Redmine.
 5. **Mapeamento de usuários** — usuários com o **mesmo e-mail** nos dois sistemas são associados automaticamente; cadastre *overrides* apenas para as exceções.
 
-Depois, em cada **Projeto** do GLPI, abra a aba **Redmine** para vincular ao projeto correspondente no Redmine e definir a **categoria padrão**.
+Depois, defina os vínculos nas abas **Redmine**:
+- Em cada **Projeto** do GLPI (`Ferramentas → Projetos`): aba **Redmine** → vincular/criar o projeto Redmine + **categoria padrão**.
+- Em cada **Entidade** de cliente recorrente (`Administração → Entidades`): aba **Redmine** → vincular/criar o projeto Redmine (1:1) + **categoria padrão**.
 
 ## Fluxo de uso
 
+**Cenário A — Projetos**
 1. Vincule o Projeto GLPI ao Projeto Redmine (aba Redmine do projeto).
 2. A partir de uma **tarefa de projeto**, crie um **chamado** ("Criar chamado a partir desta tarefa de projeto").
 3. No chamado, o técnico registra **tarefas (TicketTask)** e o tempo gasto.
 4. Ao marcar a tarefa como **Feito**, o plugin cria/atualiza a issue no Redmine e lança o tempo — com o autor correto.
 
+**Cenário B — Clientes de suporte recorrente (Entidade)**
+1. Vincule a **Entidade** do cliente ao Projeto Redmine (aba Redmine da entidade).
+2. O cliente abre um **chamado** diretamente na sua entidade (sem projeto).
+3. O técnico registra **tarefas (TicketTask)** e o tempo gasto.
+4. Ao marcar a tarefa como **Feito**, o plugin resolve o projeto Redmine **pela entidade** e cria a issue + lança o tempo.
+
+## Documentação para desenvolvedores
+
+Contrato de API completo (o que sai do GLPI, como entra no Redmine — endpoints, payloads, cabeçalhos, mapeamento de campos, impersonation e exemplos): veja [`docs/API.md`](docs/API.md).
+
 ## Notas e limitações
 
 - O tempo de uma tarefa é lançado **uma única vez** (ao concluir). Edições posteriores de horas não re-sincronizam.
 - A *impersonation* exige que o usuário Redmine exista e seja **membro do projeto** — o plugin adiciona o técnico automaticamente; se não houver usuário correspondente, o lançamento usa o admin (com aviso em log).
-- Categorias do Redmine são **por projeto**: a categoria padrão é definida no vínculo de cada projeto.
+- Categorias do Redmine são **por projeto**: a categoria padrão é definida no vínculo de cada projeto/entidade.
+- O vínculo por **Entidade** é **1:1 e por correspondência exata** — não há herança pela árvore de entidades. O chamado precisa nascer na própria entidade vinculada.
 
 ## Suporte