knowledge-correct

Corrigir conhecimento salvo através de ferramentas do agente

Leia as convenções compartilhadas e publicação antes de escrever.

Identificar o registro proprietário

Use um ID de registro/alegação estruturado e sua revisão fornecidos como alvo principal, não apenas seu rótulo de exibição. Leia knowledge_record com metadados e evidências; confirme sua revisão/hash atual. Uma revisão referenciada que mudou requer releitura e reconciliação da solicitação, não agir silenciosamente sobre uma nova asserção. Sem uma referência exata, use pesquisa/busca, inspecione candidatos e pergunte apenas quando o alvo solicitado ou a correção permanecer materialmente ambígua.

Distinguir uma asserção salva errônea de uma resposta sem suporte, declarações conflitantes em fontes e um fato que mudou ao longo do tempo. Contradição sozinha não autoriza substituição; o único caso não-usuário é uma declaração permanente que seu próprio detentor substituiu explicitamente, de acordo com a publicação. Não fabrique um "fato de guarda" armazenado quando nenhum registro existe ou trate uma retirada como evidência para seu oposto.

Aplicar a operação correta

• Correção de alegação ou relacionamento explícito: chame knowledge_correct com o ID exato, expectedRevision e expectedHash observados, motivo, UUID do vault observado e impressão digital da ontologia, e uma replacement completa do mesmo kind. Campos de substituição usam o contrato de criar-alegação/criar-relacionamento; há um ID de solicitação externo, não uma segunda solicitação de substituição. Preserve contexto suportado, atribuição, datas precisas e evidências; remova ou revise o que a correção realmente altera. A operação publica a substituição e substitui a asserção antiga juntas, com links em ambas as direções.
• Retirada sem substituição: chame knowledge_withdraw com o ID exato, revisão/hash, motivo e UUID do vault. Aceita páginas, alegações e relacionamentos explícitos. Uma aresta é identificada por seu próprio ID, não por seu par de extremidades. Preserva evidências/histórico originais e não é exclusão de arquivo.
• Correção de prosa de página: use knowledge_save_page com isolamento de revisão, preservando material autoral não relacionado e fontes. Correções de página são revisões, não identidades de entidade substitutas.
• Duas páginas para uma entidade: chame knowledge_merge com a página sobrevivente, a duplicata, a revisão/hash atual de ambas as páginas e um motivo. Mantenha a página com a identidade mais completa (nome real, mais conexões) como a sobrevivente; passe title para renomeá-la e body quando a página combinada deve dizer mais do que a prosa atual da sobrevivente. O ID, título, aliases, alegações, relacionamentos e links da duplicata então resolvem para a sobrevivente; nada é corrigido um por um. Desfaça uma fusão equivocada com knowledge_unmerge.

Uma correção explícita do usuário pode fornecer evidência: retenha sua declaração exata com knowledge_attach, atribua-a ao usuário e referencie seu localizador verificado. Use assertion_origin: user_belief para distinguir uma asserção de usuário de uma declaração com fonte independente; não afirme verificação documental. Inferência de agente ainda precisa de evidência de premissa retida, não de uma citação inventada.

Resolver um pseudônimo ou identidade equivocada

Use knowledge-entities para encontrar e ler o perfil do pseudônimo, a pessoa estabelecida e seus registros conectados. Retenha a identificação exata do usuário como evidência. Atualize aliases suportados e contexto de identidade nas páginas existentes; preserve conteúdo não relacionado e descreva a conexão com a pessoa estabelecida. Use o ID existente dessa pessoa para enriquecimento futuro. Quando o pseudônimo já tem sua própria página, mescle-a na página da pessoa estabelecida com knowledge_merge em vez de escrever uma página de ponteiro, retirá-la ou corrigir suas alegações uma a uma. Mescle apenas com evidência de identidade (a declaração do usuário, uma auto-apresentação, um ID de conta estável compartilhado), nunca com base em semelhança de nome; knowledge_diagnostics mergeCandidates lista páginas para verificar, não páginas para mesclar. Retenha a evidência de identidade com knowledge_attach e passe-a como evidence.

Inspecione prosa, alegações, linhas do tempo e relacionamentos afetados dentro do escopo da correção. Corrija atribuição equivocada e identidade não resolvida onde a nova evidência suporta, usando as operações de página/asserção acima; preserve rótulos de fonte, citações literais, datas de eventos e proveniência da correção. Uma identidade de autor confirmada não verifica independentemente as alegações factuais desse autor.

Alterações passam por essas ferramentas, não por edições manuais em Markdown, formulários de navegador, SQL, ou chamadas separadas de "criar então retirar". Nenhum ritual de aprovação adicional é aplicável para uma correção inequívoca autorizada pelo usuário. Siga o tratamento de repetição/conflito de publicação; um recibo no estado aceito/conflito não é um reparo concluído.

Inspecionar propagação e relatar honestamente

O impact.items do recibo identifica dependentes diretos/transitivos de escopo conhecido no momento da aceitação. Ele não os atualiza. Leia registros afetados por ID exato e inspecione suas evidências. Repare apenas alterações suportadas dentro do escopo da solicitação; não substitua cegamente IDs de dependência ou citações de fonte com a nova alegação. Registros que dependem de uma asserção inativa são retidos da descoberta atual até serem reparados; a inspeção exata de registro/histórico permanece disponível.

Pesquise por cópias de prosa plausíveis como uma verificação suplementar. Pesquisas perdidas, prosa não vinculada, escopos ocultos e índices incompletos impedem uma promessa universal de "todas as cópias corrigidas". Não altere sistemas de memória ou identidade não relacionados como uma consequência automática de uma correção de Conhecimento.

Leia de volta a original e a substituição (ou alvo retirado), verifique ciclo de vida e evidências, e verifique que a busca atual exclui a asserção antiga. Responda com o ID do recibo/solicitação, IDs de registro afetados, o motivo da correção/retirada e dependências reparadas versus não resolvidas. Mencione histórico retido apenas quando relevante; nunca prometa apagamento de originais, exportações ou backups.