knowledge-unlinked-claims

Revisar claims não vinculados

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

knowledge_remember salva um claim sem uma página de assunto quando nenhum nome nele corresponde exatamente a uma página. A manutenção agendada então executa knowledge_relink, que vincula apenas claims cuja página de origem registrada é uma página de entidade ou cujo texto nomeia exatamente uma página. O restante permanece não vinculado e fica invisível nas páginas que lhe dizem respeito. Esta skill lida com esse resíduo com julgamento. Trabalhe nesta ordem: vincule, depois duplicatas e claims substituídos, e por último o texto da página.

1. Enumere o resíduo

Chame knowledge_status para o escopo pretendido e knowledge_ontology para a impressão digital atual. Execute knowledge_relink sem dryRun primeiro para que todos os claims lembrados que ela pode vincular sejam vinculados. Em seguida, liste o resíduo com knowledge_relink dryRun: true, include: "all" e limit: 10, seguindo nextCursor: todos os claims atuais sem página vinculada e sem página de origem, independentemente de qual ferramenta os salvou. Cada chamada relata no máximo 10 exemplos por resultado, então um limite de 10 retorna todos os claims que examinou.

Leia cada claim com knowledge_record e metadataView: "full". Seu subject_hint, quando presente, é a própria descrição do salvador sobre o que o claim trata e a pista mais forte para seu assunto. Agrupe os claims pelo que eles são sobre (um recurso, PR, thread de decisão, pessoa ou preferência) antes de escolher páginas. A maioria dos claims só faz sentido ao lado de seus vizinhos: uma série de instantâneos de status sobre um PR geralmente termina em um claim de resultado.

2. Escolha páginas de assunto

Para cada grupo, encontre páginas candidatas com knowledge_grep e knowledge_lookup, e leia seu Estado e Linha do Tempo. Ignore páginas retiradas e páginas de fixture.

• O assunto principal é sobre o que o claim afirma algo. Adicione um assunto secundário apenas quando o claim também afirma algo sobre essa entidade, como a pessoa que tomou a decisão ou a empresa cujo produto foi configurado. Uma menção passageira não é um assunto. Dois ou três assuntos geralmente são suficientes.
• Uma preferência ou decisão declarada por uma pessoa pertence à página dessa pessoa. Não transforme a preferência de uma pessoa em uma política de projeto ou empresa.
• Corresponda a identidade com base em evidências, não em nomes semelhantes. Quando um claim nomeia algo que pode ser uma página existente (por exemplo, um nome de produto que poderia ser um serviço diferente), confirme a partir de evidências como configuração, uma URL ou os próprios aliases da página. Se permanecer incerto, deixe o claim não vinculado e relate-o.

Vincule com knowledge_annotate entities, passando a lista completa (ela substitui a existente) e a revisão e o hash atuais do claim. O texto da afirmação, evidências e ciclo de vida permanecem inalterados.

3. Crie páginas ausentes

Vincular todos os claims à página existente mais próxima pode enterrar um assunto real na Linha do Tempo de uma página ampla. Crie uma página quando:

• um assunto discreto (um recurso, projeto, ferramenta ou PR substancial) tem aproximadamente cinco ou mais claims, ou tem seu próprio design, prova e histórico de resultados; ou
• uma pessoa ou organização é autora, proprietária ou decidiu algo nos claims, não tem página e tem evidências de identidade (por exemplo, o autor do PR mostrado por gh pr view).

Não crie uma página para uma única menção ou uma correção pontual que um registro da Linha do Tempo cubra. Use knowledge_save_page com o type da ontologia, aliases e a evidência de identidade como source. Páginas de pessoa usam identity.status: partial a menos que a identidade esteja totalmente estabelecida. Escreva um Estado curto que cite os claims e uma Linha do Tempo datada. Em seguida, vincule os claims à nova página, mantendo seus assuntos existentes como secundários, e vincule a nova página a partir de sua página pai.

4. Retire duplicatas e claims substituídos

• Duplicata: dois claims afirmam o mesmo fato, decisão ou preferência sobre o mesmo evento. Mantenha aquele com recall aprovado pelo proprietário, caso contrário, o mais antigo, caso contrário, aquele com atribuição mais completa. Copie qualquer evidência que o sobrevivente não tenha com knowledge_annotate addEvidence, em seguida, knowledge_withdraw o outro com um motivo que nomeie o ID do sobrevivente.
• Substituído: um claim posterior corrige explicitamente o anterior (por exemplo, um assistente corrigindo seu próprio relatório), decide uma questão que o claim anterior deixou em aberto ou relata o estado final do mesmo item específico (mesmo PR, commit ou decisão). Retire o claim anterior com um motivo que nomeie o claim substituto. Não use knowledge_correct aqui: ele publica uma nova cópia do substituto, o que cria outra duplicata.
• Nenhum dos dois: instantâneos de momentos diferentes (CI vermelho em um head, um merge depois) são história, não erros. Mantenha-os. A contradição por si só não justifica uma retirada. Quando estiver em dúvida, mantenha ambos e relate o par.

5. Atualize o texto da página

Vincular torna os claims acessíveis a partir de suas páginas; não altera o que uma página diz. Edite uma página apenas quando os claims alterarem seu estado durável: uma decisão, uma preferência, uma alteração merged ou lançada, uma nova capacidade, uma questão em aberto resolvida ou texto da página que claims posteriores mostram estar errado.

• Condense uma série de instantâneos de progresso em seu resultado. Instantâneos (execuções de CI, PRs abertos, commits locais) são no máximo registros datados na Linha do Tempo, nunca no Estado.
• Verifique o status mutável ao vivo antes de escrevê-lo como atual (por exemplo, gh pr view para estado de merge) e diga quando verificou. Um merge não é uma implantação, e uma implantação não é prova de que um determinado Gateway executa o código.
• Quando um design ou página de decisão contradiz uma decisão posterior, adicione uma emenda datada ao lado do texto original, em vez de reescrevê-lo. Marque questões em aberto respondidas como resolvidas e mantenha a questão original.
• Cite cada frase adicionada com links [[claim-id|label]] para os claims.

Use knowledge_edit_body para edições de seção. Calcule deslocamentos UTF-16 a partir de uma leitura completa recente e releia a revisão e o hash antes de cada edição: outras sessões editam páginas ocupadas simultaneamente. Prefira inserir texto em vez de substituí-lo. Substitua uma seção inteira de Estado apenas quando tudo estiver desatualizado e mantenha os links de claim que ela já tinha.

6. Verifique e relate

Execute knowledge_verify com expectedEntities para cada claim vinculado e expectedLinks para cada página nova ou editada. Enumere o resíduo novamente: novos claims lembrados podem ter chegado enquanto você trabalhava. Trate-os da mesma forma ou relate-os.

Relate o número de claims examinados e vinculados, páginas criadas, claims retirados (com o claim sobrevivente ou substituto para cada um), páginas editadas e claims deixados não vinculados com o motivo de cada um. Ao executar sem supervisão, nunca peça uma decisão: deixe identidades incertas, duplicatas incertas e páginas que você só criaria com base em um palpite intocadas e liste-as no relatório para uma pessoa.

Executando como a revisão agendada

A manutenção do Knowledge enfileira esta revisão após sua passagem de religação noturna quando claims lembrados privados ainda estão não vinculados (maintenance.reviewJobId). A execução é não supervisionada:

• Primeiro chame knowledge_status. Se o escopo não for private ou as gravações estiverem desabilitadas, responda com AUTOMATION_FAILED em sua própria primeira linha e o motivo: o worker perdeu o acesso do proprietário e precisa ser configurado novamente.
• Trabalhe nas etapas 1 a 6. Verifique o resíduo novamente antes de parar, pois os claims salvos durante a execução fazem parte do mesmo backlog.
• Se não houver nada a fazer, responda NO_REPLY. Caso contrário, responda com o relatório da etapa 6.

Configurando a revisão agendada

A revisão precisa de acesso privado do proprietário, que apenas uma sessão descendente da conversa direta do proprietário tem. Configure-a a partir dessa conversa:

1. Gere um worker mantido: sessions_spawn com runtime: "subagent", cleanup: "keep" e context: "isolated", cuja tarefa é chamar knowledge_status e relatar o escopo. Continue apenas se ele relatar private com gravações habilitadas. Mantenha a chave de sessão retornada.

2. Crie a automação vinculada a esse worker. Ela precisa de um agendamento, então dê a ela uma data única anos à frente; a manutenção a executa sob demanda.

   openclaw automations add --agent <agent> --name knowledge-unlinked-claims-review \
     --session "session:<worker-session-key>" --at <date-years-ahead> --keep-after-run \
     --model <provider/model> --no-deliver --timeout-seconds 3600 \
     --message "Siga a skill knowledge-unlinked-claims como a revisão agendada."
   

   O trabalho registra a conta de inferência com a qual foi criado. Escolha um modelo que use essa conta (um provedor com um perfil de autenticação); caso contrário, toda execução falha antes que o modelo seja chamado.

3. Defina plugins.entries.knowledge.config.maintenance.reviewJobId para o ID do trabalho.

4. Prove-o: openclaw automations run <job-id> --wait deve terminar com o worker relatando o escopo privado, e maintenance_status relata o resultado da revisão após a próxima passagem.

Desabilite a automação para pausar a revisão. Resetar ou remover a conversa do proprietário da qual o worker veio revoga seu acesso; configure a revisão novamente.