knowledge-meeting-ingest

회의 수집

하나의 전사본을 출처가 명시된 회의 페이지, 업데이트된 엔티티 프로필, 구조화된 주장으로 변환한 다음 검증합니다. 각 단계가 필요할 때만 참조 문서를 읽으세요:

• 설정: 항상, 먼저 (상태, 온톨로지, 검색)
• 출처 확보: API(Granola 포함)에서 가져오기
• 출처: 원본 보존; 인용 형식
• 화자: 가능한 분할, 중복 또는 불명확한 화자
• 신원: 사람, 회사 또는 프로젝트 식별
• 작성: 페이지 내용을 작성하기 전에
• 회의 페이지: 회의 페이지 작성
• 프로필: 프로필 생성 또는 업데이트
• 주장: 주장, 참석 관계(edge), 재실행
• 출판: 배치 또는 페이지 단위 쓰기
• 복구: 불확실, 거부 또는 충돌하는 쓰기 작업
• 검증: 검증 및 보고

계약

• 실제 회의당 하나의 페이지. 전체 전사본을 보관하세요; 녹음기의 요약은 주장(claim)이지 사실이 아닙니다.
• 화자는 증거와 신뢰도에 기반하여 식별되며, 추측하지 않습니다. 모든 실제 신호를 사용하고, 신호가 전혀 없을 때만 화자를 미해결 상태로 둡니다.
• 모든 참가자(발언, 지목, 또는 기타 방식으로 참여)는 타임라인 항목과 참석 관계(edge)가 있는 프로필을 받습니다. 초대 목록에만 있는 이름은 아무것도 받지 못합니다.
• 회의에서 실질적인 내용을 언급한 모든 회사, 프로젝트 또는 개념은 (발견되거나 생성된) 페이지, 타임라인 항목 및 양방향 링크를 받습니다. 단순 언급은 제외됩니다.
• 페이지는 좋은 인간의 노트처럼 읽혀야 합니다: 이름을 먼저, 적은 수의 주의사항, 절차적 설명 없음.
• 결정, 약속 및 이벤트는 주장(claim)이 됩니다. 검증되지 않은 주장은 다른 페이지로 퍼지지 않습니다.
• 검증을 통과할 때까지 회의가 완전히 수집되었다고 말하지 마십시오.

단계

1. 확보 및 정규화

완전한 전사본을 가져옵니다. 빈 내용, 요약본만 있거나 진행 중인 입력은 이 단계에서 실패합니다: 보고하세요. 사용자가 노트만 저장하기를 원한다면 knowledge-capture를 사용하고 회의 수집이 완료되지 않았다고 말하세요.

작업 컨텍스트에서 다음으로 정규화하세요: source, source_id, title, date, time, duration, attendees (출처 주장), speaker, speaker_raw 및 text가 포함된 정렬된 세그먼트, 출처 요약, URL. 알 수 없는 값은 null입니다. 녹음기별 처리는 여기서 끝납니다; 모든 녹음기는 이후 동일한 단계를 실행합니다.

원본 내보내기와 전사본을 보관하세요 (출처). 정규화된 텍스트는 레이블이 지정된 파생물입니다. 획득, 보관 및 게시를 실제 개수와 함께 별도로 보고하세요 ("9/16 원본 보관됨").

정규화된 전사본을 약 150줄 섹션으로 한 번 읽습니다. 각 섹션 후에 작업 다이제스트(digest) 파일에 다음을 추가하세요: 줄 범위, 누가 말했는지, 주제, 후보 결정, 약속 및 정확한 줄 인용이 포함된 사실, 인용문 후보, 그리고 새로운 고유 명사. 이후 단계는 다이제스트를 기반으로 작성합니다. 특정 줄 범위(표현 확인 또는 인용문 확인)를 위해서만 전사본으로 돌아가고, 전체를 다시 읽지 마십시오.

완료 조건: 완전한 전사본 보관됨; 증거 영수증 확보됨; 다이제스트가 모든 줄을 포함함.

2. 분할, 중복 제거, 화자 식별

다중 회의 녹음, 이 회의에 대한 기존 페이지 및 화자 매핑을 확인합니다 (화자).

완료 조건: 각 실제 회의에 세그먼트 범위 지정됨; 중복 발견됨; 모든 화자 레이블이 매핑되거나 명시적으로 미해결 상태이며 근거가 있음.

3. 각 주문 검증

제안된 모든 주장을 전사본 및 동일한 엔티티에 대한 기존 지식과 대조하여 확인합니다.

• 역할 또는 관계: 명시적인 구절, 암시가 아님.
• 소유권: 명시적인 소유권 표현; 이름을 언급하는 것은 소유를 의미하지 않음.
• 새로운 고유 명사: 지식 저장소를 검색한 다음 (허용된다면) 웹에서 표준 철자를 검색합니다; 그렇지 않으면 Name (unverified spelling)으로 작성하고 페이지나 링크를 제공하지 않습니다.
• 주요 인생 또는 거래 이벤트: 그대로 지원되는지 확인하고 기존 연대기와 대조합니다.

전사본 지원만으로는 충분하지 않습니다. 또한 다음을 확인하세요:

• 모순: 기존 지식과 충돌합니까? 기본적으로 기존 내용이 우선합니다. 충돌하는 주장을 프로필에 쓰지 말고, 회의 페이지에 두 인용문과 함께 보관하고 사용자가 해결할 수 있도록 보고서에 나열하세요. 명시적이고 그대로의 지원이 있는 경우에만 재정의하고, 여전히 변경 사항을 보고하세요.
• 개연성: 다른 알려진 정보를 고려할 때 가능합니까? (두 사람이 같은 프로젝트를 시작할 수 없음; 작년에 설립된 회사가 5년 전에 인수될 수 없음.) 불가능성은 일반적으로 왜곡을 의미합니다.
• 놀라움: 사용자가 "잠깐, 뭐?"라고 말할 만한 내용이라면 모든 검사를 적용하세요. 놀라움을 질문으로 표면화하고 설명하려고 하지 마세요.

추론 및 불확실한 신원은 회의 페이지에 레이블이 지정된 상태로 유지되며 프로필, 타임라인, 메타데이터 또는 관계에 사실로 입력되지 않습니다.

완료 조건: 각 주장이 게시, 불확실로 레이블 지정 또는 보류로 표시됨.

4. 게시

순서: 회의 페이지 → 엔티티 페이지 → 주장 및 관계 → 링크 편집. 관련 레코드를 일괄 처리합니다 (게시).

• 회의 페이지에 따른 회의 페이지.
• 각 참가자 및 실질적 엔티티에 대해 knowledge-entities의 SKILL.md에 있는 단계를 따르세요: 엔티티를 식별하고, 페이지를 받을지 결정하며, 프로필 및 타임라인 항목을 작성합니다. 이 스킬과 동일한 이름을 가진 해당 참조 문서는 동일한 복사본입니다; 이미 읽은 것을 사용하고 다시 읽지 마세요. 유일한 추가 참조는 보강(해당 문서의 "수집 중" 섹션 읽기)입니다.
• 주장에 따른 주장: 결정, 약속, 사실 및 회의 자체에 대한 source_event: true 이벤트 하나(관련 entities 포함). 다른 이벤트는 자체 날짜를 유지합니다.
• 참가자당 입증된 attended 관계. 제공된 온톨로지에서는 participant → meeting으로 실행됩니다; 정의에서 확인하세요. source_page를 설정합니다.
• 페이지가 있는 언급된 사람들은 링크도 받습니다. 알 수 없는 화자를 위해 페이지를 생성하지 마세요.
• 법적 또는 개인적 콘텐츠의 경우 회의 페이지를 사실적으로 유지하고 프로필로의 확산을 제한하세요; 범위가 불명확하면 물어보세요.

완료 조건: 모든 계획된 레코드가 작업 로그에 게시 영수증을 가지고 있음.

5. 검증 (엄격한 게이트, 모든 회의)

먼저 검증을 실행합니다. 그런 다음 확인하세요:

• 내용: 필수 섹션에 내용 또는 출처 기반 이유가 있습니다.
• 링크: knowledge_verify expectedLinks는 meeting ↔ 각 엔티티, plus claim entities/dependencies, commitment owner, edge from/to/label/source_page를 확인합니다. 연결된 모든 프로필에는 이 회의에 대한 타임라인 항목이 있습니다.
• 상태: 업데이트된 프로필에 날짜나 회의 이름이 지정된 State 주제가 없습니다.
• 스타일: 게시 전에 작성과 대조하여 작업 파일의 초안을 확인하세요: 이름 먼저, 누적된 주의사항 없음, 자신에 대한 메모 없음, 채우기 줄 없음. 스타일을 확인하기 위해 게시된 페이지를 다시 읽지 마세요; 수정 후에는 변경한 섹션만 다시 읽으세요.
• 화자: 원시 레이블이 알려진 사람으로 전달되지 않음; 화자에서 가짜 참석자 확인을 실행하세요.
• 인용문: knowledge_evidence_read를 사용하여 인용된 각 범위의 줄을 읽으세요. 채우기 단어("like", "you know")만 다를 수 있습니다. 실패한 인용문은 원래 말한 단어를 복원하거나 더 깔끔한 범위를 선택하여 수정하세요; 인용문에 의역을 절대 유지하지 마세요.
• 순서: 서술된 순서(이전/동안/이후, 장소, 사람)를 타임스탬프와 비교하고, 제목 순서와 독립적으로 확인하세요. knowledge_chronicle_day(회의 날짜 및 시간대) 및 관련 엔티티에 대한 knowledge_timeline을 사용하세요. 역전되거나 불가능한 장소/시간은 모순입니다; 절대 이동을 만들어내지 마세요. 수정하고 재확인하거나, 명시적 사용자 면제를 해결됨(resolved)이 아닌 WAIVED로 기록하세요. 면제는 순서에만 적용됩니다. 당일 연대기에서 참가자가 누락된 것은 일반적으로 타임라인 항목이 누락되었음을 의미합니다: 조사하고 차단하지 마세요. 진정으로 모호한 순서는 차단하지 않고 보고서에 표시됩니다.

완료 조건: 모든 검사 통과, 또는 실패가 수정되고 재확인됨.

보고서

회의당 한 줄 (분할 녹음의 경우 페이지당 하나): 페이지, 보관된 출처, 보강된 참가자, 업데이트되거나 재사용된 엔티티, 작업 항목, 주장 및 관계, 검증 결과, 순서 PASS 또는 WAIVED (미해결 모순 포함). 기존 지식과의 모순, 보류된 주장, 미해결 신원 및 남은 작업을 페이지가 아닌 여기 보고서에 나열하세요; 사용자가 해결합니다. 검사를 통과할 수 없으면 회의가 수집되지 않았다고 보고하고 검사 이름을 지정하세요. 부분 보고서는 완료가 아닌 정직한 진행 상황입니다.