docs(stage1-part3): add revision strategy spec superseding morning draft

- stage_1_part_3_개정_신전략서.md (48,467 B, sha16 0fa7c0ddf172dcd3): Part 3 work spec rebuilt on post-BO-projection premises — deployment origin extension_research/Default_Agent, builder roots already fixed, sidecar deployment (50 files, manifest 371→426), deterministic BO-attachment join (alias list resolution via legacy_alias_targets, BO conservation equation, by_bo_id index), SG-11 join key = signal_id, L0/L2 two-task design (no L1), input contracts I-1~I-14, regressions L-a~L-s (22, 8 mandatory), D-4 decision pending user approval (P3-0a) - verified by adversarial sub-agent loop: findings 13→5→1→1→1→0 (round 1 MAJORs: BO-attachment silent path, B1~B5 alias unwired, regression vs _verify_asset discipline conflict, manifest superset wording; rounds 4-5: active vs expected_runnable term unification, EC-00 sidecar absence rule) - closes carried-over C-7 (legacy signal names → canonical read set) and C-8 (interface table updates) by design - v.7/MEMORY.md: append entry 22 - 확장_최적워크플로우_연구_프롬프트.txt: session prompt log Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-20 17:10:08 +09:00
parent 8dfda00c12
commit d8e5b241ac
3 changed files with 458 additions and 6 deletions
@@ -1452,3 +1452,25 @@ sub-agent 1라운드: 지적 9건(MAJOR 6·MINOR 3) — 핵심은 **문서가
 1. **문서 검증이 자산 결함을 잡는다.** "불일치 0" 승계 문장을 재실측하게 했더니 조립본 장부의 빌더 불일치가 나왔다 — 이월 문장(D-2)의 근거가 실측으로 강화된 사례. 승계 수치는 옮길 때마다 다시 센다(⑯·⑲ 교훈의 재확인).
 2. **"손대지 않은 곳"도 파급 검사 대상이다.** 이월 잔재 지적 6건 중 4건이 앞 판본이 보존한 절(§1.3·§1.4·§3.5·§4.4)에서 나왔다 — 코드가 바뀌면 보존 절의 현재형 서술("R0 가 읽는다")이 거짓이 된다. incremental 갱신 시 보존 절을 "현재형 주장" 기준으로 한 번 훑을 것.
 3. 배치 순서가 서술의 참을 정한다 — 회전(구판→outdated)을 신판 배치보다 먼저. 문서에 완료형으로 적은 상태 전이는 그 순서로 실행해야 참이 된다.
+
+
+---
+
+## 2026-08-19 ㉒ — Part 3 개정 신전략서 작성 (구 전략서 대체 · sub-agent 6라운드 · 지적 0 종결)
+
+산출 `extension_research/stage_1_part_3_개정_신전략서.md` **신규**(48,467 B · sha 앞 `0fa7c0ddf172dcd3`). `stage_1_part_3_개정방안전략서.md`(09:37 판)를 대체 — 같은 날 완료된 BO 투영 회차가 그 문서의 전제 넷을 무너뜨렸기 때문(구 문서는 참고용 존치).
+
+### 구 전략서에서 바뀐 전제 넷 (§0.2)
+① 정본 뿌리 조립본 → **배포 원본 `extension_research/Default_Agent`**(신설 자산 배치·게이트·`--asset-root` 전부 이 기준, 조립본 반영은 이월) ② 빌더 뿌리 교정(P3-0b) → **이미 완료**(6→10, 신선 395⊇370) ③ 사이드카(structure_types·module_role_projection ×25)가 **배포 원본에 0건** → 바이트 복사 배포 + 매니페스트 등재(371→426, 델타 55)로 명세화 ④ BO 레코드가 registry 토큰(`Legal_Keywords`=type_ids · `provenance.source_domain`)을 싣게 됨 → **BO 부착 조인 신설**(별칭 목록 해소 → 부착 → 침묵 금지 3단, BO 보존 등식, `by_bo_id` 색인). +정정: SG-11 조인 키는 `details.request_id`(비보장)가 아니라 **`signal_id`**(request_id 승계).
+
+### 골격
+D-4 결정안 승계(Θ=expected_runnable 합집합 · order_key 3키 · by_module · 폴백 폐기) — P3-0a 사용자 승인 게이트 유지. L1 없는 2-task(L0 `Task_C_LE_L0_structure_seed_reducer` · L2 `Task_C_LE_L2_final_structure_index_writer`), pack 금지(판정자 없는 pack = 침묵 삼킴 or 상시 실패). 입력 계약 I-1~I-14(별칭표 = `extension_payload_key_declarations.v1.json` 의 `legacy_alias_targets`). 신설 자산: 모듈 1+미러 · 정책 1(`structure_index_policy.v1.json` — 검증 오라클 선례 승계) · 스키마 2(파일명 판본 금지) · 사이드카 복사 50 · yaml 3. 보존 등식 셋(선언·근거·BO — L2 가 I-9/I-2/I-7 원본에서 바깥 수 직접 계수). 회귀 22종(L-a~L-s, 필수 8종), 26 도메인 합성 실측(Θ 56 · 레코드 73 · by_module 34), 예행 pass3. C-7·C-8 폐쇄(선언표 신규 11줄 + 기존 8줄 갱신, count 34→45).
+
+### 검증 루프 (지시 방법 5)
+6라운드: 13(MAJOR 4) → 5(MAJOR 1) → 1 → 1 → 1 → **0건**. MAJOR 는 전부 설계 구멍이었다 — BO 부착 실패의 침묵 경로, `source_domain` 구 이름(B1~B5) 별칭 미배선(F0 `_resolve_domain_ids` 는 **목록** 해소·primary 개념 없음), 회귀 기대 코드가 자기 읽기 규율(`_verify_asset`)과 모순, "매니페스트 전수 일치"가 상위 장부 구조(371 중 트리 실재 94)와 충돌. 라운드 4~5 는 한 단어 수준 — "활성"↔`expected_runnable` 혼용이 L-k 필수 회귀를 오발화시키는 지점, 선언 0 도메인(EC-00)의 사이드카 부재 규칙.
+
+### 교훈
+1. **조인을 신설하면 그 조인의 실패 경로·보존 등식·별칭 층까지 한 벌이다.** 부착 규칙만 적은 초안은 "부분 부착이 모든 게이트를 통과"하는 침묵 경로를 남겼다.
+2. **회귀 시나리오는 자기 문서의 읽기 규율과 대조해야 한다.** `_verify_asset` 로 읽으라고 지시한 자산의 "내용만 변조" 회귀는 해시 게이트에 먼저 걸려 의미 검사에 도달하지 못한다 — 변조 회귀는 장부 동반/미동반 두 변종이 짝이다.
+3. **용어 하나("활성")가 필수 회귀를 뒤집는다.** 정의역이 둘(`active` ⊊ `expected_runnable`) 있는 시스템에서는 집합 이름을 축약하지 말 것.
+4. 문서 검증자는 편집 파급 검증에서 가장 세다 — 라운드 2~6 의 지적 전부가 "반영이 만든 새 모순"이었다. 반영 후 재검증을 생략하면 수정이 결함을 재생산한다.
@@ -0,0 +1,375 @@
+# Stage 1 — Part 3 개정 신전략서 (작업명세서)
+
+- 작성일 2026-08-19 · 문서 위치 `v.7/extension_research/stage_1_part_3_개정_신전략서.md`
+- 대상: `stage_1_update_strategy.md` §1 의 Part 3 구간(P3-L0 · P3-L1 · P3-L2)과 §4 세부 워크플로우
+- 상위 계약: `ver_8_yaml_candidates/stage_1_part_1_v.8.yml` · `stage_1_part_2_v.8.yml`(195,938 B · BO 투영 회차 반영본) · `stage_1_part_1_and_2_updated_yaml_analysis.md`(2026-08-19 판)
+- **이 문서는 `stage_1_part_3_개정방안전략서.md`(2026-08-19 09:37 판)를 대체한다.** 그 문서가 쓰인 뒤 같은 날 Part 2 의 BO 투영 회차가 실행 완료되어 전제 네 가지가 바뀌었다(§0.2). 구 문서는 참고용으로 제자리에 둔다.
+- 정본 자산 뿌리(배포 원본): **`v.7/extension_research/Default_Agent/`** — 런타임이 `Default_Agent/` 로 보는 실제 배포 트리(155 파일). 조립본 `선행구축/Default_Agent_Stage_1/` 은 재생성 원천으로 강등됐고 실행 경로가 아니다.
+
+---
+
+## 0. 문서 성격과 판정 기준
+
+### 0.1 완수의 정의 · 절대 원칙
+
+이 명세를 실행해 만드는 Part 3 가 **완수**로 인정되는 기준은 실행 완주가 아니다 — **의도한 결과물(`legal_effect_structures.json` 과 그 색인)이 올바른 방식으로 생성되고, 소작업 간 upstream–downstream consistency(넘겨받은 파일을 올바로 읽고, handoff 를 정해진 포맷으로 넘김)가 끝까지 유지**되어야 한다.
+
+절대 원칙(Stage 1 전체): Liti-agent 는 민사 137종 어느 사건이든 **registry 기반** — 사건 종류 이름이 아니라 증거 구성요소·요건 슬롯·단서 — 으로 다룬다. 자산은 법리 도메인 26(leaf 20 + 공통층 2 + 상시 4) · 계산 17 · signal 13 이며 정의는 `ensemble_v2.md` 다. **사건 종류 이름은 런타임 라우팅 키가 될 수 없다.**
+
+제약: ① `v.7/Claude_YAML/` 의 구 yaml 이 지시하는 내용에 일절 의존하지 않는다 — Part 3 는 registry 와 Part 1·2 실산출 계약만으로 **새로 짓는다**(구 Part 3 v2 의 diff 가 아니다). ② Part 3 실행 자산(md·py·txt·json)은 전부 **`extension_research/Default_Agent/` 의 정확한 배포 위치 서브폴더에만** 만든다.
+
+### 0.2 구 전략서에서 바뀐 전제 네 가지 (2026-08-19 BO 투영 회차의 결과)
+
+| # | 구 전략서의 전제 | 지금의 사실 | 이 문서가 바꾸는 것 |
+|---|---|---|---|
+| ① | 정본 자산 뿌리 = 조립본 `선행구축/Default_Agent_Stage_1/` | **배포 원본 = `extension_research/Default_Agent/`**(155 파일). 명세서 3곳의 `PART2_DEPLOYMENT_REMEDY` 가 이 트리를 정본화했고, 검증자가 이 트리 단독 재실행·바이트 동일을 실증했다 | 신설·복사 자산의 배치 목적지, `PART3_REQUIRED_ASSETS` 의 대조 대상, 예행의 `--asset-root` 전부 배포 원본 기준(§5·§6). 조립본 반영·빌더 등록·신선 빌드 재현은 **조립본 동기화 회차로 이월**(§10) |
+| ② | `generate_runtime_manifest()` 뿌리 6개 — 370항 중 6 재현 불가(P3-0b 로 교정 예정) | **이미 교정됐다.** BO 투영 회차가 뿌리를 6→10 으로 늘렸고(`platform/schemas`·`contracts/signals`·`domains/_common`·`routing` 추가) 신선 시뮬레이션 395항 ⊇ 현행 370항(결손 0)을 실측했다 | P3-0b 를 "완료 확인"으로 축소(§6). 남은 것은 Part 3 자산의 등재 재현 규칙(사이드카 sweep)뿐이며 이월 묶음에 넣는다 |
+| ③ | registry 사이드카(`structure_types.json`·`module_role_projection.json` ×25)를 조립본에서 읽는다(I-10) | 사이드카는 **배포 원본에 0건**이다(조립본에만 25+25). `domain_config.json` 의 `effect_projection.schema_ref` 도 배포 트리에서 dangling | 사이드카 2종 ×25 를 배포 원본으로 **바이트 복사 배포**하고 `runtime_manifest` 에 등재한다(§5.3). `effect_projection.schema.json` ×25 는 Part 3 가 읽지 않으므로 배포하지 않고 dangling 을 관찰로 기록(§10) |
+| ④ | BO 레코드는 효과 유형을 싣지 않는다(SG-13 이 유일한 효과 원천, `source_bo_ids` 는 실측 공백) | **BO 투영 회차가 BO 레코드에 registry 토큰을 실었다** — `Legal_Keywords` = 그 후보의 `legal_effect_candidates[].type_id`(중복 제거·사전순), `Action` 은 `extensions.domain_payload.action_summary` 부재 시 `<bo_type>:<type_id>` 폴백(예행에서는 전건 폴백 경로), `provenance.source_domain` = 도메인 ID. 예행 실물: `bh1 = {source_domain: X1, Legal_Keywords: [general_legal_effect, succession_notice_lien_asset_defense]}` | **BO 부착 조인을 결정론으로 신설**한다(§4.2 L0-7b) — SG-05·SG-13 의 `source_bo_ids` 가 비어 있어도 BO↔구조 연결이 선다. 단 `source_domain` 은 Part 2 계약상 구 이름(B1~B5)일 수 있으므로 별칭 해소를 조인 앞에 둔다. 역인덱스에 `by_bo_id` 를 더한다(§4.3) |
+
+그 밖의 정정 하나 — 구 전략서 I-4 는 SG-11 조인 키를 `details.request_id` 로 적었으나 그 키는 보장되지 않는다 — `emitter_runtime.py` 는 `details` 에 요청 원문을 통째로 복사하므로 worker 가 `request_id` 를 실은 실주행에서만 존재하고 예행에서는 부재다. 반면 `signal_id = request.get("request_id") or "calculation-request-<순번>"` 은 **항상 존재하며 `request_id` 를 승계**한다. 조인 키는 `signal_id` 다(§3 I-4).
+
+### 0.3 구 전략서에서 승계하는 결정 (재론하지 않는다)
+
+D-4 결정안 네 갈래(§2), L1 을 두지 않는 2-task 구성과 그 근거(§4.1), 스테이징 뿌리 `/tmp/s1` 공유, 스키마 파일명에 판본을 넣지 않는 규칙, order_key 3키 전순서, (도메인, `type_id`) 쌍 = 구조 레코드 정의, 보존 등식 둘과 부착 분할 규칙(이 문서가 BO 보존 등식 하나를 §4.3 에 신설해 셋이 된다), `admission_policy` 두 단 정의, 사이드카 방언 지도(목록 키 3 · `schema_version` 6 · 투영 키 3 · 정책 자리 4), `domains/_registry_index.json` 을 배포 게이트가 아니라 SG-01 봉인으로 지키는 규율. 각 근거 실측은 구 문서 §1 에 있고 이 문서 §1 이 배포 원본 기준으로 재확인한 값만 다시 적는다.
+
+---
+
+## 1. 전제 실측 (전부 배포 원본과 예행 실물에서 다시 쟀다)
+
+### 1.1 registry — 배포 원본 `domain_config.json` 26종
+
+- 배포 원본의 `domain_config.json` 26개는 조립본과 **26/26 바이트 동일**(사이드카 복사의 원천 정합 근거).
+- `structure_types` 전수 = **선언 73건 · 고유 `type_id` 56종**. 레코드 필드는 정확히 4키 — `type_id` · `priority_rank` · `module` · `role_projection`.
+- `general_legal_effect` 는 **10/26 도메인만** 선언(전부 rank 11 · `module: legal_effect`). 보편 폴백이 아니다.
+- rank 는 도메인 간 전순서를 정의하지 못한다 — `land_use_gain` 이 E-04=5 · E-11=6 으로 갈리고, 같은 rank 에 서로 다른 유형이 **14개 rank**(1~6 · 20 · 21 · 71~76)에서 몰리고 관련 유형이 43종이다(머리 1~6 포함 — 구 전략서의 13/42 는 재실측으로 정정). **도메인 내부에서는 26/26 전부 rank 가 엄격 오름차순**이라 도메인 내 선언 순서는 rank 로 보존된다.
+- `EC-00.structure_types == []` — 구조 0 은 정상값이다.
+- `(module, role_projection)` 쌍 56개 ↔ `type_id` 56개 **일대일**. `module` 은 34종이고 12개가 2~6 유형을 덮는다 — 묶음 색인은 `by_module` 만 성립한다.
+- 상시 도메인의 선언(예행 Θ 의 재료): X1 = `{succession_notice_lien_asset_defense(10), general_legal_effect(11)}` · X2 = `{asset_state(4), valuation(6)}` · X3 = X1 과 동일 2종 · E-00 = `{general_legal_effect(11)}` 하나.
+
+### 1.2 사이드카 — 조립본에만 있고, 내용은 `domain_config` 와 일치한다
+
+`domains/<id>/structure_types.json` · `module_role_projection.json` ×25(EC-00 만 없음 — 선언 0 도메인이므로 정합). 세 목록 방언(`entries` 10 · `structure_types` 9 · `types` 6)과 `schema_version` 6종, 투영 키 3종, 정책 자리 4갈래로 갈리지만, **정규화 리더로 읽으면 73/73 · 불일치 0** 이다. 정책 선언이 여기에 있다 — `nonregistered_type_review_code: "UNREGISTERED_EFFECT_TYPE_REVIEW"` · `silent_general_legal_effect_fallback_forbidden: true` · `registered_membership_required` · `multiple_types_allowed` · `source_order_deduplicated` · `default_projection` · `missing_mapping_policy`. `admission_policy` 는 두 단 정의(파일 단위 정책 3키 → 없으면 항목 단위 `admission_rule`)로 **73/73** 이 채워진다 — 둘째 단으로 채워지는 7건(E-00·E-15·X1·X3)은 상시 계열이라 예행의 주류다.
+
+### 1.3 Part 2 실산출 — Part 3 의 입력면 (예행 `/tmp/dry_v6` 실물)
+
+- `signals/signal_manifest.json`(v2): `downstream_read_sets.part3_L0 = ["SG-02","SG-05","SG-07","SG-11","SG-13"]` · `transaction_id ^S5TX-[a-f0-9]{20}$` · `files[]` 19항(자기 자신 제외, **`path` 에 `signals/` 접두사 없음**).
+- 다섯 중 **SG-02·SG-07 은 구조적으로 비어 있다**(생산자 없음 · 레코드 0). SG-05(6) · SG-11(5) · SG-13(6) 은 채워진다. **다섯 전부 `source_bo_ids: []` · `issue_cluster_ids: []`** — signal 층의 BO 연결은 지금 비어 있다.
+- SG-13 레코드: `record_type: "legal_effect_route"` · `details: {type_id, registered, source_seed_id, source_refs}` · `registered: false` 면 상류가 이미 `status: review` 로 내린다.
+- SG-11 레코드: `signal_id`(= worker `request_id` 승계 또는 `calculation-request-<순번>`) · `details: {calculation_domain, completeness, review_code, source_refs}` — **`details.request_id` 는 없다.**
+- `signals/domain_signals/<id>.json`(활성 도메인당 1): 루트 `domain_signal_envelope`, `evidence_slot_status[]` · `calculation_refs[]`(예행에서는 stub 이 `request_id` 를 안 실어 빈 배열) 등.
+- `BO.json`: 레코드 18키 불변. BO 투영 회차 이후 `Legal_Keywords`·`Action`·`provenance.source_domain` 이 registry 토큰을 싣는다(§0.2 ④). `downstream_seed_refs.legal_effect_structure_seed_ref_proposed` 는 전부 null — Part 3 가 채울 자리가 예약돼 있다(이번 회차는 채우지 않는다 — BO.json 은 최대 호환면, §8.2).
+- `routing/domain_activation_manifest.json`(SG-01): `expected_runnable_domain_ids` 가 Θ 의 정의역. `registry_index_sha256` 봉인 보유.
+- `runtime/domain_slices/<id>.json`: `domain_declarations.structure_type_ids` 가 실려 있다(정합 검사 대상).
+- 구 이름 3종(`actio_case_signals.json` 등 루트 별칭·호환 뷰)은 **읽지 않는다** — 이 이관이 Part 1|2 분석문서가 남긴 이월 **C-7** 이며, 이 문서의 입력 계약(§3)이 그것을 닫는다.
+
+### 1.4 배포 지형 · 이월 인계
+
+- 배포 원본 155 파일(`.json` 58 · `.md` 29 · `.py` 34 · `.txt` 34) · `runtime_manifest.json` **371항**(58,211 B) · 미러 34/34. **매니페스트는 Stage 1 전 계열의 상위 장부다** — 371항 중 배포 트리에 실물이 있는 것은 94항이고(전수 해시 일치·불일치 0), 나머지 277항(계산기 205 · 법령판 63 등)은 Part 1·2 실행이 반입하지 않는 모듈로 조립본에 실재한다. **매니페스트 전수 존재 검사를 배포 트리에 걸면 안 되는 이유다** — 게이트·`_verify_asset` 은 자기가 읽는 경로만 대조한다. 조립본은 세 파일이 낡았고(정책 부재·계약 구 바이트·매니페스트 370) 자기 장부(`release_manifest`)가 빌더 수정(뿌리 6→10)을 미반영(불일치 1) — 전부 조립본 동기화 회차 이월(D-1~D-6).
+- Part 1|2 가 Part 3 에 넘긴 이월: **C-7**(구 signal 3종 → 정본 집합 이관 — §3 이 닫는다) · 인계면 선언표 갱신(개별 정본 signal 등재 + `client_goal.json` 등재 + `client_meeting.md` 소비자 — §5.6 이 닫는다) · 예행 영수증 정본화(D-5, Part 3 회귀 기록과 함께 이월 유지).
+
+---
+
+## 2. D-4 결정안 (P3-0a 승인 대상 — 승인 없이 착수하지 않는다)
+
+구 전략서 §2 를 승계한다. 네 갈래를 요지로 재확정한다.
+
+**(가) 열거 범위 Θ** — `Θ(사건) = ⋃ { domain_config(d).structure_types[].type_id | d ∈ SG-01.expected_runnable_domain_ids }`. `active_domain_ids` 가 아니다(D-3 넓은 정의). "전역 열넷 고정"은 대상이 없다 — 유형은 56종이고, 전역 고정은 "이 사건에 없는 것"과 "이 사건에서 비어 있는 것"을 하류가 구별하지 못하게 한다.
+
+**(나) 전순서** — `order_key(구조) = (그 도메인이 선언한 priority_rank, domains/_registry_index.json entries[] 의 도메인 위치, type_id)`. 구조 레코드는 **(도메인, `type_id`) 쌍마다 하나**이며 도메인 간에 유형을 합치지 않는다 — 그래서 rank 충돌을 뭉갤 일이 없고 각 도메인의 선언 순서가 보존된다.
+
+**(다) `actio_remedy_or_cap`** — E-13 이 rank 9 · `module: actio` · `role_projection: linked_actio_structures` 로 이미 선언한다. 별도 매핑표를 만들지 않고, `s5_execution_contract.v2.json` 의 `e13_extension_domains` 가 선언한 `actio_case_signals.v2` 를 `extension_key` 로 함께 싣는다.
+
+**(라) 폴백 폐기 · `by_module` 채택** — 빈 입력은 `structure_count: 0` 으로 기록한다(폴백 없음). Θ 밖·`registered:false` 유형은 버리지도 일반화하지도 않고 `UNREGISTERED_EFFECT_TYPE_REVIEW` 를 붙여 남긴다 — 사이드카에 `default_projection` 이 있으면 그 투영을 싣되 검토 코드를 반드시 동반한다. `by_claim_form` 은 만들지 않는다(claim-form 어휘가 registry 어디에도 없고 `(module, role_projection)` 은 `type_id` 와 일대일) — 묶음 색인은 `by_module`(34 버킷)이다.
+
+---
+
+## 3. 확정 입력 계약
+
+경로는 실행 루트 기준. `Default_Agent/` 접두사가 붙은 것만 자산 뿌리(배포 원본)에서 읽는다. **`v.7/Claude_YAML/` 아래는 어떤 파일도 읽지 않는다.**
+
+| # | 입력 | 루트 키 / 형식 | 생산자 | 쓰임 |
+|---|---|---|---|---|
+| I-1 | `signals/signal_manifest.json` | `signal_manifest` v2 | P2-S0 | **진입 봉인.** `transaction_id` 형식 + `files[].file_sha256` 를 실제 파일 해시와 대조(경로에 `signals/` 접두사를 붙여서). 실패 `PART3_SIGNAL_SEAL_FAILED` |
+| I-2 | `signals/legal_effect_routes.json` | SG-13 봉투 | P2-S0 | 효과 경로. `record_type == "legal_effect_route"` 만 조인. `details.type_id`·`details.registered`·`details.source_seed_id` 사용 |
+| I-3 | `signals/legal_relation_lifecycle_signals.json` | SG-05 봉투 | P2-S0 | 근거 refs 원자(`evidence_refs`·`meeting_clause_refs`) |
+| I-4 | `signals/calculation_requirements.json` | SG-11 봉투 | P2-S0 | 계산 요청. **조인 키는 레코드의 `signal_id`**(worker `request_id` 승계값 — `details.request_id` 는 보장되지 않는 키라 쓰지 않는다) ↔ 도메인 봉투 `calculation_refs` |
+| I-5 | `signals/domain_signals/<domain_id>.json` | `domain_signal_envelope` v2 | P2-S0 | 도메인별 슬롯 현황·계산 참조. `expected_runnable` 도메인 중 실재하는 것만(부재는 영수증 계수로 기록) |
+| I-6 | `routing/domain_activation_manifest.json` | SG-01 | P1-D0 | **Θ 의 정의역** `expected_runnable_domain_ids` + `registry_index_sha256` 봉인 원문 |
+| I-7 | `BO.json` | 리스트(18키 레코드) | P2-F0 | **BO 부착 조인**(L0-7b) — `provenance.source_domain` 과 `Legal_Keywords` 로 구조 레코드에 부착 |
+| I-8 | `runtime/domain_slices/<domain_id>.json` | `stage_b_domain_slice` | P2-A0 | 정합 검사 — `domain_declarations.structure_type_ids` ↔ `domain_config` 집합 동일성(L0-2b) |
+| I-9 | `Default_Agent/domains/<id>/domain_config.json` ×26 | json | registry | `structure_types` 원문 — **Θ 와 순서의 정본.** 무결성은 SG-01 → `_registry_index.json` → `config_sha256` 사슬이 지킨다 |
+| I-10 | `Default_Agent/domains/<id>/structure_types.json` · `module_role_projection.json` ×25 | json(방언 3·6·3·4) | registry (이 회차에 배포 원본으로 복사, §5.3) | 정책 이름·`admission_policy` 재료·`default_projection`. `domain_config` 와 교차 검증(L0-2c). `_verify_asset` 로 매니페스트 해시 대조하며 읽는다 |
+| I-11 | `Default_Agent/domains/_registry_index.json` | json (18,921 B) | registry | 도메인 순서(`entries[]` 위치)와 `config_sha256`. **매니페스트 등재 대상이 아니다** — SG-01 의 `registry_index_sha256` 봉인이 지킨다(`PART3_REGISTRY_INDEX_SEAL_FAILED`). 조립본 뿌리에는 동명·다른 바이트의 `_registry_index.json`(1,458 B)이 있다 — 사이드카 복사(§5.3) 때 그 파일을 끌어오지 않는다 |
+| I-12 | `Default_Agent/runtime_manifest.json` | `stage1_runtime_manifest.v1` | 배포 원본 정본 | 반입 자산 sha256 (게이트·`_verify_asset` 의 대조 원천) |
+| I-13 | `Default_Agent/stage1_runtime/structure_index_policy.v1.json` | `stage1_structure_index_policy.v1` | 이 회차 신설(§5.2) | Θ 정의·전순서·부착 분할·조인 키·검토 코드의 코드 밖 선언. 판본 불일치 `PART3_POLICY_INVALID` |
+| I-14 | `Default_Agent/routing/extension_payload_key_declarations.v1.json` | `stage1_extension_payload_key_declarations.v1` | registry (Part 2 F0 도 같은 자산을 쓴다) | **`legacy_alias_targets` — BO 부착 조인의 별칭표**(구 이름 → registry 도메인 ID **목록**, 예 `B1_Money_Successor → ["E-02","E-03"]`. 단일 primary 필드는 없다). `_verify_asset` 반입 |
+
+**읽되 비어 있음을 정상 처리** — SG-02(`signals/procedural_posture_relief_signals.json`) · SG-07(`signals/asset_right_state_signals.json`). 조인 코드를 지금 쓰지 않는다(SG-02 닫힌 스키마에 claim-form 어휘가 정의된 적이 없다). 영수증에 형식화된 사실로 남긴다 — `{signal_id, transform: "passthrough", producer_count: 0, record_count: 0, reason}`.
+
+---
+
+## 4. 작업 명세 — 두 task
+
+### 4.1 왜 L1 이 없는가 (구 전략서 §4.1 승계)
+
+예외 다섯 부류가 전부 결정론이거나 registry 가 사람 검토로 지정한 것이고, 하나("같은 `type_id` 에 다른 `(module, role_projection)`")는 실측 0건이다. **LLM 이 판정할 부류가 없다.** 그래서 L1 을 두지 않고 검토는 `quality_gates/stage1_part3_review_handoff.json` 이 사람에게 나른다. 예외 pack 은 만들지 않는다 — 판정자 없는 pack 은 침묵 삼킴이나 상시 실패 중 하나가 된다. 되돌리는 경로는 열어 둔다: 판정 부류가 생기면 L0–L2 사이에 L1 을 끼우고 그때 L0 가 pack 을 쓰기 시작하며 L2 가 Part 2 F0 의 조건부 규칙(`exception_count > 0` 이면 판정 부재 = 실패)을 그대로 복사한다. 그래서 **L0/L2 를 한 task 로 합치지 않고 둘 사이 파일 계약(seed bundle · review handoff)을 지금 만들어 둔다.**
+
+### 4.2 P3-L0 `Task_C_LE_L0_structure_seed_reducer` [신설 · code-executor]
+
+**도입부** — Part 2 A0 의 형태를 복사한다. 스테이징 뿌리 `/tmp/s1` 공유(새 뿌리 금지 — 회귀 변종의 청소 목록을 늘리지 않는다).
+
+1. `assert_deployment()` — `PART3_REQUIRED_ASSETS`(§5.5) 를 한 벌로 검사(등재·sha256·가독). 실패 `PART3_ASSET_DEPLOYMENT_INCOMPLETE`.
+2. 모듈 반입 R-1~R-5 — `.txt` 미러 `read_raw` → `runtime_manifest` 해시 대조 → `/tmp/s1` 에 `.py` 기록 → `sys.path.insert`. 실패 코드는 기존 `MODULE_MIRROR_UNREGISTERED` / `MODULE_MIRROR_HASH_MISMATCH`. 반입 모듈: `runtime_common` · `schema_subset_validator` · `registry_loader` · **신설 `structure_index_compiler`**.
+3. 정책 반입 — I-13 을 `_verify_asset`(Part 2 R0 와 같은 헬퍼, 매니페스트 해시 대조) 로 읽고 `schema_version` 을 검사한다. 판본 불일치 `PART3_POLICY_INVALID`.
+4. **의미 검사 두 갈래** (장부 검사만으로는 닫히지 않는다 — Part 2 R-b/R-g2 교훈. 각 검사는 자기가 쓰는 산출물의 스키마만 본다):
+   - 입력 쪽 — 자기가 쓸 `structure_seed_bundle.schema.json` 이 `theta[]` 와 `structure_records[].admission_policy` 를 아는지. 모르면 `PART3_STRUCTURE_SCHEMA_STALE`. (`admission_rule` 은 13/73 에만 있는 선택 필드라 게이트 기준이 아니다.)
+   - 출력 쪽 — 컴파일러 산출에 `theta` 와 `order_key` 가 실려 나오는지. 없으면 `PART3_COMPILER_STALE`(옛 판본은 `TypeError` 가 먼저 나므로 같은 코드에 `detail: "signature_mismatch"`).
+5. 진입 봉인 둘 — ① I-1 의 `signal_manifest` 봉인(`PART3_SIGNAL_SEAL_FAILED`) ② SG-01 의 `registry_index_sha256` ↔ `Default_Agent/domains/_registry_index.json` 원문 해시(`PART3_REGISTRY_INDEX_SEAL_FAILED`). 전순서의 둘째 키가 이 색인의 배열 위치에 걸려 있으므로 이 봉인만이 색인 교체를 잡는다.
+
+**호출부** — 신설 모듈 `structure_index_compiler` 하나를 부른다. 판정 규칙을 YAML 문자열에 쓰지 않는다.
+
+```
+compile_structure_seeds(
+    activation_manifest, registry_index, domain_configs, domain_sidecars,
+    policy, alias_declarations, sg13_records, sg05_records, sg11_records,
+    domain_envelopes, bo_records, slice_documents)
+      -> {structure_seed_bundle, review_items, audit}
+```
+
+**모듈이 하는 일**
+
+| 단계 | 내용 | 검토/오류 코드 |
+|---|---|---|
+| L0-1 | Θ 조립 — `expected_runnable_domain_ids` 의 `domain_config.structure_types` 합집합 | `expected_runnable` 도메인이 색인에 없으면 `PART3_DOMAIN_NOT_IN_REGISTRY` |
+| L0-2 | 전순서 부여(§2 나) · 구조 레코드를 (도메인, `type_id`) 쌍마다 하나 생성 · `admission_policy`(두 단 정의, 73/73) 를 싣고 `admission_rule`·`registered` 는 있는 것만 덧붙임 | — |
+| L0-2b | 정합 검사 — `expected_runnable` 도메인의 `slice.domain_declarations.structure_type_ids` ↔ `domain_config` 집합 동일성 | `PART3_SLICE_PROJECTION_DIVERGENCE` 검토 |
+| L0-2c | 사이드카 교차 검증 — 목록 방언 3종·투영 방언 3종을 **하나의 정규화 리더**로 읽어 `domain_config` 와 집합 동등성 단언(오늘 73/73) + `types` 방언의 항목 `registered` ↔ SG-13 `details.registered` 대조. 방언 지도는 영수증에 기록 | `PART3_REGISTRY_SIDECAR_MISMATCH` 검토 |
+| L0-3 | SG-13 레코드를 `details.type_id` 로 Θ 에 조인 | Θ 밖·`registered:false` 는 버리지 않고 `UNREGISTERED_EFFECT_TYPE_REVIEW`(+`default_projection` 있으면 투영 동반) |
+| L0-4 | 도메인 소속 검사 — 레코드의 `type_id` 가 자기 `domain_ids[0]` 의 선언인지 | `PART3_EFFECT_TYPE_CROSS_DOMAIN` 검토 |
+| L0-5 | `module`·`role_projection` 부여 — `domain_config` 원문 그대로. E-13 레코드에는 `extension_key: "actio_case_signals.v2"` 동반(§2 다) | 사이드카 매핑과 어긋나면 L0-2c 검토에 합류 |
+| L0-6 | 계산 조인 — SG-11 `signal_id` ↔ 도메인 봉투 `calculation_refs`. 봉투에 있는데 SG-11 에 없는 참조는 dangling. 반대로 봉투 참조에 연결되지 않은 SG-11 레코드(합성 `calculation-request-<순번>` id — worker 가 `request_id` 를 안 실은 경우)는 구조에 싣지 않되 **영수증에 미연결 계수로 형식화 기록**(SG-02/07 공백과 같은 처리) | 없는 참조 `PART3_CALCULATION_REF_DANGLING` 검토 |
+| L0-7 | 근거 refs 수집 — SG-05 원자·SG-13 레코드의 `evidence_refs`·`meeting_clause_refs` 합집합. **출처 소속 재검사는 두지 않는다**(상류 R0 hard BLOCK + `_source_fields()` 교집합으로 이미 닫혔다 — 죽은 게이트 금지) | — |
+| L0-7b | **BO 부착 조인(신설)** — ① `source_domain` 별칭 해소: 값이 registry 도메인 ID 면 그대로 `[d]`, 아니면 I-14 의 `legacy_alias_targets[값]` **목록**으로 옮긴다(Part 2 F0 의 `_resolve_domain_ids` 와 같은 목록 해소 — 별칭표에 단일 primary 개념은 없다). 별칭표에도 없는 값은 그 BO 를 `PART3_BO_DOMAIN_UNRESOLVED` 검토로 격리 ② 부착: BO 레코드 b 는 해소된 **모든** `d` 에 대해 `t ∈ b.Legal_Keywords` 인 구조 레코드 (d, t) 부착을 시도(`source_bo_ids` 에 `BO_ID` 추가). SG-13 `details.source_seed_id` 는 보조 근거로 보존 ③ **부착 실패는 침묵 금지** — `Legal_Keywords` 가 비었거나 해소된 어느 (d, t) 에도 닿지 않는 BO 는 `PART3_BO_UNATTACHED` 검토로 싣는다 | **BO 보존 등식**: 부착 BO + 미부착 BO == BO 총수(L2 가 원본에서 직접 센다, §4.3). 조인 계수 영수증 기록(예행 기대: 2건 전부 부착) |
+| L0-8 | 검토 모으기 — 검토 코드 붙은 구조를 review handoff 에 싣는다(예외 pack 없음, §4.1). E-00 유래 구조는 `review_required: true` 강제 | — |
+
+**비정본 라벨·다중 유형** — 라우팅에 쓰지 않되 원문 보존. 한 BO 가 여러 유형에 걸리면 유형별 레코드 각각에 부착되고 `source_bo_ids` 로 묶인다(`multiple_types_allowed` 와 같은 방향).
+
+**산출**
+
+| 경로 | 스키마 | 내용 |
+|---|---|---|
+| `stage1_tmp/task_le/structure_seed_bundle.json` | `stage1_structure_seed_bundle.v1` (루트 키 `structure_seed_bundle`) | 구조 seed · Θ 열거 · 전순서 · BO 부착 |
+| `quality_gates/stage1_part3_review_handoff.json` | Part 2 handoff 준용 | 검토 항목. L2 가 `FINALIZED` 갱신(공동 기록자) |
+| `validation_assets/routing/part3_receipt.json` | `stage1_part3_receipt.v1` | 배포 게이트 영수증(실측값 — 상수 PASS 금지) · 진입 봉인 둘 · 조인 계수(SG-13·SG-11·BO 부착) · 보존 등식 양변 · SG-02/07 공백 사실 · 사이드카 방언 지도 · **`BO.json` 의 sha256 과 레코드 수**(signal 5종은 I-1 봉인·registry 는 SG-01 봉인이 지키지만 BO.json 은 무봉인 입력이다 — 비대칭을 관찰로 남긴다) · **해결된 전순서표**(rank·domain·type_id·module·admission_policy 한 줄씩) |
+
+### 4.3 P3-L2 `Task_C_LE_L2_final_structure_index_writer` [신설 · code-executor]
+
+- **구조 레코드의 정의** — Θ 의 (도메인, `type_id`) 쌍마다 하나. SG-13 레코드·BO 부착은 그 위에 붙는 근거이지 레코드 생성 주체가 아니다. 레코드 수는 registry 선언에서 결정론으로 나오고(26 도메인 전수면 73), 근거 없는 유형은 "선언됐으나 근거 없음"으로 보이며, EC-00 은 자연히 0 이다.
+- 입력은 전부 파일 계약 — seed bundle · review handoff · SG-01 · **`domain_config.json`(I-9 — `expected_runnable` 도메인 것만, Θ 의 정의역) · SG-13 원본(I-2) · `BO.json` 원본(I-7)** (+ 정책 I-13, `_verify_asset`). 뒤의 셋은 세 보존 등식의 **바깥 수**(선언 수·route 총수·BO 총수)를 L2 가 각각 원본에서 직접 세기 위해서다 — I-9 의 무결성은 L0 와 같은 SG-01 봉인 → `_registry_index.json` → `config_sha256` 사슬을 재사용한다 — L0 가 bundle 에 실은 수와 비교하면 같은 호출의 산물끼리 비교라 항등식이 된다. **판정 파일은 없다**(L1 부재 — 조건부 규칙을 흉내 내지 않는다, §4.1).
+- 닫힌 스키마 검증 — `legal_effect_structures.schema.json`(`additionalProperties: false`) 으로 자기 산출을 검증. 자기 스키마가 `by_module`·`by_bo_id` 를 아는지 함께 본다(`PART3_INDEX_SCHEMA_STALE`).
+- **보존 등식 셋** — 각각 바깥 수와 비교한다(항등식 금지):
+
+| 등식 | 식 | 어긋나면 |
+|---|---|---|
+| 선언 보존 | 구조 레코드 수 == Σ(`expected_runnable` 도메인의 `structure_types` 개수) | `PART3_STRUCTURE_COUNT_BROKEN` |
+| 근거 보존 | 붙은 route 수 + 미부착 route 수 == SG-13 `legal_effect_route` 총수 | `PART3_ROUTE_CONSERVATION_BROKEN` |
+| BO 보존 | 부착 BO 수 + 미부착 BO 수(검토 포함) == `BO.json` 레코드 총수 | `PART3_BO_CONSERVATION_BROKEN` |
+
+  **분할은 부착 여부로만 가른다.** 검토 여부는 분할과 무관하다 — `registered:false` 라도 `type_id` 가 Θ 안·자기 도메인 선언이면 **붙은 채로** 검토 꼬리표를 단다(이중 계상 금지). 구조 0 은 등식을 깨지 않는다.
+- **역인덱스 셋** — `by_domain_id` · `by_module` · **`by_bo_id`**(BO 부착 조인의 사영 — Part 4 F0 가 BO 행마다 구조를 찾는 소비 형태의 직접 색인). ID 목록만 담고 본문 복제 금지. 1차 전순서는 rank-major 라 `by_domain_id` 와 겹치지 않는다.
+- 검토 재산정 후 review handoff `FINALIZED` 갱신 재기록(공동 기록자). review 는 근거 없이 줄지 않는다.
+- 산출 — `legal_effect_structures.json`(실행 루트 · 루트 키 `legal_effect_structures_output` 아님 — 최상위에 `schema_version: "stage1_legal_effect_structures.v1"` · `status` · `theta` · `structure_records[]` · `structure_index{by_domain_id, by_module, by_bo_id}` · `quality_gate`) + handoff 갱신. 기록 후 재읽기 검증.
+
+---
+
+## 5. 신설·배포 자산과 정확한 배포 위치 (전부 배포 원본 `extension_research/Default_Agent/`)
+
+### 5.1 런타임 모듈 1종
+
+| 배포 경로 | 비고 |
+|---|---|
+| `Default_Agent/stage1_runtime/structure_index_compiler.py` | 조립·판정 로직 전부 |
+| `Default_Agent/stage1_runtime/structure_index_compiler.txt` | 바이트 동일 미러(직접 작성 — 미러 자동 생성은 조립본 빌더 몫이라 이월) |
+
+`domain_slice_compiler` 확장 대신 신설 — 그 모듈은 Part 2 A0 의 봉인된 소비 대상이고 서명 변경은 `PART2_COMPILER_STALE` 판정을 흔든다.
+
+### 5.2 정책 자산 1종 (신설)
+
+`Default_Agent/stage1_runtime/structure_index_policy.v1.json` — `schema_version: "stage1_structure_index_policy.v1"`. Θ 정의(가) · 전순서 3키(나) · 레코드 정체((도메인,type_id) 쌍) · `admission_policy` 두 단 정의 · 부착 분할 규칙 · BO 부착 조인 규칙(별칭 해소 포함, L0-7b) · **BO 보존 등식** · SG-11 조인 키(`signal_id`) · `extension_key` 규칙(다) · 검토 코드 목록(`UNREGISTERED_EFFECT_TYPE_REVIEW` · `PART3_BO_UNATTACHED` · `PART3_BO_DOMAIN_UNRESOLVED` 포함). **선례**: `prompt_composition_policy.json` · `bo_surface_projection_policy.v1.json` — 규칙을 코드 밖에 선언하면 적대 검증이 선언의 목적문을 오라클로 쓸 수 있다(BO 투영 회차에서 결손 2건을 정확히 그 방식으로 잡았다).
+
+### 5.3 사이드카 배포 2종 ×25 (조립본 → 배포 원본 바이트 복사)
+
+`Default_Agent/domains/<id>/structure_types.json` · `module_role_projection.json` (EC-00 제외 25 도메인 · 합 50 파일). 원천은 조립본 동명 파일이며 **바이트 동일 복사만** 한다(내용 수정 금지 — 방언 통일은 registry 소유자 몫, §8.2). `domain_config` 26/26 이 조립본과 바이트 동일임을 복사 전에 재확인한다(원천 정합).
+
+### 5.4 매니페스트 갱신 — `runtime_manifest.json` 371 → 426 (델타 정확히 55)
+
+사이드카 50 + 스키마 2 + 모듈 `.py`/`.txt` 2 + 정책 1 = **55행 추가**(기존 행 수정 0). 직렬화 왕복 보존(indent=2 · trailing newline) 확인. `runtime_artifact_count` 도 426 으로.
+
+### 5.5 봉인 스키마 2종과 `PART3_REQUIRED_ASSETS`
+
+| 배포 경로 | 내용의 `schema_version` |
+|---|---|
+| `Default_Agent/platform/schemas/structure_seed_bundle.schema.json` | `stage1_structure_seed_bundle.v1` |
+| `Default_Agent/platform/schemas/legal_effect_structures.schema.json` | `stage1_legal_effect_structures.v1` |
+
+**파일명에 판본을 넣지 않는다**(`*.schema.v1.json` 금지) — 빌더의 `$ref` 폐포·형식 검증이 `rglob("*.schema.json")` 로만 훑는다. 스키마 패턴은 열거를 하드코딩하지 않는다 — `type_id` `^[a-z][a-z0-9_]{1,127}$` · 도메인 ID `^(?:(?:EC|E)-[A-Z0-9]{2,8}|X[A-Z0-9]{1,8})$` · 검토 코드 `^[A-Z][A-Z0-9_]{2,127}$` 재사용.
+
+```
+PART3_REQUIRED_ASSETS = (
+    "Default_Agent/platform/schemas/structure_seed_bundle.schema.json",
+    "Default_Agent/platform/schemas/legal_effect_structures.schema.json",
+    "Default_Agent/stage1_runtime/structure_index_policy.v1.json",
+    "Default_Agent/routing/extension_payload_key_declarations.v1.json",
+    "Default_Agent/signals/signal_registry.v2.json",
+    "Default_Agent/contracts/signals/s5_execution_contract.v2.json",
+    "Default_Agent/stage1_runtime/structure_index_compiler.txt",
+    "Default_Agent/stage1_runtime/runtime_common.txt",
+    "Default_Agent/stage1_runtime/schema_subset_validator.txt",
+    "Default_Agent/stage1_runtime/registry_loader.txt",
+)   # 10 리터럴
+```
+
+사이드카 50 은 게이트 목록에 넣지 않는다 — `expected_runnable` 도메인 것만 읽으므로 **읽는 시점에 `_verify_asset`(매니페스트 해시 대조)** 로 지킨다(Part 2 가 seed 스키마·검증기 미러에 쓴 규율). **부재 규칙**: `structure_types` 선언이 0 인 도메인(오늘 EC-00 하나)의 사이드카 부재는 정상이다 — 스킵하고 영수증에 기록한다. 선언이 있는 도메인의 부재·미등재는 `PART3_ASSET_DEPLOYMENT_INCOMPLETE` 계열 경성 실패다(L-j 의 "EC-00 활성 → 실패 아님"과 이 규칙이 맞물린다). `domains/_registry_index.json` 은 게이트가 아니라 SG-01 봉인이 지킨다(I-11).
+
+### 5.6 Part 3 작업 yaml 과 선언표
+
+| 경로 | 내용 |
+|---|---|
+| `ver_8_yaml_candidates/P3-L0_structure_seed_reducer_v1.yml` · `P3-L2_final_structure_index_writer_v1.yml` | 조각 후보본 |
+| `ver_8_yaml_candidates/stage_1_part_3_v.8.yml` | 통합본 — Agent `Liti-agent_Civil_Suit_Plaintiff_Stage_1_Part_3` · 스테이지 `stage1_법률효과구조_생성` 하나 · 선언 1벌 · `IN → L0 → L2 → OUT` |
+
+선언표 `handoffs/stage1_part_interface.v1.json` 과 `stage1_stage_chain.v1.json`(둘 다 조립본 `handoffs/` 의 계약 문서 — 실행 자산이 아니므로 **이 2종만 예외적으로 조립본에서 갱신**한다): **신규 11줄 + 기존 8줄 갱신 · `handoff_count` 34 → 45**(갱신은 수를 늘리지 않는다). 신규 = 구 전략서 §5.5 의 10줄(정본 signal 경로 6 · Part 3 산출 4) + **`client_goal.json` 등재 1줄**(생산자 T1 · 소비자 빈 배열 + note "Part 3 이후 스테이지가 읽는다" — C-8 폐쇄). 기존 갱신 8줄 = ① `runtime/domain_slices/<id>` 소비자에 L0 추가 ② `client_meeting.md` 소비자에 Part 2 A0 추가(C-8 나머지 한 줄) ③~⑤ **구 이름 3종 행(`actio_case_signals.json` 등)에서 Part 3 소비자 제거**(C-7 — 남겨 두면 계약 문서가 §3 의 "읽지 않는다"와 어긋난 채 남는다) ⑥~⑧ `signal_manifest.json` 행 소비자에 L0, `routing/domain_activation_manifest.json` · `BO.json` 행 소비자에 **L0 와 L2 둘 다**(`Task_C_LE_L0_structure_seed_reducer` · `Task_C_LE_L2_final_structure_index_writer`) 추가. 신규 행 중 `signals/legal_effect_routes.json` 의 소비자도 L0·L2 둘이다(§4.3 바깥 수). 규칙: `consumer_tasks` 는 실제 task 이름만 · 약칭 금지 · `produced_by_module` 위임을 빠뜨리면 `U5_REQUIRED_KEY_ABSENT`. `stage_chain` 의 Part 3 구간과 상위 전략서 `stage_1_update_strategy.md` 두 곳 — §1 사슬(`S0→L0→L1→L2`)과 §4.2(P3-L1 절) — 의 L1 부재 반영도 함께 고친다.
+
+**신설·변경 자산 합계** — 실행 자산(배포 원본): 모듈 1(+미러 1) · 정책 1 · 스키마 2 · 사이드카 복사 50 · 매니페스트 갱신 1 = 56 파일. 명세·계약: yaml 3(조각 2+통합 1) · 선언표 1 · stage_chain 1 · 상위 전략서 두 곳(§1 사슬 · §4.2).
+
+---
+
+## 6. 실행 단계
+
+되돌릴 수 있는 크기로 자른다. 앞 단계 통과 전에 다음 단계에 착수하지 않는다.
+
+| 단계 | 내용 | 통과 조건 |
+|---|---|---|
+| **P3-0a** | **D-4 결정(§2) 사용자 승인** — Θ 범위 · 전순서 · `by_module` · 폴백 폐기 | 승인 없이는 착수하지 않는다 |
+| **P3-0b** | 전제 확인(작업 아님) — 빌더 뿌리 10(완료 실측) · 배포 원본 371항 · `domain_config` 26/26 조립본과 바이트 동일 | 실측 일치 |
+| **P3-1** | 사이드카 50 복사 배포 + 매니페스트 등재 | 50/50 바이트 동일 · 등재 sha 일치 |
+| **P3-2** | 정책 1 · 스키마 2 작성 배포 + 등재 | `schema_subset_validator` 로 자기 검증 통과 · 등재 sha 일치 |
+| **P3-3** | `structure_index_compiler.py` + 미러 작성 배포 + 등재(426항 도달) | 미러 해시 일치 · 왕복 보존 |
+| **P3-4** | 선언표 신규 11줄 + 기존 8줄 갱신 + count 45 + stage_chain + 상위 전략서 두 곳(§1 사슬 · §4.2) | `_check_stage1_interface.py` finding 0 |
+| **P3-5** | L0 yaml (도입부는 Part 2 A0 복사, 호출부만 신작) | 문법 PASS · AST 미정의 이름 0 |
+| **P3-6** | L2 yaml | 〃 |
+| **P3-7** | 통합본 병합 | 선언 각 1벌 · 개별↔통합 블록 불일치 0 |
+| **P3-8** | 예행 pass3(기존 2패스 뒤에 L0·L2, `--asset-root` = 배포 원본) + 26 도메인 합성 실측 + 계산 조인 탐침 | PASS · `legal_effect_structures.json` 실제 생성 · Θ·레코드 수·버킷 수·BO 부착 계수가 영수증에 실측 기록 |
+| **P3-9** | 회귀 22종(§7.2) → 적대적 sub-agent 검증 루프(지적 0 까지) → 내역서 작성 | 회귀 전건 기대대로 발화 · "잔여 필수 수정 없음" |
+
+### 6.1 조립본 동기화 회차로 이월 (Part 2 의 D-1~D-6 과 한 벌)
+
+① Part 3 신설 자산 5종(+미러)·사이드카 등재의 조립본 반영 + 빌더 `PART3_ASSEMBLY_AUTHORED` 등록 + 사이드카 sweep 규칙(파일 반영과 등록은 한 벌 — 등록만 선행하면 `MISSING_SELECTED_SOURCE` 즉사) ② `release_manifest`·`source_copy_map` 재생성 ③ 신선 빌드의 Part 3 자산 재현 확인 ④ `dry_run_receipt` 정본화(Part 2 M-* + Part 3 L-* 합본) ⑤ `effect_projection.schema_ref` dangling 해소(배포 여부는 registry 소유자 결정).
+
+---
+
+## 7. 검증 설계
+
+### 7.1 세 층
+
+| 층 | 통과 조건 |
+|---|---|
+| 결정론 회귀 | 같은 입력 2회 → `legal_effect_structures.json` sha256 동일(3키 전순서가 보장) |
+| 계약 준수 | 닫힌 스키마 통과 · 선언표 finding 0 · 진입 봉인 둘 · 보존 등식 셋 · 정책-코드 등가(선언 목적문 대조) |
+| 행동 검증 | **미측정으로 명시** — 사건 실주행과 법률 검토 필요. 대역으로 닫히지 않는다 |
+
+### 7.2 회귀 22종 — Part 2 의 R-a~R-l · M-a~M-r 에 잇는다
+
+변종 실행 전 `/tmp/s1` · `/tmp/s1_r0` 청소 절차 유지.
+
+| id | 시나리오 | 기대 |
+|---|---|---|
+| L-a | 필수 자산 1건 결손 | `PART3_ASSET_DEPLOYMENT_INCOMPLETE` |
+| L-b | seed 스키마와 매니페스트 항목을 함께 옛 판본으로 | `PART3_STRUCTURE_SCHEMA_STALE` · 기록 구조 0 |
+| L-c | 서명 같고 `theta`/`order_key` 투영만 잃은 컴파일러 | `PART3_COMPILER_STALE` |
+| L-d | `signal_manifest.files[].file_sha256` 변조 | `PART3_SIGNAL_SEAL_FAILED` |
+| L-d2 | `_registry_index.json` 도메인 순서 변경(SG-01 봉인은 그대로) | `PART3_REGISTRY_INDEX_SEAL_FAILED` |
+| L-e | Θ 밖 `type_id` 주입 | 버려지지 않고 `UNREGISTERED_EFFECT_TYPE_REVIEW` · 근거 보존 등식 유지 |
+| L-f | `registered:false` 후보 | 같은 검토 코드 · `default_projection` 있으면 투영+검토 동시 |
+| L-g | Θ 안이지만 남의 도메인 유형 | `PART3_EFFECT_TYPE_CROSS_DOMAIN` |
+| L-h | rank 1 선언 도메인 넷(E-02·E-03·E-07·E-08) 동시 활성 | 색인 머리 네 줄(`money_claim` ×2 — 합치지 않음) · 순서 결정론 |
+| L-i | E-04·E-11 동시 활성(`land_use_gain` 양쪽) | 구조 둘 · E-11 의 선언 순서 보존(`possession_vindication`(5) 가 E-11 `land_use_gain`(6) 앞) |
+| L-j | EC-00 만 활성 | 구조 0 · 등식 통과 · 실패 아님 |
+| L-k | `active ⊊ expected_runnable`(감시 도메인 포함) | 감시 도메인 효과가 Θ 안 — 검토로 쓸려가지 않음 (**D-3 회귀 · 필수**) |
+| L-l | 사이드카 한 도메인 항목 하나 제거 — **매니페스트 항목도 함께 갱신**(안 하면 `_verify_asset` 해시 불일치가 먼저 난다) | `PART3_REGISTRY_SIDECAR_MISMATCH` |
+| L-m | 슬라이스 투영 ↔ config 불일치 주입 | `PART3_SLICE_PROJECTION_DIVERGENCE` |
+| L-m2 | `registered:false` + Θ 안·자기 도메인 | 붙은 채 검토 꼬리표 · 등식 불변 (**분할 규칙 회귀 · 필수**) |
+| L-n | 같은 입력 2회 | 바이트 동일 |
+| L-o | 137종 일반성 | 통합본에 사건 이름 라우팅 0 · `case_kind_domain_matrix` 참조 0 |
+| L-p | 무변조 트리에서 사이드카 정규화 리더 | 73/73 · 불일치 0 (**리더 자체 검증 · 필수** — 방언 하나라도 못 읽으면 여기서 드러난다) |
+| **L-q** | BO 부착 조인(신설) — 양성·음성 두 변종 | 양성: 예행 BO 2건 부착 · `by_bo_id` 등재. 음성: `Legal_Keywords` 를 비운 BO·별칭 해소 불능 `source_domain` 주입 → `PART3_BO_UNATTACHED` / `PART3_BO_DOMAIN_UNRESOLVED` 검토 · **BO 보존 등식 유지** |
+| **L-r** | 정책 자산 판본 변조 — **매니페스트 항목도 함께 갱신** | `PART3_POLICY_INVALID` |
+| **L-s** | 사이드카(또는 정책)를 매니페스트 **미동반** 변조 | `_verify_asset` 경성 실패(`PART3_ASSET_DEPLOYMENT_INCOMPLETE` 계열) — 해시 게이트 자체의 발화 증명 |
+| **L-b2** | `legal_effect_structures.schema.json` 과 매니페스트 항목을 함께 옛 판본으로 | `PART3_INDEX_SCHEMA_STALE`(L2 쪽 의미 검사의 발화 증명) |
+
+L-b·L-c 는 짝(장부 검사 대 의미 검사), L-l·L-r 대 L-s 도 짝(의미 검사 대 해시 게이트). **L-b·L-b2·L-c·L-d2·L-k·L-m2·L-p·L-q(음성 포함) 를 빼고 통과로 세지 않는다.**
+
+### 7.3 예행의 한계와 별도 실측
+
+예행 활성은 X1·X2·X3 — Θ 4종(`succession_notice_lien_asset_defense`·`general_legal_effect`·`asset_state`·`valuation`) · 구조 레코드 6건(X1 2·X2 2·X3 2). stub seed 에 `request_id` 가 없어 `calculation_refs` 가 비므로 L0-6 조인·dangling 검토가 예행에서 발화하지 않는다. 그래서 셋을 따로 잰다: ① **26 도메인 합성 실측** — 전 도메인 `execution_eligible` 합성 SG-01 로 컴파일러를 돌려 Θ 56종 · 구조 73건 · `by_module` 34 버킷 · 전순서 결정론 확인 ② **계산 조인 탐침** — `request_id` 를 넣은 합성 재료로 L0-6 정상·dangling 각 1회 ③ `admission_policy` 둘째 단 경로 — 예행 구조 6건 중 4건(E-00·E-15·X1·X3 방언)이 그 경로이므로 값이 비지 않음을 영수증으로 확인. 오버레이·실 LLM 활성(실체 도메인) 검증은 실주행 몫으로 남긴다.
+
+### 7.4 검증 루프
+
+작업 완료 후 독립 sub-agent 적대 검증: §4 동일 수행 여부(A 계열) + 완수 기준(B 계열 — 산출물 정합·상하류 consistency) 전건 실측. 지적 반영 → 재검증을 **"잔여 필수 수정 없음"까지 반복**한다. 정책 자산(§5.2)의 선언 목적문은 검증 오라클로 쓴다.
+
+---
+
+## 8. 137종 일반성 보증과 하지 않는 것
+
+### 8.1 보증
+
+Part 3 코드는 사건 이름·도메인 목록·유형 열거를 고정하지 않는다. 도메인 26→27, 새 `structure_type`, 새 계산 도메인, 새 `module`, 새 사건 종류 — 전부 Part 3 무수정으로 흡수된다(Θ 는 SG-01+config, 정렬은 색인 위치, 스키마는 패턴, 조인은 `signal_id`, 버킷은 값에서). 이름 검사(L-o)만으로 부족하므로 **L-k(D-3 넓은 정의)** 를 필수로 둔다.
+
+### 8.2 하지 않는 것
+
+| 항목 | 왜 |
+|---|---|
+| SG-02·SG-07 생산자 신설 | Part 2 S0 개정이다. 어휘 설계가 먼저다 — 공백을 형식화된 사실로 영수증에 남긴다 |
+| 청구 형태 어휘 신설 · 사이드카 방언 통일 · `effect_projection.schema_ref` 해소 | registry 소유자 결정. Part 3 는 정규화해 읽고 보고한다 |
+| 예행 seed 대역에 `request_id` 추가 | Part 2 예행 자산. §7.3 탐침으로 대신한다 |
+| `signal_registry.v2.json`·13 signal 계약·`BO.json` 레코드 구조 변경 | 확정 계약·최대 호환면. `downstream_seed_refs.legal_effect_structure_seed_ref_proposed` 채우기도 BO 재기록이므로 하지 않는다 |
+| 조립본·빌더·장부 갱신 | 조립본 동기화 회차(§6.1) |
+| 구 Part 3 yaml 대조·읽기 | 제약 1 |
+| Part 4 착수 | `legal_effect_structures.json` 이 서고 회귀 통과 뒤 |
+
+---
+
+## 9. 위험과 중단 규칙
+
+| 위험 | 징후 | 대응 |
+|---|---|---|
+| Θ 를 `active_domain_ids` 로 잡음 | 감시 도메인 효과 전부 검토행 · 커버리지는 통과 | L-k 필수 회귀 |
+| 전순서 비결정론 | 2회 실행 순서 상이 | L-n · 3키를 정책 자산에 못박음 |
+| 스키마 파일명 판본 | 형식 검증·`$ref` 폐포 누락 | §5.5 규칙 |
+| 사이드카를 조립본에서 읽는 코드 | 배포 원본 단독 실행이 깨진다 | **명세서 전수에서 `선행구축` 참조 0 을 회귀로 확인**(Part 2 검증 방식) |
+| 보존 등식 항등식화 | 결손 불검출 | 세 등식 다 **원본 파일에서 직접 센 바깥 수**와 비교(§4.3) |
+| 방언 못 읽는 리더 | 없는 불일치 생성(구 전략서 초안이 실제로 겪음) | L-p 필수 |
+| pack 신설 유혹 | 판정자 없는 pack = 침묵 삼킴 or 상시 실패 | §4.1 — L1 도입 시점까지 pack 금지 |
+| 구 계약 잔재 | 리터럴이 registry ID 와 동시 만족 불가(Part 2 가 두 번 겪음) | 신설이므로 처음부터 registry ID 패턴만 |
+
+중단 규칙: P3-0a 미승인 착수 금지 · 앞 단계 미통과 진행 금지 · 필수 회귀 8종(L-b·b2·c·d2·k·m2·p·q) 미발화 상태로 완료 선언 금지.
+
+---
+
+## 10. 완료 판정
+
+1. `stage_1_part_3_v.8.yml` — 스테이지 하나 · 선언 1벌 · 개별↔통합 불일치 0 · task 2(L0·L2) · `IN→L0→L2→OUT`.
+2. 배포 원본에 실행 자산 56 파일(모듈+미러 2 · 정책 1 · 스키마 2 · 사이드카 50 · 매니페스트 갱신 1)이 정확한 위치에 있고 `runtime_manifest` 426항. 해시 일치의 범위는 **이 회차 신설·복사 55행 전수 + 배포 트리에 실물이 있는 기존 등재분(94항)** 이다 — 매니페스트는 상위 장부라 277항은 이 트리에 실물이 없는 것이 정상이다(§1.4).
+3. 선언표 45줄 · 검사기 finding 0 (C-7·C-8 폐쇄 포함).
+4. 예행 pass3 통과 — `legal_effect_structures.json` 실제 생성 · Θ 4종/구조 6건/BO 부착 2건 실측 기록.
+5. 26 도메인 합성 실측 — Θ 56종 · 구조 73건 · `by_module` 34 버킷 · 전순서 결정론.
+6. 회귀 22종 전건 기대대로 발화(필수 8종 — L-b·L-b2·L-c·L-d2·L-k·L-m2·L-p·L-q — 포함).
+7. 적대적 sub-agent 재검증 "잔여 필수 수정 없음".
+8. 이월 목록(§6.1)이 내역서에 기록되고, 행동 검증은 **미측정으로 명시**된다.
+
+---
+
+## 11. 이 문서의 검증 이력
+
+독립 sub-agent 가 문서의 주장을 믿지 않고 배포 원본·조립본·Part 2 통합본·예행 실물(`/tmp/dry_v6`)을 직접 측정해 대조했고, 지적이 0 이 될 때까지 반복했다 — 라운드 1 지적 13건(MAJOR 4 · MINOR 9: BO 부착 실패 처분·`source_domain` 별칭·회귀-읽기규율 모순·매니페스트 전수 일치 문구 넷이 MAJOR), 라운드 2 지적 5건(별칭표 배선 I-14 신설이 MAJOR), 라운드 3 지적 1건(선언 보존 등식의 바깥 수 원천), 라운드 4 지적 1건(등식 정의역 `expected_runnable` 용어 통일 — L-k 오발화 예방), 라운드 5 지적 1건(선언 0 도메인의 사이드카 부재 규칙), **라운드 6 지적 0건.** 약 90개 실측 항목(수치·경로·키 이름·코드 인용)은 라운드 1 에서 전건 일치가 확인됐다. 검증 불가로 남은 셋 — 배포 원본 단독 재실행 실증(분석문서 §6.4 기록으로만 확인) · Part 2 검증에서 정책 목적문이 오라클로 쓰였다는 서술 · 예행 하네스의 pass3 접속 가능성 — 은 P3-8 실행 시 실측으로 닫는다.
@@ -2068,17 +2068,18 @@ Stage 1 -- Part 2 작업내역서를 개정한 작업 내용을 바탕으로 기

 MEMORY.md 파일에는 지금까지의 작업 내역들이 압축적으로 요약되어 있다.

-그리고 2개 yaml 작업명세서의 작업 흐름과 내역을 상세히 분석하여 제시한 문서가 `stage_1_part_1_and_2_updated_yaml_analysis.md`이다. 
+그리고 `stage 1 -- part 1|2` 2개 yaml 작업명세서의 작업 흐름과 내역을 상세히 분석하여 제시한 문서가 `stage_1_part_1_and_2_updated_yaml_analysis.md`이다. 

-이제 `stage_1_update_strategy.md`에 제시된 stage 1 -- part 3 개정작업 내용을 좀 더 최적화하고, 최적화된 개정 작업 전략서를 작성하고자 한다. 
+이제 `stage_1_update_strategy.md`에 제시된 `stage 1 -- part 3` 개정작업을 최적화된 방식으로 실행할 수 있도록 지시 사항을 작성하여 part 3 개정 작업 전략서를 작성하고자 한다. 
 </context>

 <method>
 1. <context>에 제시된 지금까지의 작업 히스토리를 숙지한다. 
 2. `stage_1_update_strategy.md`의 `## 1. Stage 1 최적 워크플로우 — 전체 DAG`의 `Part 3 — 법률효과 구조`의 `P3-L0`, `P3-L1`, `P3-L2` 작업 흐름도와 `## 4. Part 3 세부 워크플로우`에 제시된 내용을 분석한다. 
-3. 지금까지 stage 1 -- part 1|2 개정 작업명세서와 작업 결과물들과 consistent한 방식으로, '최소한의 작업으로 최고의 품질을 얻는다' 원칙을 준수하여 stage 1 -- part 3 작업을 최적화하는 방안을 구상한다. 최적화하는 방안을 구상할 때 아래 제시하는 <constraints>를 준수한다. 
-4. 최적 개정 작업 방안에 대한 구상을 1차 드래프트로 작성한 후, 독립적인 sub-agent를 띄워서 1차 드래프트 내용이 과연 stage 1 -- part 3 작업 개정을 위한 최적의 방안인지 엄격하게 검증한다. Sub-agent가 최적의 개정 작업 방안이라고 판단할 때까지 최적 개정 작업 방안을 재작성한다. 
-5. 4번의 검증 작업을 완전히 통과한 stage 1 -- part 3 최적 개정 방안을 상세한 작업 명세서 겸 실행 전략서로 작성하여 `v.7/extension_research/stage_1_part_3_개정_신전략서.md`로 생성한다. 
+3. Liti-agent가 Stage 1 -- Part 1,2 yaml 작업명세서를 실행할 때 사용하는 자산들이 저장된 `v.7/extension_research/Default_Agent` 폴더 내 자산들의 위치와 파일들을 점검한다.
+4. 3에서 얻은 지식에 기반을 두고, `stage 1 -- part 1|2` 2개 yaml 작업명세서 및 그것을 실행해서 얻는 작업 결과물들과 consistent한 방식으로, '최소한의 작업으로 최고의 품질을 얻는다' 원칙을 준수하여 stage 1 -- part 3 작업을 최적화하는 방안을 구상한다. 최적화하는 방안을 구상할 때 아래 제시하는 <constraints>를 준수한다. 
+5. 최적 개정 작업 방안에 대한 구상을 1차 드래프트로 작성한 후, 독립적인 sub-agent를 띄워서 1차 드래프트 내용이 과연 stage 1 -- part 3 작업 개정을 위한 최적의 방안인지 엄격하게 검증한다. 검증에 100% 통과할 때까지, sub-agent 검증과 최적 개정 작업명세서를 반복한다. 
+6. 5번의 검증 작업을 완전히 통과한 stage 1 -- part 3 최적 개정 작업명세서를 `v.7/extension_research/stage_1_part_3_개정_신전략서.md`로 생성한다. 

 <constraints>
 1. 작업 시, 기존 yaml 작업명세서('v.7/Claude_YAML'의 yaml 파일들)와 관련한 dependency는 완전히 제거한다. 즉, 기존 yaml 작업 명세서가 지시하는 내용에 전혀 의존하지 않도록 한다. 
@@ -2094,12 +2095,66 @@ MEMORY.md 파일에는 지금까지의 작업 내역들이 압축적으로 요
 </method>

 <global_constraints>
- `v.7/CLAUDE.md`가 제시하는 #### 5 행동 규칙을 준수한다.
+- `v.7/CLAUDE.md`가 제시하는 Fable 5 행동 규칙을 준수한다.
 - 작업 완료 시 작업 내역을 압축 요약하여 `v.7/MEMORY.md`에 추가 기입한다. 
 </global_constraints>


+==================================

+┌────────────────────────────────────────────┐
+│                  Lessons                   │
+└────────────────────────────────────────────┘
+작업명세서 개정 작성 시 그 작업의 궁극적 목적/목표/목적물을 '최소 작업으로 최고 품질로 달성'하는 원칙을 기반으로 두고 최적 워크플로우를 구성하여 작업명세서를 작성한다. 
+
+--> 이 기준을 prompt에 명시해야 한다. 
+
+
+
+
+
+
+┌────────────────────────────────────────────┐
+│                                            │
+│ 1st Execution of Update Strategy of Part 3 │
+│                                            │
+└────────────────────────────────────────────┘
+
+<goal>
+`stage_1_part_3_개정_신전략서.md`에 제시된 지시사항을 실행하여 stage 1 -- part 3 작업내역서를 개정 생성한다. 
+</goal>
+
+<context>
+지금까지 stage 1 -- part 1|2 개정작업을 진행했다. 
+`stage_1_part_1_v.8.yml`, `stage_1_part_2_v.8.yml`를 검증하여 두 작업명세서가 모두 의도한 작업 과정을 실행하는 것을 확인했다. 
+
+이제 `stage_1_part_3_개정_신전략서.md`가 제시하는 방식을 실행하여 part 3 작업의 궁극적 목적(목표/목적물)을 '최소 작업으로 최고 품질로 달성'하는 원칙을 기반으로 두고 최적 워크플로우를 구성하여 작업명세서(yaml & related assets)를 개정 생성하고자 한다. 
+</context>
+
+<method>
+1. `stage_1_part_3_개정_신전략서.md`의 작업 내용들을 독립적으로 동시 실행가능한 task들과, 직렬로 sequential 방식으로 실행해야 할 task들로 분류한다. 
+2. 1의 결과를 바탕으로 독립 동시 실행 가능한 task들은 병렬로 동시 실행하고, sequential 방식으로 실행해야 하는 task들은 upstream-downstream 작업 consistency를 유지하면서 실행한다. 
+3. 2번 작업을 수행한 후 sub-agent를 띄워서 2번 작업이 `stage_1_part_3_개정_신전략서.md`가 지시하는 사항들을 100% 정확하게 준수하여 작업을 `완수`했는지 검증한다. Sub-agent가 100% 검증 통과라고 판정할 때까지, 2번 작업을 반복한다. 
+4. 3번 작업이 완료되면, 작업 결과물 중 저장해야 할 자산들(assets)을 `extension_research/Default_Agent` 폴더에 배포 위치를 정확히 지켜서 저장하고, part 3 작업명세서를 `extension_research/ver_8_yaml_candidates/stage_1_part_3_v.8.yml`로 생성한다. 
+
+<constraints>
+1. 작업 시, 기존 yaml 작업명세서('v.7/Claude_YAML'의 yaml 파일들)와 관련한 dependency는 완전히 제거한다. 즉, 기존 yaml 작업 명세서가 지시하는 내용에 전혀 의존하지 않도록 한다. 
+2. Stage 1 -- part 1|2 작업이 사용하는 자산들의 명칭과 배포 위치 그리고 포맷은 `extension_research/Default_Agent` 폴더에 저장되어 있으며, 앞으로 Part 3 개정 작업을 통해 생성될 Stage 1 (part 상관없이) 실행 시 사용될 모든 자산(md, .py, .txt, .json)들은 이 폴더에 정확한 배포 위치 서브 폴더에  저장한다. 
+3. Liti-agent가 stage # yaml 작업명세서를 실행하여 작업을 `완수`했다는 표현을 사용할 때, `완수`의 기준은 단순히 yaml 작업명세서를 끝까지 실행 완주할 수 있다는 것이 아니다. Yaml 작업명세서를 실행했을 때, 원래 의도한 결과물들이 올바른 방식으로 생성되어야 하고, 소작업(sub-task)들의 upstream-downstream 간에 consistency(넘겨받은 파일을 올바로 읽고, handoff로 넘겨주는 파일도 정해진 포맷에 맞게 넘겨줌)를 유지하여 작업이 끝까지 이어진 경우를 작업이 `완수`되었다고 평가한다. 
+4. Stage 1 전체 작업에 대한 아래 내용을 절대 규칙으로 삼는다. 
+<absolute_principle_for_whole_stage_1>
+- Liti-agent는 대한민국 민사소송 사건종류 137종을 모두 다룰 수 있도록 개발되어야 한다. 
+- Stage 1 에서는 Liti-agent가 137종 중 그 어떤 사건을 다루더라도 `레지스트리 기반` 방식으로 사건 종류의 이름이 아니라 증거 구성요소·요건 슬롯·단서로 구조화된 정보를 확보하는 것을 목표로 한다. 이를 위해 사용할 자산들이 '법리 도메인, 계산 도메인, signal'이며 이에 대한 정의는 `v.7/extension_research/ensemble_v2.md`에 제시되어 있다. 
+</absolute_principle_for_whole_stage_1>
+</constraints>
+
+</method>
+
+<global_constraints>
+- `v.7/CLAUDE.md`가 제시하는 Fable 5 행동 규칙을 준수한다.
+- 작업 완료 시 작업 내역을 압축 요약하여 `v.7/MEMORY.md`에 추가 기입한다. 
+- yaml 작성을 할 때는 <v.7/SKILL.md>의 규칙을 엄격하게 준수하며, python code를 작성할 때는 <v.7/extension_research/test_code_executor.ipynb>가 제시하는 Python code 작성 규칙을 엄수한다. 
+</global_constraints>