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.
This commit is contained in:
+49
-22
@@ -1,22 +1,24 @@
|
||||
# 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
|
||||
# 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
|
||||
@@ -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
|
||||
|
||||
@@ -1,22 +1,24 @@
|
||||
# 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
|
||||
# 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
|
||||
@@ -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:
|
||||
- .
|
||||
|
||||
@@ -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의 비전
|
||||
|
||||
|
||||
|
||||
|
||||
+539
@@ -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_* <PART_FILE_OUTPUT_SCHEMA> + 해당 RULE 블록
|
||||
│ └─ 사건/상태(event/state) → Task_B2_map_events_* <PART_FILE_OUTPUT_SCHEMA> + 해당 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 <OUTPUT_CONTRACT>의 domain_payload에서 `{}`를 named 스키마로 교체
|
||||
│ + <WORKFLOW>에 채움 규칙 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: <ACTIO_EVIDENCE_EXTRACTION_RULE> 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` — `<STATIC_BLOCK_TASK_B1_MAP_DOC>`**
|
||||
|
||||
- 위치: `<CLAIM_DOCUMENT_COMPONENT_RULES>`(L1216-1222) 및 `<ACTIO_EVIDENCE_EXTRACTION_RULE>`(L1247-1254) 사이 또는 직후.
|
||||
- 내용: `loan_components`의 항목 스키마를 명문화하는 규칙 블록을 추가한다.
|
||||
|
||||
```
|
||||
<LOAN_COMPONENT_NAMED_SCHEMA_RULE>
|
||||
- `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으로 본다.
|
||||
</LOAN_COMPONENT_NAMED_SCHEMA_RULE>
|
||||
```
|
||||
|
||||
- 함께: `<VALIDATION_GATES>`(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`**
|
||||
|
||||
- 위치: `<OUTPUT_CONTRACT>`의 `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},
|
||||
```
|
||||
|
||||
- 함께: `<WORKFLOW>` 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` — `<STATIC_BLOCK_TASK_B1_MAP_DOC>`**
|
||||
|
||||
- 위치: `<REGISTRY_AND_SECURED_DEBT_EXTRACTION_RULE>`(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` — `<STATIC_BLOCK_TASK_B2_MAP_EVENTS>`**
|
||||
|
||||
- 위치 ①: `<PART_FILE_OUTPUT_SCHEMA>` candidate object(L2000-2053) — `"object_spec"` 근처에 optional 필드 1개 추가: `"fraction_ref": null`.
|
||||
- 위치 ②: `<REGISTRY_ROUTINE>`(L1709-1714) — 1줄 추가: "row에 지분 표시가 읽히면 candidate에 같은 ordinal B1 part의 `registry_row_components[*].fraction_ref`와 동일한 `fraction_ref`를 남긴다. 지분 표시가 없으면 null."
|
||||
- 위치 ③: `<REQUIRED_EVENT_SUBKINDS>` 담보부 부동산 목록(L1801-1813)의 `mortgage_setting_by_fraction`, `mortgage_extinguishment_by_fraction` — 목록은 수정하지 않고, `<SECURED_PROPERTY_LEGAL_EFFECT_EVENT_RULE>`(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`**
|
||||
|
||||
- 위치: `<OUTPUT_CONTRACT>` domain_payload(L2683-2709)의 `"registry_rows": []`.
|
||||
- 내용: 주석 규칙로 명문화(스키마 항목 추가) — `registry_rows`의 각 항목에 `{"registry_ref": null, "fraction_ref": null, "fraction_display": null, ...}`를 포함하고, `<WORKFLOW>`에 "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` — `<STATIC_BLOCK_TASK_B2_MAP_EVENTS>` (2-track raw의 원천)**
|
||||
|
||||
- 위치: `<STATE_CANDIDATE_RULES>`(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의 `<OUTPUT_CONTRACT>` 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": []}
|
||||
]
|
||||
},
|
||||
```
|
||||
|
||||
- `<WORKFLOW>`에 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`**
|
||||
|
||||
- 위치: `<OUTPUT_CONTRACT>` 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 규칙(같은 블록의 `<AUTHORITY_BOUNDARY>` 직후에 1줄): "lien seed가 복수이면 가장 이른 관련 event date(동률이면 candidate_ref 사전순) 순으로 `B5:LIEN:001`, `B5:LIEN:002`…를 부여한다. 이 id는 transport-스코프이며 final BO_ID가 아니다."
|
||||
- `<WORKFLOW>` 4항(L3407)에 보강: "Assign `lien_id` deterministically and reference it from possession/notice payloads of the same seed group."
|
||||
- **의도적 배제 명문화**: `<AUTHORITY_BOUNDARY>`에 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` — `<STATIC_BLOCK_TASK_B1_MAP_DOC>`**
|
||||
|
||||
- 위치: `<LIEN_NOTICE_SUCCESSION_COMPONENT_RULE>`(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 승격**
|
||||
|
||||
- 위치: `<OUTPUT_CONTRACT>` 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": []
|
||||
},
|
||||
```
|
||||
|
||||
- `<WORKFLOW>` 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` — `<STATIC_BLOCK_TASK_B1_MAP_DOC>`**
|
||||
|
||||
- 위치 ①: `<REGISTRY_AND_SECURED_DEBT_EXTRACTION_RULE>`(L1230-1237)에 1줄 — "`registry_row_components`의 각 row에 `registry_ref`를 부여한다. 형식: `REG-{ordinal:03d}-{row_seq:02d}` (갑구/을구·순위번호 순 deterministic)."
|
||||
- 위치 ②: `<LIEN_NOTICE_SUCCESSION_COMPONENT_RULE>`(L1256-1263)의 schedule_items 항목(L1260)에 1줄 — "`schedule_items`의 각 항목에 `schedule_ref`를 부여한다. 형식: `SCH-{ordinal:03d}-{seq:02d}` (별지 기재 순서 deterministic). asset alias 문자열은 기존대로 함께 보존한다."
|
||||
- 위치 ③: `<SLOT_EXTRACTION_RULES>`의 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 골격**
|
||||
|
||||
- 위치: `<OUTPUT_CONTRACT>` 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)**
|
||||
|
||||
- 위치: 각 `<OUTPUT_CONTRACT>`의 `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 `<WORKFLOW>` 말미에 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 프롬프트(`<STATIC_BLOCK_TASK_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 `<CLAIM_DOCUMENT_COMPONENT_RULES>`/`<ACTIO_EVIDENCE_EXTRACTION_RULE>` | L1216-1254 | 1-1 |
|
||||
| Part 1 | Task_B1_map_doc `<REGISTRY_AND_SECURED_DEBT_EXTRACTION_RULE>` | L1230-1237 | 2-1, 6-1① |
|
||||
| Part 1 | Task_B1_map_doc `<LIEN_NOTICE_SUCCESSION_COMPONENT_RULE>` | L1256-1263 | 5-1, 6-1② |
|
||||
| Part 1 | Task_B1_map_doc `<SLOT_EXTRACTION_RULES>` | L1291-1313 | 6-1③ |
|
||||
| Part 1 | Task_B1_map_doc `<VALIDATION_GATES>` | L1427-1452 | 1-1 보조 |
|
||||
| Part 1 | Task_B2_map_events `<REGISTRY_ROUTINE>` / `<SECURED_PROPERTY_LEGAL_EFFECT_EVENT_RULE>` | L1709-1714, L1858-1863 | 2-2 |
|
||||
| Part 1 | Task_B2_map_events `<STATE_CANDIDATE_RULES>` | L1921-1953 | 3-1 |
|
||||
| Part 1 | Task_B2_map_events `<PART_FILE_OUTPUT_SCHEMA>` | 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 `<OUTPUT_CONTRACT>` money_claim_details | L2435 | 1-3 |
|
||||
| Part 2 | B2_Secured_Registry `<OUTPUT_CONTRACT>` registry_rows | L2701 | 2-4 |
|
||||
| Part 2 | B3_Land_Valuation `<OUTPUT_CONTRACT>` possession_state | L2972 | 3-2 |
|
||||
| Part 2 | B5 `<OUTPUT_CONTRACT>` 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 | — | — | 무수정 |
|
||||
+255
@@ -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 `<VALIDATION_GATES>`에 유사 항목이 이미 존재(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의 `<LOAN_COMPONENT_NAMED_SCHEMA_RULE>`에 필드 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건. "필드를 만드는 일"보다 "필드가 끝까지 도달하게 하는 일"이 이번 개정의 절반이다.**
|
||||
@@ -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를 최소 보강"하는 방식으로 수행한다.**
|
||||
|
||||
@@ -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가 추천한 종합 권고를 채택
|
||||
|
||||
|
||||
|
||||
<context>
|
||||
- Stage 1 작업 명세서는 아래 4개 yaml들:
|
||||
<YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_1.yml>
|
||||
<YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_2.yml>
|
||||
<YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_3.yml>
|
||||
<YAML_Prompts/1. Stage_1/v.5/Stage_1_Part_4.yml>
|
||||
|
||||
- Stage 1 작업 명세를 평가한 분석 문서들:
|
||||
<YAML_Prompts/1. Stage_1/v.5/신규작업명세서_평가_평가_Claude.md>
|
||||
<YAML_Prompts/1. Stage_1/v.5/신규작업명세서_평가_평가_GPT_v1.md>
|
||||
|
||||
- Stage 1 작업 명세를 평가한 분석 문서들을 재평가하여 도출한 결론:
|
||||
<YAML_Prompts/1. Stage_1/v.5/신규작업명세서_평가_평가_평가_Claude.md>
|
||||
|
||||
<신규작업명세서_평가_평가_평가_Claude.md>에서 제시한 Layer 1 → Layer 2 → Layer 3 개정 제안을 받아들임
|
||||
|
||||
<신규작업명세서_평가_평가_평가_Claude.md>에서 제시한 Layer 1에서 Stage 1 개정을 위한 상세 작업 요약본을 아래에 <개정작업_요약>에 제시함
|
||||
</context>
|
||||
|
||||
<개정작업_요약>
|
||||
<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)
|
||||
</Stage_1_개정작업_뼈대>
|
||||
|
||||
<Layer_1>
|
||||
* 결정적 원천 구조화
|
||||
- 작업 내용: 빈 컨테이너에 named 스키마를 삽입하고, 흩어진 event에 key(fraction_id, notice date, lien_id)를 붙여 비결정성을 제거
|
||||
- 작업 위치: Stage 1(B1/B2 추출 + B5 worker 골격 + 결정적 Middle_Input)
|
||||
<Layer_1>
|
||||
|
||||
<개정작업_세부내용>
|
||||
## 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 파일들 중 어떤 위치에서 어떤 작업을 실행해야 하는지 최대한 상세한 내용을 서술한다.
|
||||
|
||||
작성한 문서는 <YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v1.md>로 생성하고 저장한다.
|
||||
</문서작성_방식>
|
||||
|
||||
==========================================================================================================================
|
||||
|
||||
<goal>
|
||||
더 발전된 Stage 1 개정 작업 명세서 재작성
|
||||
</goal>
|
||||
|
||||
<참고_내용>
|
||||
<YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_codex_v1.md>의 **2. 개정 원칙**부터 **13. 최종 결론**까지를 읽고 이해한다.
|
||||
</참고_내용>
|
||||
|
||||
<method>
|
||||
20년 이상 경력을 지닌 대한민국 최고 수준의 변호사 및 세계적인 수준의 인공지능 아키텍트 기술자의 관점에서 아래 작업을 수행한다.
|
||||
1. <참고_내용>에 제시된 Stage 1 개정 방안들 중에서 <YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v1.md>에서 받아들일만한 내용을 찾는다.
|
||||
2. 1번 작업의 결과에 기반을 두고, 가장 효율적(최소 작업, 최고 품질 목적 달성)인 Stage 1 작업 명세 개정 전략서를 재작성한다.
|
||||
3. 재작성한 Stage 1 개정 전략서를 <YAML_Prompts/1. Stage_1/v.5/stage_1_개정방식_전략서_claude_v2.md>로 생성하고 저장한다.
|
||||
</method>
|
||||
|
||||
|
||||
==========================================================================================================================
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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 추론 경량화
|
||||
|
||||
⬇
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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개)
|
||||
|
||||
- 말소등기(근저당권설정등기말소) 청구 (새로 구성)
|
||||
|
||||
- 취득시효완성을 원인으로 한 소유권이전등기 청구
|
||||
- 명의신탁해지를 원인으로 한 소유권이전등기 청구
|
||||
- 진정명의 회복을 등기원인으로 하는 소유권이전등기 청구
|
||||
- 재산분할·재산승계를 원인으로 한 소유권이전등기 청구
|
||||
|
||||
- 건물의 명도(인도)
|
||||
- 토지의 인도를 구하는 소
|
||||
- 전부금 청구
|
||||
- 청산금·채무인수금·체당금·추심금·출자금 청구 등
|
||||
- 보증금 청구
|
||||
- 분양대금 청구
|
||||
- 하자보수비·할부대금·화해금·확약금·환급금·회원가입비 등
|
||||
- 임대인의 건물철거청구와 임차인의 건물매수청구권 행사
|
||||
- 동산 등의 인도 청구
|
||||
- 부동산 소유권 확인
|
||||
- 가등기에 기한 본등기 청구
|
||||
- 소유물방해제거·방해예방청구
|
||||
- 유치권확인 또는 부존재확인
|
||||
|
||||
- 근로자의 지위 등
|
||||
|
||||
- 사용료 청구
|
||||
- 계약해제로 인한 원상회복의무와 손해배상의무의 관계
|
||||
- 진료비·치료비·의료비 청구
|
||||
- 채권존재확인 청구
|
||||
- 동업반환금 청구
|
||||
|
||||
- 주주총회결의취소의 소
|
||||
- 예금(예치금·예탁금·인출금) 청구
|
||||
- 배당금·배분금 청구
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user