knowledge-unlinked-claims

연결되지 않은 클레임 검토

공유 규칙(shared conventions)과 발행(publication)을 먼저 읽고 작성하세요.

knowledge_remember는 클레임 텍스트에 정확히 하나의 페이지 이름이 일치하지 않을 때 주제 페이지 없이 클레임을 저장합니다. 예정된 유지보수는 knowledge_relink를 실행하며, 이는 기록된 소스 페이지가 엔터티 페이지이거나 텍스트가 정확히 하나의 페이지를 가리키는 클레임만 연결합니다. 나머지는 연결되지 않은 상태로 남아 해당 페이지에서 보이지 않게 됩니다. 이 스킬은 판단력으로 그 잔여물을 처리합니다. 다음 순서대로 작업합니다: 먼저 연결, 그 다음 중복 및 대체된 클레임 처리, 마지막으로 페이지 본문 업데이트.

1. 잔여물 목록 작성

의도된 범위에 대해 knowledge_status를 호출하고 현재 지문(fingerprint)에 대해 knowledge_ontology를 호출합니다. 먼저 dryRun 없이 knowledge_relink를 실행하여 연결할 수 있는 모든 기억된 클레임이 연결되도록 합니다. 그런 다음 knowledge_relink를 dryRun: true, include: "all", limit: 10으로 설정하고 nextCursor를 따라 실행하여 연결되지 않은 잔여물을 나열합니다. 어떤 도구로 저장되었든 연결된 페이지도 소스 페이지도 없는 모든 현재 클레임이 여기에 해당됩니다. 각 호출은 결과별로 최대 10개의 예시를 보고하므로, limit이 10이면 검사한 모든 클레임을 반환합니다.

knowledge_record와 metadataView: "full"을 사용하여 각 클레임을 읽습니다. subject_hint가 있는 경우, 이는 저장자가 클레임의 대상에 대해 설명한 내용이며 주제에 대한 가장 강력한 단서입니다. 페이지를 선택하기 전에 클레임을 주제별로 그룹화합니다(하나의 기능, PR, 결정 스레드, 사람 또는 선호도). 대부분의 클레임은 옆에 있는 클레임과 함께 있을 때만 의미가 있습니다. 하나의 PR에 대한 일련의 상태 스냅샷은 일반적으로 결과 클레임으로 끝납니다.

2. 주제 페이지 선택

각 그룹에 대해 knowledge_grep과 knowledge_lookup으로 후보 페이지를 찾고, 해당 State와 Timeline을 읽습니다. 철회된 페이지와 고정(fixture) 페이지는 무시합니다.

• 기본 주제는 클레임이 주장하는 대상입니다. 클레임이 해당 엔터티에 대해서도 명시적으로 언급하는 경우에만 보조 주제를 추가합니다(예: 결정을 내린 사람, 제품을 구성한 회사). 단순 언급은 주제가 아닙니다. 일반적으로 2~3개의 주제면 충분합니다.
• 어떤 사람이 언급한 선호도나 결정은 해당 사람의 페이지에 속합니다. 한 사람의 선호도를 프로젝트나 회사 정책으로 바꾸지 마십시오.
• 유사한 이름이 아닌 증거를 기반으로 신원을 일치시킵니다. 클레임이 기존 페이지일 수 있는 무언가(예: 다른 서비스일 수 있는 제품 이름)를 언급하는 경우, 설정, URL 또는 페이지 자체의 별칭과 같은 증거를 통해 확인합니다. 불확실한 경우 클레임을 연결되지 않은 상태로 두고 보고합니다.

knowledge_annotate entities를 사용하여 연결하며, 전체 목록(기존 목록을 대체함)과 클레임의 현재 리비전 및 해시를 전달합니다. 주장 텍스트, 증거 및 수명 주기는 변경되지 않습니다.

3. 누락된 페이지 생성

모든 클레임을 가장 가까운 기존 페이지에 연결하면 실제 주제가 광범위한 페이지의 Timeline에 묻힐 수 있습니다. 다음과 같은 경우 페이지를 생성합니다:

• 개별 주제(기능, 프로젝트, 도구 또는 상당한 PR)에 대략 5개 이상의 클레임이 있거나 자체 설계, 증명 및 결과 이력이 있는 경우
• 클레임에 언급된 사람이나 조직이 작성자, 소유자 또는 결정자이며 페이지가 없고 신원 증거(예: gh pr view에 표시된 PR 작성자)가 있는 경우

단일 언급이나 Timeline 항목이 포함하는 일회성 수정에 대해서는 페이지를 생성하지 마십시오. 온톨로지 type, 별칭 및 신원 증거를 source로 사용하여 knowledge_save_page를 사용합니다. 사람 페이지는 신원이 완전히 확인되지 않는 한 identity.status: partial을 사용합니다. 클레임을 인용하는 짧은 State와 날짜가 있는 Timeline을 작성합니다. 그런 다음 클레임을 새 페이지에 연결하고 기존 주제를 보조 주제로 유지하며, 새 페이지를 상위 페이지에서 연결합니다.

4. 중복 및 대체된 클레임 폐기

• 중복: 두 클레임이 동일한 사건에 대해 동일한 사실, 결정 또는 선호도를 주장합니다. 소유자가 승인한 회상(recall)이 있는 것을 유지하고, 그렇지 않으면 더 이른 것을, 그렇지 않으면 더 완전한 속성을 가진 것을 유지합니다. knowledge_annotate addEvidence를 사용하여 생존자가 누락한 증거를 복사한 다음, 생존자의 ID를 언급하는 이유와 함께 knowledge_withdraw로 다른 것을 폐기합니다.
• 대체됨: 이후 클레임이 이전 클레임을 명시적으로 수정하는 경우(예: 어시스턴트가 자신의 보고서를 수정), 이전 클레임이 열어둔 질문을 결정하거나, 동일한 특정 항목(동일한 PR, 커밋 또는 결정)의 최종 상태를 보고합니다. 대체하는 클레임을 언급하는 이유와 함께 이전 클레임을 철회합니다. 여기서 knowledge_correct를 사용하지 마십시오. 대체 항목의 새 복사본을 게시하여 또 다른 중복을 생성합니다.
• 둘 다 아님: 서로 다른 시점의 스냅샷(한 HEAD에서 CI 실패, 나중에 병합)은 오류가 아니라 기록입니다. 유지합니다. 모순만으로는 철회가 정당화되지 않습니다. 확실하지 않은 경우 둘 다 유지하고 쌍을 보고합니다.

5. 페이지 본문 업데이트

링킹은 클레임을 해당 페이지에서 접근 가능하게 만들 뿐 페이지 내용을 변경하지는 않습니다. 클레임이 페이지의 내구성 있는 상태(결정, 선호도, 적용 또는 릴리스된 변경 사항, 새로운 기능, 해결된 미해결 질문 또는 이후 클레임이 잘못된 것으로 보여주는 페이지 텍스트)를 변경하는 경우에만 페이지를 편집합니다.

• 일련의 진행 스냅샷을 결과로 축소합니다. 스냅샷(CI 실행, 열린 PR, 로컬 커밋)은 기껏해야 날짜가 있는 Timeline 항목일 뿐이며 절대 State가 아닙니다.
• 현재 상태로 쓰기 전에 가변 상태를 라이브로 확인하고(예: 병합 상태에 대해 gh pr view), 확인한 시점을 명시합니다. 병합이 배포를 의미하지 않으며, 배포가 특정 Gateway가 해당 코드를 실행한다는 증거가 아닙니다.
• 설계 또는 결정 페이지가 이후 결정과 모순되는 경우, 원본 텍스트를 다시 쓰지 않고 날짜가 있는 수정 사항을 원본 텍스트 옆에 추가합니다. 답변된 미해결 질문은 해결됨으로 표시하고 원본 질문은 유지합니다.
• 추가된 모든 문장을 [[claim-id|label]] 링크로 클레임에 인용합니다.

섹션 편집에는 knowledge_edit_body를 사용합니다. 새 전체 읽기에서 UTF-16 오프셋을 계산하고, 모든 편집 전에 리비전과 해시를 다시 읽습니다. 다른 세션이 동시에 바쁜 페이지를 편집할 수 있습니다. 텍스트를 교체하는 것보다 삽입하는 것을 선호합니다. 전체 State 섹션이 모두 오래된 경우에만 교체하고, 이미 가지고 있던 클레임 링크는 유지합니다.

6. 확인 및 보고

연결된 각 클레임에 대해 expectedEntities를 사용하고 새 페이지 또는 편집된 각 페이지에 대해 expectedLinks를 사용하여 knowledge_verify를 실행합니다. 다시 잔여물을 열거합니다. 작업 중에 새로운 기억된 클레임이 도착했을 수 있습니다. 동일한 방식으로 처리하거나 보고합니다.

검사 및 연결된 클레임 수, 생성된 페이지, 철회된 클레임(각각에 대해 생존 또는 대체 클레임 명시), 편집된 페이지, 그리고 연결되지 않은 상태로 남은 클레임과 그 이유를 보고합니다. 무인 실행 시, 결정을 요청하지 마십시오. 불확실한 신원, 불확실한 중복 및 추측으로만 생성할 페이지는 건드리지 않고 보고서에 나열하여 사람이 처리하도록 합니다.

예정된 검토로 실행

Knowledge 유지보수는 개인 기억 클레임이 여전히 연결되지 않은 상태로 있을 때 야간 재연결 패스 이후 이 검토를 큐에 넣습니다(maintenance.reviewJobId). 실행은 무인(unattended)입니다:

• 먼저 knowledge_status를 호출합니다. 범위가 private이 아니거나 쓰기가 비활성화된 경우, 첫 줄에 AUTOMATION_FAILED를 응답하고 이유를 함께 반환합니다. 작업자가 소유자의 접근 권한을 잃었으며 다시 설정해야 합니다.
• 1단계부터 6단계까지 작업합니다. 중지하기 전에 다시 잔여물을 확인합니다. 실행 중에 저장된 클레임도 동일한 백로그의 일부이기 때문입니다.
• 할 일이 없으면 NO_REPLY로 응답합니다. 그렇지 않으면 6단계 보고서로 응답합니다.

예정된 검토 설정

검토에는 소유자-개인 액세스가 필요하며, 이는 소유자의 직접 대화에서 파생된 세션만이 가지고 있습니다. 해당 대화에서 설정합니다:

1. 유지된 작업자(kept worker)를 생성합니다: runtime: "subagent", cleanup: "keep", context: "isolated"로 sessions_spawn을 사용하며, 작업은 knowledge_status를 호출하고 범위를 보고하는 것입니다. private이며 쓰기가 활성화된 경우에만 계속합니다. 반환된 세션 키를 유지합니다.

2. 해당 작업자에 바인딩된 자동화를 생성합니다. 스케줄이 필요하므로 수년 후의 일회성 날짜를 지정합니다. 유지보수는 온디맨드로 실행합니다.

   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 "예정된 검토로 knowledge-unlinked-claims 스킬을 따릅니다."
   

   작업은 생성된 inference 계정을 기록합니다. 해당 계정(인증 프로필이 있는 공급자)을 사용하는 모델을 선택합니다. 그렇지 않으면 모델이 호출되기 전에 모든 실행이 실패합니다.

3. plugins.entries.knowledge.config.maintenance.reviewJobId를 작업 ID로 설정합니다.

4. 증명합니다: openclaw automations run <job-id> --wait가 작업자가 개인 범위를 보고하는 것으로 끝나야 하며, maintenance_status는 다음 패스 후 검토 결과를 보고합니다.

자동화를 비활성화하여 검토를 일시 중지합니다. 작업자가 속한 소유자 대화를 재설정하거나 제거하면 액세스 권한이 취소됩니다. 검토를 다시 설정하세요.