From 20c5235e68f7cbb8ca02c6d32c81796ffae29bba Mon Sep 17 00:00:00 2001 From: jhogyu Date: Wed, 8 Jul 2026 15:11:05 +0900 Subject: [PATCH] Add new YAML prompts and update existing files for Stage 1 to Stage 2 transition - Created new files for Stage 1 evaluation and revision strategy based on GPT and Claude recommendations. - Added detailed revision plans addressing runtime issues in LES2 and optimizing workflows for Stage 2. - Updated existing Stage 1 to Stage 2 transition prompts with additional search results and completion indicators. - Enhanced clarity and structure in the documentation for better usability and understanding. --- .serena/project.yml | 73 ++- .../.serena/project.yml | 70 ++- .../6월마지막계획서.txt | 48 -- .../v.5/stage_1_개정방식_전략서_claude_v1.md | 539 ++++++++++++++++++ .../v.5/stage_1_개정방식_전략서_claude_v2.md | 255 +++++++++ .../v.5/stage_1_개정방식_전략서_codex_v1.md | 484 ++++++++++++++++ .../v.5/stage_1_개정작업_final_프롬프트.txt | 201 +++++++ .../Stage_1_to_Stage_2_업데이트_플랜.txt | 85 +++ .../개정작업_stage_1_to_stage_2.txt | 18 - 판례모음/판례수집_작업_추진_업데이트.txt | 73 ++- 10 files changed, 1727 insertions(+), 119 deletions(-) create mode 100644 Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v1.md create mode 100644 Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v2.md create mode 100644 Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_codex_v1.md create mode 100644 Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정작업_final_프롬프트.txt create mode 100644 Case_02_Comparison_Research/YAML_Prompts/Stage_1_to_Stage_2_업데이트_플랜.txt diff --git a/.serena/project.yml b/.serena/project.yml index 0e9207aa..3c98f6d9 100644 --- a/.serena/project.yml +++ b/.serena/project.yml @@ -1,23 +1,25 @@ -# the name by which the project can be referenced within Serena +# the name by which the project can be referenced within Serena/when chatting with the LLM. project_name: "prompt_updates_sequential" - -# list of languages for which language servers are started; choose from: -# al angular ansible bash clojure -# cpp cpp_ccls crystal csharp csharp_omnisharp -# dart elixir elm erlang fortran -# fsharp go groovy haskell haxe -# hlsl html java json julia -# kotlin lean4 lua luau markdown +# list of languages for which language servers are started (LSP backend only); choose from: +# ada al angular ansible bash +# bsl clojure cpp cpp_ccls crystal +# csharp csharp_omnisharp cue dart elixir +# elm erlang fortran fsharp gdscript +# go groovy haskell haxe hlsl +# html java json julia kotlin +# latex lean4 lua luau markdown # matlab msl nix ocaml pascal -# perl php php_phpactor powershell python -# python_jedi python_ty r rego ruby -# ruby_solargraph rust scala scss solidity -# svelte swift systemverilog terraform toml -# typescript typescript_vts vue yaml zig -# (This list may be outdated. For the current list, see values of Language enum here: -# https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py -# For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.) +# perl php php_phpactor php_phpantom powershell +# python python_jedi python_pyrefly python_ty r +# rego ruby ruby_solargraph rust scala +# scss solidity svelte swift systemverilog +# terraform toml typescript typescript_vts vue +# yaml zig +# (This list may be outdated; generated with scripts/print_language_list.py; +# For the current list, see values of Language enum here: +# https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py) +# For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.) # Note: # - For C, use cpp # - For JavaScript, use typescript @@ -55,8 +57,8 @@ ignore_all_files_in_gitignore: true # advanced configuration option allowing to configure language server-specific options. # Maps the language key to the options. -# Have a look at the docstring of the constructors of the LS implementations within solidlsp (e.g., for C# or PHP) to see which options are available. -# No documentation on options means no options are available. +# The settings are considered only if the project is trusted (see global configuration to define trusted projects). +# See https://oraios.github.io/serena/02-usage/050_configuration.html#language-server-specific-settings ls_specific_settings: {} # list of additional paths to ignore in this project. @@ -129,13 +131,38 @@ ignored_memory_patterns: [] # See https://oraios.github.io/serena/02-usage/050_configuration.html#modes added_modes: -# list of additional workspace folder paths for cross-package reference support (e.g. in monorepos). +# list of additional workspace folder paths for cross-package reference support. # Paths can be absolute or relative to the project root. # Each folder is registered as an LSP workspace folder, enabling language servers to discover -# symbols and references across package boundaries. -# Currently supported for: TypeScript. +# symbols and references across package boundaries, but these folders are not indexed by Serena, +# i.e. the respective symbols will not be found using Serena's symbol search tools. # Example: # additional_workspace_folders: # - ../sibling-package # - ../shared-lib -additional_workspace_folders: [] +ls_additional_workspace_folders: [] + +# list of workspace folder paths (LSP backend only). +# These folders will be used to build up Serena's symbol index. +# Paths must be within the project root and should thus be relative to the project root. +# Furthermore, the paths should not be filtered by ignore settings. +# Default setting: The entire project root folder (".") is considered. +# In (large) monorepos, this can be used to index only subfolders of the project root, e.g. +# ls_workspace_folders: +# - "./subproject1" +# - "./subproject2" +ls_workspace_folders: +- . + +# optional shell command to run before the language backend (LSP or JetBrains) is initialised. +# the command runs in the project root directory and is only executed if the project is trusted +# (see trusted_project_path_patterns in the global configuration). +# serena waits for the command to exit: a non-zero exit code is logged as an error but does not +# abort activation. a per-project timeout (activation_command_timeout, default 180s) is the safety +# backstop for non-terminating commands; on expiry the process is killed and activation continues. +# example: activation_command: "npx nx run-many -t build" +activation_command: + +# maximum time in seconds to wait for activation_command to complete before killing it (default 180s). +# must be a positive number. +activation_command_timeout: 180.0 diff --git a/Case_02_Comparison_Research/.serena/project.yml b/Case_02_Comparison_Research/.serena/project.yml index 369bd51b..33faf6ce 100644 --- a/Case_02_Comparison_Research/.serena/project.yml +++ b/Case_02_Comparison_Research/.serena/project.yml @@ -1,23 +1,25 @@ -# the name by which the project can be referenced within Serena +# the name by which the project can be referenced within Serena/when chatting with the LLM. project_name: "Case_02_Comparison_Research" - -# list of languages for which language servers are started; choose from: -# al angular ansible bash clojure -# cpp cpp_ccls crystal csharp csharp_omnisharp -# dart elixir elm erlang fortran -# fsharp go groovy haskell haxe -# hlsl html java json julia -# kotlin lean4 lua luau markdown +# list of languages for which language servers are started (LSP backend only); choose from: +# ada al angular ansible bash +# bsl clojure cpp cpp_ccls crystal +# csharp csharp_omnisharp cue dart elixir +# elm erlang fortran fsharp gdscript +# go groovy haskell haxe hlsl +# html java json julia kotlin +# latex lean4 lua luau markdown # matlab msl nix ocaml pascal -# perl php php_phpactor powershell python -# python_jedi python_ty r rego ruby -# ruby_solargraph rust scala scss solidity -# svelte swift systemverilog terraform toml -# typescript typescript_vts vue yaml zig -# (This list may be outdated. For the current list, see values of Language enum here: -# https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py -# For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.) +# perl php php_phpactor php_phpantom powershell +# python python_jedi python_pyrefly python_ty r +# rego ruby ruby_solargraph rust scala +# scss solidity svelte swift systemverilog +# terraform toml typescript typescript_vts vue +# yaml zig +# (This list may be outdated; generated with scripts/print_language_list.py; +# For the current list, see values of Language enum here: +# https://github.com/oraios/serena/blob/main/src/solidlsp/ls_config.py) +# For some languages, there are alternative language servers, e.g. csharp_omnisharp, ruby_solargraph.) # Note: # - For C, use cpp # - For JavaScript, use typescript @@ -128,17 +130,6 @@ ignored_memory_patterns: [] # See https://oraios.github.io/serena/02-usage/050_configuration.html#modes added_modes: -# list of additional workspace folder paths for cross-package reference support (e.g. in monorepos). -# Paths can be absolute or relative to the project root. -# Each folder is registered as an LSP workspace folder, enabling language servers to discover -# symbols and references across package boundaries. -# Currently supported for: TypeScript. -# Example: -# additional_workspace_folders: -# - ../sibling-package -# - ../shared-lib -additional_workspace_folders: [] - # optional shell command to run before the language backend (LSP or JetBrains) is initialised. # the command runs in the project root directory and is only executed if the project is trusted # (see trusted_project_path_patterns in the global configuration). @@ -151,3 +142,26 @@ activation_command: # maximum time in seconds to wait for activation_command to complete before killing it (default 180s). # must be a positive number. activation_command_timeout: 180.0 + +# list of additional workspace folder paths for cross-package reference support. +# Paths can be absolute or relative to the project root. +# Each folder is registered as an LSP workspace folder, enabling language servers to discover +# symbols and references across package boundaries, but these folders are not indexed by Serena, +# i.e. the respective symbols will not be found using Serena's symbol search tools. +# Example: +# additional_workspace_folders: +# - ../sibling-package +# - ../shared-lib +ls_additional_workspace_folders: [] + +# list of workspace folder paths (LSP backend only). +# These folders will be used to build up Serena's symbol index. +# Paths must be within the project root and should thus be relative to the project root. +# Furthermore, the paths should not be filtered by ignore settings. +# Default setting: The entire project root folder (".") is considered. +# In (large) monorepos, this can be used to index only subfolders of the project root, e.g. +# ls_workspace_folders: +# - "./subproject1" +# - "./subproject2" +ls_workspace_folders: +- . diff --git a/Case_02_Comparison_Research/6월마지막계획서.txt b/Case_02_Comparison_Research/6월마지막계획서.txt index 168ee800..b14e1241 100644 --- a/Case_02_Comparison_Research/6월마지막계획서.txt +++ b/Case_02_Comparison_Research/6월마지막계획서.txt @@ -1,12 +1,6 @@ Stage 2 개정 작업 Plan -1. 6/28 일요일 -- IR 자료 개정 - -> 추가할 자료 (현재 비즈니스 흐름 / Eroom 비전/전략의 정당성 / Eroom의 기술력 / Eroom의 확장성) 강조할 자료 - -> 슬라이드 자료 업데이트 구상 및 개정 - -> 시간: 자료수집 30분, 구상 20분, 개정 20분 -> 총 70분 작업: 9:20pm-10:30pm - - stage 1 정합성 체크 / 개정 필요 식별 / 최소한도 개정 전략서 생성 -> stage 2 작업 전체 흐름 파악 -> 사용 정보를 최대한 구체적으로 식별 (field 별로) -> 현행 stage 2 작업에 사용될 정보 field를 개정 stage 1 작업명세서와 BO/Fact_Ledger/3-signals (+추가 생성 블록)과 대조하여 일치/기존만존재/신규에만존재 등으로 분리 식별 @@ -72,21 +66,6 @@ Weaviate DB 구성 및 vector search 개정 작업 ====================================================================================== -월요일 -- 이른 아침: IR 업데이트 / 유은하에게 딸의 adhd 진단서 제출 -- 학교에 도서 반납(사무실 도서 포함 / 필수 도서만 제외) -- Stage 2 업데이트 작업 - -점심: 기분을 올리는 음식으로 --> 징계위원회 참석 대비 --> 징계위원회 출석 후 곧바로 회사에 와서 이사회 준비(알림 내용) - - 현재 자금 사정 - - 매달 지출 크기 - - 현재 에이전트 업데이트 진행 상황 - - 7월 첫째주부터 shell company 구성해서 seeding 작업 시작 가능한지 여부 문의 - -> 더 늦어질 것 같으면 박현민을 푸시해서라도 일을 진행할 것 - -> 용배와는 이번 주 중으로 본격적인 evaluation 과정 진행 시작 계획 - ====================================================================================== @@ -194,33 +173,6 @@ Weaviate DB 구성 및 vector search 개정 작업 ======================================================================== -IR 최종 개정 - -1. 목차 선정 - -2. CesiumAstro 슬라이드를 참조하여 template 생성 (by Claude Design) - -3. 선정 목차에 따라 최대한 서술을 줄이고 그래픽 위주로 배치 -- Eroom의 경쟁력 / 시장 전략 강조 - - - -목차 - -Eroom - -1. 소개 -2. 비전과 미션 -3. 시장 진출 - 리걸 테크 - 3.1. 법률 시장 - 3.2. 법률 시장 문제와 해결책 - 3.3. 시장 전략 - 3.4. 전망치 -4. 자금 조달 전략 -5. 확대(Scale) 전략 -#. Contact Information - - -Eroom의 비전 diff --git a/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v1.md b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v1.md new file mode 100644 index 00000000..653deb36 --- /dev/null +++ b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v1.md @@ -0,0 +1,539 @@ +# Stage 1 개정방식 전략서 (Decision Tree) — claude_v1 + +> 근거 문서: `신규작업명세서_평가_평가_평가_Claude.md`의 3계층(L1/L2/L3) 판정 및 `<개정작업_요약>` +> 개정 범위: **Layer 1(L1) 최소 결정화만** Stage 1에 이식한다. 조립(L2)·법리(L3)는 Stage 2로 보내며 본 전략서의 범위가 아니다. +> 대상 파일: `Stage_1_Part_1.yml`(B1/B2 추출) · `Stage_1_Part_2.yml`(BO 생성) · `Stage_1_Part_3.yml`(LES) · `Stage_1_Part_4.yml`(Fact Ledger) +> 설계 원칙: **additive-only**(기존 필드 삭제·개명 금지), **결정적 key 규칙**(mapper propose → gate finalize 기존 패턴 재사용), **게이트는 sealed 산출물 작성 직전의 deterministic task에만** 배치. + +--- + +## 0. 전체 아키텍처와 개정 지점의 대응 + +``` +Part 1 (Stage_1_Part_1.yml) + Task_A_client_goal + Task_Evidence_shard_planner + Task_B1_map_doc_* ← [작업1·5·6] 문서 component 추출 스키마 (약정이율·notice 5날짜·schedule/registry key) + Task_B2_map_events_* ← [작업2·3] event/state candidate 스키마 (fraction_ref·possession 2-track raw) + Task_B1_quality_gate_evidence_indexed ← [작업5] notice 날짜 누락 HARD_WARNING 추가 + Task_B2_quality_gate_event_candidates ← [작업2] fraction_ref 무결성 점검 추가 + Task_B2_SHA256_soft_gate_handoff_writer (무수정) + +Part 2 (Stage_1_Part_2.yml) + Task_C_BO_Stage_B_B1_Money_Successor ← [작업1] money_claim_details 약정이율 named 승격 + Task_C_BO_Stage_B_B2_Secured_Registry ← [작업2] registry_rows에 fraction_ref 보존 + Task_C_BO_Stage_B_B3_Land_Valuation ← [작업3] possession_state:{} → 2-track named 스키마 + Task_C_BO_Stage_B_B5_Succession_... ← [작업3·4·5·6] possession/lien/notice/asset_alias named 골격 + lien_id + (5개 worker 공통) ← [작업7] domain_review_queue issue_type에 escalation enum 추가 + Task_C_BO_PostB_1~4 (구조 무수정 — extensions.domain_payload pass-through 이미 보장됨) + +Part 3 (Stage_1_Part_3.yml) ← 무수정 (LES는 개정 5건의 대상 아님) + +Part 4 (Stage_1_Part_4.yml) + Task_FL1_deterministic_fact_ledger_candidate_builder ← [작업3·5] 모순 검출 + 수령 게이트의 "검출" 지점 + Task_FL2_single_fact_exception_adjudicator (enum만 인지 — 사실상 무수정) + Task_FL3_final_fact_ledger_gate_and_writer ← [작업3·5] sealed writer report에 게이트 결과 기록 +``` + +핵심 pass-through 근거(수정 불요 확인): `Task_C_BO_PostB_3_final_bo_compiler`는 seed의 `extensions.domain_payload`를 그대로 final BO에 싣고(Part 2 L5340·L5399·L5463), `Task_C_BO_PostB_4_final_gate_and_writer`는 `ALLOWED_TOP_LEVEL`에 `extensions`를 허용한다(Part 2 L5528, L5788-5790). 따라서 **B1~B5 worker payload에 named 필드를 추가하면 BO.json까지 자동 도달**하며 PostB 개정이 불필요하다. 이것이 본 전략의 최소성(minimality)의 토대다. + +--- + +## 1. Root Decision Tree — "이 개정 항목을 어디에 넣는가" + +모든 개정 항목은 아래 트리 하나로 위치가 결정된다. + +``` +Q0. 이 값은 Stage 1 시점에 실재(문서/상담에 존재)하는 데이터인가? +├─ NO → Stage 1 개정 대상 아님. (예: 소장 송달일, 법정이율 확정, 견련성 인정) +│ → Stage 2 L2 view 또는 L3 법리 모듈로. [본 전략서 범위 외] +└─ YES + Q1. 성질이 무엇인가? + ├─ (a) 문서에서 직접 읽히는 "추출 사실" (날짜·이율·지분표시·접수번호) + │ → Part 1 mapper 스키마에 named 필드 추가 + │ ├─ 문서 정적 속성(component) → Task_B1_map_doc_* + 해당 RULE 블록 + │ └─ 사건/상태(event/state) → Task_B2_map_events_* + 해당 ROUTINE 블록 + │ → 대응 quality gate에 누락검출 HARD_WARNING 1줄 추가 + │ + ├─ (b) 흩어진 event를 묶는 "식별 key" (fraction_id, lien_id, notice_id, schedule_ref/registry_ref) + │ Q1-b. key의 스코프가 단일 문서 안에서 닫히는가? + │ ├─ YES (schedule_ref, registry_ref, notice_id, fraction 표시) + │ │ → Part 1 mapper가 deterministic 규칙으로 propose + │ │ (기존 `EVT-{ordinal:03d}-{seq:02d}` 패턴 복제; finalize는 quality gate) + │ └─ NO (lien_id처럼 여러 문서의 event를 관통) + │ → Part 2 worker(B5)가 slice 전체를 보고 deterministic 정렬 순서로 부여 + │ (mapper 단계 부여는 authority drift 금지 원칙 위반이므로 금지) + │ + ├─ (c) 빈 컨테이너에 박을 "named 스키마 골격" (lien_state, possession_state, notice_lifecycle, asset_alias) + │ → Part 2 해당 worker 의 domain_payload에서 `{}`를 named 스키마로 교체 + │ + 에 채움 규칙 1-2줄 추가 + │ + 법리 필드(violation_candidates, status_after_notice_receipt 등)는 스키마에서 의도적으로 배제하고 + │ `domain_review_queue`의 escalation enum으로 올린다 [작업7] + │ + └─ (d) 법적 효력을 갖는 "게이트" (모순 차단, 수령여부 차단) + Q1-d. 게이트가 감시하는 모순/결측이 처음으로 한 곳에 모이는 지점은? + → 도메인 간 사실이 전부 합류하고 sealed 산출물이 되는 지점 = Fact Ledger 컴파일 + → 검출: Part 4 Task_FL1 (deterministic builder — 전 row를 메모리에 가진 유일한 결정적 지점) + → 기록: Part 4 Task_FL3 writer report + row `skeleton_validation_codes` (sealed) + → LLM에 게이트를 맡기지 않는다(재현성). PostB_4는 BO 단계라 FL 파생 row를 못 보므로 제외. +``` + +**트리 적용 결과 요약표** + +| # | 개정 항목 | Q1 분기 | 파일 | 개정 지점(task) | +|---|---|---|---|---| +| 작업1 | 약정이율·약정지연손해금율 named 승격 | (a)+(c) | Part 1, Part 2 | Task_B1_map_doc / B1_Money_Successor | +| 작업2 | fraction_id key 부착 | (a)+(b-단일문서) | Part 1, Part 2 | Task_B2_map_events / B2_Secured_Registry | +| 작업3 | possession 2-track + 모순 차단 게이트 | (a)+(c)+(d) | Part 1, Part 2, Part 4 | Task_B2_map_events / B3·B5 worker / FL1·FL3 | +| 작업4 | lien_state_timeline named 골격 + lien_id | (b-관통)+(c) | Part 2 | B5 worker | +| 작업5 | notice 5날짜 추출 + 수령 게이트 | (a)+(c)+(d) | Part 1, Part 2, Part 4 | Task_B1_map_doc / B5 worker / FL1·FL3 | +| 작업6 | asset_id·schedule_ref·registry_ref key 승격 | (a)+(b-단일문서)+(c) | Part 1, Part 2 | Task_B1_map_doc / B5 worker | +| 작업7 | escalation 메커니즘(review_required/legal_theory_required) | 공통 장치 | Part 2 | 5개 worker의 domain_review_queue | + +--- + +## 2. 항목별 상세 Decision Tree 및 작업 지시 + +각 항목은 `[판단트리] → [수정 지시(파일·위치·내용)] → [하지 말 것]` 순서로 서술한다. +위치 표기는 v.5 현재 파일의 라인 번호(±수 라인)와 블록명을 병기한다. 라인 번호는 참고용이고 **블록명이 규범적 anchor**다. + +### 작업 1 — 약정이율(agreed_interest_rate)·약정지연손해금율(agreed_delay_damage_rate) named 승격 + +``` +약정이율은 차용증 등 문서에 실재하는가? ─ YES → (a) 추출 사실 + └─ 현재 어디에 있나? + ├─ Part 1 B1: L1249에 "각 원금·변제기·이자율…추출"이라는 + │ prose 지시만 있고 loan_components의 named 필드 스키마가 없음 → 스키마 명문화 필요 + └─ Part 2 B1_Money_Successor: money_claim_details.interest_hint (L2435) freeform 뿐 + → named 필드 2개 추가 필요 (interest_hint는 하위호환용으로 유지) +``` + +**수정 1-1. `Stage_1_Part_1.yml` — ``** + +- 위치: ``(L1216-1222) 및 ``(L1247-1254) 사이 또는 직후. +- 내용: `loan_components`의 항목 스키마를 명문화하는 규칙 블록을 추가한다. + +``` + +- `loan_components`의 각 항목은 아래 named 필드를 가진다. 직접 읽히지 않는 필드는 null. +{ + "loan_component_id": "E-{ordinal:03d}-LC-{seq:02d}", + "principal_amount": null, + "loan_date": null, + "due_date": null, + "agreed_interest_rate": null, // 원문 그대로: "연 5%", "월 1%" 등 문자열 + "agreed_delay_damage_rate": null, // 약정 지연손해금율. 없으면 null (법정이율로 보충 금지) + "interest_accrual_start_hint": null, + "collateral_object_hint": null, + "role_in_claim_hint": null +} +- `agreed_interest_rate`/`agreed_delay_damage_rate`는 계산·환산·보간 금지. 원문 문자열만 허용. +- 이율이 문서에 있는데 두 필드가 모두 null이면 self-warning으로 본다. + +``` + +- 함께: ``(L1427-1452)의 기존 항목 "차용금 문서에 이율 또는 변제기가 있는데 `secured_debt_components` 또는 `loan_components`가 없으면 self-warning"(L1444) 뒤에 1줄 추가 — "`loan_components`가 있는데 이율 문구가 문서에 보이면서 `agreed_interest_rate`가 null이면 self-warning으로 본다." + +**수정 1-2. `Stage_1_Part_1.yml` — `Task_B1_quality_gate_evidence_indexed`** + +- 위치: HARD_WARNING 검출 목록(L2313-2319)의 말미. +- 내용: 1줄 추가 — "차용증·변제약정서에 이율 기재가 보이는데 `loan_components[*].agreed_interest_rate`와 `agreed_delay_damage_rate`가 모두 비어 있으면 severity=`HARD_WARNING` 및 `review_findings[]`에 기록". + +**수정 1-3. `Stage_1_Part_2.yml` — `Task_C_BO_Stage_B_B1_Money_Successor`** + +- 위치: ``의 `money_claim_details`(L2435). +- 내용(치환): + +``` +"money_claim_details": {"claim_type_candidate": null, "principal_amount_hint": null, + "interest_hint": null, "delay_damage_hint": null, + "agreed_interest_rate": null, "agreed_delay_damage_rate": null, + "interest_accrual_start_hint": null, + "unpaid_balance_hint": null, "creditor_candidate": null, "debtor_candidate": null}, +``` + +- 함께: `` 4항(L2337)에 "Preserve agreed interest rate and agreed delay damage rate as literal strings from B1 `loan_components` when present" 취지 1줄 추가. +- `interest_hint`·`delay_damage_hint`는 삭제하지 않는다(하위호환). + +**하지 말 것**: 법정이율(연 5%/12%) 보충, pre/post_service 분리 계산(→ L3), 소장 송달일 관련 필드 신설(Stage 1에 존재 불가한 값). + +--- + +### 작업 2 — 지분 event에 `fraction_id` key 부착 + +``` +지분(fraction) 정보의 원천은? ─ 등기부 row의 지분 표시(예: "2분의 1") = 단일 문서에서 직접 읽힘 + → (a) 추출 사실 + (b) key: 단일 문서 스코프에서 닫힘 + → mapper가 deterministic 규칙으로 propose (EVT- 패턴 복제) + → 여러 문서에 걸친 동일 지분의 통합(정규화)은? → Stage 2 L2 (여기서 하지 않는다) + 단, Stage 2가 정규화를 "신뢰성 있게" 하려면 각 event에 원천 key가 붙어 있어야 한다 — 그것만 한다. +``` + +**수정 2-1. `Stage_1_Part_1.yml` — ``** + +- 위치: ``(L1230-1237). +- 내용: 2줄 추가 — + - "row에 지분 표시(예: 2분의 1, 1/2 지분)가 직접 읽히면 `registry_row_components[*].fraction_display`(원문 문자열)와 `registry_row_components[*].fraction_ref`를 채운다." + - "`fraction_ref`는 `FR-{ordinal:03d}-{row_seq:02d}` 형식의 deterministic propose 값이다. 같은 row에서 파생되는 모든 component는 같은 `fraction_ref`를 공유한다." + +**수정 2-2. `Stage_1_Part_1.yml` — ``** + +- 위치 ①: `` candidate object(L2000-2053) — `"object_spec"` 근처에 optional 필드 1개 추가: `"fraction_ref": null`. +- 위치 ②: ``(L1709-1714) — 1줄 추가: "row에 지분 표시가 읽히면 candidate에 같은 ordinal B1 part의 `registry_row_components[*].fraction_ref`와 동일한 `fraction_ref`를 남긴다. 지분 표시가 없으면 null." +- 위치 ③: `` 담보부 부동산 목록(L1801-1813)의 `mortgage_setting_by_fraction`, `mortgage_extinguishment_by_fraction` — 목록은 수정하지 않고, ``(L1858-1863)에 1줄 추가: "`*_by_fraction` subkind candidate는 지분 표시가 문서에 직접 읽히는 한 `fraction_ref`를 반드시 가진다." + +**수정 2-3. `Stage_1_Part_1.yml` — `Task_B2_quality_gate_event_candidates`** + +- 위치: schema/coverage 검출 목록(L2713-2720)의 말미. +- 내용: 1줄 추가 — "`mortgage_setting_by_fraction` 또는 `mortgage_extinguishment_by_fraction` candidate에 지분 표시가 원문에 보이는데 `fraction_ref`가 null이면 `HARD_WARNING` 및 `review_findings[]`에 기록". + +**수정 2-4. `Stage_1_Part_2.yml` — `Task_C_BO_Stage_B_B2_Secured_Registry`** + +- 위치: `` domain_payload(L2683-2709)의 `"registry_rows": []`. +- 내용: 주석 규칙로 명문화(스키마 항목 추가) — `registry_rows`의 각 항목에 `{"registry_ref": null, "fraction_ref": null, "fraction_display": null, ...}`를 포함하고, ``에 "carry `fraction_ref` from source event candidates unchanged; do not merge or renumber" 1줄 추가. + +**하지 말 것**: fraction 정규화(cross-document 동일 지분 판정), 상태 전이표(state folding) 생성(→ Stage 2 L2 view), FL row에 fraction 전용 컬럼 신설(평가서 §2.2: FL 평면화는 의미 파괴). + +--- + +### 작업 3 — possession 2-track raw + 모순 차단 게이트 (sealed) + +``` +Q. possession 관련 값 중 무엇이 L1인가? +├─ 점유 "사실" (누가·언제부터 점유) ─ 문서에서 직접 읽힘 → (a) Part 1 B2 state candidate (이미 존재: current_state_candidate 4축) +├─ 점유 "권원 주장" (유치권행사중/임대차/무권원 등) ─ 문서·답변서에서 직접 읽히는 주장 → (a) 신규 track 필요 +│ ※ 권원의 "법적 확정"(견련성 인정 등)은 L3 → Stage 2. 여기서는 주장(raw assertion)만. +├─ 두 track의 컨테이너 ─ B3 possession_state:{} (L2972), B5 possession_state:{} (L3513) 빈 컨테이너 → (c) named 골격 +└─ 모순 검출(동일 자산·기간에 양립불가 권원) ─ (d) 게이트 + → 검출 지점: 도메인(B3·B5)을 관통해 사실이 전부 모이는 결정적 지점 = Part 4 FL1 + → 기록 지점: FL3 writer report + skeleton_validation_codes (sealed) +``` + +**수정 3-1. `Stage_1_Part_1.yml` — `` (2-track raw의 원천)** + +- 위치: ``(L1921-1953)의 `current_state_candidate` 스키마(L1925-1936). +- 내용: optional 필드 2개 추가 — + +``` +"possession_legal_cause_asserted": null, + // enum: "유치권행사중|임대차|사용대차|물권|동시이행항변|명도후잔류|무권원주장|미상" +"possession_legal_cause_asserted_by": [] + // 그 권원을 주장한 주체(원고측/피고측/제3자 이름). 문서에 직접 읽힐 때만. +``` + +- 규칙 2줄 추가: "점유 사실과 권원 주장은 같은 candidate 안에서 축을 분리해 남긴다(사실=4축 배열, 권원=`possession_legal_cause_asserted`). 권원 주장이 문서에 없으면 `미상`이 아니라 null로 둔다." / "서로 다른 문서가 동일 자산에 대해 다른 권원을 주장하는 것은 본 mapper의 검출 대상이 아니다(authority drift 금지). 각 문서의 주장을 그대로 보존한다." + +**수정 3-2. `Stage_1_Part_2.yml` — B3(L2972)·B5(L3513) worker의 `possession_state: {}` named 골격 치환** + +- 위치: 두 worker의 `` domain_payload. +- 내용(동일 스키마를 양쪽에 삽입 — B3/B5 간 필드명 불일치 금지): + +``` +"possession_state": { + "asset_ref": null, + "possession_events": [ + {"possessor_candidates": [], "start_date": null, "end_date": null, + "source_event_candidate_ids": [], "evidence_indexes": []} + ], + "legal_cause_assertions": [ + {"cause_asserted": "유치권행사중|임대차|사용대차|물권|동시이행항변|명도후잔류|무권원주장|미상", + "asserted_by": null, "assertion_date": null, + "source_event_candidate_ids": [], "evidence_indexes": []} + ] +}, +``` + +- ``에 1줄 추가(양쪽): "Populate `possession_state` two-track structure from selected event candidates only; never resolve which legal cause prevails (that is Stage 2 work); preserve conflicting assertions side by side." + +**수정 3-3. `Stage_1_Part_4.yml` — `Task_FL1_deterministic_fact_ledger_candidate_builder` (모순 "검출" 게이트)** + +- 위치: row 생성 후 exception 생성 구간 — `_exceptions_for_row`(L1041 이하) 뒤에 **cross-row post-pass 함수 1개 추가** (`_possession_conflict_scan(rows, bo_by_id)`), `main()`의 exception_pack 조립 직전에 호출. +- 로직(결정적, LLM 불개입): + 1. BO(`bo_by_id`)의 `extensions.domain_payload.possession_state`에서 (asset_ref 또는 asset_cluster_ids, 기간, cause_asserted)를 수집. + 2. 동일 asset + 기간 중첩 + 양립불가 cause 쌍(최소 규칙: `유치권행사중` vs `무권원주장`; 확장 쌍은 상수 테이블 `INCOMPATIBLE_CAUSE_PAIRS`로 관리)이 검출되면: + - 관련 FL row 각각에 `skeleton_validation_codes += ["POSSESSION_CAUSE_CONFLICT"]`, `must_consider=true` + - exception_pack에 `severity="HARD_WARNING"`, `allowed_output_fields=["state_context","skeleton_validation_codes","derivation_basis"]`인 exception 항목 추가 (FL2가 BLOCK_REVIEW/PATCH 판단 — 기존 메커니즘 재사용) + 3. 모순 검출은 candidate 삭제·병합을 하지 않는다. 두 사실 모두 ledger에 남기고 code만 부착한다. + +**수정 3-4. `Stage_1_Part_4.yml` — `Task_FL3_final_fact_ledger_gate_and_writer` (모순 "기록" — sealed)** + +- 위치: `report` dict 초기화(L1788-1795) 및 최종 `print` summary(L1845-1857). +- 내용: writer report에 top-level 필드 `"possession_conflict_gate": {"status": "PASS|HARD_WARNING", "conflicts": [...]}` 추가. `skeleton_validation_codes`에 `POSSESSION_CAUSE_CONFLICT`가 있는 row를 집계해 채운다. 최종 stdout summary에 `possession_conflict_count` 1개 추가. **pipeline BLOCK은 하지 않는다**(모순은 병존 가능한 사실 주장이므로 HARD_WARNING + 봉인 기록까지가 Stage 1의 소관). + +**하지 말 것**: 어느 권원이 우세한지 판정(L3), enum의 법적 확정, LLM task(FL2 제외)에서 모순 판정, 모순 candidate 자동 삭제. + +--- + +### 작업 4 — `lien_state_timeline` named 골격 + `lien_id` 부여 + +``` +Q. lien 필드를 성질별로 분할하면? +├─ lien_id + named 골격 → L1 (없으면 데이터 변동/유실) → 본 작업 +├─ secured_claim·possession_events의 "재구성" → L2 (Stage 2 view) → 제외 +└─ violation_candidates·status_after_notice_receipt → L3 (법리) → 스키마에서 의도적 배제 + 작업7 escalation +Q. lien_id는 어디서 부여? → 여러 문서(주장서·통지서·답변서·임대차)를 관통 → (b-관통) → Part 2 B5 worker + (Part 1 mapper는 자기 문서만 보므로 불가; B0 router의 allowed_legal_effect_bo_types에 + "lien_state_timeline_BO"가 이미 존재(L2012)하므로 타입 신설 비용 없음) +``` + +**수정 4-1. `Stage_1_Part_2.yml` — `Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense`** + +- 위치: `` domain_payload의 `"lien_state": {}`(L3512). +- 내용(치환): + +``` +"lien_state": { + "lien_id": null, // "B5:LIEN:001" 형식. deterministic 부여 규칙은 아래. + "asset_ref": null, + "lien_holder_candidates": [], + "secured_claim_hint": {"amount_hint": null, "basis_hint": null, "evidence_indexes": []}, + "possession_event_refs": [], // possession_state.possession_events와 연결되는 source_event_candidate_ids + "assertion_events": [], // lien_assertion / third_party_lease_by_lien_holder 등 raw event refs + "extinction_notice_refs": [], // notice_lifecycle의 notice_id 참조 + "status_raw_hint": null // 문서에 직접 읽히는 현재상태 문구만. 법적 판정 금지. +}, +``` + +- `lien_id` deterministic 규칙(같은 블록의 `` 직후에 1줄): "lien seed가 복수이면 가장 이른 관련 event date(동률이면 candidate_ref 사전순) 순으로 `B5:LIEN:001`, `B5:LIEN:002`…를 부여한다. 이 id는 transport-스코프이며 final BO_ID가 아니다." +- `` 4항(L3407)에 보강: "Assign `lien_id` deterministically and reference it from possession/notice payloads of the same seed group." +- **의도적 배제 명문화**: ``에 1줄 — "Do not produce `violation_candidates` or `status_after_notice_receipt`; route such needs to `domain_review_queue` with `issue_type="legal_theory_required"`." + +**하지 말 것**: BO/FL에서 lien timeline의 조립(→ Stage 2 L2), 견련성·소멸 판단(L3), Part 1 mapper에서의 cross-document lien_id 부여. + +--- + +### 작업 5 — notice 5개 lifecycle 날짜 추출 + received_date 수령 게이트 (sealed) + +``` +Q. received_date의 성질? → 추출 사실 (답변서의 수령 인정, 배달증명 등에서 직접 읽힘) + → 추출이 없으면 Stage 2 view는 null을 창조할 수 없다 → 추출은 반드시 Part 1 B1 +Q. 5개 lifecycle 날짜 = 작성일 / 발송일 / 도달일 / 수령(인정)일 / 법률효과발생후보일 +Q. "received_date 없으면 final drafting 제한"의 성질? → (d) 게이트 + → 검출: Part 4 FL1 (notice BO를 전부 보는 결정적 지점) + → 기록: FL3 writer report의 drafting_gates[] (sealed) — pipeline BLOCK 아님, downstream 제한 플래그 +``` + +**수정 5-1. `Stage_1_Part_1.yml` — ``** + +- 위치: ``(L1256-1263)의 `notice_components` prose 지시(L1258)를 named 스키마로 강화. +- 내용(기존 문장 유지 + 스키마 블록 추가): + +``` +- `notice_components`의 각 항목은 아래 named 필드를 가진다. 직접 읽히지 않는 필드는 null. +{ + "notice_id_proposed": "E-{ordinal:03d}-NT-{seq:02d}", + "notice_type": "최고|해제통지|유치권소멸청구통지|기타", + "drafted_date": null, // 1. 작성일 + "dispatch_date": null, // 2. 발송일 + "arrival_date": null, // 3. 도달일 (민법 111조 도달주의 — 도달≠수령을 구분) + "received_date": null, // 4. 수령일(수령 인정 포함). 도달일과 다르면 별도 보존 + "legal_effect_date_candidate": null, // 5. 법률효과 발생 후보일 (계산 금지, 문서 직접 기재만) + "requires_receipt_for_effect": null, // true|false|null — 문서 유형상 도달/수령이 효력요건인지의 후보 표시 + "sender_candidates": [], + "receiver_candidates": [], + "target_object_hint": null, + "receipt_evidence_refs": [], // 수령을 뒷받침하는 같은 문서 내 단서 locator + "legal_effect_candidate_hint": null +} +- 수령일이 상대방 답변서에서 인정되는 경우 그 답변서의 `admission_components`에 남기고, + 본 통지서 문서의 `received_date`에 타 문서 사실을 주입하지 않는다(authority drift 금지). + cross-document 연결은 Part 2 B5가 수행한다. +``` + +**수정 5-2. `Stage_1_Part_1.yml` — `Task_B1_quality_gate_evidence_indexed`** + +- 위치: HARD_WARNING 목록(L2313-2319) 말미. +- 내용: 1줄 추가 — "통지서(`notice_doc` 계열)인데 `notice_components[*].dispatch_date`와 `arrival_date`가 모두 null이면 severity=`HARD_WARNING` 및 `review_findings[]`에 기록". +- 참고: Task_B2 gate에는 `lien_extinction_notice_dispatch`+`receipt` 쌍 누락 HARD_WARNING이 이미 존재(L2718) — 수정 불요. + +**수정 5-3. `Stage_1_Part_2.yml` — B5 worker `notice_lifecycle` named 승격** + +- 위치: `` domain_payload의 `"notice_lifecycle": {"dispatch_hints": [], "arrival_hints": []}`(L3508-3511). +- 내용(치환 — 기존 2필드는 하위호환 유지): + +``` +"notice_lifecycle": { + "notice_id": null, // B1 part의 notice_id_proposed 승계. 복수 통지면 seed 분리. + "notice_type": null, + "drafted_date": null, + "dispatch_date": null, + "arrival_date": null, + "received_date": null, // 답변서 수령 인정 등 cross-document 연결은 여기서 수행 + "legal_effect_date_candidate": null, + "requires_receipt_for_effect": null, + "sender_candidates": [], + "legal_sender_after_resolution_ref": null, // succession_resolution과의 cross-link (값 확정은 L3) + "receiver_candidates": [], + "receipt_evidence_refs": [], + "dispatch_hints": [], + "arrival_hints": [] +}, +``` + +- `` 5항(L3408)에 보강: "When `received_date` cannot be established from selected sources, leave it null and add a `domain_review_queue` item with `issue_type="missing_source"` (do not fabricate); the sealed drafting gate is applied downstream at FL." + +**수정 5-4. `Stage_1_Part_4.yml` — FL1 검출 + FL3 기록 (`BLOCK_FINAL_DRAFTING` 게이트)** + +- FL1 (`Task_FL1_deterministic_fact_ledger_candidate_builder`): 작업 3-3과 같은 위치에 cross-row post-pass `_notice_receipt_gate_scan(rows, bo_by_id)` 추가 — + 1. `extensions.domain_payload.notice_lifecycle`에서 `requires_receipt_for_effect==true`인 notice 수집. + 2. `received_date`와 `arrival_date`가 모두 null이면: 관련 row에 `skeleton_validation_codes += ["NOTICE_RECEIPT_UNVERIFIED"]`, `must_consider=true`, exception_pack에 `severity="HARD_WARNING"` 항목 추가. +- FL3 (`Task_FL3_final_fact_ledger_gate_and_writer`): writer report에 top-level 필드 추가 — + +``` +"drafting_gates": [ + {"gate": "BLOCK_FINAL_DRAFTING", "reason": "NOTICE_RECEIPT_UNVERIFIED", + "notice_ids": [...], "affected_fact_ids": [...]} +] +``` + + 최종 stdout summary에 `drafting_gate_count` 추가. 이 게이트는 **Stage 1 pipeline을 중단시키지 않고**, sealed artifact에 "수령 미확인 통지 기반 final drafting 제한" 신호를 봉인해 Stage 2/drafting 단계가 기계적으로 읽게 한다. + +**하지 말 것**: 도달일 추정 보충("발송 후 3일" 등 — 법리), 발신자 적격 확정(`legal_sender_after_resolution` 값 채우기 — L3), notice_lifecycle_view 조립(L2). + +--- + +### 작업 6 — `asset_id`·`schedule_ref`·`registry_ref` key 승격 (asset_alias 골격) + +``` +Q. 각 key의 스코프? +├─ schedule_ref: 별지목록 항목 → 단일 문서 → Part 1 B1 schedule_items에 deterministic propose +├─ registry_ref: 등기부 row → 단일 문서 → Part 1 B1 registry_row_components에 deterministic propose +└─ asset_id crosswalk(같은 자산의 alias 묶음): 여러 문서 관통 → Part 2 B5 asset_alias named 골격 + (최종 crosswalk view는 L2 — Stage 2. 여기서는 key가 붙은 원천 row만 만든다) +``` + +**수정 6-1. `Stage_1_Part_1.yml` — ``** + +- 위치 ①: ``(L1230-1237)에 1줄 — "`registry_row_components`의 각 row에 `registry_ref`를 부여한다. 형식: `REG-{ordinal:03d}-{row_seq:02d}` (갑구/을구·순위번호 순 deterministic)." +- 위치 ②: ``(L1256-1263)의 schedule_items 항목(L1260)에 1줄 — "`schedule_items`의 각 항목에 `schedule_ref`를 부여한다. 형식: `SCH-{ordinal:03d}-{seq:02d}` (별지 기재 순서 deterministic). asset alias 문자열은 기존대로 함께 보존한다." +- 위치 ③: ``의 slot 스키마(L1291-1313) — `"asset_id": null` 필드는 이미 존재. 규칙 1줄 추가: "slot이 등기부 row 또는 별지 항목에서 직접 파생되면 `registry_ref_hint`/`schedule_ref_hint`를 optional로 남긴다." + +**수정 6-2. `Stage_1_Part_2.yml` — B5 worker `asset_alias` named 골격** + +- 위치: `` domain_payload의 `"asset_alias": []`(L3514). +- 내용: 항목 스키마 명문화 — + +``` +"asset_alias": [ + {"asset_ref": null, // seed 스코프 asset 식별자 (final asset_cluster_id 아님) + "alias_strings": [], + "schedule_refs": [], // Part 1 schedule_items의 SCH-* key + "registry_refs": [], // Part 1 registry_row_components의 REG-* key + "source_evidence_indexes": []} +], +``` + +**하지 말 것**: 최종 asset_cluster_id 확정(Part 3 LES1이 이미 asset_cluster_ids를 결정적으로 부여 — Part 3 L1147-1193 무수정 유지), crosswalk view 조립(L2). + +--- + +### 작업 7 — escalation 메커니즘 (`review_required` / `legal_theory_required`) + +``` +Q. 미확정·법리 필드를 어디로 올리나? +→ 기존 escalation 채널이 이미 2개 존재: worker의 domain_review_queue / FL의 exception_pack +→ 신규 채널을 만들지 않고 enum만 확장한다 (최소 delta) +``` + +**수정 7-1. `Stage_1_Part_2.yml` — 5개 worker 공통 (B1 L2450 / B2 L2716 / B3 L2984 / B4 L3253대 / B5 L3526)** + +- 위치: 각 ``의 `domain_review_queue[].issue_type` enum (B1 L2450 / B2 L2717 / B3 L2984 / B4 L3254 / B5 L3526). +- 내용(치환): + +``` +"issue_type": "missing_source|source_conflict|cross_domain_merge_needed|amount_or_date_uncertain|legal_effect_uncertain|review_required|legal_theory_required" +``` + +- 사용 규칙(각 worker `` 말미에 1줄): "Use `legal_theory_required` for fields this stage must not decide (e.g., lien violation, notice sender standing, possession cause resolution); use `review_required` for extractable-but-unclear facts." + +**수정 7-2. `Stage_1_Part_4.yml` — FL1/FL2** + +- FL1의 exception 생성 시 `escalation` 필드에 위 두 값을 그대로 통과시킨다(신규 로직 불요 — exception description에 태그 포함으로 충분). +- FL2 프롬프트(`` L1268 이하)의 결정 규칙에 1줄: "`legal_theory_required` 태그가 붙은 exception은 PATCH로 해소하지 말고 `BLOCK_REVIEW`(= downstream legal module 소관)를 우선한다." + +--- + +## 3. 실행 순서 Decision Tree (의존성 기반) + +``` +START +└─ Step 1. Part 1 스키마 확장 [작업1-1, 2-1, 2-2, 3-1, 5-1, 6-1] + (하류가 소비할 named 필드/key의 "원천"이 먼저 존재해야 하므로 최우선) + └─ Step 2. Part 1 quality gate 문구 추가 [작업1-2, 2-3, 5-2] + (같은 파일 내 후속 task — Step 1과 같은 편집 세션에서 처리) + └─ Step 3. Part 2 worker 스키마 확장 [작업1-3, 2-4, 3-2, 4-1, 5-3, 6-2, 7-1] + (Part 1 신규 필드를 승계하는 소비자. PostB는 pass-through라 무수정 — §0 근거 참조) + └─ Step 4. Part 4 FL1 게이트 스캔 2종 + FL3 report 필드 [작업3-3, 3-4, 5-4, 7-2] + (BO.json의 신규 payload를 읽는 최종 소비자이자 sealed 기록 지점) + └─ Step 5. schema_contract_version 승급 및 회귀 확인 + ├─ evidence_indexed_part.v3 → v4 (Part 1 B1, L1415) + ├─ evidence_event_candidate_part.v3 → v4 (Part 1 B2, L2057) + ├─ task_c_bo_stage_b_domain_bo_seed.v1 → v2 (Part 2 worker 5종) + └─ 기존 필드 삭제·개명 0건인지 diff로 확인 (additive-only invariant) +END +``` + +분기 규칙: **Step N에서 스키마 충돌(기존 필드와 동명이의)이 발견되면** 신규 필드명을 양보(변경)하고 기존 필드는 절대 건드리지 않는다. **게이트 로직(Step 4)이 기존 exception 메커니즘과 충돌하면** 신규 post-pass를 exception_pack 표준 항목으로 강등하고 전용 코드는 `skeleton_validation_codes`에만 남긴다. + +--- + +## 4. 명시적 비(非)개정 결정 (경계 방어) + +| 항목 | 결정 | 근거 | +|---|---|---| +| Stage 1 독립 final JSON 신설 (7블록) | 하지 않음 | 평가서 §2.6 양 문서 합의 | +| `pre/post_service_rate` 분리 | 하지 않음 | 소장 송달일은 Stage 1에 존재 불가한 값 (§2.1) | +| property_fraction 상태 전이표(folding) | 하지 않음 | 자산 단위 파생구조 — Stage 2 L2 view (§2.2) | +| FL row에 fraction/possession 전용 컬럼 평면화 | 하지 않음 | FL(사실 1건=1 row) 의미 파괴 (§2.2) | +| legal_cause enum의 법적 확정 | 하지 않음 | L3 — Stage 2 법리 (§2.3) | +| lien `violation_candidates`·`status_after_notice_receipt` | 스키마 배제 + escalation | L3 (§2.4) | +| notice 발신자 적격·법률효과일 확정 | 하지 않음 | L3 (§2.5) | +| `Task_S2_0_stage1_handoff_surface_compiler` 등 view 8종 | 본 문서 범위 외 | L2 — Stage 2 개정서에서 다룸 | +| Part 3 (LES) 수정 | 하지 않음 | 개정 5건의 대상 아님; asset_cluster_id 결정 로직 기존 유지 | +| PostB_1~4 수정 | 하지 않음 | domain_payload pass-through 이미 보장 (§0) | + +--- + +## 5. 검증 체크리스트 (개정 완료 판정 게이트) + +``` +[ ] A. Part 1 B1 part 산출물에 agreed_interest_rate / notice 5날짜 / SCH-* / REG-* / fraction_ref가 + "문서에 직접 읽히는 경우에 한해" 채워지고, 없으면 null인가 (창작 금지 invariant) +[ ] B. Part 1 B2 candidate에 fraction_ref·possession_legal_cause_asserted가 optional로 존재하고 + 기존 candidate 스키마 필드가 하나도 삭제되지 않았는가 +[ ] C. Part 2 B5 산출 seed의 lien_state.lien_id가 동일 입력 재실행 시 동일하게 부여되는가 (결정성) +[ ] D. BO.json의 extensions.domain_payload에 신규 named 구조가 PostB 수정 없이 도달하는가 +[ ] E. FL1이 (i) 양립불가 possession cause 쌍, (ii) requires_receipt=true & received/arrival null을 + 결정적으로 검출해 HARD_WARNING exception을 만들고, FL2가 이를 legal_theory_required 규칙대로 + BLOCK_REVIEW 우선 처리하는가 +[ ] F. FL3 writer report에 possession_conflict_gate / drafting_gates(BLOCK_FINAL_DRAFTING)가 + 기록되고 Fact_Ledger_base.json과 함께 봉인되는가 — 단 pipeline은 중단되지 않는가 +[ ] G. schema_contract_version 3종이 승급되었고, diff 상 기존 필드 삭제·개명이 0건인가 +[ ] H. 개정 후에도 §4의 비개정 항목(법리 필드·view 조립)이 Stage 1 산출물 어디에도 생성되지 않는가 +``` + +--- + +## 부록 — 개정 항목 ↔ 파일 위치 총괄표 + +| 파일 | 블록/Task (anchor) | 라인(참고) | 작업 | +|---|---|---|---| +| Part 1 | Task_B1_map_doc ``/`` | L1216-1254 | 1-1 | +| Part 1 | Task_B1_map_doc `` | L1230-1237 | 2-1, 6-1① | +| Part 1 | Task_B1_map_doc `` | L1256-1263 | 5-1, 6-1② | +| Part 1 | Task_B1_map_doc `` | L1291-1313 | 6-1③ | +| Part 1 | Task_B1_map_doc `` | L1427-1452 | 1-1 보조 | +| Part 1 | Task_B2_map_events `` / `` | L1709-1714, L1858-1863 | 2-2 | +| Part 1 | Task_B2_map_events `` | L1921-1953 | 3-1 | +| Part 1 | Task_B2_map_events `` | L1985-2069 | 2-2, 3-1 | +| Part 1 | Task_B1_quality_gate HARD_WARNING 목록 | L2313-2319 | 1-2, 5-2 | +| Part 1 | Task_B2_quality_gate coverage 목록 | L2713-2720 | 2-3 | +| Part 2 | B1_Money_Successor `` money_claim_details | L2435 | 1-3 | +| Part 2 | B2_Secured_Registry `` registry_rows | L2701 | 2-4 | +| Part 2 | B3_Land_Valuation `` possession_state | L2972 | 3-2 | +| Part 2 | B5 `` notice_lifecycle / lien_state / possession_state / asset_alias | L3508-3514 | 3-2, 4-1, 5-3, 6-2 | +| Part 2 | 5개 worker domain_review_queue issue_type | L2450, L2717, L2984, L3254, L3526 | 7-1 | +| Part 4 | Task_FL1 builder — cross-row post-pass 2종 신설 | L1041 이하 | 3-3, 5-4 | +| Part 4 | Task_FL2 prompt — legal_theory_required 처리 규칙 | L1268 이하 | 7-2 | +| Part 4 | Task_FL3 writer report — possession_conflict_gate / drafting_gates | L1788-1857 | 3-4, 5-4 | +| Part 3 | — | — | 무수정 | diff --git a/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v2.md b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v2.md new file mode 100644 index 00000000..009dd935 --- /dev/null +++ b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v2.md @@ -0,0 +1,255 @@ +# Stage 1 개정방식 전략서 — claude_v2 (통합·최종) + +> 선행 문서: `stage_1_개정방식_전략서_claude_v1.md` (이하 **v1**) · `stage_1_개정방식_전략서_codex_v1.md` (이하 **codex**) +> 작성 방식: codex §2~§13을 v1의 실증 기준(실제 YAML 코드 검증)으로 재심사하여, 수용할 것은 수용하고 기각할 것은 근거와 함께 기각한 뒤, **최소 작업으로 최고 품질을 달성하는 단일 실행 전략**으로 재작성했다. +> v2의 결정적 발견: codex가 지적한 **pass-through 문제는 실제 YAML 코드로 확인된 진짜 결함**이다. v1은 PostB pass-through만 검증했고, **Stage_A(component count 압축)·B0(whitelist 재투영 ×5)·FL0(`_compact_bo`의 extensions 탈락)** 3개 지점을 검증하지 않았다. 이 3개 지점을 고치지 않으면 v1의 작업 1~7은 **절반이 무효**가 된다(신규 필드가 worker와 FL 게이트에 도달하지 못함). 따라서 v2는 "작업 0: pass-through 완결"을 최우선 신규 작업으로 추가한다. + +--- + +## 0. 요약 — v2가 v1과 다른 점 + +| # | 변경 | 출처 | 성격 | +|---|---|---|---| +| 1 | **작업 0 신설**: Stage_A·B0×5·FL0 pass-through 보강 | codex §3·STEP 2·Pkg-5 (수용) | v1 결함 정정 — 없으면 작업 1~7이 도달 불능 | +| 2 | FL1 게이트 스캔에 review code 2종 추가 (`LIEN_ASSERTED_AFTER_EXTINCTION_NOTICE_REVIEW`, `LEGAL_CAUSE_STATE_UNKNOWN_REVIEW`) | codex C.4 (수용) | 저비용 품질 보강 | +| 3 | sealed gate 명칭 통합: writer report gate명 `BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING` | codex E (수용·병합) | 명칭 정밀화 | +| 4 | fraction 수치 분해 optional 필드 (`fraction_numerator`/`fraction_denominator`) | codex B.2 (수용) | Stage 2 정규화 비용 절감 | +| 5 | B2 worker에 `fractional_effect_events[]` 명시 배열 | codex B.2 (수용) | 지분 event join 표면 명확화 | +| 6 | asset_alias 골격 보강 (`canonical_label_candidate`, `usable_in_relief`) | codex F.3 (수용) | 문서에 실재하는 사실만 추가 | +| 7 | notice 골격에 `recipient_admission_text`, `legal_sender_after_resolution` 구조 필드 | codex E.3 (수용·값 확정 금지 조건부) | cross-link 구조 개선 | +| 8 | 5개 패키지 실행 단위 + Acceptance Criteria 표 형식 | codex §11·§12 (수용) | 실행 관리 개선 | +| 9 | Task_A·PostB·Middle_Input·B2 gate 수정 등 codex 나머지 제안 | (기각 — §1 판정표) | 최소성 방어 | + +v1의 작업 1~7(항목별 스키마·게이트 설계, anchor 총괄표)은 **본 문서 §4의 병합 수정분을 제외하고 전부 유효**하며, v2는 이를 대체하지 않고 승계한다. + +--- + +## 1. codex_v1 수용/기각 판정표 + +판정 기준: (i) 실제 YAML 코드로 필요성이 입증되는가, (ii) 평가서(신규작업명세서_평가_평가_평가_Claude.md)의 L1 경계를 지키는가, (iii) 최소 작업인가. + +### 1.1 수용 + +| codex 제안 | 판정 근거 (YAML 실증) | +|---|---| +| **Stage_A pass-through 보강** (§3, STEP 2) | **결함 확인.** `Task_C_BO_Stage_A_input_normalization`의 `_build_evidence_authority_map`(Part 2 L545-618)은 B1 component를 `_component_count`(L537)로 **개수만** 압축한다(L580 `component_summary`). 약정이율·notice 5날짜·schedule_ref/registry_ref/fraction_ref는 **내용이 worker에 도달하지 않는다.** 또 `_build_event_candidate_map`의 record dict(L477-506)는 **명시적 필드 whitelist**라 B2 candidate의 신규 top-level 필드(`fraction_ref`)가 탈락한다. | +| **B0 pass-through 보강** (§3) | **결함 확인.** 5개 B0 router가 각각 `EVENT_FIELDS`/`EVIDENCE_FIELDS` whitelist로 재투영한다(`_copy_fields`, L1038·1047 / L1376·1377 / L1591·1592 / L1816·1817 / L2039·2040). Stage_A를 고쳐도 B0에서 다시 탈락한다. | +| **FL pass-through 보강** (Pkg-5) | **결함 확인.** Part 4 FL0의 `_compact_bo`(L284-306)는 BO를 고정 필드로 압축하며 **`extensions.domain_payload`를 통째로 버린다.** v1의 FL1 게이트 스캔(작업 3-3, 5-4)은 `bo_by_id`의 domain_payload를 읽는 설계였으므로, 이 수정 없이는 **게이트가 빈 데이터를 스캔하는 무효 코드**가 된다. | +| gate/review code 2종 추가 (C.4) | FL1 스캔이 이미 (asset, 기간, cause, notice 날짜)를 메모리에 갖게 되므로 비교 2건 추가는 한계비용 수 줄. 유치권 소멸통지 도달 후 유치권 지속(날짜 비교)·점유 사실 존재+권원 track 부재(null 검사) 모두 결정적. | +| `BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING` 명칭 (E) | v1의 2단 구조(row code + writer report `drafting_gates[]`)를 유지하되 gate 식별자를 codex 명칭으로 통일 — Stage 2가 reason 문자열 파싱 없이 gate명만으로 분기 가능. | +| `fraction_numerator`/`fraction_denominator` (B.2) | "2분의 1"의 수치 분해는 결정적 추출(계산 아님). Stage 2 지분 정규화의 파싱 오류원을 제거. optional·null 허용이므로 비용 극소. | +| `fractional_effect_events[]` (B.2) | v1은 `registry_rows[*].fraction_ref`만 두었으나, 지분 **event**(설정/말소 by fraction)가 Stage 2 folding의 실제 join 대상이다. registry row는 상태의 근거일 뿐 event 의미를 담지 않는다. B2 payload에 event ref 배열 1개 추가가 view 신뢰성 대비 저렴. | +| asset_alias 골격 보강 (F.3) | `canonical_label_candidate`(별지 표제 문구)·`usable_in_relief`(청구취지 사용 가능 문구 여부)는 **Part 1 B1 schedule_items가 이미 추출하는 사실**(Part 1 L1260 "청구취지에서 그대로 사용할 수 있는 문구")의 승계이므로 L1 경계 내. | +| notice 골격 보강 (E.3) | `recipient_admission_text`(답변서 수령 인정 원문)는 추출 사실. `legal_sender_after_resolution`은 **구조(status/party/ref)만 두고 값 확정(L3)은 금지**하는 조건으로 수용 — v1의 단일 ref 필드보다 Stage 2 상속 모듈과의 계약이 명확. | +| 패키지·Acceptance 표 (§11·§12) | 실행 단위 관리 형식으로 채택. | + +### 1.2 기각 + +| codex 제안 | 기각 근거 (YAML 실증) | +|---|---| +| Task_A_client_goal 수정 (§3, C.2, E.2, F.2) | **중복.** Task_A에는 `possession_basis_asserted`(Part 1 L355·L537), `notice_lifecycle_hints`(L338), `fractional_title_issue_hint`(L321-322·L500) 등 동등 hint가 **이미 존재**한다. 평가서의 L1 위치 지정도 "B1/B2 추출 + B5 worker 골격"이며 Task_A를 포함하지 않는다. hint layer는 본래 freeform이 허용되는 상담 요약층이다. | +| PostB_1·PostB_3 "보존" 수정 (§3, STEP 4) | **불필요.** PostB_3는 seed의 `extensions.domain_payload`를 그대로 final BO에 병합함이 코드로 확인됨(Part 2 L5340·L5399·L5463). PostB_4의 `ALLOWED_TOP_LEVEL`도 `extensions`를 허용(L5528, L5788-5790). 이미 통과하는 배관을 다시 깔 이유 없음. | +| PostB_4 skeleton key warning (§3, STEP 4) | **중복 게이트.** 동일 검사를 FL1 결정적 스캔이 수행하며, FL 쪽이 sealed 산출물(Fact_Ledger_base.json + writer report)에 직접 봉인되므로 감사 가치가 더 높다. 게이트 이원화는 유지보수 비용만 늘린다. | +| Middle_Input_legal_effect_signals 확장 (§3) | **표면 확장 불필요.** 게이트 결과는 FL3 writer report에 sealed로 존재하고 Stage 2 compiler가 그 파일을 읽는다. signal 파일에 중복 기록하면 두 표면의 불일치 리스크가 생긴다. | +| B2 quality gate에서 possession conflict 검출 (§3) | **비결정성.** Part 1 B2 quality gate는 LLM-backed task다. 모순 차단 게이트를 LLM에 맡기면 평가서 §1.3의 감사논거(결정적 재현성)가 무너진다. 검출은 FL1(결정적 Python) 단일 지점으로 일원화한다. 문서 내 dispatch/arrival 혼동 self-check는 mapper ``에 유사 항목이 이미 존재(Part 1 L1441). | +| possession 2-track을 신규 event 종으로 분리 (C.2: `possession_start/change/end`, `legal_cause_asserted` 등) | **파급 과대.** `event_kind` enum·`REQUIRED_EVENT_SUBKINDS`·identity_signature 규칙까지 연쇄 수정된다. v1의 방식(기존 `current_state_candidate` 내부에 `possession_legal_cause_asserted` 추가)은 whitelist에 이미 있는 컨테이너(L1042 `current_state_candidate`) 내부 중첩이므로 **Stage_A·B0 수정 없이 공짜로 통과**한다. 동일 정보, 1/10 비용. | +| notice_lifecycle를 payload 내 배열로 (E.3) | **BO seed 모델 위반.** 1 seed = 1 법률효과 단위가 BO 설계 원칙이고 provenance(`transport_candidate_refs`)가 seed 단위로 묶인다. 복수 통지는 seed 분리(v1 5-3)로 처리한다. | +| `lien_state` → `lien_state_timeline` key 개명 (D.2) | **additive-only 위반.** 기존 payload key `lien_state`(Part 2 L3512)를 유지하고 내부에 골격을 채운다(v1 4-1). BO type명 `lien_state_timeline_BO`(L2012)와의 대응은 Stage 2 view 명명에서 해소한다. | + +--- + +## 2. v2 개정 원칙 (v1 원칙 + 신규 2개) + +| 원칙 | 내용 | +|---|---| +| (v1 승계) additive-only | 기존 필드 삭제·개명 금지. 신규는 optional·null 허용 | +| (v1 승계) 결정적 key | mapper propose → gate finalize 기존 패턴(`EVT-` 등) 복제 | +| (v1 승계) 게이트는 결정적 task에만 | 검출 = FL1(Python), 봉인 = FL3 writer report. LLM task에 게이트 금지 | +| (v1 승계) 새 final JSON 금지 | 7파일 handoff 유지. Stage 2 L2/L3 작업 침범 금지 | +| **(신규) pass-through 완결성** | 신규 필드를 추가할 때는 **원천(Part 1) → Stage_A → B0 → worker → PostB → FL0 → FL1 전 구간의 투영 코드를 함께 개정**한다. 한 구간이라도 whitelist/압축에서 탈락하면 그 필드는 죽은 스키마다. 모든 신규 필드는 §3.1의 도달 경로표에 등록한다 | +| **(신규) nested-first** | 신규 필드는 가능하면 **이미 whitelist에 있는 컨테이너 내부에 중첩**시켜 투영 코드 수정을 0으로 만든다(예: `current_state_candidate` 내부). top-level 신설은 whitelist 6개 지점 동시 수정을 감수할 가치가 있을 때만(예: `fraction_ref`, `component_details`) | + +--- + +## 3. 작업 0 (신설·최우선) — Pass-through 완결 + +> 이 작업이 완료되기 전에는 작업 1~7의 Part 2·Part 4 개정을 시작하지 않는다(도달 불능 필드를 만들게 됨). + +### 3.1 신규 필드 도달 경로표 (규범) + +| 신규 데이터 | 원천 | Stage_A | B0 | worker | FL0 | FL1 게이트 | +|---|---|---|---|---|---|---| +| 약정이율 2종 | B1 `loan_components`/`secured_debt_components` | **0-A** `component_details` | **0-B** EVIDENCE_FIELDS | B1_Money 승계 | (BO payload 경유) **0-C** | — | +| notice 5날짜·수령 | B1 `notice_components` (+ B2 dispatch/arrival/receipt event는 기존 경로로 이미 도달) | **0-A** | **0-B** | B5 승계 | **0-C** | 수령 게이트 | +| fraction_ref(+display·분자·분모) | B1 `registry_row_components` / B2 candidate top-level | **0-A**(component) + **0-D**(event record) | **0-B**(양쪽) | B2_Secured 승계 | **0-C** | — | +| schedule_ref/registry_ref | B1 `schedule_items`/`registry_row_components` | **0-A** | **0-B** | B5 승계 | **0-C** | — | +| possession 2-track | B2 `current_state_candidate` 내부 (nested) | 수정 불요 (L494 통짜 통과) | 수정 불요 (whitelist 기존 항목) | B3/B5 승계 | **0-C** | 모순 게이트 | +| lien_id·notice_id | Part 2 B5 worker가 부여 (원천 아님) | — | — | B5 | **0-C** | review code | + +### 3.2 수정 0-A. `Stage_1_Part_2.yml` — `Task_C_BO_Stage_A_input_normalization` + +- 위치 ①: `_build_evidence_authority_map`의 record dict(L581-596). +- 내용: `"component_summary"` 유지(하위호환) + 신규 `"component_details"` 추가. 전 component 내용 복사가 아니라 **신규 named 필드만의 유계(bounded) 투영**으로 한다: + +```python +COMPONENT_DETAIL_PROJECTION = { + "loan_components": ["loan_component_id", "principal_amount", "loan_date", "due_date", + "agreed_interest_rate", "agreed_delay_damage_rate", "interest_accrual_start_hint"], + "secured_debt_components": ["agreed_interest_rate", "agreed_delay_damage_rate", "due_date"], + "notice_components": ["notice_id_proposed", "notice_type", "drafted_date", "dispatch_date", + "arrival_date", "received_date", "legal_effect_date_candidate", + "requires_receipt_for_effect", "receipt_evidence_refs", + "recipient_admission_text", "sender_candidates", "receiver_candidates"], + "registry_row_components": ["registry_ref", "fraction_ref", "fraction_display", + "fraction_numerator", "fraction_denominator", "receipt_no"], + "schedule_items": ["schedule_ref", "canonical_label_candidate", "usable_in_relief"], +} +# record 조립부에 1줄: +"component_details": {k: [_copy_fields(c, fields) for c in _as_list(item.get(k))] + for k, fields in COMPONENT_DETAIL_PROJECTION.items() if item.get(k)}, +``` + +- 위치 ②: `_build_event_candidate_map`의 record dict(L477-506) — `"confidence"` 앞에 1줄 추가: `"fraction_ref": cand.get("fraction_ref"),` +- schema_version은 유지 가능(additive)하되, 회귀 추적을 위해 `evidence_authority_map.v1`→`v2`, `event_candidate_map.v1`→`v2` 승급을 권장. + +### 3.3 수정 0-B. `Stage_1_Part_2.yml` — 5개 B0 router whitelist (기계적 동일 편집 ×5) + +- 위치: `EVENT_FIELDS`/`EVIDENCE_FIELDS` 5쌍 — L1038·1047 / L1376·1377 / L1591·1592 / L1816·1817 / L2039·2040. +- 내용: `EVENT_FIELDS`에 `"fraction_ref"` 1개, `EVIDENCE_FIELDS`에 `"component_details"` 1개 추가. **5곳 모두 동일하게** — diff에서 5쌍의 목록이 문자 단위로 일치하는지 확인한다(한 곳만 누락되면 해당 도메인 worker만 조용히 필드를 잃는 최악의 부분 장애가 된다). + +### 3.4 수정 0-C. `Stage_1_Part_4.yml` — `Task_FL0` `_compact_bo` (L284-306) + +- 내용: return dict에 유계 투영 1줄 추가: + +```python +DOMAIN_PAYLOAD_KEEP_KEYS = ["money_claim_details", "possession_state", "lien_state", + "notice_lifecycle", "asset_alias", "fractional_effect_events"] +# _compact_bo return dict에: +"domain_payload_compact": {k: v for k, v in + _as_dict(_as_dict(bo.get("extensions")).get("domain_payload")).items() + if k in DOMAIN_PAYLOAD_KEEP_KEYS and v not in (None, {}, [])}, +``` + +- FL1의 게이트 스캔 2종(작업 3-3, 5-4)은 `bo_by_id[*].domain_payload_compact`를 읽도록 v1 지시를 정정한다. `fact_source_pack` schema_version `stage1_fact_source_pack.v1`→`v2` 승급. + +### 3.5 수정 0-D 해당 없음 여부의 명시적 확인 (검증 전용, 무수정) + +- PostB_1~4: 무수정 (§1.2 기각 근거의 코드 라인 참조). +- Part 3 (LES): 무수정 — LES0/LES1은 자체 입력 pack을 쓰며 개정 5건의 필드를 소비하지 않는다. + +--- + +## 4. 작업 1~7 — v1 승계 + codex 병합 수정분 + +아래는 v1 §2의 해당 작업에 **덧붙이거나 정정하는 delta만** 기술한다. 위치 anchor는 v1 부록 총괄표를 그대로 사용한다. + +### 작업 1 (약정이율) — delta + +- v1 1-1의 ``에 필드 2개 추가: `"rate_text": null`(원문 그대로), `"rate_source_locator": null`(조항 locator) — codex A.2의 `rate_text`/`rate_source_span` 수용(감사 추적성). +- `secured_debt_components`에도 동일 rate 필드를 추가한다(codex A.2) — 근저당 설정계약서·차용증 겸용 문서의 이율은 secured_debt 쪽에서 읽히는 경우가 있다. 위치: v1 1-1과 같은 RULE 블록에 1줄. +- B1_Money worker `money_claim_details`에 `"interest_rate_source_evidence_refs": []` 추가(codex A.2) — rate의 근거 evidence index 보존. + +### 작업 2 (fraction_id) — delta + +- B1 `registry_row_components`에 optional 2필드 추가: `"fraction_numerator": null, "fraction_denominator": null` (직접 읽히는 경우만; "2분의 1"→1/2. 환산·약분 금지). +- B2_Secured_Registry worker payload에 배열 1개 추가(v1 2-4를 대체·확장): + +``` +"fractional_effect_events": [ + {"fraction_ref": null, "fraction_display": null, + "fraction_numerator": null, "fraction_denominator": null, + "effect_kind_hint": "mortgage_setting|mortgage_extinguishment|transfer|other", + "source_event_candidate_ids": [], "registry_refs": [], "evidence_indexes": []} +], +``` + + 규칙: 상태 folding·정규화 금지, event ref 나열까지만. `registry_rows[*].fraction_ref`(v1 2-4)도 유지. + +### 작업 3 (possession 2-track + 모순 게이트) — delta + +- FL1 스캔이 읽는 원천을 `domain_payload_compact`로 정정(작업 0-C). +- FL1 스캔에 review code 1종 추가: 점유 사실 row가 있는데 대응 `legal_cause_assertions`가 전무하면 `LEGAL_CAUSE_STATE_UNKNOWN_REVIEW`(SOFT — HARD 아님; 권원 부재 주장 자체가 소송상 유리할 수 있으므로 차단이 아니라 검토 신호만). +- 2-track 골격(v1 3-2)은 whitelist 기존 컨테이너 내부이므로 작업 0의 수정 없이도 worker에 도달하지만, **FL 게이트 도달을 위해 작업 0-C는 필수**임을 명시. + +### 작업 4 (lien_state 골격 + lien_id) — delta + +- key명 `lien_state` 유지(§1.2 기각 근거). 골격 내부에 codex D.3의 `secured_claim_ref.debtor_candidate`·`claimed_remaining_amount_hint`를 v1 4-1의 `secured_claim_hint`에 병합: + +``` +"secured_claim_hint": {"debtor_candidate": null, "basis_text": null, + "claimed_remaining_amount_hint": null, "evidence_indexes": []}, +``` + +- FL1 스캔에 review code 1종 추가: `lien_state`에 소멸통지 receipt(도달/수령일 존재)가 연결되어 있는데 그 날짜 **이후**의 점유/임대 event가 같은 asset에 존재하면 `LIEN_ASSERTED_AFTER_EXTINCTION_NOTICE_REVIEW`(HARD_WARNING 아님 — 소멸 여부는 L3 판단이므로 review 신호). 날짜 비교는 결정적. + +### 작업 5 (notice 5날짜 + 수령 게이트) — delta + +- B1 `notice_components` 스키마(v1 5-1)에 `"recipient_admission_text": null` 추가 — 단, **답변서 문서의 component에서만** 채운다(통지서 자기 문서에 타 문서 사실 주입 금지 원칙은 v1 그대로). +- B5 `notice_lifecycle` 골격(v1 5-3)의 `legal_sender_after_resolution_ref` 단일 필드를 codex E.3 구조로 교체: + +``` +"legal_sender_after_resolution": { + "status": "resolved|unresolved|disputed|not_required", + "party": null, // Stage 1에서는 항상 null로 남긴다 (값 확정 = L3) + "succession_resolution_ref": null +}, +``` + +- FL3 writer report의 gate 항목 명칭 정정: + +``` +"drafting_gates": [ + {"gate": "BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING", + "row_code": "NOTICE_RECEIPT_UNVERIFIED", + "notice_ids": [...], "affected_fact_ids": [...]} +] +``` + +### 작업 6 (asset key) — delta + +- B1 `schedule_items`에 optional 2필드 추가: `"canonical_label_candidate": null`(별지 표제 문구), `"usable_in_relief": "yes|no|unknown"`(청구취지 직접 사용 가능 여부 — 이미 v.5가 추출하는 판단의 명시화). +- B5 `asset_alias` 골격(v1 6-2)에 두 필드 승계 + `registry_ref` 상세(codex F.3의 `receipt_no_refs`)를 `registry_refs` 항목 내 optional로 병합. + +### 작업 7 (escalation) — 변경 없음 (v1 그대로) + +--- + +## 5. 실행 패키지 (codex §11 형식 수용, v2 내용으로 재구성) + +| 패키지 | 파일 | 내용 | 선행 조건 | 성공 기준 | +|---|---|---|---|---| +| **Pkg-0 Pass-through** | Part 2, Part 4 | 작업 0-A/0-B/0-C | 없음 (최우선) | 테스트 BO에 심은 신규 필드가 worker 입력 slice와 fact_source_pack에 도달 | +| Pkg-1 Part 1 원천 | Part 1 | 작업 1-1, 2-1/2-2, 3-1, 5-1, 6-1 (v1) + §4 delta | 없음 (Pkg-0과 병행 가능) | B1/B2 part 파일에 신규 named 필드가 "직접 읽히는 경우만" 등장 | +| Pkg-2 Part 1 gate | Part 1 | 작업 1-2, 2-3, 5-2 (v1) | Pkg-1 | 누락 시나리오에서 HARD_WARNING `review_findings[]` 생성 | +| Pkg-3 Worker 골격 | Part 2 | 작업 1-3, 2-4+delta, 3-2, 4-1+delta, 5-3+delta, 6-2+delta, 7-1 | Pkg-0, Pkg-1 | B5 payload에 빈 `{}` 부재; lien_id 재실행 결정성; BO.json 도달 | +| Pkg-4 FL sealed gate | Part 4 | 작업 3-3/3-4, 5-4 (v1, 0-C 정정 반영) + review code 2종 | Pkg-0, Pkg-3 | 모순/수령누락 시나리오에서 `POSSESSION_CAUSE_CONFLICT`·`BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING`이 writer report에 봉인; pipeline은 비중단 | +| Pkg-5 버전·회귀 | 전체 | schema_version 승급 5종(v1 3종 + `evidence_authority_map.v2`·`event_candidate_map.v2`·`stage1_fact_source_pack.v2`), diff 검사 | 전 패키지 | 기존 필드 삭제·개명 0건; B0 whitelist 5쌍 문자 단위 일치 | + +의존성 그래프: `Pkg-0 ∥ Pkg-1` → `Pkg-2` → `Pkg-3` → `Pkg-4` → `Pkg-5`. + +--- + +## 6. Acceptance Criteria (v1 체크리스트 대체·확장) + +| # | 검증 | 기준 | +|---|---|---| +| 1 | YAML parse | 4개 파일 parse 성공 | +| 2 | 새 final JSON 없음 | 7파일 handoff 체계 유지 | +| 3 | **pass-through 왕복** | Part 1 part 파일에 심은 각 신규 필드가 (i) B0 slice, (ii) worker payload, (iii) BO.json, (iv) fact_source_pack `domain_payload_compact`까지 도달 — 필드별 왕복 테스트 | +| 4 | 창작 금지 invariant | 문서에 없는 값은 전 구간 null 유지 (법정이율 보충·도달일 추정·지분 약분 금지) | +| 5 | 결정성 | 동일 입력 2회 실행 시 lien_id·notice_id·fraction_ref·게이트 코드 동일 | +| 6 | sealed gate | 모순·수령누락 fixture에서 `POSSESSION_CAUSE_CONFLICT` / `BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING` / `LIEN_ASSERTED_AFTER_EXTINCTION_NOTICE_REVIEW` / `LEGAL_CAUSE_STATE_UNKNOWN_REVIEW`가 FL3 writer report·`skeleton_validation_codes`에 기록되고 pipeline은 중단되지 않음 | +| 7 | L3 침범 없음 | Stage 1 산출물 어디에도 pre/post_service_rate·시효기간·견련성·발신자 적격 확정값·지분 상태 folding이 없음 | +| 8 | additive-only | diff 상 기존 필드 삭제·개명 0건; `interest_hint`·`dispatch_hints`·`arrival_hints`·`lien_state` key 잔존 | +| 9 | B0 5중 일치 | EVENT_FIELDS/EVIDENCE_FIELDS 5쌍이 문자 단위 동일 | +| 10 | Stage 2 연결성 | 7파일 + evidence_indexed/event_candidates를 읽는 Stage 2 `Task_S2_0` compiler 설계(별도 문서)가 본 개정의 key·골격을 전제로 view 조립 가능 | + +--- + +## 7. 최종 결론 + +codex_v1의 가장 큰 기여는 **pass-through 경고**였고, 이는 실제 코드 검증 결과 v1의 치명적 맹점이었음이 확인되었다(Stage_A count 압축 · B0 whitelist ×5 · FL0 extensions 탈락). v2는 이를 "작업 0"으로 수용하되, codex가 함께 제안한 광범위 수정(Task_A·PostB·Middle_Input·신규 event 종·key 개명)은 코드 근거로 기각하여 최소성을 지켰다. + +한 줄 요약: + +> **v2 = v1의 검증된 anchor·스키마·게이트 설계 + codex의 pass-through 완결(작업 0) + 저비용 품질 보강 6건. "필드를 만드는 일"보다 "필드가 끝까지 도달하게 하는 일"이 이번 개정의 절반이다.** diff --git a/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_codex_v1.md b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_codex_v1.md new file mode 100644 index 00000000..6e34b191 --- /dev/null +++ b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_codex_v1.md @@ -0,0 +1,484 @@ +# Stage 1 v5 Layer 1 개정방식 전략서 + +## 0. 목적 + +본 전략서는 `신규작업명세서_평가_평가_평가_Claude.md`의 Layer 1 개정 제안을 받아들여, Stage 1 v5의 4개 YAML 파일에 어떤 순서와 방식으로 최소 개정을 넣을지 결정트리 형식으로 정리한다. + +대상 YAML은 다음 4개다. + +| Part | 파일 | 역할 | +|---|---|---| +| Part 1 | `Stage_1_Part_1.yml` | `client_goal.json`, evidence/component extraction, event candidates, quality gates | +| Part 2 | `Stage_1_Part_2.yml` | BO 생성, B1-B5 domain worker, PostB compiler, 3 signal files | +| Part 3 | `Stage_1_Part_3.yml` | `legal_effect_structures.json` 생성 | +| Part 4 | `Stage_1_Part_4.yml` | `Fact_Ledger_base.json` 생성 및 sealed gate | + +최종 목표는 다음이다. + +**Stage 1 final JSON 파일을 새로 늘리지 않고, 기존 7파일 handoff surface를 유지하면서, Stage 2가 신뢰할 수 있는 결정적 원천 구조를 Stage 1에서 최소한으로 sealed 처리한다.** + +## 1. 최상위 의사결정 트리 + +아래 결정트리는 Stage 1 v5 개정 범위를 정하는 기준이다. + +```text +START + | + |-- Q1. Stage 1 입력 문서에서 실제로 존재하는 원천 데이터인가? + | | + | |-- NO -> Stage 1에서 만들지 않는다. + | | Stage 2 Layer 2/3 derived view 또는 법리 계산으로 넘긴다. + | | + | |-- YES -> Q2로 이동 + | + |-- Q2. 현재 v5에서 freeform hint, 빈 {}, [] 또는 event만으로 남아 비결정성이 있는가? + | | + | |-- NO -> Stage 1 개정하지 않는다. Stage 2에서 7파일 handoff compiler가 조립한다. + | | + | |-- YES -> Q3로 이동 + | + |-- Q3. 그 정보가 Fact_Ledger_base.json이 봉인되기 전에 모순 또는 drafting block을 막아야 하는가? + | | + | |-- YES -> Stage 1 sealed gate 대상. + | | Part 1/2에서 named 구조화 + Part 4 FL gate에 skeleton_validation_codes 추가. + | | + | |-- NO -> Stage 1에서 key/named skeleton까지만 부여. + | 조립/법리 판단은 Stage 2로 넘긴다. +``` + +Layer별 책임은 다음처럼 고정한다. + +| Layer | 위치 | 책임 | Stage 1 개정 여부 | +|---|---|---|---| +| Layer 1 | Stage 1 | 원천 데이터 named/key 승격, 빈 컨테이너 스키마화, 모순/수령 gate 봉인 | 본 전략서의 개정 대상 | +| Layer 2 | Stage 2 `Task_S2_0_stage1_handoff_surface_compiler` | 7파일 handoff를 조립하여 derived view 생성 | Stage 1에서 하지 않음 | +| Layer 3 | Stage 2 법리 모듈 | 시효, 이율, 견련성, 현재 권리귀속, 가액배상 cap 등 법률 적용 | Stage 1에서 하지 않음 | + +## 2. 개정 원칙 + +| 원칙 | 내용 | +|---|---| +| 새 final JSON 금지 | `money_claim_timeline.json`, `property_fraction_state_timeline.json`, `notice_lifecycle.json` 같은 새 Stage 1 final file은 만들지 않는다 | +| 기존 7파일 handoff 유지 | `client_goal.json`, `BO.json`, `legal_effect_structures.json`, `Fact_Ledger_base.json`, 3 signals를 유지한다 | +| Part 1은 원천 추출만 | 문서에 실제로 있는 날짜, 이율, 지분, asset 표시, notice 수령 사실만 named field로 추출한다 | +| Part 2는 BO payload skeleton | B1/B2/B5 worker의 `extensions.domain_payload`에 named skeleton을 만든다 | +| Part 4는 sealed gate | 자기모순 ledger와 final drafting 제한 사유를 `skeleton_validation_codes`/writer report로 봉인한다 | +| Stage 2로 넘길 것 구분 | legal conclusion은 Stage 1에서 확정하지 않고 `review_required` 또는 `legal_theory_required`로 올린다 | + +## 3. YAML별 개정 위치 요약 + +| 파일 | task | 개정 목적 | +|---|---|---| +| `Stage_1_Part_1.yml` | `Task_A_client_goal` | `current_control_map_4axis`에 `legal_cause_state_hint`, `asset_id`, notice/succession watchpoint를 추가 | +| `Stage_1_Part_1.yml` | `Task_B1_map_doc_*` | 약정이율, 지분 key, asset refs, notice 5날짜, receipt evidence를 component로 named 추출 | +| `Stage_1_Part_1.yml` | `Task_B2_map_events_*` | `fraction_id`, `notice_id`, `lien_id`, `asset_id`를 event에 부착하고 possession/legal-cause 2-track event를 분리 | +| `Stage_1_Part_1.yml` | `Task_B1_quality_gate_evidence_indexed` | named field 누락 warning/error 생성 | +| `Stage_1_Part_1.yml` | `Task_B2_quality_gate_event_candidates` | event key 누락, notice 수령 누락, possession/legal-cause conflict 후보를 gate finding으로 남김 | +| `Stage_1_Part_2.yml` | `Task_C_BO_Stage_A_input_normalization` | Part 1 신규 key들이 compact context에서 탈락하지 않도록 whitelist/compact map 보강 | +| `Stage_1_Part_2.yml` | `Task_C_BO_Stage_B0_input_*` | B1/B2/B5 domain slice가 신규 fields를 읽을 수 있게 `EVENT_FIELDS`/`EVIDENCE_FIELDS` 또는 component pass-through 보강 | +| `Stage_1_Part_2.yml` | `Task_C_BO_Stage_B_B1_Money_Successor` | `agreed_interest_rate`, `agreed_delay_damage_rate`를 `money_claim_details`에 named 추가 | +| `Stage_1_Part_2.yml` | `Task_C_BO_Stage_B_B2_Secured_Registry` | `fraction_id` 기반 `fractional_effect_events` skeleton 추가 | +| `Stage_1_Part_2.yml` | `Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense` | `notice_lifecycle`, `lien_state_timeline`, `possession_legal_cause_tracks`, `asset_alias_map_seed` named skeleton 추가 | +| `Stage_1_Part_2.yml` | `Task_C_BO_PostB_1_seed_ledger_compiler` | 신규 domain_payload keys 보존 및 candidate ledger에 반영 | +| `Stage_1_Part_2.yml` | `Task_C_BO_PostB_3_final_bo_compiler` | final `BO.json`에 신규 payload keys를 안전하게 병합 | +| `Stage_1_Part_2.yml` | `Task_C_BO_PostB_4_final_gate_and_writer` | B5 skeleton 필수 key 누락을 writer warning/blocker로 기록 | +| `Stage_1_Part_2.yml` | `Task_C_BO_Middle_Input_legal_effect_signals` | 새 파일을 만들지 않고 existing signal에 sealed gate hints 또는 state-route hints를 확장 | +| `Stage_1_Part_4.yml` | `Task_FL1_deterministic_fact_ledger_candidate_builder` | possession/legal-cause conflict, notice receipt gate 후보를 fact row `skeleton_validation_codes`로 생성 | +| `Stage_1_Part_4.yml` | `Task_FL3_final_fact_ledger_gate_and_writer` | `BLOCK_FINAL_DRAFTING_*`, `POSSESSION_LEGAL_CAUSE_CONFLICT` 등 sealed code를 최종 보존 | + +## 4. Branch A: `money_claim_timeline` + +### A.1 Decision Tree + +```text +문서에 금전채권/변제기/이자/지연손해금 단서가 있는가? + | + |-- NO -> 기존 구조 유지. Stage 2 timeline view에서 계산하지 않음. + | + |-- YES -> 약정이율 또는 약정 지연손해금률이 문서에 명시되어 있는가? + | + |-- YES -> Stage 1 Layer 1 named field로 승격. + | + |-- NO -> null로 두고 warning은 만들지 않는다. + 법정이율/pre-post service rate는 Stage 2 계산으로 둔다. +``` + +### A.2 개정 위치와 방식 + +| 위치 | 개정 내용 | +|---|---| +| Part 1 `Task_B1_map_doc_*` | `claim_document_components[*]`에 `agreed_interest_rate`, `agreed_delay_damage_rate`, `rate_text`, `rate_basis_text`, `rate_source_span` 추가 | +| Part 1 `Task_B1_map_doc_*` | 담보채무 문서인 경우 `secured_debt_components[*]`에도 동일 rate fields 추가 | +| Part 2 `Task_C_BO_Stage_A_input_normalization` | `component_summary.claim_document_components`와 `secured_debt_components`에서 rate fields가 drop되지 않게 pass-through | +| Part 2 `Task_C_BO_Stage_B_B1_Money_Successor` | `extensions.domain_payload.money_claim_details`에 `agreed_interest_rate`, `agreed_delay_damage_rate`, `interest_rate_source_evidence_refs` 추가 | +| Part 4 `Task_FL1/FL3` | rate가 있으면 `legal_calculation_object.amount_source`류에 rate source를 요약할 수 있게 두되, 법정이율 확정은 하지 않음 | + +### A.3 하지 말 것 + +| 금지 | 이유 | +|---|---| +| `pre_service_rate`, `post_service_rate`를 Stage 1에서 확정 | 소장 송달일은 Stage 1 시점에 존재하지 않음 | +| `limitation_period`를 Stage 1에서 확정 | 법률 적용/시효 계산은 Layer 3 책임 | +| 통합 `money_claim_timeline.json` 생성 | Stage 2 `money_claim_timeline_view`로 충분 | + +## 5. Branch B: `property_fraction_state_timeline` + +### B.1 Decision Tree + +```text +client_goal 또는 registry/evidence에 지분별 효력 차이가 보이는가? + | + |-- NO -> 기존 registry/secured 구조 유지. + | + |-- YES -> event 또는 registry row가 특정 지분을 가리키는가? + | + |-- YES -> Stage 1에서 fraction_id를 부착한다. + | + |-- NO -> fraction_id=null, fraction_text 보존, review_required. + Stage 2가 정규화하지 못하면 blocking_gaps. +``` + +### B.2 개정 위치와 방식 + +| 위치 | 개정 내용 | +|---|---| +| Part 1 `Task_A_client_goal` | `fractional_title_issue_hint`에 `asset_id`, `fraction_id_candidates`, `fraction_texts` 추가 | +| Part 1 `Task_B1_map_doc_*` | `registry_row_components[*]`에 `asset_id`, `fraction_id`, `fraction_text`, `fraction_numerator`, `fraction_denominator`, `registry_ref` 추가 | +| Part 1 `Task_B2_map_events_*` | `mortgage_setting_by_fraction`, `mortgage_extinguishment_by_fraction` event에 `asset_id`, `fraction_id`, `registry_row_ref`, `fraction_text` 부착 | +| Part 1 `Task_B2_quality_gate_event_candidates` | 지분 event인데 `fraction_id`와 `fraction_text`가 모두 없으면 `HARD_WARNING` | +| Part 2 `Task_C_BO_Stage_B_B2_Secured_Registry` | `extensions.domain_payload.fractional_effect_events[]` 추가. full state table은 만들지 않음 | +| Part 2 `Task_C_BO_PostB_3_final_bo_compiler` | B2 BO에 `fractional_effect_events` 보존 | + +### B.3 산출 방식 + +| 선택지 | 결론 | +|---|---| +| 독립 `property_fraction_state_timeline.json` | 만들지 않음 | +| `Fact_Ledger_base.json` 컬럼으로 평면화 | 하지 않음. FL은 사실 row이고 상태 전이표가 아님 | +| `BO.json`의 B2 domain payload | 최소 원천 구조 보존에 적합 | +| Stage 2 derived view | 최종 지분 상태표 생성 위치 | + +## 6. Branch C: `possession_state` ↔ `legal_cause_state` + +### C.1 Decision Tree + +```text +점유/사용/임대/유치권/무권원/인도거절 단서가 있는가? + | + |-- NO -> 기존 current state 구조 유지. + | + |-- YES -> 사실 점유와 법률상 원인을 분리할 수 있는가? + | + |-- YES -> possession_track + legal_cause_track 2-track 생성. + | + |-- NO -> 직접 읽히는 사실만 track에 넣고 legal_cause_state=unknown/disputed. + | + |-- 이후 동일 asset/period/party에서 양립 불가 상태가 있는가? + | + |-- YES -> Stage 1 sealed gate: HARD_WARNING + skeleton_validation_codes. + | + |-- NO -> Stage 2 legal-cause 확정으로 넘김. +``` + +### C.2 개정 위치와 방식 + +| 위치 | 개정 내용 | +|---|---| +| Part 1 `Task_A_client_goal` | `current_control_map_4axis`를 유지하되 optional `legal_cause_state_hint`와 `asset_id` 추가 | +| Part 1 `Task_B2_map_events_*` | possession factual events와 legal-cause raw events를 분리. 예: `possession_start`, `possession_change`, `possession_end`, `legal_cause_asserted`, `legal_cause_extinction_candidate` | +| Part 2 `Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense` | `possession_legal_cause_tracks` named skeleton 추가 | +| Part 2 `Task_C_BO_PostB_4_final_gate_and_writer` | B5 BO에 track이 있는데 `asset_id`가 없으면 warning | +| Part 4 `Task_FL1_deterministic_fact_ledger_candidate_builder` | candidate row 생성 시 동일 asset/period/party conflict 후보를 계산 | +| Part 4 `Task_FL3_final_fact_ledger_gate_and_writer` | 최종 row의 `skeleton_validation_codes`에 conflict code 보존 | + +### C.3 권장 skeleton + +```json +{ + "possession_legal_cause_tracks": [ + { + "asset_id": "string|null", + "possessor_candidate": "string|null", + "period": {"start": "date|null", "end": "date|null"}, + "possession_state": "possessed|not_possessed|disputed|unknown", + "legal_cause_state_raw": "lease|owner_consent|lien_asserted|no_title|succession_uncertain|extinguished_after_notice|disputed|unknown", + "source_event_candidate_ids": [], + "source_evidence_indexes": [], + "legal_theory_required": true + } + ] +} +``` + +### C.4 Gate Codes + +| code | 의미 | +|---|---| +| `POSSESSION_LEGAL_CAUSE_CONFLICT` | 동일 asset/period/party에서 점유 권원 상태가 양립 불가 | +| `LIEN_ASSERTED_AFTER_EXTINCTION_NOTICE_REVIEW` | 유치권 소멸통지 도달 후에도 유치권 행사 상태가 계속되는 후보 | +| `LEGAL_CAUSE_STATE_UNKNOWN_REVIEW` | 점유 사실은 있으나 법률상 원인 raw track이 없음 | + +## 7. Branch D: `lien_state_timeline` + +### D.1 Decision Tree + +```text +유치권 주장, 피담보채권, 점유, 유치권 소멸통지 단서가 있는가? + | + |-- NO -> B5 lien_state_timeline 비움. + | + |-- YES -> lien_id를 부여할 수 있는가? + | + |-- YES -> LIEN-001... deterministic id 부여. + | + |-- NO -> asset/claimant 기준 임시 lien_id 부여 + review_required. + | + |-- secured_claim/possession_events/status 판단은? + | + |-- 사실로 직접 읽히는 값 -> skeleton에 ref만 보존. + |-- 법리 적용 필요한 값 -> legal_theory_required=true. +``` + +### D.2 개정 위치와 방식 + +| 위치 | 개정 내용 | +|---|---| +| Part 1 `Task_B1_map_doc_*` | 유치권 관련 문서/답변서에서 `secured_claim` 단서, 점유 기간, 차임, owner consent, 통지 수령 단서 추출 | +| Part 1 `Task_B2_map_events_*` | `lien_assertion`, `lien_possession_event`, `lien_extinction_notice_dispatch`, `lien_extinction_notice_receipt` event에 `lien_id`, `asset_id`, `notice_id` 부착 | +| Part 2 `Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense` | 기존 `lien_state:{}`를 `lien_state_timeline` named skeleton으로 확장 | +| Part 2 `Task_C_BO_PostB_1_seed_ledger_compiler` | `lien_id`와 source refs 보존 | +| Part 2 `Task_C_BO_PostB_3_final_bo_compiler` | `lien_state_timeline`을 B5 BO payload에 병합 | +| Part 4 `Task_FL1/FL3` | `legal_theory_required`, notice-after-status review code를 FL row에 반영 | + +### D.3 권장 skeleton + +```json +{ + "lien_state_timeline": [ + { + "lien_id": "LIEN-001", + "asset_id": "string|null", + "claimant_candidate": "string|null", + "secured_claim_ref": { + "debtor_candidate": "string|null", + "basis_text": "string|null", + "claimed_remaining_amount_hint": "string|null", + "source_evidence_indexes": [] + }, + "possession_event_refs": [], + "extinction_notice_refs": [], + "review_required": [], + "legal_theory_required": [] + } + ] +} +``` + +### D.4 하지 말 것 + +| 금지 | 이유 | +|---|---| +| Stage 1에서 견련성 인정 여부 확정 | 법리 적용은 Layer 3 | +| Stage 1에서 `status_after_notice_receipt`를 final 확정 | 소멸 요건 판단은 Stage 2 법리 | +| 빈 `lien_state:{}` 유지 | 동일 입력 비결정성과 유실 위험 | + +## 8. Branch E: `notice_lifecycle` + +### E.1 Decision Tree + +```text +내용증명/통지서/답변서상 수령 인정/도달 단서가 있는가? + | + |-- NO -> notice_lifecycle 비움. + | + |-- YES -> notice_id 부여 후 5개 날짜를 분리한다. + | + |-- drafted_date : 작성일 + |-- dispatch_date : 발송일 + |-- arrival_date : 도달 추정일/배달일 + |-- received_date : 수령일 또는 답변서상 수령 인정일 + |-- legal_effect_date_candidate : 직접 읽히는 효과일 후보만 + | + |-- requires_receipt=true인데 received_date 또는 receipt_evidence_refs가 없는가? + | + |-- YES -> BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING sealed code. + | + |-- NO -> Stage 2 notice_lifecycle_view로 넘김. +``` + +### E.2 개정 위치와 방식 + +| 위치 | 개정 내용 | +|---|---| +| Part 1 `Task_A_client_goal` | `notice_lifecycle_hints`에 `notice_id_candidates`, `requires_receipt_candidate`, `asset_id` 추가 | +| Part 1 `Task_B1_map_doc_*` | `notice_components[*]`에 5개 날짜와 `receipt_evidence_refs`, `recipient_admission_text`, `sender_candidates`, `recipient_candidates` 추가 | +| Part 1 `Task_B2_map_events_*` | `notice_dispatch`, `notice_arrival`, `notice_received`, `receipt_admission`, `notice_legal_effect_candidate` event를 분리 | +| Part 1 `Task_B2_quality_gate_event_candidates` | dispatch/arrival/received가 서로 혼동되면 `HARD_WARNING`; received 필수인데 없으면 drafting block 후보 | +| Part 2 `Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense` | 기존 `notice_lifecycle:{dispatch_hints,arrival_hints}`를 named skeleton으로 확장 | +| Part 2 `Task_C_BO_PostB_3_final_bo_compiler` | notice skeleton을 B5 BO payload에 보존 | +| Part 4 `Task_FL1/FL3` | `BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING`를 `skeleton_validation_codes` 또는 writer report에 봉인 | + +### E.3 권장 skeleton + +```json +{ + "notice_lifecycle": [ + { + "notice_id": "NOTICE-001", + "notice_type": "demand|lien_extinction|termination|delivery_request|other|unknown", + "sender_candidates": [], + "recipient_candidates": [], + "drafted_date": "date|null", + "dispatch_date": "date|null", + "arrival_date": "date|null", + "received_date": "date|null", + "receipt_evidence_refs": [], + "recipient_admission_text": "string|null", + "legal_effect_candidate": { + "effect": "default_start|limitation_preservation|lien_extinction|delivery_delay|termination|other|unknown", + "effect_date_candidate": "date|null", + "requires_receipt": true + }, + "legal_sender_after_resolution": { + "status": "resolved|unresolved|disputed|not_required", + "party": "string|null", + "succession_resolution_ref": "string|null" + } + } + ] +} +``` + +## 9. Branch F: `asset_id`, `schedule_ref`, `registry_ref` + +### F.1 Decision Tree + +```text +별지목록, 등기부 표시, 실제 점유 객체, asset alias가 등장하는가? + | + |-- NO -> 기존 asset_refs 유지. + | + |-- YES -> canonical asset_id를 부여할 수 있는가? + | + |-- YES -> schedule_ref/registry_ref/aliases를 같은 asset_id에 묶는다. + | + |-- NO -> asset_alias_map_seed에 unresolved 후보로 보존. +``` + +### F.2 개정 위치와 방식 + +| 위치 | 개정 내용 | +|---|---| +| Part 1 `Task_A_client_goal` | `current_control_map_4axis[*].asset_id`, `asset_alias_candidates` 추가 | +| Part 1 `Task_B1_map_doc_*` | `schedule_items[*]`, `registry_object_display`, `registry_row_components[*]`에 `asset_id`, `schedule_ref`, `registry_ref`, `canonical_label_candidate` 추가 | +| Part 2 `Task_C_BO_Stage_B_B5_Succession_Notice_Lien_Asset_Defense` | `asset_alias_map_seed` skeleton 추가 | +| Part 2 `Task_C_BO_PostB_3_final_bo_compiler` | BO payload에 asset crosswalk seed 보존 | +| Part 4 `Task_FL1/FL3` | fact row `object_spec`/`state_context.asset_cluster_ids`와 asset_id seed 충돌 시 review code | + +### F.3 권장 skeleton + +```json +{ + "asset_alias_map_seed": [ + { + "asset_id": "ASSET-001", + "canonical_label_candidate": "string|null", + "aliases": [], + "schedule_ref": { + "evidence_index": "string|null", + "schedule_item_id": "string|null", + "usable_in_relief": "yes|no|unknown" + }, + "registry_ref": { + "evidence_index": "string|null", + "address": "string|null", + "exclusive_part": "string|null", + "receipt_no_refs": [] + }, + "unresolved_conflicts": [] + } + ] +} +``` + +## 10. 구현 순서 Decision Tree + +```text +STEP 1. Part 1 원천 필드부터 추가한다. + | + |-- claim/secured components: agreed_interest_rate, agreed_delay_damage_rate + |-- registry/schedule components: fraction_id, asset_id, schedule_ref, registry_ref + |-- notice components: 5 lifecycle dates + receipt_evidence_refs + |-- event candidates: fraction_id, notice_id, lien_id, asset_id, possession/legal-cause track refs + | + v +STEP 2. Part 2 Stage_A/B0 pass-through를 보강한다. + | + |-- 신규 field가 compact context와 domain slice에서 drop되지 않는지 확인 + | + v +STEP 3. Part 2 B1/B2/B5 worker output contract를 확장한다. + | + |-- B1: money_claim_details rate named fields + |-- B2: fractional_effect_events + |-- B5: notice_lifecycle, lien_state_timeline, possession_legal_cause_tracks, asset_alias_map_seed + | + v +STEP 4. Part 2 PostB compiler/gate가 신규 payload를 보존한다. + | + |-- PostB_1: seed ledger 보존 + |-- PostB_3: final BO 병합 + |-- PostB_4: 필수 skeleton key warning/blocker + | + v +STEP 5. Part 4 FL sealed gate를 추가한다. + | + |-- POSSESSION_LEGAL_CAUSE_CONFLICT + |-- BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING + |-- LIEN_ASSERTED_AFTER_EXTINCTION_NOTICE_REVIEW + | + v +STEP 6. Stage 2는 기존 계획대로 7파일 handoff compiler가 derived view를 만든다. +``` + +## 11. 최소 변경 패키지 + +가장 간단한 방식으로 목적을 달성하려면 아래 5개 패키지로 나누어 적용한다. + +| 패키지 | YAML | 핵심 변경 | 성공 기준 | +|---|---|---|---| +| Pkg-1 Money Rate | Part 1, Part 2 | 약정이율/지연손해금률 named 승격 | `interest_hint` 외에 named rate field 존재 | +| Pkg-2 Fraction/Asset Keys | Part 1, Part 2 | `fraction_id`, `asset_id`, `schedule_ref`, `registry_ref` 부착 | 지분 event와 registry row가 같은 key로 join 가능 | +| Pkg-3 B5 Named Skeleton | Part 2 | `notice_lifecycle`, `lien_state_timeline`, `possession_legal_cause_tracks`, `asset_alias_map_seed` 추가 | B5 payload에 빈 `{}`만 남지 않음 | +| Pkg-4 Sealed Gates | Part 1, Part 4 | 수령게이트, possession/legal-cause conflict gate | `skeleton_validation_codes` 또는 writer report에 block/review code | +| Pkg-5 Pass-through/Validation | Part 2, Part 4 | Stage_A/B0/PostB/FL에서 신규 fields 탈락 방지 | BO/FL final write 후 신규 keys가 보존 | + +## 12. Acceptance Criteria + +| 검증 | 기준 | +|---|---| +| YAML parse | 4개 YAML이 parse 가능해야 함 | +| 새 final JSON 없음 | Stage 1 final handoff는 기존 7파일 체계 유지 | +| Part 1 extraction | `agreed_interest_rate`, `fraction_id`, `asset_id`, `received_date`, `receipt_evidence_refs`가 prompt/output contract에 등장 | +| Part 2 B5 skeleton | `lien_state_timeline`, `notice_lifecycle`, `possession_legal_cause_tracks`, `asset_alias_map_seed`가 named skeleton으로 존재 | +| sealed gate | `BLOCK_FINAL_DRAFTING_NOTICE_RECEIPT_MISSING`, `POSSESSION_LEGAL_CAUSE_CONFLICT` 계열 code가 Part 4 gate에 반영 | +| pass-through | Stage_A/B0/PostB에서 신규 fields가 drop되지 않도록 whitelist 또는 pass-through가 확인됨 | +| Stage 2 연결성 | `Task_S2_0_stage1_handoff_surface_compiler`가 7파일을 읽어 Layer 2 derived view를 만들 수 있음 | + +## 13. 최종 결론 + +Layer 1 개정은 Stage 1을 다시 거대하게 재설계하는 작업이 아니다. 목적은 비결정성을 만드는 빈 컨테이너와 freeform hint를 최소한으로 닫는 것이다. + +따라서 최종 개정 전략은 다음과 같다. + +1. `money_claim_timeline`은 약정이율만 Stage 1 named 승격하고, timeline 계산은 Stage 2에 둔다. +2. `property_fraction_state_timeline`은 Stage 1에서 `fraction_id`만 확실히 부착하고, 상태표 folding은 Stage 2에 둔다. +3. `possession_state`와 `legal_cause_state`는 Stage 1에서 raw 2-track과 모순 차단 gate를 sealed 처리하고, 법적 확정은 Stage 2에 둔다. +4. `lien_state_timeline`은 Stage 1에서 `lien_id`와 named skeleton만 만들고, 견련성/소멸 판단은 Stage 2에 둔다. +5. `notice_lifecycle`은 Stage 1에서 5개 lifecycle 날짜와 수령게이트를 sealed 처리하고, 발신자적격/법률효과 확정은 Stage 2에 둔다. +6. `asset_alias_map`은 Stage 1에서 `asset_id`, `schedule_ref`, `registry_ref` seed만 만들고, crosswalk 확정은 Stage 2에 둔다. + +한 줄로 정리하면 다음과 같다. + +**Stage 1 v5 개정은 "새 산출물 추가"가 아니라 "기존 산출물 안의 Layer 1 원천 key와 sealed gate를 최소 보강"하는 방식으로 수행한다.** + diff --git a/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정작업_final_프롬프트.txt b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정작업_final_프롬프트.txt new file mode 100644 index 00000000..77eeea30 --- /dev/null +++ b/Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.5/stage_1_개정작업_final_프롬프트.txt @@ -0,0 +1,201 @@ + +┌─────────────────────────────────────────┐ +│ eval_eval_eval_GPT │ +└─────────────────────────────────────────┘ + +# Conclusion +GPT v1의 7파일 handoff 전략을 기본 채택하되, Claude 문서가 요구한 세부 스키마와 충돌 검출 규칙을 Stage 2 첫 compiler의 derived view 및 validation rule로 흡수하는 것이다. 즉시 Stage 1 v5를 다시 크게 개정하여 별도 final JSON들을 늘리는 것은 비효율적이다. + +# Stage 1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +┌─────────────────────────────────────────┐ +│ eval_eval_eval_Claude │ +└─────────────────────────────────────────┘ +Claude가 추천한 종합 권고를 채택 + + + + +- Stage 1 작업 명세서는 아래 4개 yaml들: + + + + + +- Stage 1 작업 명세를 평가한 분석 문서들: + + + +- Stage 1 작업 명세를 평가한 분석 문서들을 재평가하여 도출한 결론: + + +<신규작업명세서_평가_평가_평가_Claude.md>에서 제시한 Layer 1 → Layer 2 → Layer 3 개정 제안을 받아들임 + +<신규작업명세서_평가_평가_평가_Claude.md>에서 제시한 Layer 1에서 Stage 1 개정을 위한 상세 작업 요약본을 아래에 <개정작업_요약>에 제시함 + + +<개정작업_요약> + +- 약정이율·fraction_id·asset_id(schedule_ref/registry_ref) named/key 승격 + -> 위치: Stage 1 B1·B2 (Layer 1) +- possession 2-track **모순 차단 게이트**, notice **received_date 수령 게이트**를 Stage 1 sealed로 + -> 위치: Stage 1 (Layer 1) + + + +* 결정적 원천 구조화 +- 작업 내용: 빈 컨테이너에 named 스키마를 삽입하고, 흩어진 event에 key(fraction_id, notice date, lien_id)를 붙여 비결정성을 제거 +- 작업 위치: Stage 1(B1/B2 추출 + B5 worker 골격 + 결정적 Middle_Input) + + +<개정작업_세부내용> +## 1. `money_claim_timeline` +- 판정: `pre/post_service_rate` 분리는 결함이 아니라 필연. 소장 송달일은 소 제기 후에야 생기는 값이라 Stage 1에 정보 존재 불가. +- 개정 방식: 약정이율(約定利率)은 Stage 1에 '실재하는 데이터'인데 `interest_hint` freeform으로만 남음 → Layer 1 보강 1건: B1 `agreed_interest_rate`/`agreed_delay_damage_rate` named 승격 + +## 2. `property_fraction_state_timeline` +- 판정: 상태 전이표는 자산 단위 파생구조이므로 FL(사실 1건 = 1 row) 컬럼으로 평면화하면 의미가 깨진다. +- 개정 방식: Layer 1 보강 → B1/B2에서 지분 event에 `fraction_id` key 부착(이것이 없으면 Stage 2가 지분 정규화를 신뢰성 있게 수행할 수 없음) + +## 3. `possession_state` ↔ `legal_cause_state` 분리 +- 판정: enum·2-track·충돌검출의 '내용'은 사실상 동일 → 합의로 간주. 유일 쟁점은 충돌검출의 위치. 감사논거상 충돌 및 *검출*(=모순 차단 게이트)은 Stage 1에 둔다 → 모순된 두 사실이 'Fact_Ledger_base.json'에 기록되는 시점이 Stage 1이므로, Stage 2에서야 검출하면 이미 자기모순 ledger가 봉인·배포된다. 반면 legal_cause enum의 '법적 확정'(견련성 인정 등)은 Layer 3(Stage 2)에서 처리할 작업이다. +- 개정 방식: Layer 1의 Stage 1에서 2-track raw + 구조적 정합 게이트(모순 시 HARD_WARNING, sealed) + +## 4. `lien_state_timeline` 세부 필드 +- 판정(필드 성질로 분할): + - `lien_id` 부여 + named 스키마 골격 → Layer 1(Stage 1): 없으면 데이터가 변동/유실. + - `secured_claim`·`possession_events`(사실, BO+FL에서 재구성) → Layer 2(Stage 2 view): GPT_v1 옳음. + - `violation_candidates`·`status_after_notice_receipt`(법리 적용) → Layer 3(Stage 2 법리). +- 개정 방식: + - 미확정 필드를 `review_required`/`legal_theory_required`로 올리는 **에스컬레이션 메커니즘** 적용 + - Stage 1에서 `lien_state_timeline` named 골격 + lien_id 부여 + +## 5. `notice_lifecycle` 세부 필드 +- 판정: + - `received_date`는 **추출(extracted) 사실**이지 계산값이 아니다. GPT_v1식 순수 Stage 2 view는 BO에 도달일이 안 잡혀 있으면 **null을 메울 수 없다**(존재하지 않는 사실을 view가 창조 불가). 따라서 도달/수령 **날짜 추출은 Layer 1(Stage 1 B1 notice_components)**에 있어야 하고, view는 그 위에 얹는 것이 좋다. + - **received_date 없으면 final drafting 제한**"은 *게이트*다 → Stage 1 sealed 게이트(`BLOCK_FINAL_DRAFTING`)로 두는 게 안전하다. +- 개정 방식: Stage 1에서 5개 lifecycle 날짜 추출 + 수령여부 게이트(Layer 1) + + + +<문서작성_방식> +<개정작업_요약>에 제시된 Stage 1 개정 작업 세부내역을 최적의 방식(가장 간단한 방식으로 목적을 달성하는 방법)으로 실행할 수 있도록 하는 Stage 1 개정 전략서를 decision tree 형식으로 작성한다. 작성 시, 4개 yaml 파일들 중 어떤 위치에서 어떤 작업을 실행해야 하는지 최대한 상세한 내용을 서술한다. + +작성한 문서는 로 생성하고 저장한다. + + +========================================================================================================================== + + +더 발전된 Stage 1 개정 작업 명세서 재작성 + + +<참고_내용> +의 **2. 개정 원칙**부터 **13. 최종 결론**까지를 읽고 이해한다. + + + +20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점에서 아래 작업을 수행한다. +1. <참고_내용>에 제시된 Stage 1 개정 방안들 중에서 에서 받아들일만한 내용을 찾는다. +2. 1번 작업의 결과에 기반을 두고, 가장 효율적(최소 작업, 최고 품질 목적 달성)인 Stage 1 작업 명세 개정 전략서를 재작성한다. +3. 재작성한 Stage 1 개정 전략서를 로 생성하고 저장한다. + + + +========================================================================================================================== + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Case_02_Comparison_Research/YAML_Prompts/Stage_1_to_Stage_2_업데이트_플랜.txt b/Case_02_Comparison_Research/YAML_Prompts/Stage_1_to_Stage_2_업데이트_플랜.txt new file mode 100644 index 00000000..b9d33f65 --- /dev/null +++ b/Case_02_Comparison_Research/YAML_Prompts/Stage_1_to_Stage_2_업데이트_플랜.txt @@ -0,0 +1,85 @@ + +---------------------------------------------------------- + +1. 평가_평가_평가_GPT / 평가_평가_평가_Claude 조합하여 개정 작업 플랜 작성 + +2. LES2 런타임 폭증 문제 해결 +- 파악: LES1 모호성 exception pack 분리 원리? + -> Exception Pack 범위가 너무 큼 -> 작업 명세서 분석 -> 범위 경량화 + -> LES2 exception adjudicator 추론 작업 부담이 커서 런타임 폭증 -> prompt 추론 경량화 + +3. Stage 1 업데이트 개정 완료하고 테스트 + -> 결과물 받아두기 + +4. Stage 2 개정 작업을 위한 현행 prompt 분석 + -> 모든 작업들 상세 구조화 + -> 작업 목적 / 작업 상세 / IO / JSON Schema + +5. Stage 1 결과물을 잘 활용하여 Stage 2 본연의 목적을 달성하기 위한 최적 workflow 확정 + -> Stage 2 목적 분석 + -> Stage 1 결과물 활용했을 때 Stage 2 최적 workflow 식별 (런타임 최소, 결과물 최고 품질, 인간변호사 논리 따라야 함) + +6. Stage 2 YAML 개정 + -> Stage 2 optimal structure of tasks 반영한 yaml 생성 + -> optimal structure를 Code vs LLM 최대한 단순하게 분해 + -> LLM은 GPT-5.5 high 작업을 전제로 작성 + +---------------------------------------------------------- + +Stage 1 개정 작업 +- JSON 정보 블록 삽입 +- LES1 + LES2 동시 개정 + +---------------------------------------------------------- + +2. LES2 런타임 폭증 문제 해결 +- 파악: LES1 모호성 exception pack 분리 원리? + -> Exception Pack 범위가 너무 큼 -> 작업 명세서 분석 -> 범위 경량화 + -> LES2 exception adjudicator 추론 작업 부담이 커서 런타임 폭증 -> prompt 추론 경량화 + + ⬇ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Case_02_Comparison_Research/YAML_Prompts/개정작업_stage_1_to_stage_2.txt b/Case_02_Comparison_Research/YAML_Prompts/개정작업_stage_1_to_stage_2.txt index 7c2e6411..dadfed9c 100644 --- a/Case_02_Comparison_Research/YAML_Prompts/개정작업_stage_1_to_stage_2.txt +++ b/Case_02_Comparison_Research/YAML_Prompts/개정작업_stage_1_to_stage_2.txt @@ -159,24 +159,6 @@ Weaviate DB 구성 및 vector search 개정 작업 =========================================================================================== -28일 일요일 일처리 - -4. 이룸 이사회를 위한 IR 개정 -> 밤까지 마무리해서 보내기 -5. 틈을 내서 30-40분 IR 논문 개정 작업 planning - -29일 월요일 일처리 -2. 이정민 대표에게 송금 -3. Stage 2 개정작업 진행 / 요건사실론 workflow test / 판례모음 아르바이트 구성 (충대 학부생 10명 / pm=백지민) -4. 오후 징계위원회 출석 (1:30pm에 학교로 가서 3:20pm까지 회사 복귀) -5. 4pm 이룸 이사회 -> Seeding 작업 시작 요청 (박현민에게 강한 의지 요구 / 성용배에게도 본격 작업 시작 요청) -6. 퇴근하면서 도서 파본 신청 -7. 저녁식사 / 유준 놀이터 -8. 샤워 -> Stage 2 개정 작업 -9. 틈내서 30분간 IR 논문 개정작업 planning - -30일 화요일 일처리 -1. Stage 2 개정작업 마무리 -2. diff --git a/판례모음/판례수집_작업_추진_업데이트.txt b/판례모음/판례수집_작업_추진_업데이트.txt index f7dfca8b..6c20a38b 100644 --- a/판례모음/판례수집_작업_추진_업데이트.txt +++ b/판례모음/판례수집_작업_추진_업데이트.txt @@ -101,7 +101,13 @@ - 사건명: 소유권이전등기말소 (주의: 이 사건명은 '소유권이전등기'와 다름) 법원등급: 대법/전합/고법/지법 선고일자: 20000101 - 20260531 -검색결과: 5,599건 -> 다운로드 요망 -> [] +검색결과: 5,599건 -> 다운로드 요망 -> [COMPLETE] +┌──────────────────┐ +│ COMPLETE │ +└──────────────────┘ + + +------------------------------------- - 사건명: 대위, 소유권이전등기말소 법원등급: 대법/전합/고법/지법 @@ -141,10 +147,15 @@ 법원등급: 대법/전합/고법/지법 선고일자: 20000101 - 20260531 검색결과: 111건 + +------------------------------------- - 사건명: 임금, 퇴직금 법원등급: 대법/전합/고법/지법 선고일자: 20000101 - 20260531 검색결과: 435건 -> 다운로드 요망 +┌──────────────────┐ +│ COMPLETE │ +└──────────────────┘ ======================================================================== @@ -159,11 +170,16 @@ 법원등급: 대법/전합/고법/지법 선고일자: 20000101 - 20260531 검색결과: 352건 +-------------------------------------- - 사건명: 보험금 법원등급: 대법/전합/고법/지법 선고일자: 20000101 - 20260531 검색결과: 11,175건 -> 모두 다운로드 할 것 -> +┌──────────────────┐ +│ COMPLETE │ +└──────────────────┘ * 주의: "보험금"에는 '보험금 청구', '보험금수익자변경' 등 보험금이라는 단어가 들어가는 모든 사건 포함 + - 사건명: 보험금수익자변경 법원등급: 대법/전합/고법/지법 선고일자: 20000101 - 20260531 @@ -239,7 +255,60 @@ - 사건명: 소유권이전등기, 말소 법원등급: 대법/전합/고법/지법 선고일자: 20000101 - 20260531 -검색결과: 6,057건 +검색결과: 6,057건 --> [COMPLETE] + + +======================================================================== + +- 관리비 청구 +- 보증채무금 청구 +- 투자금반환 청구 +- 수표금 청구 +- 위약금 청구 + +- 손해배상(산) +- 손해배상(의) +- 손해배상(건) +- 손해배상(언) + +- 지료 청구 + +- 사해행위취소 청구 (새로 구성, 최소 60,000개) + +- 말소등기(근저당권설정등기말소) 청구 (새로 구성) + +- 취득시효완성을 원인으로 한 소유권이전등기 청구 +- 명의신탁해지를 원인으로 한 소유권이전등기 청구 +- 진정명의 회복을 등기원인으로 하는 소유권이전등기 청구 +- 재산분할·재산승계를 원인으로 한 소유권이전등기 청구 + +- 건물의 명도(인도) +- 토지의 인도를 구하는 소 +- 전부금 청구 +- 청산금·채무인수금·체당금·추심금·출자금 청구 등 +- 보증금 청구 +- 분양대금 청구 +- 하자보수비·할부대금·화해금·확약금·환급금·회원가입비 등 +- 임대인의 건물철거청구와 임차인의 건물매수청구권 행사 +- 동산 등의 인도 청구 +- 부동산 소유권 확인 +- 가등기에 기한 본등기 청구 +- 소유물방해제거·방해예방청구 +- 유치권확인 또는 부존재확인 + +- 근로자의 지위 등 + +- 사용료 청구 +- 계약해제로 인한 원상회복의무와 손해배상의무의 관계 +- 진료비·치료비·의료비 청구 +- 채권존재확인 청구 +- 동업반환금 청구 + +- 주주총회결의취소의 소 +- 예금(예치금·예탁금·인출금) 청구 +- 배당금·배분금 청구 + +