모은 자료로 연구 위키를 만들고 출처를 밝혀 질문에 답하기

## 모은 출처와 AI가 쓰는 위키 페이지를 따로 보관하기 출처 보존과 에이전트가 관리하는 지식을 분리하세요. - `sources/`에는 불변 입력 문서를 보관합니다. - `wiki/index.md`에는 관리 중인 모든 페이지를 기록합니다. - `wiki/log.md`는 추가 전용 작업 이력입니다. - `wiki/overview.md`는 여러 출처를 아우르며 계속 갱신되는 종합 분석입니다. - `wiki/sources/`에는 입력 출처마다 하나의 요약 페이지를 둡니다. - `wiki/entities/`에는 사람, 조직, 프로젝트, 제품을 둡니다. - `wiki/concepts/`에는 아이디어, 방법, 이론, 프레임워크를 둡니다. - `wiki/syntheses/`에는 연구 질문에 대해 저장된 답변을 둡니다. - `graph/`에는 생성된 그래프 데이터와 시각화를 둡니다. - `tools/`에는 결정론적 및 의미론적 유지 관리 유틸리티를 둡니다. 출처를 편입하는 동안 원본 문서를 절대 수정하지 마세요. 관리 계층은 생성하고 개정할 수 있지만, 모든 주장을 출처 페이지까지 추적할 수 있어야 합니다. 출처를 편입할 때마다 인덱스를 업데이트하세요. 작업 이력은 다시 쓰지 말고 내용을 추가하며, 새로운 근거로 인해 출처 간 종합 분석이 달라질 때만 개요를 개정하세요. ## 모든 페이지에 출처와 수정 날짜를 적고 이름 붙이는 법 통일하기 관리 중인 모든 페이지는 구조화된 메타데이터를 사용해야 합니다. - `title`: 페이지 내용을 설명하는 제목. - `type`: `source`, `entity`, `concept`, `synthesis` 중 정확히 하나. - `tags`: 분류 태그 목록. - `sources`: 페이지를 뒷받침하는 출처 슬러그 목록. - `last_updated`: `YYYY-MM-DD` 형식의 날짜. 출처 요약에는 출처 날짜와 원래 출처에 대한 참조도 추가하세요. 안정적인 내부 링크로 출처, 엔터티, 개념, 종합 분석을 연결하세요. 일관된 명명 방식을 사용하세요. - 출처 슬러그에는 소문자 kebab-case를 사용합니다. - 엔터티 및 개념 페이지에는 안정적인 제목 형식의 이름을 사용합니다. - 저장된 종합 분석에는 내용을 설명하는 슬러그를 사용합니다. - 작업 로그에는 `YYYY-MM-DD`, 작업, 제목을 사용합니다. 특수한 출처 유형에는 전용 섹션을 사용할 수 있습니다. 회의록에는 목표, 논의, 결정, 조치를 보존하고, 일지에는 사건, 결정, 관찰, 연결, 변화를 보존하세요. 모든 템플릿에서 동일한 출처 추적 요구 사항을 유지하세요. ## 새 출처를 추가하고 영향을 받는 페이지 고치기 출처 편입을 요청받으면 다음 단계를 순서대로 완료하세요. 1. 출처 전체를 읽으세요. 지원되지 않는 출처 형식은 원본을 변경하지 않고 Markdown으로 변환하세요. 2. 현재 인덱스와 개요를 읽어 기존 수록 범위를 파악하세요. 3. 짧은 요약, 주요 주장, 선별한 근거, 연결, 모순이 포함된 출처 페이지를 하나 만드세요. 4. 새 출처를 인덱스에 추가하세요. 5. 새 출처로 인해 변경이 필요한 부분만 개요에서 개정하세요. 6. 중요한 엔터티와 개념의 페이지를 만들거나 업데이트하세요. 7. 새 주장을 기존 페이지와 비교하고 모순을 명시적으로 표시하세요. 8. 작업 로그에 출처 편입 기록을 추가하세요. 9. 모든 새 페이지가 인덱스에 포함되어 있고 모든 내부 링크가 올바르게 연결되는지 검증하세요. 10. 생성, 업데이트 또는 표시한 정확한 페이지를 보고하세요. 출처 편입을 단순 추출로만 취급하지 마세요. 출처 추적 정보와 불확실성을 보존하면서 출처를 기존 지식 모델에 통합해야 합니다. ## 근거가 되는 페이지를 밝혀 연구 질문에 답하기 질문을 받으면 다음 단계를 따르세요. 1. 인덱스를 읽어 관련 가능성이 높은 페이지를 찾으세요. 2. 답변에 충분한 최소한의 출처, 엔터티, 개념, 종합 분석 페이지를 읽으세요. 3. 출처의 주장과 자신의 종합 분석을 구분하세요. 4. 근거 페이지를 가리키는 인라인 내부 인용을 포함해 답하세요. 5. 억지로 합의를 만들지 말고 모순, 불확실성, 누락된 근거를 밝히세요. 6. 답변을 영구적인 종합 분석 페이지로 저장하기 전에 확인을 요청하세요. 저장된 종합 분석에는 답변 대상 질문을 기록하고, 이를 뒷받침하는 출처로 연결하며, 나중에 새로운 근거가 들어오면 개정할 수 있는 상태를 유지해야 합니다. 기반 출처 페이지를 사용할 수 있다면 인덱스 항목을 근거로 인용하지 마세요. 출처 추적 사슬에서 근거에 가장 가까운 권위 있는 페이지를 우선하세요. ## 내용을 깊이 점검하기 전에 페이지 구조부터 빠르게 확인하기 비용이 큰 의미 분석에 앞서 빠른 구조 건전성 검사를 실행하세요. 구조 건전성 검사는 결정론적 검사만 사용하고 모델을 호출하지 않습니다. 다음 항목을 감지해야 합니다. - 비어 있거나 뼈대뿐인 페이지. - 실제 페이지와 일치하지 않는 인덱스 항목. - 출처 편입 로그 항목이 없는 출처 페이지. 작업 세션을 시작할 때와 의미 린트를 실행하기 전에 구조 건전성을 검사하세요. 의미 린트는 콘텐츠 품질을 평가하며 모델 분석을 사용할 수 있습니다. 출처를 10~15건 편입한 뒤와 같이 정기적으로 실행하고 다음 항목을 검사하세요. - 들어오는 링크가 없는 고립 페이지. - 끊어진 내부 링크. - 페이지 간 모순. - 새로운 출처로 대체된 오래된 요약. - 반복해서 등장하지만 엔터티 페이지가 없는 엔터티. - 나가는 링크가 두 개 미만인 희소 페이지. - 답하지 않은 질문과 누락된 근거. 그래프 데이터가 있다면 내용이 빈약한 고차수 허브, 단 하나의 에지로만 연결된 커뮤니티 쌍, 고립된 커뮤니티도 보고하세요. 구조 건전성 검사를 통과하기 전에는 의미 분석 리소스를 사용하지 마세요. ## 페이지 링크로 지식 그래프를 만들고 약한 곳 찾기 관리 중인 페이지마다 하나의 노드를, 명시적인 내부 링크마다 하나의 에지를 만드세요. 그래프 데이터를 생성할 때는 다음 단계를 따르세요. 1. 관리 중인 모든 페이지에서 명시적 링크를 분석하세요. 2. 기계 판독 가능한 그래프 데이터에 노드, 에지, 구축 날짜를 기록하세요. 3. 유용한 경우 자체 완결형 시각화를 생성하세요. 4. 에지 대 노드 비율, 고립 페이지 비율, 커뮤니티 수, 링크 밀도를 계산하세요. 5. 평균에 표준편차 두 배를 더한 값보다 높은 고차수 허브를 찾으세요. 6. 500자 미만인 고차수 페이지를 내용이 빈약한 허브로 표시하세요. 7. 단 하나의 에지로만 연결된 커뮤니티 쌍을 취약한 다리로 표시하세요. 8. 두 개 이상의 페이지가 같은 누락 대상을 가리키면 누락 페이지 참조를 보고하세요. 추론된 관계에는 신뢰도 점수를 부여하고 `INFERRED`로 표시해야 합니다. 신뢰도가 낮은 추론은 `AMBIGUOUS`로 표시하고, 출처에 명시적으로 근거한 링크인 것처럼 절대 제시하지 마세요. ## 자동 링크는 초안으로 두고 끊어진 링크로 페이지를 만들지 않기 자동으로 제안된 링크를 초안으로 취급하세요. 1. 제안된 에지를 페이지 본문에는 쓰지 말고 `DRAFT` 상태로 그래프에 추가하세요. 2. 각 제안이 출처 콘텐츠에 근거하며 기존 지식과 일치하는지 검증하세요. 3. 검증을 통과한 제안만 승격하세요. 4. 승격된 에지를 내부 링크로 구현하세요. 5. 페이지를 안정 상태로 승격하기 전에 나가는 링크를 두 개 이상 요구하세요. 끊어진 링크를 바탕으로 페이지를 절대 자동 생성하지 마세요. 누락 대상을 연구 또는 큐레이션 신호로 보고하세요. 자동 생성은 환각으로 만들어진 참조를 증폭하게 됩니다. 기존 명령이나 워크플로가 같은 작업을 지원한다면 새 명령이나 워크플로를 추가하지 마세요. 대신 기존 진입점을 확장하거나 명확히 하세요. 모든 유지 관리 작업에서 불변 출처, 추가 전용 이력, 출처 추적 링크를 보존하세요. 생성된 그래프 결과물을 덮어쓰기 전에 관리 중인 페이지에서 결정론적으로 다시 구축할 수 있는지 확인하세요.