**순차 목록** 1. `Task_A`: `client_goal.json` 개선 사건군별 `domain_profiles`, 4축 `current_control_map`, `legal_entitlement_candidates`, `legal_sustainability_watchpoints` 추가. Schema: `IssueClusterDomainProfile`, `LegalEntitlementCandidate`, `CurrentControlMap4Axis`. 2. `Task_B1`: `evidence_indexed.json` 개선 문서별 법률효과 component 분해, 등기부/감정표/통지서/별지목록/상속자료 등 구조화. Schema: `DocumentComponentEnvelope`, `ScheduleItem`, `SuccessionDocumentComponents`. 3. `Task_B2`: `evidence_event_candidates.json` 개선 raw event와 derived legal-effect event 분리, payment/notice/auction/lien/succession/valuation/defense subtype 생성. Schema: `LegalEffectEventCandidate`. 4. `Task_C`: `BO.json`, `actio_case_signals.json` 개선 모든 사건군의 `legal_effect_bo_type`, BO role template, actio/non-actio signal 생성. Schema: Section 6.4의 Task_C/Task_C2 공용 구조 일부 사용. 5. `Task_C2`: `legal_effect_structure_builder` 신설 BO를 `legal_effect_structures`로 정규화하고, Stage 2 module 선택용 structure id 및 claim group seed 생성. 출력: `legal_effect_structures.json`, `case_liability_signals.json`, `legal_effect_signals.json`, `canonical_theory_graph_seed.json`, `claim_group_candidates_seed.json`. Schema: `MoneyClaimTimeline`, `CommercialSuccessorLiability`, `ClaimGroup`, `SecuredDebtChain`, `PaymentAllocationResult`, `ActioBalanceSheet`, `ValueCompensationCap`, `SuccessionResolutionBundle`, `NoticeLifecycle`, `LienStateTimeline`, `AssetAliasMap`, `DefenseRebuttalMatrix`. 6. `Task_B3`: `evidence_actio_support.json` 개선 사해행위취소 support 유지, `supports_claim_roles` 및 가액배상 계산 role 보강. 7. `Task_B4`: `evidence_domain_support_extraction` 신설 사해행위취소 외 사건군의 evidence support 생성. 출력: `evidence_money_claim_support.json`, `evidence_commercial_successor_support.json`, `evidence_secured_property_support.json`, `evidence_registry_invalidity_support.json`, `evidence_land_use_gain_support.json`, `evidence_valuation_support.json`, `evidence_legal_effect_support.json`. 8. `Task_D1`: `Fact_Ledger_base.json` 개선 fact에 `legal_effect_roles`, `claim_chain_ref`, `linked_structures`, `derived_fact`, `state_context` 등 보존. Schema: `FactLegalMetadata`. 9. `Task_D2`: `fact_actio_support.json` 개선 fact-level actio support에 `fact_id`, `claim_role_candidates`, `mandatory_for_claim_ids` 추가, 범용 support 확장. Schema: `FactLegalSupport`. 10. `Task_D3`: `fact_domain_support_assembly` 신설 `Task_B4` evidence support와 Fact Ledger를 조인하여 fact별 claim role 후보와 mandatory 여부 생성. Schema: `FactLegalSupport`. 11. `Task_D4`: `stage1_validation_summary` 신설 Stage 1의 missing role, conflict, blocking warning을 통합. 출력: `stage1_validation_summary.json`. 12. `Task_Display`: `stage1.html` 개선 legal-effect board, money timeline, 담보채무 체인, actio balance sheet, 상속/유치권/통지 lifecycle, warning card 표시. 참고로 Section 4.5의 `Stage 2.1 Task_B2: claim_group_and_role_normalizer`는 Stage 1 DAG 내부 노드는 아니고, Stage 2.1의 `Task_B` 이후 `Task_C` 이전에 들어가는 후속 작업입니다. **Stage 1 확장 DAG** ```yaml task_procedure: IN: nexts: ["Task_A", "Task_B1"] wait_until: [] Task_A: nexts: ["Task_C2", "Task_Display"] wait_until: ["IN"] Task_B1: nexts: ["Task_B2"] wait_until: ["IN"] Task_B2: nexts: ["Task_C"] wait_until: ["Task_B1"] Task_C: nexts: ["Task_C2", "Task_B3"] wait_until: ["Task_B1", "Task_B2"] Task_C2: nexts: ["Task_B4", "Task_D1"] wait_until: ["Task_A", "Task_C"] Task_B3: nexts: ["Task_B4", "Task_D2"] wait_until: ["Task_B1", "Task_C"] Task_B4: nexts: ["Task_D1", "Task_D3"] wait_until: ["Task_B3", "Task_C2"] Task_D1: nexts: ["Task_D2", "Task_D3", "Task_Display"] wait_until: ["Task_B1", "Task_C", "Task_C2", "Task_B4"] Task_D2: nexts: ["Task_D3", "Task_Display"] wait_until: ["Task_B3", "Task_C", "Task_D1"] Task_D3: nexts: ["Task_D4", "Task_Display"] wait_until: ["Task_B4", "Task_D1", "Task_D2"] Task_D4: nexts: ["Task_Display"] wait_until: ["Task_A", "Task_B1", "Task_B2", "Task_C", "Task_C2", "Task_B3", "Task_B4", "Task_D1", "Task_D2", "Task_D3"] Task_Display: nexts: ["OUT"] wait_until: ["Task_A", "Task_D1", "Task_D2", "Task_D3", "Task_D4"] OUT: nexts: [] wait_until: ["Task_Display"] ``` **Stage 2.1 연계 노드** ```yaml stage2_1_extension: Task_A: nexts: ["Task_B"] wait_until: ["Stage_1_OUT"] Task_B: nexts: ["Task_B2"] wait_until: ["Task_A"] Task_B2: nexts: ["Task_C"] wait_until: ["Task_B", "Stage_1_Task_C2", "Stage_1_Task_D3", "Stage_1_Task_D4"] Task_C: nexts: [] wait_until: ["Task_B2"] ``` 완료했습니다. 새 Stage 1 YAML을 아래 경로에 생성했고, `Task_A`, `Task_B1`, `Task_B2`, `Task_C` 프롬프트만 개선 반영했습니다. [Stage_1_4_27_update_A_B1_B2_C.yaml]() 반영한 핵심은 다음입니다. - `Task_A`: `domain_profiles`, `legal_entitlement_candidates`, `CurrentControlMap4Axis`, 금전채권/담보부동산/사해행위/유치권·상속 profile 및 validation 추가 - `Task_B1`: `DocumentComponentEnvelope`, `claim_document_components`, 등기 row, valuation, loan, notice/admission/defense/schedule/succession component 추가 - `Task_B2`: raw event와 legal-effect event 분리, 필수 `event_subkind` registry 및 `LegalEffectEventCandidate` 확장 - `Task_C`: `legal_effect_bo_type`, domain별 legal-effect BO, `case_liability_signals.json`, `legal_effect_signals.json`, actio balance sheet 및 downstream module hint 추가 검증도 했습니다: Ruby YAML parser로 `YAML_OK` 확인했습니다. 요청하신 검증은 “수정된 네 task가 새 기능을 추가하면서도 기존 수행 계약을 잃지 않았는가”를 보는 작업이라, 원본 YAML과 새 YAML을 직접 대조해서 보존/변경/리스크를 분리해 평가하겠습니다. 먼저 구조 파싱, task 경계, 핵심 실행·입출력 계약을 확인하겠습니다. 검증 평가서를 생성해 저장했습니다. [stage_1_A_B1_B2_C_evaluation.md]() 요약하면 판정은 **적합**입니다. 기존 입력/핵심 출력/성공 메시지/재읽기 금지/필수 schema는 유지되고, 개선분은 대부분 optional additive 확장으로 평가했습니다. 단, `Task_C`는 새 output 2개가 추가된 additive 변경이라 그 점과 문구 정합성 주의사항을 별도로 적어두었습니다.