fix(stage1): enforce Fact Ledger schema

- add a canonical Draft 2020-12 row schema
- validate candidate, patched, and reread rows
- document the v3-to-v4 rationale and fixture results

Case_02_Comparison_Research/YAML_Prompts/1. Stage_1/v.7/Part_3_to_Part_4_modification_summary.md

@@ -0,0 +1,35 @@
+# Stage 1 Part 4 v3에서 v4로의 개정 작업 요약
+
+## 1. 개정 목적
+
+`Stage_1_Part_4_Codex_v3.yml`은 `Fact_Ledger_base.json`의 27개 key 존재 여부만 검사하고 field type과 nested structure는 강제하지 않았다. 이에 따라 FL1이 upstream `amount` Object를 JSON String으로 바꾸고, `object_spec`도 자산 ID Array를 문자열화할 수 있었으며 FL3는 이를 차단하지 못했다. v4는 실행 코드의 의미 구조를 유지하면서 machine-readable JSON Schema를 단일 기준으로 도입하여 생성, 보정, 최종 저장 전 과정에 같은 자료형 계약을 적용한다.
+
+## 2. 핵심 개정
+
+| 항목 | v3 | v4 |
+|---|---|---|
+| Schema | `FINAL_FIELDS` key 목록 | Draft 2020-12 `FACT_LEDGER_ROW_SCHEMA` 및 `fact_ledger_row_schema.json` |
+| `amount` | Object를 String으로 변환 | upstream Object를 `deepcopy`, Object 또는 null 유지 |
+| `object_spec` | JSON String 가능 | `source_object`, `asset_cluster_ids`를 가진 Object 또는 null |
+| 파생 정보 | `derived_fact` String | `derived_fact` String/null과 `is_derived` Boolean 분리 |
+| 도출 근거 | 세미콜론 String | BO, evidence, structure 참조를 담은 Array of Object |
+| FL3 gate | key 집합만 확인 | type, enum, nested required key, ID, reference universe 검증 |
+
+FL1에는 `_structured_amount()`, `_object_spec()`, `_derivation_basis()`, `_validate_row_schema()`를 추가하였다. 최종 row는 `is_derived`가 추가된 28개 필드이다. `fact_id`는 `^F-[0-9]{3}$`, `credibility`는 `high|medium|low`, `must_consider`와 `is_derived`는 Boolean으로 고정하였다. `claim_chain_ref`, `linked_structures`, `linked_actio_structures`는 named Object로 유지하고 `legal_calculation_object`의 nested required key도 명시하였다.
+
+FL1은 schema의 `$id`와 SHA-256 digest를 candidate bundle의 `row_schema_ref` 및 `compile_gate`에 연결한다. FL3는 같은 artifact의 경로, `$id`, digest와 closed-schema 조건을 확인한 후 다음 네 시점에 row를 재검증한다.
+
+1. FL1 candidate 수신 시
+2. 각 FL2 `PATCH` 또는 `BLOCK_REVIEW` 적용 직후
+3. 최종 정렬 및 Fact ID 재부여 후 쓰기 직전
+4. `Fact_Ledger_base.json` 쓰기 후 재읽기 시
+
+`amount`나 `object_spec`이 JSON처럼 보이는 String이면 hard failure 처리한다. `BLOCK_REVIEW`의 근거도 String 연결 대신 `derivation_basis`의 review provenance Object로 기록한다. candidate bundle, FL1 manifest, writer report와 final writer의 관련 계약은 v3으로 승격하였다.
+
+## 3. 보존 범위 및 검증
+
+`FL0 -> FL1 -> 조건부 FL2 -> FL3 -> OUT` DAG, task 이름, Agent/Stage 메타데이터, FL0와 FL2는 변경하지 않았다. FL2 common cache prefix도 기존과 byte 단위로 동일하며 SHA-256은 `6e01f72f1803767b6bb16b5aef6cf34760e6dc1b293c316c75e990d09ad5fe63`이다.
+
+v4는 YAML 파싱과 FL0, FL1, FL3 embedded Python 컴파일을 통과하였다. 실제 v.7 source pack의 BO 48개를 fixture로 투입한 결과 48개 row가 새 schema를 통과했고 `amount` Object 48개가 값 손실 없이 deep copy되었다. `amount`와 `object_spec`의 JSON String 변환은 0건이며, 잘못된 ID, 필드 누락, String형 도출 근거, nested key 누락, BO universe 외 참조 등 7개 음성 사례는 모두 차단되었다.
+
+이 개정으로 문서상 format, FL1 생성값, FL3 통과 조건이 하나의 authoritative schema로 통합된다. Stage 2는 재파싱이나 의미 추정 없이 Object, Boolean, provenance 구조를 직접 소비할 수 있다. 이번 결과는 로컬 fixture 및 정적 검증 기준이며 원격 Liti-agent/MCP 통합 실행은 별도로 수행해야 한다.