클레임 통합 검토

페이지가 큐레이션되는 속도보다 클레임이 더 빠르게 축적됩니다. knowledge_remember는 클레임에 포함된 이름이 정확히 하나의 페이지와 일치하지 않을 때 주제 페이지 없이 클레임을 저장하며, 예약된 유지보수의 knowledge_relink는 소스 페이지가 엔티티 페이지이거나 텍스트가 정확히 하나의 페이지를 명명하는 클레임만 연결합니다. 연결된 클레임도 쌓입니다. 허브 페이지는 상태 스냅샷, 중복, 그리고 더 구체적인 주제에 속해야 하는 클레임을 수집합니다. 이 검토는 선택된 범위에 대해 하나의 절차를 실행합니다. 다음 순서로 작업하세요: 범위 선택, 연결, 중복 및 대체된 클레임 및 스냅샷 시리즈 처리, 페이지 본문 업데이트.

1. 범위 선택 및 열거

의도된 범위에 대해 knowledge_status를 호출하고 현재 지문에 대해 knowledge_ontology를 호출하세요. 그런 다음 정확히 하나의 시작 집합을 열거합니다.

미연결 잔여물 (기본값이며, 서기 실행의 유일한 범위). 먼저 dryRun 없이 knowledge_relink를 실행하여 기억된 모든 클레임 중 연결할 수 있는 것을 연결합니다. 그런 다음 knowledge_relink를 dryRun: true, include: "all", limit: 10으로 실행하여 잔여물을 나열하고, nextCursor를 따릅니다. 연결된 페이지도 소스 페이지도 없는 모든 현재 클레임(어떤 도구로 저장되었든). 각 호출은 결과당 최대 10개의 예제를 보고하므로, limit 10은 검사된 모든 클레임을 반환합니다.
하나의 페이지, 허브 페이지 또는 크기 예산을 초과하는 페이지용. knowledge_connections를 id, direction: "claims", view: "full", includeCards: true로 호출하여 현재 클레임을 나열하고, 동일한 필터로 nextOffset을 따릅니다. snapshot이 변경되면 다시 시작합니다. 허브에서는 먼저 카드에서 그룹화하고 한 번에 한 그룹씩 작업합니다. 모든 클레임을 처음부터 전체로 읽지 마세요.
하나의 주제, 선택적으로 특정 날짜 이후. 주제에 페이지가 있는 경우 knowledge_timeline을 entity, timeField: "recorded_at", since와 함께 호출하고 nextOffset을 따릅니다. 또한 knowledge_grep을 kind: "claim", 주제의 고유한 이름(PR 번호, 커밋 SHA, 기능 이름), 동일한 since/timeField로 호출하여 다른 곳에 제출되었거나 연결되지 않은 클레임을 검색합니다. 실제로 주제에 관한 클레임만 유지합니다.

범위를 보고서에 명시하세요. knowledge_record와 metadataView: "full"로 변경할 각 클레임을 읽으세요. subject_hint가 있는 경우, 이는 저장자가 클레임이 무엇에 관한 것인지 설명한 것으로, 주제에 대한 가장 강력한 단서입니다. 페이지를 선택하기 전에 클레임을 주제(하나의 기능, PR, 커밋, 결정 스레드, 사람 또는 선호도)별로 그룹화하세요. 대부분의 클레임은 이웃 클레임과 함께 있을 때만 의미가 있습니다. 하나의 PR에 대한 일련의 상태 스냅샷은 일반적으로 결과 클레임으로 끝납니다.

2. 주제 페이지 선택

각 그룹에 대해 knowledge_grep과 knowledge_lookup으로 후보 페이지를 찾고, 해당 페이지의 상태를 읽으세요. 철회된 페이지와 고정 페이지는 무시합니다.

기본 주제는 클레임이 주장하는 대상입니다. entities에 먼저 나열하세요. 클레임이 해당 엔티티에 대해서도 무언가를 주장하는 경우에만 보조 주제를 추가하세요(예: 결정을 내린 사람, 제품을 구성한 회사). 단순한 언급은 주제가 아닙니다. 두세 개의 주제면 충분합니다.
기본 주제는 클레임이 가리키는 가장 구체적인 페이지여야 합니다. 하나의 PR에 대한 클레임은 해당 PR의 페이지에 속해야 하며, PR이 속한 프로젝트에만 속하지 않습니다. 더 넓은 범위의 페이지는 클레임이 프로젝트 수준의 결정, 정책 또는 릴리스와 같이 해당 페이지에 대해 무언가를 말할 때만 주제로 유지됩니다.
한 사람이 진술한 선호도나 결정은 그 사람의 페이지에 속합니다. 한 사람의 선호도를 프로젝트나 회사 정책으로 바꾸지 마세요.
정체성은 유사한 이름이 아닌 증거를 기반으로 일치시킵니다. 클레임이 기존 페이지(예: 다른 서비스일 수 있는 제품 이름)일 수 있는 것을 명명하는 경우, 설정, URL 또는 페이지 자체의 별칭과 같은 증거를 통해 확인하세요. 불확실한 경우 클레임을 그대로 두고 보고하세요.

knowledge_annotate entities로 연결하고, 전체 목록(기존 목록을 대체함)과 클레임의 현재 리비전 및 해시를 전달하세요. 주장 텍스트, 증거 및 수명 주기는 변경되지 않습니다. 클레임을 대체하기 전에 먼저 연결하세요. 대체된 클레임은 다시 연결할 수 없습니다.

3. 누락된 페이지 생성 및 다시 연결

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

별개의 주제(기능, 프로젝트, 도구 또는 중요한 PR)에 대략 5개 이상의 클레임이 있거나 자체 설계, 증명 및 결과 기록이 있는 경우
또는 클레임에 등장하는 사람이나 조직이 페이지가 없고, 정체성 증거(예: gh pr view에 표시된 PR 작성자)가 있는 경우

단일 언급이나 날짜가 있는 클레임으로 충분히 다루어지는 일회성 수정에 대해서는 페이지를 생성하지 마세요. 온톨로지 type, 별칭 및 정체성 증거를 source로 하여 knowledge_save_page를 사용하세요. 사람 페이지는 정체성이 완전히 확립되지 않은 경우 identity.status: partial을 사용합니다. 클레임을 인용하는 짧은 상태를 작성하고, 타임라인은 클레임에서 파생됩니다. 상위 페이지에서 새 페이지를 연결하세요.

그런 다음 그룹의 클레임을 다시 연결합니다(4단계에서 대체할 스냅샷 포함). 새 페이지는 각 클레임의 기본 주제가 됩니다. 클레임이 제출되었던 광범위한 페이지(종종 이 검토가 시작된 허브)는 2단계의 규칙에 따라 해당 페이지에 대해 무언가를 말하는 클레임에 대해서만 유지하고, 나머지에서는 제거하세요. 여전히 자격이 되는 기존의 다른 보조 주제는 유지하세요. 임계값 미만인 경우 클레임을 현재 페이지에 그대로 두세요.

4. 중복, 대체된 클레임 및 스냅샷 시리즈 처리

중복: 두 클레임이 동일한 이벤트에 대해 동일한 사실, 결정 또는 선호도를 주장합니다. 소유자 승인 리콜이 있는 클레임을 유지하고, 그렇지 않으면 더 이른 클레임, 그렇지 않으면 더 완전한 속성이 있는 클레임을 유지합니다. 생존자가 부족한 증거를 knowledge_annotate addEvidence로 복사한 다음, knowledge_withdraw로 다른 클레임을 생존자의 ID를 명시하는 이유와 함께 철회합니다.
대체됨: 나중 클레임이 이전 클레임을 명시적으로 수정(예: 조수가 자신의 보고서를 수정)하거나 이전 클레임이 열어둔 질문을 결정합니다. knowledge_supersede로 이전 클레임을 이후 클레임으로 대체하고, 무엇이 대체했는지 설명하는 이유를 제공하세요. 여기서 knowledge_correct를 사용하지 마세요. 대체 항목의 새 복사본을 게시하여 또 다른 중복을 생성합니다.
스냅샷 시리즈: 특정 항목(동일한 PR, 커밋 또는 결정 스레드: CI 빨간불, 리뷰 요청됨, CI 초록불)에 대한 여러 상태 스냅샷과 동일한 항목(병합됨, 닫힘, 되돌려짐, 릴리스됨, 결정됨, 포기됨)에 대한 결과 클레임이 뒤따르는 경우. 하나의 knowledge_supersede 호출(최대 25개 클레임)에서 시리즈의 모든 스냅샷을 결과로 대체합니다. 클레임 자체 텍스트와 날짜에서 다음이 모두 충족되어야 합니다.
- 모든 스냅샷과 결과는 동일한 특정 항목을 명명하며, 단순히 동일한 프로젝트가 아닙니다.
- 결과는 대체하는 모든 스냅샷보다 나중 날짜이며 최종 상태를 명시하고, 또 다른 중간 상태가 아닙니다.
- 결과와 스냅샷은 공통 주제 페이지를 공유합니다(먼저 연결하세요, 3단계). 도구는 공통 페이지가 없는 클레임을 거부합니다. 결과 이후 날짜의 스냅샷 또는 다른 헤드나 다른 항목에 대한 스냅샷은 유지됩니다.
해당 사항 없음: 나중 결과로 대체되지 않은 서로 다른 순간의 스냅샷(CI 빨간불, 그다음 CI 초록불, 아직 병합되지 않음)은 기록일 뿐 오류가 아닙니다. 유지하세요. 모순만으로는 철회나 대체가 정당화되지 않습니다. 확실하지 않은 경우 둘 다 유지하고 쌍을 보고하세요.

knowledge_supersede는 대체된 각 클레임의 텍스트, 증거, 출처 및 기록을 유지하고, superseded_by와 이유를 기록하며, 대체하는 클레임은 변경하지 않습니다. 기본 읽기는 대체된 클레임을 더 이상 표시하지 않습니다. 기록 읽기(historical: true, lifecycle: "all")와 knowledge_history는 여전히 표시합니다. 대체가 잘못된 경우, undo: true, 동일한 by 클레임 및 수신 영수증의 items에 있는 경계를 사용하여 다시 호출하세요.

5. 페이지 본문 업데이트

연결은 클레임을 해당 페이지에서 접근 가능하게 만듭니다. 페이지 내용을 변경하지는 않습니다. 클레임이 페이지의 지속 가능한 상태를 변경할 때만 페이지를 편집하세요. 결정, 선호도, 적용 또는 릴리스된 변경 사항, 새로운 기능, 해결된 미해결 질문 또는 이후 클레임이 잘못되었음을 보여주는 페이지 텍스트.

진행 스냅샷 시리즈를 해당 결과로 축소하세요. 스냅샷(CI 실행, 열린 PR, 로컬 커밋)은 최대 날짜가 있는 이벤트 클레임일 뿐이며, 상태가 아닙니다.
가변 상태를 현재 상태로 작성하기 전에 실시간으로 확인하세요(예: gh pr view로 병합 상태 확인). 확인한 시점을 명시하세요. 병합이 배포를 의미하지 않으며, 배포가 특정 게이트웨이가 코드를 실행 중임을 증명하지 않습니다.
설계 또는 결정 페이지가 이후 결정과 모순되는 경우, 원본 텍스트를 다시 작성하는 대신 날짜가 있는 수정 사항을 원본 텍스트 옆에 추가하세요. 답변된 미해결 질문을 해결됨으로 표시하고 원래 질문을 유지하세요.
추가된 각 문장을 [[claim-id|label]] 링크로 클레임에 인용하세요.
페이지 본문에는 크기 예산이 있습니다(페이지 예산). state: "rejected" 편집은 저장되지 않지만, 연결된 클레임은 이미 사실을 보유합니다. knowledge_extract_section을 사용하여 섹션을 해당 주제의 페이지로 이동하고(필요시 3단계에 따라 페이지 생성), 다시 읽고 재시도하세요. 다른 산문을 줄여 공간을 확보하지 마세요. 추출은 섹션이 인용하는 클레임의 첫 번째 주제를 대상 페이지로 만들고, 추출한 페이지를 포함한 기존 주제를 유지합니다. 각 해당 클레임에 2단계를 적용하고 클레임이 해당 페이지에 대해 아무것도 말하지 않는 경우 knowledge_annotate entities로 소스 페이지를 제거하세요.

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

6. 확인 및 보고

연결된 각 클레임에 대해 expectedEntities로, 새로 생성되거나 편집된 각 페이지에 대해 expectedLinks로 knowledge_verify를 실행하세요. 작업 중에 새 클레임이 도착했을 수 있으므로 범위를 다시 열거하세요. 동일한 방식으로 처리하거나 보고하세요.

범위, 검토된 클레임 수, 연결 및 다시 연결된 클레임 수, 생성된 페이지 수, 대체된 클레임 수(각 시리즈의 대체하는 클레임 포함), 철회된 클레임 수(생존하는 클레임 포함), 편집된 페이지 수, 그리고 검토했지만 변경하지 않은 클레임(각 사유 포함)을 보고하세요. 무인 실행 시에는 결정을 요청하지 말고 추측하지 마세요. 불확실한 정체성, 불확실한 중복, 결과가 확실하지 않은 스냅샷 시리즈, 추측으로만 생성할 페이지는 그대로 두고 사람이 처리할 수 있도록 보고서에 나열하세요.

서기 실행

지식 통합 서기는 이 검토를 무인으로 미연결 잔여물에 대해 실행합니다. 프롬프트에 명시된 일정에 따라 수행됩니다. 프롬프트는 액세스 권한을 확인하고 자동화를 설정합니다. 이 섹션은 한 번 실행의 작업만 설명합니다.

미연결 잔여물에 대해 1단계를 실행합니다. 잔여물이 비어 있으면 검토된 클레임이 0개라고 보고하고 아래의 작성된 타임라인으로 진행합니다.
그렇지 않으면 2~6단계를 통해 작업하고, 중지하기 전에 잔여물을 다시 확인하세요. 실행 중에 저장된 클레임은 동일한 백로그의 일부이기 때문입니다.
그런 다음 최대 10개의 작성된 ## 타임라인 섹션을 가장 큰 것부터 순서대로 제거합니다(작성된 타임라인 제거). Timeline에 대한 knowledge_grep으로 찾고 페이지 본문에서 제목을 확인하세요. 제거된 섹션 수와 여전히 타임라인이 있는 페이지 수를 계산하세요.
질문하지 마세요. 6단계 보고서를 제공하세요. 마감 상태 줄은 검토된 클레임, 연결된 클레임, 대체된 클레임, 철회된 클레임 및 남은 클레임 수, 그다음 제거된 타임라인과 남은 타임라인 수를 집계합니다.

지식 클레임 통합 검토