Capítulo 7.4 — Depreciação como disciplina

🎯 Objetivo

Mostrar que depreciação é engenharia, não uma flag no registry.

🧠 Fluxo recomendado de depreciação de tool

1. Marcar como deprecated no registry.
2. Registrar motivo e substituta.
3. Medir uso atual.
4. Avisar consumidores e owners.
5. Bloquear novos usos via policy/registry.
6. Manter compatibilidade temporária para consumidores existentes.
7. Criar testes de regressão da substituta.
8. Migrar consumidores gradualmente.
9. Remover após janela planejada.
10. Manter auditoria de uso histórico.

⚠️ Marcar metadata como deprecated não impede que um modelo tente chamar. O bloqueio real precisa estar no harness, executor, registry, policy engine ou camada de autorização.

🧠 Itens que exigem plano de depreciação

• Modelo.
• Prompt.
• Tool.
• MCP server.
• Schema de saída.
• Embedding model.
• Índice RAG.
• Agente.

📊 Tabela consolidada

Item	Estratégia de versionamento	Estratégia de depreciação
Prompt	prompt_name@major.minor	Janela com versão anterior; eval regression
Tool	Semver + registry	Deprecated -> read-only -> removida
MCP server	Semver + capabilities	Dual server por período
Schema	Semver + contract tests	Aceitar v1 e v2 temporariamente
Modelo	Alias controlado + versão fixa	Shadow eval antes da troca
Embeddings	Versão de modelo + índice	Índice paralelo e reembedding
Vector DB	Versão de índice + migração	Dual-write/dual-read
Policy	Bundle versionado	Janela curta com override controlado
Memória	Schema + data version	Migração ou expiração
Agente	agent@major.minor.patch	Desativação por tenant/fase

🧰 Exemplo prático relacionado (planejado)

• EX-LIFE-01 - exemplo de depreciação de tool com adapter e logs de uso.

---