wiki-synthesize은(는) 무엇을 하나요?
처음 실행하기 전에 키트의
docs/GOTCHAS.md(수집, 종합 및 린트를 위한 운영상의 주의사항)와docs/SEALS.md(봉인 형식)를 읽으십시오.
'살아있는 종합(living-synthesis)' 레이어의 '외과의'입니다. 이미 검증된 발견 저장소(개념 노트의 ## Key Findings, 방법 노트의 주장을 담은 섹션)를 재구성하여 증거의 흐름(해결됨, 논쟁 중, 대체됨, 새로 등장함)을 포착하는 '지식 상태(State-of-Knowledge)' 블록을 만듭니다. 절대 주장을 만들어내지 않습니다. 모든 항목은 기존 발견을 추적하며, 모든 새 항목이나 변경된 항목은 사용자가 승인하기 전에 인용된 각 작업의 PDF와 대조 확인됩니다(증거 확인, 층위 2).
모드
- 기본:
/wiki-synthesize <NoteName>하나의 개념 또는 방법 노트를 종합합니다. - 작업 목록:
/wiki-synthesize(인수 없음)wiki-lint검사 15를 실행한 후,check15_missing을 우선순위별로(먼저synthesis.priority_fields에 나열된 필드, 그 다음 출처 작업 수 기준 내림차순) 그리고check15_stale(재종합 후보)을 제시하며, 처리할 노트를 묻습니다. 작업 목록은 백로그이지, 지금 모두 처리해야 하는 목록이 아닙니다. 적격 세트는 검사 15가 실시간으로 보고하는 내용입니다. 문서에 기록된 고정된 개수는 유효하지 않습니다. - 배치:
/wiki-synthesize --batch [N]예외 기반 관리(management-by-exception) 캠페인 모드입니다(기본 파동 크기 8). 검사 15를 실행하고, 우선순위 파동을 구성하며, 병렬 하위 에이전트를 파견합니다(각 하위 에이전트는SYNTHESIS-WORKFLOW.md를 따르고 블록과 자체 보고서를 반환하며, 절대 쓰지 않습니다), 모든 쓰기 작업을 증거 확인 및scripts/synth_validate.py로 검증하고, 깨끗한 노트를 작성하며, 4가지 트리거(T1 확인 불가능한 주요 숫자, T2 정보 손실, T3 구조적 이상, T4 하위 에이전트 신뢰도 낮음)와 검사에서 발견된 모든 결함에 대해 에스컬레이션합니다.references/BATCH-WORKFLOW.md를 참조하십시오. 먼저 사용자에게 파동의 하위 에이전트를 제안하십시오(그들이 무엇을 하는지, 몇 명인지, 어떤 모델인지) 그리고 진행 승인을 기다리십시오.
역할 및 경계
수행하는 작업: 노트의 발견 저장소를 읽고, evidence_level과 인라인 측정값을 기준으로 가중치를 부여하고, 블록을 초안 작성하고, 각 새 항목 또는 변경된 항목을 PDF와 대조 확인하고, 승인을 위해 제시한 후, 작성(블록 삽입 및 ## Controversies or Gaps 흡수)하고, 출처 노트를 봉인하고, 게이트를 실행하고, 기록합니다.
수행하지 않는 작업: 숫자나 주장을 만들어내지 않고, debates/ 노트를 생성하지 않으며(대신 보고서에 후보를 표시), 종합 임계값 미만의 노트를 건드리지 않으며, 사용자가 승인하기 전에 아무것도 쓰지 않습니다.
위치
경로는 wiki.config.json에서 가져옵니다. 노트: <wiki_root>/concepts/, methods/, papers/, books/. 시작하기 전에 항상 WIKI_SCHEMA.md (Living-Synthesis Layer)를 읽으십시오.
임계값 (종합 전에 반드시 충족해야 함)
status: final AND (synthesis.min_sources개 이상의 고유 출처 작업(기본값 3) OR evidence_level이 synthesis.sr_levels(기본값 SR-MA, SR)에 있는 출처 작업이 최소 하나 이상). 이는 정확히 wiki-lint 검사 15의 자격 테스트입니다. 충족되지 않으면: 보고하고 중지합니다.
워크플로
전체 절차는 references/SYNTHESIS-WORKFLOW.md에 있습니다. 요약: 계약 읽기, 노트 확인(정확한 test -f/내용 검색, 글로브 단독 사용 금지), 임계값 게이트, 전문 사전 가드, 발견을 하위 질문으로 클러스터링, 새 항목이나 변경된 항목을 PDF와 대조 확인, 인용 및 페이지와 함께 채팅에서 블록 제안, 승인, 작성(scripts/synth_write.py: ## Definition 뒤에 삽입, Controversies 흡수, 스탬프), 출처 노트 봉인(<kit>/tools/seal.py), 블록이 이미 존재하는 경우 재종합 차이(diff) 생성, 그런 다음 기록, 게이트 재실행 및 검사 15 재실행.
안전 규칙
- 절대 만들어내지 마십시오. 모든 항목은 기존 발견을 추적합니다. 메모리나 출처 노트에서 새로운 숫자를 가져오지 마십시오.
- 증거 확인, 층위 2: PDF 확인 없이 새 항목이나 변경된 항목을 만들지 마십시오. 최대 3개의 고유 작업은 오케스트레이터가 확인합니다. 그 이상이면 오케스트레이터가 차이(diff)로 제한된 브리프를 가진 하위 에이전트를 제안하고 사용자의 승인을 기다립니다. 모든 결함은 변경 전에 PDF에서 다시 읽히며, 출처 노트는 노트 이름으로 봉인됩니다. 출처 노트에 대한 전문 봉인(fulltext seal)이 해당 작업에 대해 노트가 말하는 내용을 보호하지는 않습니다. 이 방법의 과거 감사에서, 표본으로 뽑힌 노트-출처 노트 쌍의 약 40%에 결함이 있었습니다.
- 인간 개입. 대화형 모드: 제안, 승인, 작성(사용자의 승인 없이 작성하지 않음). 배치 모드:
synth_validate.py가 모든 쓰기를 검증하고 4가지 트리거가 에스컬레이션됩니다. 절대 완전 자율적이지 않습니다. - 정보 손실 제로.
## Controversies or Gaps의 모든 항목은 해당 섹션이 흡수되기 전에 블록 항목에 매핑되어야 합니다. - 전문 사전 가드. 전문 사전 코호트(전문 사전 차단 날짜 이전에 작성되고 전문이 봉인되지 않았거나 초록 수준에서만 봉인된 논문 노트)에 인용된 논문은 영향을 받는 항목의 신뢰도를 낮추고 인라인
⚠플래그를 얻습니다. 항목이 의존하는 숫자 자체가 확인 불가능한 경우에만 해당 항목을 중단하십시오. 자체status:가draft또는stub인 경우를 제외하고 책 장(chapter)은 신뢰할 수 있는 앵커입니다. 이는 노트가 전문 없이 수집되었음을 명시하는 것입니다(전문 수준의source_verification이 상태를 재정의함).synth_validate.pyV4가 이를 기계적으로 적용합니다. - 주장에는 출처가 필요합니다. 각 항목은
[[wikilinks]]를 인용합니다. - 파일 시스템 우선. 호스트의 파일 도구를 사용하십시오. Obsidian 플러그인이나 MCP는 필요하지 않습니다.
관련 스킬
wiki-lint: 검사 15는 이 스킬의 작업 목록을 생성합니다. 검사 32는 (노트, 작업) 쌍에 봉인이 없는지 플래그를 지정합니다. 종합 후 이를 실행하여 드리프트가 없는지 확인하십시오(링크 검사 통과, 검사 15가 노트를missing에서 제거).wiki-ingest: 업스트림. 이 스킬이 재구성하는 발견은 ingest에 의해 작성되었습니다.
참조
references/SYNTHESIS-WORKFLOW.md: 상세 절차, 블록 템플릿, 가드 로직, 재종합 처리.references/BATCH-WORKFLOW.md: 배치 모드, 오케스트레이터 루프, 하위 에이전트 브리프, V1-V5 쓰기 게이트, 에스컬레이션 트리거.scripts/synth_validate.py: 쓰기 게이트 및 전체 위키 스위프.scripts/synth_write.py: 블록 삽입.<kit>/tools/seal.py: 봉인.