ITHZ MCP

Memória do projeto com um plano para o próximo passo

O que isso traz

• O projeto é dono da memória: os agentes recebem pacotes de contexto determinísticos e específicos da tarefa, em vez de depender de um chat ou de varrer todo o arquivo.
• Os eventos permanecem imutáveis, enquanto decisões, riscos, portões e alegações são registros tipados com proveniência, validade e substituição explícita.
• Registros vinculados à fonte podem ser verificados contra evidências exatas; memória não verificada ou desanexada pode ser bloqueada ou colocada em quarentena, em vez de ser confiada automaticamente.
• Implementadores, revisores e oponentes independentes podem receber diferentes visões de evidências, incluindo um caminho cru-primeiro que reduz o viés de resumo compartilhado.
• Hashes de checkpoint, recibos de comando e manifestos de revisão final tornam o estado revisado do projeto reproduzível, enquanto o Git permanece como o histórico do código-fonte e o ITHZ MCP permanece como evidência de revisão, não como autoridade de implantação.

Planeje primeiro, verifique cada entrega

Na entrada da tarefa, proponha as etapas, papéis consultivos, dependências, verificações, caminhos de reparo e limites de aprovação. Uma tarefa pequena pode ficar com um único agente; papéis adicionais não iniciam automaticamente.

O coordenador local opcional vincula os resultados ao checkout e ao contrato da tarefa, preserva falhas e aplica limites configurados de reparo e tempo. A execução é sequencial nesta versão. Isso não substitui permissões do host, um sandbox do sistema operacional ou um adaptador de implantação.

Alegações não se passam mais por fatos

Notas clássicas de projeto são úteis até que decisões antigas e novas entrem em conflito ou um resumo perca sua fonte. O ITHZ MCP mantém uma trilha de episódios imutável e constrói abstrações tipadas acima dela: uma decisão, risco, portão ou alegação pode apontar para evidências, declarar seu escopo e ser substituída sem apagar o histórico.

O resultado prático é um contexto menor e específico por papel. Um implementador pode receber as decisões e restrições necessárias para uma tarefa, enquanto um revisor ou oponente de outro laboratório pode inspecionar um caminho de evidências mais independente. O modelo não se torna magicamente mais inteligente; ele se torna mais consistente e mais fácil de auditar.

Um canário com freios, não uma segunda autoridade

Uma memória de longa duração pode preservar um erro tão eficientemente quanto uma decisão correta. O canário, portanto, testa memória suspeita ou conflitante em uma pista deliberadamente restrita: ele começa desabilitado, lê apenas evidências, tem limites de tempo e de casos, e pode ser interrompido com um interruptor de emergência.

Seu veredito não pode executar uma mudança nem se escrever no arquivo como verdade. A promoção ainda depende de recibos rastreáveis, revisão independente e da autoridade humana ou de fluxo de trabalho que já governa o projeto.

A memória existente do projeto não precisa ser reescrita

Arquivos existentes do project.ithz permanecem legíveis. A atualização segura é fazer backup do arquivo, instalar o pacote atual em um ambiente Python 3.10+ limpo, executar as verificações de integridade da memória e do canário, e manter o canário desabilitado até que o projeto opte explicitamente por ele.

Registros mais antigos podem permanecer como evidência legada enquanto novos trabalhos começam a produzir proveniência mais forte e recibos de revisão v2. Instalações muito antigas ou personalizadas ainda precisam de um teste específico do projeto e de um rollback testado; compatibilidade não é motivo para pular a verificação.