task_procedure: IN: nexts: ["Task_A", "Task_B1"] wait_until: [] Task_A: nexts: ["Task_A_save_results", "Task_C"] wait_until: ["IN"] Task_A_save_results: nexts: ["OUT"] wait_until: ["Task_A"] Task_B1: nexts: ["Task_B2"] wait_until: ["IN"] Task_B2: nexts: ["Task_C"] wait_until: ["Task_B1"] Task_C: nexts: ["Task_C_save_results", "Task_B3", "Task_D1"] wait_until: ["Task_A", "Task_B1", "Task_B2"] Task_C_save_results: nexts: ["OUT"] wait_until: ["Task_C"] Task_B3: nexts: ["Task_D2"] wait_until: ["Task_B1", "Task_C"] Task_D1: nexts: ["OUT"] wait_until: ["Task_B1", "Task_C"] Task_D2: nexts: ["OUT"] wait_until: ["Task_B3", "Task_C"] OUT: nexts: [] wait_until: ["Task_A_save_results", "Task_C_save_results", "Task_D1", "Task_D2"] -------------------------------------------- 이 DAG의 의미는 단순하다. - Task_B1이 먼저 증거 식별자 권위본을 만든다. - Task_B2는 그 권위본을 사용하여 raw evidence를 event-level intermediate로 분해한다. - Task_C는 raw evidence_all.json 대신 evidence_event_candidates.json을 읽어 BO를 만든다. 따라서 토큰 폭발을 줄이면서도, meeting에 없는 사건행위를 evidence에서 보완하는 본래 목적은 그대로 달성된다. - Task_B3는 Task_C가 남긴 사해행위 의심 신호를 이용하여 정확한 actio support만 추출한다. - Task_D1과 Task_D2는 기존 철학을 거의 유지한다. D1은 BO를 1차 소스로 fact를 만들고, D2는 BO와 actio support를 조인한다. -------------------------------------------- 1. 새 번호 체계와 역할 재정의 이제부터 번호는 아래 의미로 고정하는 것이 맞다. - Task_B1: 증거 authority catalog 생성 - evidence_all.json → evidence_indexed.json - Task_B2: 증거문서 사건행위 후보 추출 (신설; 당신의 요구사항 2) - evidence_all.json + evidence_indexed.json → evidence_event_candidates.json - Task_C: 사건구조 합성 - client_meeting.md + Juristic_Act.md + evidence_event_candidates.json + evidence_indexed.json → BO.json + actio_case_signals.json - Task_B3: 사해행위 support 추출 (기존 Task_B2의 개명판; 당신의 요구사항 1, 3) - evidence_indexed.json + evidence_all.json + client_meeting.md + BO.json + actio_case_signals.json → evidence_actio_support.json 이 구조가 되어야 Task_B3가 단순 문서 스캐너가 아니라, Task_C가 이미 파악한 사건 구조와 사해행위 의심 정황을 이용하는 scoped extractor가 된다. 이것이 당신의 요구사항 1의 정확한 구현이다. -------------------------------------------- # Task_A IN: client_meeting.md OUT: client_goal.json # Task_B1 IN: evidence_all.json OUT: evidence_indexed.json -------------------------------------------- 4. Task_B1 재설계안 Task_B1의 본질은 유지하되, 역할을 더 엄격하게 제한해야 한다. 현재 B1은 이미 token-lean catalog를 만드는 authority task로 설계되어 있고, actio support는 만들지 않도록 되어 있다. 이 점은 유지하는 것이 맞다. Task_B1의 수정된 역할 - evidence_indexed.json의 유일한 권위본 생성 - evidence_index, title, doc_type, source_pointer.ordinal의 안정적 부여 - 최소 key_*와 선택적 base legal_calculation_object만 생성 - 절대 하지 말아야 할 일 - BO 추출 - event candidate 분해 - actio support 생성 5. Task_B2 재설계안 Task_B2의 역할 - evidence_indexed.json의 evidence_index와 source_pointer.ordinal을 기준으로 - evidence_all.json 각 문서를 - 법적 중요 사건행위 후보들의 리스트로 분해하여 - evidence_event_candidates.json을 생성한다. 입력과 출력 - IN: evidence_indexed.json, evidence_all.json, client_meeting.md - OUT: evidence_event_candidates.json 여기서 client_meeting.md는 사건을 덮어쓰는 용도가 아니라, 당사자 alias 정규화, 사건상 중요도 판단의 보조, 금액/대상물 표현의 문맥보조에만 사용한다. -------------------------------------------- 6. Task_C 재설계안 Task_C의 역할 재정의 - client_meeting.md에서 BO 후보 생성 - evidence_event_candidates.json에서 meeting에 없는 BO 후보 보강 - 중복 제거 - Juristic_Act.md를 이용해 ActionType, JuristicAct 확정 - 시간순 정렬, PriorAct, Reason 구성 - 증거 매칭은 evidence_indexed.json 기준으로 수행 - 동시에 사건 전체를 훑어 사해행위 의심 구조가 있는지 machine-readable하게 기록 새 입력 - client_meeting.md - evidence_event_candidates.json - evidence_indexed.json - Default_Agent/Juristic_Act.md 새 출력 - BO.json - actio_case_signals.json - Task_C_result.md (human-readable summary; 기존 유지) 나는 여기서 actio_case_signals.json을 추가하는 것이 필수라고 본다. B3가 markdown 문장을 파싱하도록 만드는 것은 결정론적으로 매우 나쁘다. Task_C의 “사해행위 의심 정황”은 machine-readable JSON으로 남겨야 한다. `actio_case_signals.json` 최소 구조 ``` { "is_actio_pauliana_suspected": true, "suspicion_level": "high", "suspicion_reasons": [ "채무자 자산 처분 후보가 존재함", "원고채권 존속 후보가 존재함" ], "related_bo_ids": ["bh11", "bh12"], "related_evidence_indexes": ["E-014", "E-015"], "target_property_candidates": ["여의도 장미아파트 14동 101호"], "fraudulent_act_date_candidates": ["2016-01-31"], "preserved_claim_candidates": [ { "bo_id": "bh2", "claim_type_candidate": "보증/구상", "creditor_candidate": "원고", "debtor_candidate": "채무자" } ], "beneficiary_candidates": ["수익자 성명"], "encumbrance_related_evidence_indexes": ["E-016", "E-017"] } ``` -------------------------------------------- 7. Task_B3 재설계안 이제 B3는 더 이상 “blind doc-level actio extractor”가 아니다. 반드시 Task_C가 남긴 사건 구조와 사해행위 의심 신호를 이용해야 한다. 새 입력 - evidence_indexed.json - evidence_all.json - client_meeting.md - BO.json - actio_case_signals.json 출력 - evidence_actio_support.json 역할 - Task_C가 사해행위 의심을 기록했을 때 - 관련 목적물, 관련 보전채권, 관련 부담·임차권·가압류, 수익자 이익 후보를 중심으로 - 문서별 sparse actio support를 정밀 추출한다. 핵심 원칙 - Task_C가 identified한 목적물/BO/증거를 우선 스코핑한다. - 사건 전체를 다시 백지에서 actio로 분류하지 않는다. - fraudulent_act_date는 Task_C가 잡아낸 목적물 처분 cluster에 직접 속하는 문서에서만 candidate로 올린다. - proof_doc는 현재 문서의 evidence_index만 사용한다. - 출력 스키마는 기존 evidence_actio_support.json과 호환되게 유지한다. 그러면 D2는 거의 그대로 둘 수 있다. -------------------------------------------- 9. 최종 정리 최종적으로 Stage 1의 B 계열은 아래 3층으로 나뉘는 것이 맞다. B1 = authority layer - evidence_all.json → evidence_indexed.json B2 = event decomposition layer - evidence_all.json + evidence_indexed.json → evidence_event_candidates.json B3 = actio support layer - evidence_all.json + evidence_indexed.json + BO.json + actio_case_signals.json → evidence_actio_support.json 그리고 Task_C는 그 사이에서 meeting + evidence event candidates를 결합하여 BO와 사건 구조를 확정하는 synthesis layer가 된다. 이 설계가 좋은 이유는 단순하다. - B1은 식별자 권위본을 안정화한다. - B2는 token-lean catalog가 잃어버린 문서 내부 다중 사건행위 정보를 복원한다. - C는 raw evidence 대신 event-level intermediate를 사용하므로 토큰 폭발을 피한다. - B3는 C가 파악한 사건 구조를 이용해 사해행위 support를 정확히 스코핑한다. - D1과 D2, 그리고 Stage 2의 E-### 중심 조인 구조와도 자연스럽게 이어진다. 원하면 다음 단계로 바로 이어서, 내가 위 설계를 기준으로 Legal_Agent_V4_v3.yaml에 실제로 삽입할 수 있는 Task_B2, Task_C, Task_B3의 완성형 prompt 본문과 task_procedure patch를 YAML 형식으로 통째로 작성 -------------------------------------------- # stage1_task_B2_C_B3_patch.yaml 이 patch는 현재 Stage 1의 구조, 즉 Task_B1 뒤에 곧바로 기존 Task_B2가 evidence_actio_support.json을 만들고, Task_C는 별도로 client_meeting.md, evidence_all.json, Juristic_Act.md를 읽어 BO.json을 만든 뒤, Task_D1이 BO.json + evidence_indexed.json, Task_D2가 BO.json + evidence_actio_support.json을 사용하는 구조를 전제로 작성했다. 따라서 B 계열의 역할만 재배치하고 D1/D2의 기존 인터페이스는 최대한 보존했다. 적용 방식은 네 줄로 요약된다. - Task_B2 기존 블록을 patch의 새 Task_B2로 교체 - Task_C 기존 블록을 patch의 새 Task_C로 교체 - 새 Task_B3 블록을 Task_C 뒤, Task_C_save_results 앞에 삽입 - stage1_사건개요파악.task_procedure를 patch의 task_procedure로 교체 # Stage 2를 위해 알고 있어야 할 전제 지식 stage1_yaml_patch_proposal.md --> Task_B1 실무적으로는 이 patch를 적용한 뒤, 다음 단계로 Stage 2의 claim_information 생성기에서 evidence_ref_structs, asset_scope_key, fact_role_candidate를 실제로 소비하도록 수정해야 한다. 그래야 Stage 1에서 만든 안전장치가 Stage 2에서 완전히 효력을 가진다. --- Task_B1 교체용 프롬프트 ``` - task_name: Task_B1 llm_provider: google llm_model: gemini-3.1-flash-lite-preview llm_reasoning: medium use_tools: [localdocs] prompts: - role: user content: | ## 실행방법(체크리스트) [ ] 1) Preflight: `list_docs` 사용해서 `evidence_all.json`, `client_meeting.md`만 확인하고, `read_docs` 사용해서 `evidence_all.json`, `client_meeting.md`만 읽기 [ ] 2) `write_file` 사용해서 `evidence_indexed.json` 생성 [ ] 3) `list_docs` 사용해서 `evidence_indexed.json` 파일만 존재 확인(절대 읽기 금지) [ ] 4) `"증거문서 인덱싱 완료"` 출력하고 작업 종료 ## 역할/목적 당신은 Stage 1의 증거 authority catalog 생성기다. 이 작업의 유일한 목적은 `evidence_all.json`에 안정적인 `E-###` 인덱스를 부여하고, 후속 단계가 사용할 수 있는 경량 증거 카탈로그 `evidence_indexed.json`을 만드는 것이다. ## 필수 IO ### IN - evidence_all.json - client_meeting.md ### OUT - evidence_indexed.json ## 핵심 규칙 1. `evidence_indexed.json`은 이후 모든 단계가 신뢰하는 유일한 증거 authority다. 2. `source_pointer.ordinal`은 반드시 원본 `evidence_all.json` 배열 순서와 정확히 일치해야 한다. 3. `evidence_index`는 E-001부터 순서대로 부여한다. 4. `key_facts`, `key_dates`, `key_amounts`, `key_parties`는 최소한으로만 추출한다. 5. `legal_calculation_object`는 현재 문서가 직접 뒷받침할 때만 선택적으로 1개까지 허용한다. 6. `actio_pauliana_support`는 절대 생성하지 않는다. 7. event-level 분해는 절대 하지 않는다. 그것은 `Task_B2`의 책임이다. 8. 원문 대량 복사 금지. 요약, 정규화, 포인터 중심으로만 작성한다. ``` Task_B2 교체용 프롬프트 ``` - task_name: Task_B2 llm_provider: google llm_model: gemini-3.1-flash-lite-preview llm_reasoning: medium use_tools: [localdocs] prompts: - role: user content: | ## 실행방법(체크리스트) [ ] 1) Preflight: `list_docs` 사용해서 `evidence_indexed.json`, `evidence_all.json`, `client_meeting.md`만 확인하고, `read_docs` 사용해서 세 파일만 읽기 [ ] 2) `write_file` 사용해서 `evidence_event_candidates.json` 생성 [ ] 3) `list_docs` 사용해서 `evidence_event_candidates.json` 파일만 존재 확인(절대 읽기 금지) [ ] 4) `"증거문서 사건행위 후보 추출 완료"` 출력하고 작업 종료 ## 역할/목적 당신은 Stage 1의 증거-사건행위 분해기다. `evidence_indexed.json`을 authority로 사용하여, `evidence_all.json` 각 문서에서 권리/의무/책임의 발생·변경·소멸과 관련된 법적 중요 사건행위 후보를 빠짐없이 추출한다. ## 필수 IO ### IN - evidence_indexed.json - evidence_all.json - client_meeting.md ### OUT - evidence_event_candidates.json ## 불가침 원칙 1. `evidence_indexed.json`의 `evidence_index`와 `source_pointer.ordinal`을 유일한 문서 식별 기준으로 사용한다. 2. 한 문서에 여러 사건행위가 있으면 반드시 여러 `event_candidates`로 분해한다. 3. 문서 단위 1요약으로 뭉개지 않는다. 4. `client_meeting.md`는 alias 정규화와 중요도 보조에만 사용한다. 5. 문서에 없는 사건행위를 meeting만으로 새로 만들지 않는다. 6. 최종 BO, 최종 JuristicAct, 최종 청구권은 결정하지 않는다. 7. 이 단계는 candidate layer다. 확정 판단을 금지한다. 8. 원문 장문 복사 금지. `support_locators.excerpt`는 짧게 유지한다. ## 추출 대상 - 소유권 이전 / 매매 / 증여 / 대물변제 - 근저당·저당 설정 / 말소 - 대여 / 보증 / 신용보증 / 대위변제 / 구상권 발생 / 변제 / 배당 - 임대차 / 임차보증금 - 가압류 / 압류 / 강제집행 관련 기재 - 통지 / 최고 / 판결·결정 등 법적 중요 사건행위 ## 산출 규칙 1. 출력은 문서별 레코드 배열이되, 각 레코드에는 `event_candidates` 배열을 둔다. 2. `event_candidates[].candidate_id`는 반드시 `E-###-EC-##` 형식을 사용한다. 3. `identity_signature`는 Task_C의 meeting-기반 BO와 중복 제거할 때 사용할 수 있도록 `(행위종류 + 핵심당사자 + 핵심목적물/금액 + 날짜)`를 정규화한 문자열로 만든다. 4. `actio_relevance_candidates`는 최종 판단이 아니라 후보 태그만 남긴다. 5. `fraudulent_act_date_candidate`는 현재 candidate가 직접 목적물 처분/이전과 연결될 때만 기입한다. 6. 문서에서 직접 뒷받침되지 않으면 `null` 또는 빈 배열로 두되, 최종 출력에서는 pruning한다. ``` Task_C 의 actio_case_signals.json 최소 구조 ``` { "is_actio_pauliana_suspected": true, "suspicion_level": "high", "suspicion_reasons": [ "채무자 자산 처분 후보가 존재함", "원고채권 존속 후보가 존재함" ], "related_bo_ids": ["bh11", "bh12"], "related_evidence_indexes": ["E-014", "E-015"], "target_property_candidates": ["여의도 장미아파트 14동 101호"], "fraudulent_act_date_candidates": ["2016-01-31"], "preserved_claim_candidates": [ { "bo_id": "bh2", "claim_type_candidate": "보증/구상", "creditor_candidate": "원고", "debtor_candidate": "채무자" } ], "beneficiary_candidates": ["수익자 성명"], "encumbrance_related_evidence_indexes": ["E-016", "E-017"] } ``` Task_C 교체용 프롬프트 ``` - task_name: Task_C llm_provider: anthropic llm_model: claude-opus-4-5 use_tools: [localdocs] prompts: - role: user content: | ## 실행방법(체크리스트) [ ] 1) Preflight: `list_docs` 사용해서 `client_meeting.md`, `evidence_event_candidates.json`, `evidence_indexed.json`, Default_Agent/Juristic_Act.md만 확인하고, `read_docs` 사용해서 해당 파일만 읽기 [ ] 2) `write_file` 사용해서 `BO.json` 생성 [ ] 3) `write_file` 사용해서 `actio_case_signals.json` 생성 [ ] 4) `list_docs` 사용해서 `BO.json`, `actio_case_signals.json` 파일 존재만 확인(절대 읽기 금지) [ ] 5) `"사건개요를 구조적으로 파악"` 출력하고 작업 종료 ## 역할/목적 당신은 Stage 1의 사건구조 합성기다. `client_meeting.md`의 진술과 `evidence_event_candidates.json`의 증거기반 사건행위 후보를 통합하여 `BO.json`을 생성하고, 동시에 사건에 사해행위취소 구조가 의심되는지 기록한다. ## 필수 IO ### IN - client_meeting.md - evidence_event_candidates.json - evidence_indexed.json - Default_Agent/Juristic_Act.md ### OUT - BO.json - actio_case_signals.json ## 핵심 규칙 1. meeting 기반 BO와 evidence 기반 event candidate를 통합한다. 2. evidence에서 meeting에 없는 법적 중요 행위는 BO로 추가한다. 3. 중복 판정은 `identity_signature`와 `(행위종류 + 핵심당사자 + 핵심목적물/금액 + 날짜)`를 함께 사용한다. 4. `ActionType`, `JuristicAct`는 반드시 Juristic_Act.md를 기준으로 분류한다. 5. `Evidence`는 `evidence_indexed.json`의 authority를 기준으로 연결한다. 6. `EvidenceTitles`는 `Evidence[].source_title`의 uniq와 완전 일치해야 한다. 7. raw evidence 본문을 다시 뒤지지 않는다. evidence 측 입력은 `evidence_event_candidates.json`과 `evidence_indexed.json`으로 한정한다. 8. BO 생성과 별도로, 사건 전체에서 아래 정황이 함께 포착되면 `actio_case_signals.json`에 기록한다: - 자산 처분/이전 후보 - 원고채권 존속 후보 - 수익자/전득자 후보 - 부담·임차권·가압류 등 가치공제 관련 후보 - 처분시점 후보 9. `actio_case_signals.json`은 최종 법률판단이 아니라 suspicion record다. ## actio_case_signals 기록 규칙 - `is_actio_pauliana_suspected`는 true/false로 명시 - suspicion_level은 `high|medium|low|none` - 관련 BO, 관련 evidence, 목적물 후보, 처분일 후보, 보전채권 후보를 구조화해서 남긴다 - markdown 서술이 아니라 JSON 구조로 남긴다 ``` Task B3 교체 프롬프트 ``` - task_name: Task_B3 llm_provider: google llm_model: gemini-3.1-flash-lite-preview llm_reasoning: medium use_tools: [localdocs] prompts: - role: user content: | ## 실행방법(체크리스트) [ ] 1) Preflight: `list_docs` 사용해서 `evidence_indexed.json`, `evidence_all.json`, `client_meeting.md`, `BO.json`, `actio_case_signals.json`만 확인하고, `read_docs` 사용해서 해당 파일만 읽기 [ ] 2) `write_file` 사용해서 `evidence_actio_support.json` 생성 [ ] 3) `list_docs` 사용해서 `evidence_actio_support.json` 파일만 존재 확인(절대 읽기 금지) [ ] 4) `"사해행위취소 support 인덱싱 완료"` 출력하고 작업 종료 ## 역할/목적 당신은 Stage 1의 사해행위취소 support 추출기다. 다만 이 작업은 백지상태에서 수행되지 않는다. 반드시 `Task_C`가 생성한 `BO.json`과 `actio_case_signals.json`을 읽고, 그 사건 구조 및 의심 정황을 기준으로 scoping한 뒤 문서별 sparse support를 생성한다. ## 필수 IO ### IN - evidence_indexed.json - evidence_all.json - client_meeting.md - BO.json - actio_case_signals.json ### OUT - evidence_actio_support.json ## 핵심 규칙 1. `actio_case_signals.json.is_actio_pauliana_suspected == false`이면 원칙적으로 매우 보수적으로 추출하거나 `[]`를 저장한다. 2. 관련 목적물, 관련 BO, 관련 evidence, 관련 처분일 후보가 있는 경우에만 적극적으로 support를 추출한다. 3. `fraudulent_act_date`는 목적물 처분/이전 문서와 직접 연결되는 경우에만 채운다. 4. 원고채권 snapshot, 부담, 임차권, 가압류, 수익자이익도 Task_C가 남긴 cluster 안에서만 스코핑한다. 5. `proof_doc`는 반드시 현재 문서의 `evidence_index`다. 6. base catalog 필드(`title`, `doc_type`, `key_*`, `legal_calculation_object`)는 반복 저장하지 않는다. 7. 최종 결론값(common_collateral_value, preserved_claim_total, recovery_cap 등) 계산 금지. 8. 이 단계는 문서별 sparse support delta만 생성한다. ## actio scoping 우선순위 1. `actio_case_signals.related_evidence_indexes` 2. `actio_case_signals.target_property_candidates` 3. `actio_case_signals.fraudulent_act_date_candidates` 4. `actio_case_signals.preserved_claim_candidates` 5. `BO.json`에서 관련 `Evidence[].evidence_index` ``` 지금까지 다룬 모든 것들이 stage1_task_B2_C_B3_patch.yaml 에 저장되어 있다. 이후 Task D2 프롬프트도 재작성했고, Task_B3와 중복되는지 여부를 검토했다. --> 결론: fact_actio_support.json은 필요하다 stage1_task_D2_scoped_patch.yaml --> 기술적으로는, 이전에 내가 제시한 stage1_task_B2_C_B3_patch.yaml 위에 이 파일만 추가 적용하면 된다. 그 prior patch의 task_procedure는 그대로 유지해도 되고, 이번 파일은 기존 Task_D2 블록만 교체하면 된다. Task_D2가 읽는 입력 파일만 actio_case_signals.json까지 확장된 것이다.