docs(stage1): rewrite Part 2 sections of analysis doc for BO projection round
- stage_1_part_1_and_2_updated_yaml_analysis.md: incremental Part 2 update
(122,642 B, sha16 3648dcd743353f71) — new integrated-spec metrics
(195,938 B / 3,315 lines / ec4c43027ad85195), revision rounds 4→5,
R0 projection/review-channel/status-policy/seed-rewrite-removal, F0
registry-union fallback + policy load, A0 10-asset/18-path gate,
three-tree asset geography (Default_Agent deployment origin, 155 files),
M-a~M-r regression table, deployment-origin dry run (pass2 29 writes,
BO.json 2 records value-checked), carried-over items D-1~D-6
- previous edition (2026-08-18, 106,290 B) rotated to
ver_8_yaml_candidates/outdated/..._old.md (2026-08-16 edition kept in
git history at 3d8d90dc)
- verified by independent sub-agent loop: findings 9 → 1 → 0; loop also
surfaced two asset-side facts now recorded in the doc (assembly
release_manifest stale for builder roots 6→10 edit; candidate overlay
559/560 identical)
- v.7/MEMORY.md: append entry 21
- 확장_최적워크플로우_연구_프롬프트.txt: session prompt log
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Claude Fable 5
@@ -1431,3 +1431,24 @@ sub-agent 1차가 **신규 결손 2건을 실측으로 잡았다**: ① 투영
|
||||
2. **"원본 보존" 키는 원본의 정본 키에서 채워야 한다.** additive_keys 의 목적문("review_code 를 잃지 않기 위해")과 구현이 어긋난 것을 검증자가 목적문 대조로 잡았다 — 선언의 목적문은 그 자체가 검사 오라클이다.
|
||||
3. **기록 수의 증감은 편집의 지문이다.** pass2 32→29 = 되쓰기 3건 소멸. 산출 계수의 델타를 편집 내역과 대조하면 의도 밖 변화가 즉시 드러난다.
|
||||
4. **배포 원천 이관은 실행 경로의 참조 0 실측으로 닫는다.** "조립본을 안 고쳐도 되는가"는 명세서 전수 grep(참조 0) + 배포 트리 단독 재실행(바이트 동일)로 증명했다 — 선언이 아니라 실행으로.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 2026-08-19 ㉑ — 분석문서 Part 2 절 개정: BO 투영 회차 반영 (sub-agent 3라운드 · 지적 0 종결)
|
||||
|
||||
산출 `extension_research/stage_1_part_1_and_2_updated_yaml_analysis.md` **신판**(122,642 B · sha 앞 `3648dcd743353f71`). 앞 판(2026-08-18 · 106,290 B)은 `ver_8_yaml_candidates/outdated/..._old.md` 로 회전(그 자리에 있던 2026-08-16 판 86,634 B 는 git 3d8d90dc 이력 보존). Part 2 관련 절만 incremental 갱신 — Part 1 서술(§1.2·§2·§6.1)·§6.3·§8 무변.
|
||||
|
||||
### 갱신의 뼈대 (전부 재실측 값)
|
||||
- 통합본 195,938 B / 3,315행 / sha 앞 `ec4c43027ad85195`. task 행 범위 전이동(A0 60–717 · B 718–847 · R0 848–1,793 · R1 1,794–1,896 바이트 동일 · F0 1,897–2,685 · S0 2,686–3,275 · task_procedure 3,277–3,312).
|
||||
- §1.5 추가 개정 4회→**5회**(5회차 = BO 투영), §3.2 R0 처방 다섯 + 파생 정합(`{"event","state"}`→`allowed_legal_effect_bo_types`), R0 산출 넷→**셋**(되쓰기 삭제 — §4.4 seed 공동 기록자 관찰은 "해소"로), F0 registry 합집합 폴백 + `_load_projection_policy`, A0 자산 10/18경로, §3.5 리터럴 20→21 + 정책 자산 행(6,355 B).
|
||||
- §5 재작성: 뿌리 셋 — **배포 원본 `extension_research/Default_Agent` 155**(=실행 자산 154+정책 1 · .json 58/.md 29/.py 34/.txt 34 · 미러 34/34) / 조립본 1,322(배포 원본보다 낡은 3파일 + 자기 장부가 빌더 수정을 못 따라간 불일치 1) / 후보 오버레이 560(559 동일·1 상이). 매니페스트 371항 중 배포 트리 실재 94건 전수 해시 일치, 밖 277(계산기 205·법령 63 등)은 조립본 실재.
|
||||
- §6: 검사 18 을 "불일치 1(빌더 장부)"로 정정, M-a~M-r 회귀 표 신설, §6.4 를 배포 원본 asset-root 예행으로 재작성(45/3/**29** · BO 2건 값 검사 · /tmp/dry_v6 실물 대조), §6.5 에 검증이 잡은 신규 결함 2건(value_text·source_review_code), §6.6 B-3 닫힘·C-8 3줄→2줄·이월 D-1~D-6.
|
||||
|
||||
### 검증 루프 (지시 방법 4)
|
||||
sub-agent 1라운드: 지적 9건(MAJOR 6·MINOR 3) — 핵심은 **문서가 아니라 자산의 신규 사실 2건**: 조립본 `release_manifest` 가 다섯째 회차의 빌더 제자리 수정(roots 6→10, 102,559→102,997 B)을 미반영해 전수 대조 불일치 1, 후보 오버레이도 같은 이유로 559/1. 나머지는 이월 잔재(§1.3 R1 행번호 1584 · §3.5 `_domain_label` 잔문 · §1.4 A0 ASSET_ROOT 실사용 · §3.3 F0 IN 정책 누락 · §4.4 642행 · §7 두 행). 2라운드: 1건(제목 "전부 통과" ↔ 검사 18 모순) — 3라운드: **0건**. 배치 순서 지적 1건은 회전 선행으로 해소(검증자가 git 블롭 실측으로 전제 확인).
|
||||
|
||||
### 교훈
|
||||
1. **문서 검증이 자산 결함을 잡는다.** "불일치 0" 승계 문장을 재실측하게 했더니 조립본 장부의 빌더 불일치가 나왔다 — 이월 문장(D-2)의 근거가 실측으로 강화된 사례. 승계 수치는 옮길 때마다 다시 센다(⑯·⑲ 교훈의 재확인).
|
||||
2. **"손대지 않은 곳"도 파급 검사 대상이다.** 이월 잔재 지적 6건 중 4건이 앞 판본이 보존한 절(§1.3·§1.4·§3.5·§4.4)에서 나왔다 — 코드가 바뀌면 보존 절의 현재형 서술("R0 가 읽는다")이 거짓이 된다. incremental 갱신 시 보존 절을 "현재형 주장" 기준으로 한 번 훑을 것.
|
||||
3. 배치 순서가 서술의 참을 정한다 — 회전(구판→outdated)을 신판 배치보다 먼저. 문서에 완료형으로 적은 상태 전이는 그 순서로 실행해야 참이 된다.
|
||||
|
||||
+158
-100
@@ -3,11 +3,11 @@
|
||||
- 문서 위치: `YAML_Prompts/1. Stage_1/v.7/extension_research/stage_1_part_1_and_2_updated_yaml_analysis.md`
|
||||
- 분석 대상 정본 2종
|
||||
- `ver_8_yaml_candidates/stage_1_part_1_v.8.yml` — 467,668 B / 6,667행 / sha256 `195b43edfaf1df1414acc118c17d544c…`
|
||||
- `ver_8_yaml_candidates/stage_1_part_2_v.8.yml` — **193,933 B / 3,307행 / sha256 `73644c5620b1bfbc…`** (2026-08-18 추가 개정 4회 반영본. 개정 전 값은 175,266 B / 3,026행 / `9bf771b729840936…`)
|
||||
- 근거 자료: `v.7/MEMORY.md` · `stage_1_part_1_개정작업_리포트.md` · `ver_8_yaml_candidates/part_1_remaining_update_report.md` · `stage_1_part_2_레지스트리기반개정완료_보고서.md` · `ver_8_yaml_candidates/8월12_to_16일작업압축요약본.md`(316,036 B) · `Default_Agent_Stage_1/handoffs/stage1_part_interface.v1.json`(34 인계면 선언표)
|
||||
- **Part 2 추가 개정 4회의 작업 내역서** — `stage_1_part_2_추가수정작업.md`(배포 완전성 게이트 F-1~F-7) · `stage_1_part_2_추가수정작업_더.md`(델타 30건 조립본 반영 · R0 라벨 해석) · `stage_1_part_2_추가수정작업_더더.md`(빌더 등록 · 상류 동기화) · `stage_1_part_2_추가수정작업_더더더.md`(스키마 2건 등록 · 예행 seed 보강)
|
||||
- `ver_8_yaml_candidates/stage_1_part_2_v.8.yml` — **195,938 B / 3,315행 / sha256 `ec4c43027ad85195…`** (2026-08-19 BO 투영 회차 반영본. 직전 판은 193,933 B / 3,307행 / `73644c5620b1bfbc…` — `outdated/stage_1_part_2_v.8.pre_bo_projection.yml` 로 보존)
|
||||
- 근거 자료: `v.7/MEMORY.md` · `stage_1_part_1_개정작업_리포트.md` · `ver_8_yaml_candidates/part_1_remaining_update_report.md` · `stage_1_part_2_레지스트리기반개정완료_보고서.md` · `ver_8_yaml_candidates/8월12_to_16일작업압축요약본.md`(316,036 B) · `Default_Agent_Stage_1/handoffs/stage1_part_interface.v1.json`(34 인계면 선언표) · `stage_1_part_2_여전히남은문제해결방안.md`(v2) · `stage_1_part_2_여전히남은문제해결내역.md`
|
||||
- **Part 2 추가 개정 5회의 작업 내역서** — `stage_1_part_2_추가수정작업.md`(배포 완전성 게이트 F-1~F-7) · `stage_1_part_2_추가수정작업_더.md`(델타 30건 조립본 반영 · R0 라벨 해석) · `stage_1_part_2_추가수정작업_더더.md`(빌더 등록 · 상류 동기화) · `stage_1_part_2_추가수정작업_더더더.md`(스키마 2건 등록 · 예행 seed 보강) · `stage_1_part_2_여전히남은문제해결방안.md`(v2) + `stage_1_part_2_여전히남은문제해결내역.md`(BO 투영 — worker v3 산출이 `BO.json`·검토 handoff 에 닿는 경로 복원)
|
||||
- 실측 기준: 이 문서의 모든 수치·경로·키는 위 두 YAML 원문과 자산 트리를 **직접 파싱·해시**하여 얻은 것이다. 리포트 본문에서 옮겨 온 값은 §7 근거표에 출처를 적었고, 리포트와 실측이 갈린 곳은 그 자리에 명시했다.
|
||||
- **개정 방식**: 이 문서는 Part 2 절만 incremental 로 갱신한 판본이다. Part 1 에 관한 서술(§2 전체, §1.2, §6.1)은 앞 판본에서 손대지 않았다. 앞 판본은 `ver_8_yaml_candidates/outdated/stage_1_part_1_and_2_updated_yaml_analysis_old.md`(86,634 B)에 보존돼 있다.
|
||||
- **개정 방식**: 이 문서는 Part 2 절만 incremental 로 갱신한 판본이다. Part 1 에 관한 서술(§2 전체, §1.2, §6.1)은 앞 판본에서 손대지 않았다. 앞 판본(2026-08-18)은 `ver_8_yaml_candidates/outdated/stage_1_part_1_and_2_updated_yaml_analysis_old.md`(106,290 B)로 보존돼 있다.
|
||||
|
||||
---
|
||||
|
||||
@@ -26,11 +26,11 @@
|
||||
| 사건 입력 | `client_meeting.md` · `evidence_all.json` | `client_meeting.md` (A0가 직접 읽는다) + Part 1 산출 6종 |
|
||||
| 최종 산출 | `routing/domain_activation_manifest.json` · `quality_gates/stage1_part1_soft_gate_handoff.json` 외 | `BO.json` · `signals/signal_manifest.json` 외 |
|
||||
| 개정 분류 | 신설 4 · 개정 3 · 무변경 6 | 신설 1 · 개정 4 · 무변경 1 (+ 정적 worker 5 삭제) |
|
||||
| 추가 개정 라운드 | 없음 | **4회** — 배포 완전성 게이트 · 델타 반영과 라벨 해석 · 원천 정합 · 예행 seed 보강 (§1.5) |
|
||||
| 추가 개정 라운드 | 없음 | **5회** — 배포 완전성 게이트 · 델타 반영과 라벨 해석 · 원천 정합 · 예행 seed 보강 · **BO 투영** (§1.5) |
|
||||
| 예행 완주 코드 task | 5 / 8 | **4 / 4** (A0 · R0 · F0 · S0, §6.4) |
|
||||
| YAML 구문 | PASS | PASS |
|
||||
|
||||
Part 2 는 첫 판본(레지스트리 기반 전환) 이후 네 차례 더 개정됐다. 그 네 회차가 바꾼 것은 task 구성이 아니라 **실행 전 자산 검사 · 도메인 라벨 해석 · 후보 식별자 계약 · 예행 재료**이며, task 6종과 DAG 모양은 그대로다. 회차별 내용은 §1.5 에 있다.
|
||||
Part 2 는 첫 판본(레지스트리 기반 전환) 이후 다섯 차례 더 개정됐다. 앞 네 회차가 바꾼 것은 **실행 전 자산 검사 · 도메인 라벨 해석 · 후보 식별자 계약 · 예행 재료**이고, 다섯째 회차(2026-08-19 BO 투영)가 바꾼 것은 **worker v3 산출이 `BO.json`·검토 handoff 에 실제로 닿는 값의 경로**다. 다섯 회차 모두 task 6종과 DAG 모양은 그대로다. 회차별 내용은 §1.5 에 있다.
|
||||
|
||||
두 파일 모두 **스테이지 하나 · 선언 1벌**이다. `Agent` 1 · `Stages` 1 · stage명 1 · `tasks` 1 · `task_procedure` 1 · `prevs`/`nexts` 각 1벌이며, 조각 후보본들이 각자 갖고 있던 스테이지 껍데기와 자기 `task_procedure`는 조립 시 전부 걷어냈다.
|
||||
|
||||
@@ -76,7 +76,7 @@ Part 2 통합본의 개별 6종 ↔ 통합본 대조는 불일치 0으로 확인
|
||||
| P2-A0 | `Task_C_BO_A0_context_and_domain_slice_compiler` | 개정 | 상수 3덩어리 → 조립본 모듈 **8종 호출**. `stage_a_context_builder` 신설 반입. 스크리닝의 `requested_calculation_domains` 파싱, 프롬프트 조각(`extra_specs`) 주입, `stage1_stage_receipt.v2` 기록 |
|
||||
| P2-B | `Task_C_B_domain_worker_*` | **신설** | 정적 worker `B1~B5` 다섯을 대체하는 **단일 템플릿**. 인스턴스는 fan-out 계획이 만든다 |
|
||||
| P2-R0 | `Task_C_BO_R0_seed_reducer_and_exception_planner` | 개정 | fan-out 기대집합 정확 일치 + `worker_output_validator.validate_worker_output` **실제 호출** + 판본 리터럴 `…seed.v3` 교정 |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | 무변경 | v3 3621–3723행과 **바이트 동일**(통합본 1584–1686행) |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | 무변경 | v3 3621–3723행과 **바이트 동일**(현행 통합본 1,794–1,896행 — 첫 판본 시점에는 1,584–1,686행) |
|
||||
| P2-F0 | `Task_C_BO_F0_final_bo_compiler_gate_writer` | 개정 | BOType 어휘를 registry **합집합**으로. 확장 payload 키 선언표 대조, R1 계약 조건부화 |
|
||||
| P2-S0 | `Task_C_BO_S0_signal_bundle_writer` | 개정 | 인라인 모듈 → 조립본 모듈 반입(compiler 7 + adapter 4 + emitter 13). 슬라이스 `emits_signals` 선언과 실제 방출 대조 |
|
||||
|
||||
@@ -86,17 +86,17 @@ Part 2 통합본의 개별 6종 ↔ 통합본 대조는 불일치 0으로 확인
|
||||
|
||||
| 규약 | 내용 | 실측 |
|
||||
|---|---|---|
|
||||
| **미러 규약 M-1~M-5** | 모든 `.py` 옆에 바이트 동일한 `.txt` 형제를 배포한다. localdocs가 `.py`를 서빙하지 않기 때문이다. 미러는 정본 옆에 놓이므로 `sg01_activation_adapter`의 미러는 `signals/adapters/`에 있다 | 조립본 `.py` **112 중 111 미러** · 해시 불일치 0. 유일한 예외는 빌더 `tools/build_default_agent_stage1.py` (앞 판본의 103/102 는 델타 반영 전 값이다) |
|
||||
| **미러 규약 M-1~M-5** | 모든 `.py` 옆에 바이트 동일한 `.txt` 형제를 배포한다. localdocs가 `.py`를 서빙하지 않기 때문이다. 미러는 정본 옆에 놓이므로 `sg01_activation_adapter`의 미러는 `signals/adapters/`에 있다 | 조립본 `.py` **112 중 111 미러** · 해시 불일치 0. 유일한 예외는 빌더 `tools/build_default_agent_stage1.py` (앞 판본의 103/102 는 델타 반영 전 값이다). 배포 원본 `extension_research/Default_Agent` 트리는 `.py` 34 전량 미러 · 불일치 0 (§5.2) |
|
||||
| **모듈 반입 규약 R-1~R-5** | `.txt` 미러를 `read_raw`로 읽고 `runtime_manifest.json`의 sha256과 대조한 뒤 `/tmp/…`에 `.py`로 기록하고 `sys.path.insert`. 실패 코드는 `MODULE_MIRROR_UNREGISTERED` / `MODULE_MIRROR_HASH_MISMATCH` | D0 · P2-A0 · P2-R0 · P2-S0 네 task가 사용 |
|
||||
| **실행 뿌리 3개** | `--asset-root` · `--execution-root` · `--logical-root`를 argv로만 넘긴다. 값은 `Default_Agent/` · `/tmp/s1` · `/tmp/s1` (R0만 `/tmp/s1_r0`) | argv 3벌을 실제로 넘기는 곳은 **D0 하나뿐**이다(Part 1 5,943–5,945행, `activation_gate.main`). Part 2의 네 code task는 값을 상수로만 두며 실제 사용은 갈린다 — A0는 `EXECUTION_ROOT`만 쓰고 `ASSET_ROOT`·`LOGICAL_ROOT`는 대입 1회뿐, S0는 `ASSET_ROOT`·`EXECUTION_ROOT`를 쓰고 `LOGICAL_ROOT`는 대입 1회뿐, R0는 `EXECUTION_ROOT = /tmp/s1_r0` 하나만, F0는 셋 다 없다 |
|
||||
| **실행 뿌리 3개** | `--asset-root` · `--execution-root` · `--logical-root`를 argv로만 넘긴다. 값은 `Default_Agent/` · `/tmp/s1` · `/tmp/s1` (R0만 `/tmp/s1_r0`) | argv 3벌을 실제로 넘기는 곳은 **D0 하나뿐**이다(Part 1 5,943–5,945행, `activation_gate.main`). Part 2의 네 code task는 값을 상수로만 두며 실제 사용은 갈린다 — A0는 `EXECUTION_ROOT`와 `ASSET_ROOT`(배포 게이트가 논리 경로의 접두사를 벗기는 데 쓴다 — 통합본 331행)를 쓰고 `LOGICAL_ROOT`는 대입 1회뿐, S0는 `ASSET_ROOT`·`EXECUTION_ROOT`를 쓰고 `LOGICAL_ROOT`는 대입 1회뿐, R0는 `EXECUTION_ROOT = /tmp/s1_r0` 하나만, F0는 셋 다 없다 |
|
||||
| **P0 설계판정 C** | 봉인된 스키마를 늘릴 때 기존 키의 값은 등가로 두고 신규 키만 더한다. `required`에 올리지 않는다 | `domain_slice.schema.v2.json` 루트 properties 20→21 · `required` 19 불변, 그리고 `compiled_prompt.properties` 4→5(`hash_kind` 추가) · `compiled_prompt.required` 4 불변. T3 `registry_component_ids` 슬롯 1개 additive |
|
||||
| **137종 일반성** | 사건 종류 이름을 런타임 라우팅 키로 쓰지 않는다. 라우팅은 registry 26 법리 도메인의 활성 여부로만 한다 | 두 통합본에서 사건유형 이름 라우팅 참조 0. `case_kind_domain_matrix.v2.json`은 **T0-01과 T1 두 프롬프트**가 각각 금지 목록에 명시한다(Part 1 192행 · 1,687행, 오프라인 회귀 전용) |
|
||||
|
||||
---
|
||||
|
||||
### 1.5 Part 2 추가 개정 4회
|
||||
### 1.5 Part 2 추가 개정 5회
|
||||
|
||||
§1.3 의 레지스트리 기반 전환을 마친 뒤, Part 2 는 실행 직전에 걸리는 결손 넷을 차례로 닫았다. 회차마다 독립 sub-agent 검증을 통과할 때까지 반복했고, 작업 내역서는 회차별로 따로 있다.
|
||||
§1.3 의 레지스트리 기반 전환을 마친 뒤, Part 2 는 실행에 걸리는 결손을 다섯 회차로 나눠 닫았다. 회차마다 독립 sub-agent 검증을 통과할 때까지 반복했고, 작업 내역서는 회차별로 따로 있다.
|
||||
|
||||
| 회차 | 문서 | 무엇을 닫았나 | 명세서에 남은 흔적 |
|
||||
|---|---|---|---|
|
||||
@@ -104,8 +104,9 @@ Part 2 통합본의 개별 6종 ↔ 통합본 대조는 불일치 0으로 확인
|
||||
| 2 | `stage_1_part_2_추가수정작업_더.md` | **델타 30건의 정본 반영**과 **도메인 라벨 해석**. R0 640행이 구 이름 다섯 개짜리 표를 대괄호로 조회해 registry ID 마다 `KeyError` 로 죽었다 | R0 에 `_domain_label()` 3단 해석(슬라이스 → 구 이름 표 → ID). 슬라이스 적재를 검증기 분기 밖으로 인상 |
|
||||
| 3 | `stage_1_part_2_추가수정작업_더더.md` | **원천 정합.** 조립본이 재생성 불가능한 유일본이 돼 있었다 — 빌더가 신규 23건을 모르고, 변경된 두 모듈은 상류가 옛 바이트를 쥐고 있었다 | 명세서 변경 없음. 빌더·상류·기록 표 쪽 작업이다 |
|
||||
| 4 | `stage_1_part_2_추가수정작업_더더더.md` | **스키마 2건 등록**과 **예행 seed 보강**. 후자에서 R0 의 후보 식별자 계약이 registry ID 로는 만족 불가능하다는 것이 드러났다 | R0 의 `CANDIDATE_REF_RE` 를 형식만 보도록 넓히고 `ensure_candidate_ref()` 추가, v3 의 평평한 `source_refs` 를 membership 게이트가 보도록 검사 1개 추가 |
|
||||
| 5 | `stage_1_part_2_여전히남은문제해결방안.md`(v2) · 내역서 `stage_1_part_2_여전히남은문제해결내역.md` | **BO 투영.** worker 가 v3 계약대로 만든 값이 R0 원장에서 `extensions` 한 칸 빼고 전부 버려져 BO 가 증거 없는 1건으로 접혔고, 검토는 v3 두 채널이 아니라 v3 에 없는 구 키(`domain_review_queue`)에서만 읽혔다(C-1~C-8·C-11) | R0 에 registry 근거 투영기 `project_to_bo_surface`(반환 17키 고정) + 정책 자산 `bo_surface_projection_policy.v1.json` 경성 반입 + status 5종 정책 + 계획 행 sha 대조. v2 잔재(`expand_candidate` · `_seed_payload` · `ALLOWED_SEED_KEYS` · `DOMAIN_LABELS` · 되쓰기) 제거. F0 폴백 어휘를 registry 합집합으로, 정규화를 handoff 보고로. A0 필수 자산 10(18경로). 공통 계약 한 문장 |
|
||||
|
||||
**네 회차가 공유하는 진단 형태가 하나 있다.** v3 시절의 리터럴이 registry 기반 전환 뒤에도 남아 있었고, 그 리터럴이 registry 어휘와 **동시에 만족될 수 없는** 형태였다는 것이다. 라벨 조회(`DOMAIN_LABELS[domain_id]`)와 후보 식별자(`^B[1-5]:[0-9]{3}$` + 도메인 접두사 요구)가 같은 계열이며, §6.5 가 적은 두 BLOCKER(스키마 패턴이 registry 어휘보다 좁았다)도 같다. 넷 다 **실제로 실행해 보기 전에는 드러나지 않았다.**
|
||||
**다섯 회차가 공유하는 진단 형태가 하나 있다.** 구 계약 시절의 리터럴이 registry 기반 전환 뒤에도 남아 있었고, 그 리터럴이 새 계약의 어휘와 **동시에 만족될 수 없는** 형태였다는 것이다. 라벨 조회(`DOMAIN_LABELS[domain_id]`) · 후보 식별자(`^B[1-5]:[0-9]{3}$` + 도메인 접두사 요구) · 다섯째 회차의 v2 화이트리스트(`ALLOWED_SEED_KEYS` ∩ v3 후보 필드 = `extensions` 하나)와 `{"event","state"}` 폴백이 전부 같은 계열이며, §6.5 가 적은 두 BLOCKER(스키마 패턴이 registry 어휘보다 좁았다)도 같다. 전부 **실제로 실행해 값을 관측하기 전에는 드러나지 않았다** — 특히 다섯째 회차의 결손은 완주 게이트가 전부 통과하는 상태 뒤에 숨어 있었다(보존 등식은 손실을 세지 흡수를 세지 않는다).
|
||||
|
||||
---
|
||||
|
||||
@@ -274,7 +275,7 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
|
||||
### 3.1 전체 작업 DAG
|
||||
|
||||
`task_procedure`는 통합본 3,269–3,304행에 있다(3,305행은 공백, 스테이지 층 `prevs`/`nexts`는 3,306–3,307행이다). 노드 8개(IN · task 6 · OUT), edge 오류 0. Part 1과 달리 **완전 직렬**이다 — A0가 fan-out 계획을 낸 뒤에야 worker 인스턴스가 생기기 때문이다. 추가 개정 4회는 노드도 edge도 늘리지 않았다.
|
||||
`task_procedure`는 통합본 3,277–3,312행에 있다(3,313행은 공백, 스테이지 층 `prevs`/`nexts`는 3,314–3,315행이다). 노드 8개(IN · task 6 · OUT), edge 오류 0. Part 1과 달리 **완전 직렬**이다 — A0가 fan-out 계획을 낸 뒤에야 worker 인스턴스가 생기기 때문이다. 추가 개정 5회는 노드도 edge도 늘리지 않았다.
|
||||
|
||||
```
|
||||
┌────────┐
|
||||
@@ -282,7 +283,7 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
└───┬────┘
|
||||
▼
|
||||
P2-A0 Task_C_BO_A0_context_and_domain_slice_compiler code · timeout 300
|
||||
⓪ assert_deployment — 필수 자산 9 리터럴 + 모듈 미러를 한 벌로 검사(실측 17건)
|
||||
⓪ assert_deployment — 필수 자산 10 리터럴 + 모듈 미러를 한 벌로 검사(실측 18경로)
|
||||
· 하나라도 없거나 해시가 다르면 PART2_ASSET_DEPLOYMENT_INCOMPLETE 로 선다
|
||||
· 슬라이스 스키마 능력 검사(PART2_SLICE_SCHEMA_STALE)
|
||||
· 컴파일러 산출 검사(PART2_COMPILER_STALE — 서명 불일치도 같은 코드)
|
||||
@@ -304,10 +305,13 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
│
|
||||
▼ wait_until: ["all Task_C_B_domain_worker_*"] ← barrier · 정확 일치
|
||||
P2-R0 Task_C_BO_R0_seed_reducer_and_exception_planner code · timeout 240
|
||||
try 밖에서 seed 스키마와 검증기 미러를 먼저 검사(_verify_asset · _assert_mirror_consistent)
|
||||
기대집합 대조(누락·초과·중복 전부 실패) → 후보 식별자 해석(ensure_candidate_ref)
|
||||
try 밖에서 seed 스키마·검증기 미러·투영 정책을 먼저 검사(_verify_asset ·
|
||||
_assert_mirror_consistent · 정책 판본 불일치는 PART2_PROJECTION_POLICY_INVALID)
|
||||
기대집합 대조(누락·초과·중복 전부 실패) → 후보 식별자 부여(ensure_candidate_ref)
|
||||
→ membership 대조(provenance 3갈래 + v3 의 평평한 source_refs)
|
||||
→ seed 검증 → 도메인 라벨 해석(_domain_label) → ledger · pack · review_handoff
|
||||
→ seed 검증(status 5종 정책 + 계획 행 slice_sha256·compiled_prompt_sha256 대조)
|
||||
→ registry 근거 투영(project_to_bo_surface — 투영본은 별도 보관, seed 파일은 읽기만)
|
||||
→ ledger · pack · review_handoff (구판의 worker seed 되쓰기는 삭제됐다)
|
||||
│
|
||||
▼ 조건부 — exception_count == 0 이면 통과만 (R1_SKIPPED)
|
||||
P2-R1 Task_C_BO_R1_exception_adjudicator LLM · max_iterations 1
|
||||
@@ -315,6 +319,7 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
│
|
||||
▼
|
||||
P2-F0 Task_C_BO_F0_final_bo_compiler_gate_writer code · timeout 240
|
||||
폴백 어휘는 registry 합집합(bo_types_union) · 정규화는 notes 에 적고 handoff 에도 올린다
|
||||
→ BO.json · postb_compiled_bundle_compact.json · review_handoff FINALIZED 갱신
|
||||
│
|
||||
▼
|
||||
@@ -330,12 +335,12 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
|
||||
| # | task 명칭 | 실행기 / 설정 | 작업 목적 | 작업 내역 |
|
||||
|---|---|---|---|---|
|
||||
| P2-A0 | `Task_C_BO_A0_context_and_domain_slice_compiler` | code-executor · timeout 300 · 통합본 60–716행 | Part 1의 봉인된 산출을 받아 **도메인별 작업 재료를 컴파일하고 fan-out을 계획**한다 | 모듈 8종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `registry_validator` · `prompt_compiler` · `domain_slice_compiler` · `domain_fanout_planner` · `stage_a_context_builder`)을 미러로 반입한다. 봉인 3해시를 검증한다. registry 26 config를 적재한다. `prompt_compiler.collect_domain_fragments(extra_specs=…)`로 Part 1의 어휘 사전을 도메인 프롬프트에 붙인다(조립 프롬프트 6,967 B → 24,942 B 실측). 슬라이스에 `domain_declarations` 7갈래를 투영한다. 스크리닝의 `candidates[].requested_calculation_domains`를 파싱해 도메인 `calculation_bindings`와 교집합하고, 교집합 밖은 `CALC_NOT_IN_BINDINGS` 리뷰로 남기며 `router_status`를 `READY_WITH_REVIEW`로 내린다. **도메인 상수를 두지 않는다**. 추가 개정 1회차로 `main()` 첫 문장이 `assert_deployment()`가 되었다 — 필수 자산 9 리터럴과 모듈 미러를 **한 벌로** 검사해(실측 17건) 하나라도 빠지거나 해시가 어긋나면 `PART2_ASSET_DEPLOYMENT_INCOMPLETE`로 세운다. 이어 슬라이스 스키마가 `domain_declarations`와 `compiled_prompt.hash_kind`를 아는지 보고(`PART2_SLICE_SCHEMA_STALE`), 컴파일러 산출에 투영이 실제로 실려 나오는지 본다(`PART2_COMPILER_STALE` — 옛 판본은 알 수 없는 인자로 `TypeError`가 먼저 나므로 같은 코드에 `detail: signature_mismatch`를 붙인다). 프롬프트 오버레이 실패 4코드를 승격 대상으로 강제한다 |
|
||||
| P2-B | `Task_C_B_domain_worker_*` | LLM `google / gemini-3.1-flash-lite` · reasoning high · verbosity medium · `max_concurrency: 8` · cache 15m · preflight 2 · 통합본 717–846행 | 단일 도메인의 **BO seed 후보**를 만든다 | 읽는 것은 두 파일뿐 — 조립 프롬프트와 슬라이스. **프롬프트를 다시 조립하지 않는다.** 산출 최상위는 `stage_b_domain_bo_seed_output` 한 키, `schema_version`은 `task_c_bo_stage_b_domain_bo_seed.v3` 고정. 다섯 배열(`element_fact_candidates` · `opposing_fact_candidates` · `defense_candidates` · `calculation_requests` · `dependency_refs`) 이름은 스키마가 정한 것이다. `dependency_refs`는 연결만 남기고 의존 도메인의 결론을 복사하지 않는다. 자기검증 6항(최상위 단일 키, `domain_id`·`task_instance_id` 주입값 일치, `source_refs` ⊆ slice source_universe, `bo_type` ∈ `allowed_legal_effect_bo_types`, `registry_component_ids` ⊆ 합집합, 금지 키 `BO_ID`·`Evidence`·`EvidenceTitles`·`final_*` 부재). **결론을 내리지 않는다 — 후보만 남긴다** |
|
||||
| P2-R0 | `Task_C_BO_R0_seed_reducer_and_exception_planner` | code-executor · timeout 240 · 통합본 847–1,823행 | worker 산출 M개를 **결정론으로 합치고 예외를 좁힌다** | fan-out 계획의 기대집합과 실제 seed 집합을 **정확 일치**로 대조한다(누락·초과·중복 모두 실패). 모듈 4종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `worker_output_validator`)을 반입해 `validate_worker_output`을 **실제로 호출**한다. 슬라이스의 `domain_declarations`로 두 대조를 걸어 `CALCULATION_DOMAIN_NOT_DECLARED`와 `EVIDENCE_SLOT_NOT_DECLARED`를 **review 등급**으로 남긴다. 산출은 넷이다 — seed ledger · 예외 pack · review handoff, 그리고 **worker seed 파일 M개를 제자리에서 다시 쓴다**(`transport_metadata`와 `handoff_guard`를 주입한다. 경로는 fan-out 계획의 `expected_output_path`). 추가 개정으로 넷이 더 붙었다 — ① seed 스키마와 검증기 미러 검사를 **`try` 밖**에서 먼저 한다(안에 두면 swallow-all 이 삼킨다) ② 도메인 라벨을 슬라이스 → 구 이름 표 → ID 순으로 해석한다(`_domain_label`. 개정 전에는 구 이름 다섯 개짜리 표를 대괄호로 조회해 registry ID 마다 `KeyError`였다) ③ v3 봉인 스키마가 `candidate_ref`를 금지하므로 R0가 순번에서 만든다(`ensure_candidate_ref`. 형식 검사는 도메인에 묶지 않고 접두사 검사가 도메인 일치를 맡는다) ④ v3의 평평한 `source_refs`를 Stage A universe 와 대조한다(이 검사가 없으면 v3 산출에서 membership 게이트가 통과만 하는 빈 검사가 된다) |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | LLM · reasoning low · verbosity low · `max_iterations: 1` · cache 20m · preflight 1 · 통합본 1,824–1,926행 | R0이 non-deferrable로 판정한 **compact exception만 판정**한다 | pack 하나만 읽는다. 병합·최종 파일 작성·사실 창작을 하지 않는다. v3 3,621–3,723행과 바이트 동일(추가 개정 4회에서도 손대지 않았다) |
|
||||
| P2-F0 | `Task_C_BO_F0_final_bo_compiler_gate_writer` | code-executor · timeout 240 · 통합본 1,927–2,677행 | **최종 `BO.json`을 확정**하고 게이트를 쓴다 | PostB_3(final compiler) + PostB_4(final gate/writer) 통합. 입력은 전부 파일 계약(ledger · decisions · stage_a)이다. BOType 어휘를 하드코딩하지 않고 **registry 합집합**에서 해시 검증과 함께 만든다. 확장 payload 키를 `extension_payload_key_declarations.v1.json`과 대조해 미선언 키는 `EXTENSION_PAYLOAD_KEY_UNDECLARED`로 남긴다. R1 산출은 **조건부**로 요구한다(pack의 `exception_count`가 0이면 부재 허용) |
|
||||
| P2-S0 | `Task_C_BO_S0_signal_bundle_writer` | code-executor · timeout 300 · 통합본 2,678–3,268행 | **정본 signal 거래 1건**을 기록한다 | 생성기·사영기·기록기를 여기서 만들지 않는다. 조립본 모듈 24종을 반입한다 — compiler 7(`common` · `projections` · `schema_validator` · `signal_compiler` · `signal_gate` · `transaction_writer` · `writer_boundary`) + adapter 4(`s3_domain_seed_adapter` · `s3_envelope_migration_adapter` · `s4_calculation_adapter` · `sg01_activation_adapter`) + emitter 13(`emitter_runtime` + `emit_sg02`~`emit_sg13`). 정본 기록기가 유일한지 검사한다(`S0_CANONICAL_WRITER_NOT_UNIQUE`). `transaction_id`는 `^S5TX-[a-f0-9]{20}$`. 슬라이스의 `emits_signals` 선언과 실제 방출을 대조해 선언 밖 방출은 `SIGNAL_EMISSION_NOT_DECLARED`로 남긴다(**선언보다 적게 나오는 것은 정상**이므로 그 방향은 세지 않는다). 기록 후 `signal_manifest.json`을 다시 읽어 해시 왕복 일치를 확인한다. 추가 개정으로 `signal_registry.v2.json` · `s5_execution_contract.v2.json` · `$ref` 폐포가 닿는 signal 스키마 17종을 `_verify_asset`으로 읽으면서 매니페스트 해시와 대조한다 |
|
||||
| P2-A0 | `Task_C_BO_A0_context_and_domain_slice_compiler` | code-executor · timeout 300 · 통합본 60–717행 | Part 1의 봉인된 산출을 받아 **도메인별 작업 재료를 컴파일하고 fan-out을 계획**한다 | 모듈 8종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `registry_validator` · `prompt_compiler` · `domain_slice_compiler` · `domain_fanout_planner` · `stage_a_context_builder`)을 미러로 반입한다. 봉인 3해시를 검증한다. registry 26 config를 적재한다. `prompt_compiler.collect_domain_fragments(extra_specs=…)`로 Part 1의 어휘 사전을 도메인 프롬프트에 붙인다(조립 프롬프트 6,967 B → 24,942 B 실측). 슬라이스에 `domain_declarations` 7갈래를 투영한다. 스크리닝의 `candidates[].requested_calculation_domains`를 파싱해 도메인 `calculation_bindings`와 교집합하고, 교집합 밖은 `CALC_NOT_IN_BINDINGS` 리뷰로 남기며 `router_status`를 `READY_WITH_REVIEW`로 내린다. **도메인 상수를 두지 않는다**. 추가 개정 1회차로 `main()` 첫 문장이 `assert_deployment()`가 되었다 — 필수 자산 10 리터럴과 모듈 미러를 **한 벌로** 검사해(실측 18경로 — 다섯째 회차가 BO 투영 정책 자산을 목록에 더했다) 하나라도 빠지거나 해시가 어긋나면 `PART2_ASSET_DEPLOYMENT_INCOMPLETE`로 세운다. 이어 슬라이스 스키마가 `domain_declarations`와 `compiled_prompt.hash_kind`를 아는지 보고(`PART2_SLICE_SCHEMA_STALE`), 컴파일러 산출에 투영이 실제로 실려 나오는지 본다(`PART2_COMPILER_STALE` — 옛 판본은 알 수 없는 인자로 `TypeError`가 먼저 나므로 같은 코드에 `detail: signature_mismatch`를 붙인다). 프롬프트 오버레이 실패 4코드를 승격 대상으로 강제한다 |
|
||||
| P2-B | `Task_C_B_domain_worker_*` | LLM `google / gemini-3.1-flash-lite` · reasoning high · verbosity medium · `max_concurrency: 8` · cache 15m · preflight 2 · 통합본 718–847행 | 단일 도메인의 **BO seed 후보**를 만든다 | 읽는 것은 두 파일뿐 — 조립 프롬프트와 슬라이스. **프롬프트를 다시 조립하지 않는다.** 산출 최상위는 `stage_b_domain_bo_seed_output` 한 키, `schema_version`은 `task_c_bo_stage_b_domain_bo_seed.v3` 고정. 다섯 배열(`element_fact_candidates` · `opposing_fact_candidates` · `defense_candidates` · `calculation_requests` · `dependency_refs`) 이름은 스키마가 정한 것이다. `dependency_refs`는 연결만 남기고 의존 도메인의 결론을 복사하지 않는다. 자기검증 6항(최상위 단일 키, `domain_id`·`task_instance_id` 주입값 일치, `source_refs` ⊆ slice source_universe, `bo_type` ∈ `allowed_legal_effect_bo_types`, `registry_component_ids` ⊆ 합집합, 금지 키 `BO_ID`·`Evidence`·`EvidenceTitles`·`final_*` 부재). **결론을 내리지 않는다 — 후보만 남긴다** |
|
||||
| P2-R0 | `Task_C_BO_R0_seed_reducer_and_exception_planner` | code-executor · timeout 240 · 통합본 848–1,793행 | worker 산출 M개를 **결정론으로 합치고 예외를 좁힌다** | fan-out 계획의 기대집합과 실제 seed 집합을 **정확 일치**로 대조한다(누락·초과·중복 모두 실패). 모듈 4종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `worker_output_validator`)을 반입해 `validate_worker_output`을 **실제로 호출**한다. 슬라이스의 `domain_declarations`로 두 대조를 걸어 `CALCULATION_DOMAIN_NOT_DECLARED`와 `EVIDENCE_SLOT_NOT_DECLARED`를 **review 등급**으로 남긴다. 산출은 셋이다 — seed ledger · 예외 pack · review handoff. **worker seed 파일은 읽기만 하고 다시 쓰지 않는다** — 구판의 제자리 재기록(`transport_metadata`·`handoff_guard` 주입)은 다섯째 회차에서 삭제됐고, 되쓰기와 함께 고아가 된 `_domain_label` · `DOMAIN_LABELS` · `_task_instance_id` · `digest_summary` 도 걷어냈다(R0 의 구 이름 B1~B5 의존 0). 앞 회차의 보강 — `try` 밖 자산 선검사 · `ensure_candidate_ref`(v3 봉인 스키마가 `candidate_ref`를 금지하므로 R0 가 순번에서 만든다) · v3 의 평평한 `source_refs` membership 대조 — 은 그대로다. 다섯째 회차의 처방은 다섯이다 — ① 투영 정책 자산을 `_verify_asset`으로 경성 반입한다(미등재·해시 불일치는 `PART2_ASSET_DEPLOYMENT_INCOMPLETE`, 판본 불일치는 `PART2_PROJECTION_POLICY_INVALID`) ② registry 근거 투영기 `project_to_bo_surface`가 v3 후보를 BO 호환면으로 투영한다 — 반환 키 **17개 고정**(입력 무관), registry 가 말하지 않는 칸은 만들지 않고 review 로 올린다. 투영본은 `projected_candidates`에 **별도 보관**하고 원장 루프가 그것을 읽는다(`seed_objects`는 worker 원본 유지). v2 잔재 `expand_candidate` · `_seed_payload` · `ALLOWED_SEED_KEYS` · `DOMAIN_PAYLOAD_CANON` · `_canon_payload` 는 제거 — 병합·정렬·예외 축소 헬퍼 7종(`_source_refs` · `_duplicate_key` · `_sort_key` · `_normalize_juristic` · `_compact_exception_payload` · `ensure_candidate_ref` · `validate_candidate`)은 한 줄도 고치지 않았다 ③ 검토 채널을 v3 두 키(후보별 `review_items` + 루트 `unknown_or_unrouted_reviews`)로 연결하고, 원본 `review_code`를 덧붙이기 키 `source_review_code`로, `reason`을 handoff `template_note`로 보존한다 ④ `validate_seed_object`가 status 를 v3 enum 5종 전체로 다룬다 — READY 계열 수용, `NO_SUPPORT`는 빈 후보 조건으로 수용 + review, `BLOCKED` · `FAILED` · enum 밖은 경성 중단 ⑤ 죽은 `slice_guard` 검사를 fan-out 계획 행의 `slice_sha256` · `compiled_prompt_sha256` ↔ worker echo 대조로 교체한다(`_seed_docs_from_plan`이 계획 행을 함께 보관). 파생 정합 하나 — 원장 flag 판정의 `{"event","state"}` 하드코딩도 슬라이스의 `allowed_legal_effect_bo_types`(registry 선언)로 교체됐다 |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | LLM · reasoning low · verbosity low · `max_iterations: 1` · cache 20m · preflight 1 · 통합본 1,794–1,896행 | R0이 non-deferrable로 판정한 **compact exception만 판정**한다 | pack 하나만 읽는다. 병합·최종 파일 작성·사실 창작을 하지 않는다. v3 3,621–3,723행과 바이트 동일(추가 개정 5회에서도 손대지 않았다) |
|
||||
| P2-F0 | `Task_C_BO_F0_final_bo_compiler_gate_writer` | code-executor · timeout 240 · 통합본 1,897–2,685행 | **최종 `BO.json`을 확정**하고 게이트를 쓴다 | PostB_3(final compiler) + PostB_4(final gate/writer) 통합. 입력은 전부 파일 계약(ledger · decisions · stage_a)이다. BOType 어휘를 하드코딩하지 않고 **registry 합집합**에서 해시 검증과 함께 만든다. 확장 payload 키를 `extension_payload_key_declarations.v1.json`과 대조해 미선언 키는 `EXTENSION_PAYLOAD_KEY_UNDECLARED`로 남긴다. R1 산출은 **조건부**로 요구한다(pack의 `exception_count`가 0이면 부재 허용). 다섯째 회차의 처방 둘 — ① 폴백 판정의 `bo_type not in {"event","state"}` 하드코딩을 registry 합집합 `bo_types`(5종)로 교체했다. `claim` · `communication` · `calculation_request` 를 선언한 도메인의 값이 `event`로 **침묵 덮어쓰기**되던 자리이며, 이제 빌드 루프와 검증 루프의 어휘가 같다 ② `_load_projection_policy`로 투영 정책을 반입해(`_load_declarations`와 같은 규율 — `runtime_manifest` sha 대조 후에만 사용) 정규화 기본값을 정책에서 읽고, `normalization_notes` 각 항목을 review handoff 의 `review_items`에도 올린다(`issue_type: schema_field_fallback` + `source_review_code`). Action 대체 체인(seed.Action → action_summary → Action_proposal)은 방어선으로 유지된다 |
|
||||
| P2-S0 | `Task_C_BO_S0_signal_bundle_writer` | code-executor · timeout 300 · 통합본 2,686–3,275행 | **정본 signal 거래 1건**을 기록한다 | 생성기·사영기·기록기를 여기서 만들지 않는다. 조립본 모듈 24종을 반입한다 — compiler 7(`common` · `projections` · `schema_validator` · `signal_compiler` · `signal_gate` · `transaction_writer` · `writer_boundary`) + adapter 4(`s3_domain_seed_adapter` · `s3_envelope_migration_adapter` · `s4_calculation_adapter` · `sg01_activation_adapter`) + emitter 13(`emitter_runtime` + `emit_sg02`~`emit_sg13`). 정본 기록기가 유일한지 검사한다(`S0_CANONICAL_WRITER_NOT_UNIQUE`). `transaction_id`는 `^S5TX-[a-f0-9]{20}$`. 슬라이스의 `emits_signals` 선언과 실제 방출을 대조해 선언 밖 방출은 `SIGNAL_EMISSION_NOT_DECLARED`로 남긴다(**선언보다 적게 나오는 것은 정상**이므로 그 방향은 세지 않는다). 기록 후 `signal_manifest.json`을 다시 읽어 해시 왕복 일치를 확인한다. 추가 개정으로 `signal_registry.v2.json` · `s5_execution_contract.v2.json` · `$ref` 폐포가 닿는 signal 스키마 17종을 `_verify_asset`으로 읽으면서 매니페스트 해시와 대조한다. 다섯째 회차에서는 배포 처방 문구(`PART2_DEPLOYMENT_REMEDY`)만 A0·R0 와 함께 배포 원본 `extension_research/Default_Agent` 기준으로 현행화됐다 |
|
||||
|
||||
**모듈의 디렉터리 산술** — S0은 signal 모듈들이 `_SIGNALS_ROOT.parents[1]/contracts/s5_execution_contract.v2.json`을 읽는다는 실측 사실에 맞춰 staging 배치를 재현한다(`/tmp/s1/_sig/contracts/` + `/tmp/s1/_sig/pkg/signals/`). 모듈을 고치면 미러 해시가 깨지므로 배치로 맞춘 것이다.
|
||||
|
||||
@@ -343,11 +348,11 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
|
||||
| # | task | IN | OUT |
|
||||
|---|---|---|---|
|
||||
| P2-A0 | `Task_C_BO_A0_…slice_compiler` | **Part 1 산출 6종** — `quality_gates/stage1_part1_soft_gate_handoff.json` · `routing/domain_activation_manifest.json` · `routing/domain_screening.json` · `evidence_indexed.json` · `evidence_event_candidates.json` · `routing/candidate_profile_vocabulary.md` + **사건 입력** `client_meeting.md` (md) + **자산** `runtime_manifest.json` · `domains/_registry_index.json` · `domains/_common/common_worker_contract.md` · `domains/<id>/domain_config.json` ×26 · `domains/<id>/seed_prompt_overlay.md` (config의 `prompt_overlay_ref`가 지목) · `stage1_runtime/prompt_composition_policy.json` · `platform/schemas/domain_slice.schema.v2.json` · `platform/schemas/domain_fanout_plan.schema.json` + 모듈 미러 8종(`.txt`) + **배포 게이트가 존재·해시만 확인하는 자산 5종**(`domain_seed_output.schema.v3.json` · `signals/signal_registry.v2.json` · `contracts/signals/s5_execution_contract.v2.json` · `routing/extension_payload_key_declarations.v1.json` · `stage1_runtime/worker_output_validator.txt` — 하류 R0·F0·S0 이 쓸 것을 A0 가 미리 본다) | `runtime/domain_slices/<domain_id>.json` (json ×M, `task_c_bo_stage_b_domain_slice.v2`, 루트 키 `stage_b_domain_slice`) · `runtime/compiled_prompts/<domain_id>.md` (md ×M) · `fanout/domain_fanout_plan.json` (json, `domain_fanout_plan.v1`) · `stage1_tmp/task_c_bo/stage_a_context.json` (json, 루트 `stage_a_context`) · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) · `validation_assets/routing/stage_receipt.json` (json, `stage1_stage_receipt.v2`) |
|
||||
| P2-A0 | `Task_C_BO_A0_…slice_compiler` | **Part 1 산출 6종** — `quality_gates/stage1_part1_soft_gate_handoff.json` · `routing/domain_activation_manifest.json` · `routing/domain_screening.json` · `evidence_indexed.json` · `evidence_event_candidates.json` · `routing/candidate_profile_vocabulary.md` + **사건 입력** `client_meeting.md` (md) + **자산** `runtime_manifest.json` · `domains/_registry_index.json` · `domains/_common/common_worker_contract.md` · `domains/<id>/domain_config.json` ×26 · `domains/<id>/seed_prompt_overlay.md` (config의 `prompt_overlay_ref`가 지목) · `stage1_runtime/prompt_composition_policy.json` · `platform/schemas/domain_slice.schema.v2.json` · `platform/schemas/domain_fanout_plan.schema.json` + 모듈 미러 8종(`.txt`) + **배포 게이트가 존재·해시만 확인하는 자산 6종**(`domain_seed_output.schema.v3.json` · `signals/signal_registry.v2.json` · `contracts/signals/s5_execution_contract.v2.json` · `routing/extension_payload_key_declarations.v1.json` · `stage1_runtime/worker_output_validator.txt` · `stage1_runtime/bo_surface_projection_policy.v1.json` — 하류 R0·F0·S0 이 쓸 것을 A0 가 미리 본다) | `runtime/domain_slices/<domain_id>.json` (json ×M, `task_c_bo_stage_b_domain_slice.v2`, 루트 키 `stage_b_domain_slice`) · `runtime/compiled_prompts/<domain_id>.md` (md ×M) · `fanout/domain_fanout_plan.json` (json, `domain_fanout_plan.v1`) · `stage1_tmp/task_c_bo/stage_a_context.json` (json, 루트 `stage_a_context`) · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) · `validation_assets/routing/stage_receipt.json` (json, `stage1_stage_receipt.v2`) |
|
||||
| P2-B | `Task_C_B_domain_worker_*` | `{{item.compiled_prompt_path}}` (md) · `{{item.slice_path}}` (json) — **둘뿐** | `{{item.expected_output_path}}` = `runtime/domain_seed_outputs/<domain_id>.json` (json, `task_c_bo_stage_b_domain_bo_seed.v3`) |
|
||||
| P2-R0 | `Task_C_BO_R0_…exception_planner` | `fanout/domain_fanout_plan.json` · `runtime/domain_slices/<id>.json` ×M · `runtime/domain_seed_outputs/<id>.json` ×M · `stage1_tmp/task_c_bo/stage_a_context.json` · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) + 자산 `platform/schemas/domain_seed_output.schema.v3.json` · `runtime_manifest.json` + 모듈 미러 4종 · **선언만 하고 읽지 않는 상수 2개**(`ACTIVATION_MANIFEST_PATH` · `REGISTRY_INDEX_PATH` — 각각 대입 1회뿐이고 read 0회). 추가 개정으로 seed 스키마와 검증기 미러는 `_verify_asset`이 **매니페스트 해시와 대조하며** 읽는다 | `stage1_tmp/task_c_bo/postb_seed_ledger.json` (json) · `quality_gates/stage1_part2_exception_pack.json` (json) · `quality_gates/stage1_part2_review_handoff.json` (json) · **`runtime/domain_seed_outputs/<domain_id>.json` (json ×M, 제자리 갱신 재기록 — `transport_metadata` + `handoff_guard` 주입)** |
|
||||
| P2-R0 | `Task_C_BO_R0_…exception_planner` | `fanout/domain_fanout_plan.json` · `runtime/domain_slices/<id>.json` ×M · `runtime/domain_seed_outputs/<id>.json` ×M · `stage1_tmp/task_c_bo/stage_a_context.json` · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) + 자산 `platform/schemas/domain_seed_output.schema.v3.json` · `stage1_runtime/bo_surface_projection_policy.v1.json`(판본까지 검사) · `runtime_manifest.json` + 모듈 미러 4종 · **선언만 하고 읽지 않는 상수 2개**(`ACTIVATION_MANIFEST_PATH` · `REGISTRY_INDEX_PATH` — 각각 대입 1회뿐이고 read 0회). 추가 개정으로 seed 스키마와 검증기 미러는 `_verify_asset`이 **매니페스트 해시와 대조하며** 읽는다 | `stage1_tmp/task_c_bo/postb_seed_ledger.json` (json) · `quality_gates/stage1_part2_exception_pack.json` (json) · `quality_gates/stage1_part2_review_handoff.json` (json) — **셋뿐이다.** 구판의 worker seed 제자리 재기록은 다섯째 회차에서 삭제됐고, seed 파일은 worker 가 쓴 바이트 그대로 남는다 |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | `quality_gates/stage1_part2_exception_pack.json` (json, preflight) | `stage1_tmp/task_c_bo/postb_adjudication_decisions.json` (json, **조건부**) |
|
||||
| P2-F0 | `Task_C_BO_F0_…gate_writer` | `stage1_tmp/task_c_bo/stage_a_context.json` · `postb_seed_ledger.json` · `postb_adjudication_decisions.json`(조건부) · `quality_gates/stage1_part2_review_handoff.json` · `stage1_part2_exception_pack.json` (json) + 자산 `routing/extension_payload_key_declarations.v1.json` · `runtime_manifest.json` | **`BO.json`** (json) · `stage1_tmp/task_c_bo/postb_compiled_bundle_compact.json` (json) · `quality_gates/stage1_part2_review_handoff.json` (json, `FINALIZED`로 **갱신 재기록** — R0과 공동 기록자) |
|
||||
| P2-F0 | `Task_C_BO_F0_…gate_writer` | `stage1_tmp/task_c_bo/stage_a_context.json` · `postb_seed_ledger.json` · `postb_adjudication_decisions.json`(조건부) · `quality_gates/stage1_part2_review_handoff.json` · `stage1_part2_exception_pack.json` (json) + 자산 `routing/extension_payload_key_declarations.v1.json` · `stage1_runtime/bo_surface_projection_policy.v1.json`(`_load_projection_policy` — 매니페스트 sha 대조 후 사용) · `runtime_manifest.json` | **`BO.json`** (json) · `stage1_tmp/task_c_bo/postb_compiled_bundle_compact.json` (json) · `quality_gates/stage1_part2_review_handoff.json` (json, `FINALIZED`로 **갱신 재기록** — R0과 공동 기록자) |
|
||||
| P2-S0 | `Task_C_BO_S0_signal_bundle_writer` | `BO.json` · `routing/domain_activation_manifest.json` · `fanout/domain_fanout_plan.json` · `stage1_tmp/task_c_bo/source_universe_manifest.json` · `runtime/domain_slices/<id>.json` ×M (json) + 자산 `signals/signal_registry.v2.json` · `contracts/signals/s5_execution_contract.v2.json` · `runtime_manifest.json` + 모듈 미러 24종 | `signals/…` 아래 정본 signal 집합 — `signals/signal_manifest.json` 포함 + 호환 뷰 3종 `signals/compatibility_views/{actio_case,case_liability,legal_effect}_signals.json` + **루트 별칭 3종** `actio_case_signals.json` · `case_liability_signals.json` · `legal_effect_signals.json` (구 이름 호환면, 같은 바이트) |
|
||||
|
||||
### 3.4 upstream–downstream 연결 — 이유 · 방식 · 자료 사용 방식
|
||||
@@ -360,21 +365,21 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
| P2-A0 → P2-B (프롬프트·슬라이스) | worker가 프롬프트를 **다시 조립하면** 도메인마다 다른 프롬프트가 나온다. 조립 권한을 A0 하나로 모았다 | **runtime parameter 주입** — `{{item.compiled_prompt_path}}` · `{{item.slice_path}}` · `{{item.domain_id}}` · `{{item.task_instance_id}}` · `{{item.slice_sha256}}` · `{{item.compiled_prompt_sha256}}` · `{{item.expected_output_path}}`. 둘은 preflight 화이트리스트이기도 하다 | worker는 두 파일만 읽는다. 자기 산출에 `slice_sha256`·`compiled_prompt_sha256`을 주입값 그대로 실어 사후 대조가 가능하게 한다 |
|
||||
| P2-A0 → P2-B (인스턴스 생성) | fan-out 인스턴스 수와 이름을 **계획 파일이** 정한다. YAML에는 도메인 상수가 없다 | `fanout/domain_fanout_plan.json`의 `task_instances[]`(각 원소가 `domain_id`와 `expected_output_path`를 갖는다) + 그래프 와일드카드 `Task_C_B_domain_worker_*` | 활성 도메인 수 M이 곧 인스턴스 수다. `max_concurrency: 8`로 동시 실행을 제한한다 |
|
||||
| P2-A0 → P2-R0 · P2-S0 (슬라이스 재사용) | 슬라이스는 **worker의 입력이면서 동시에 검증의 기준표**다 | 파일 계약 — `runtime/domain_slices/<domain_id>.json` | R0은 슬라이스의 `domain_declarations`로 worker 산출 어휘를 대조한다. S0은 같은 슬라이스의 `emits_signals` 선언으로 방출을 대조한다. **두 소비자가 같은 파일의 다른 블록을 읽는다** |
|
||||
| P2-B → P2-R0 | 후보 M개가 **전부** 도착한 뒤에만 합칠 수 있다. 하나라도 빠지면 도메인 커버리지가 조용히 줄어든다 | 집계 토큰 `wait_until: ["all Task_C_B_domain_worker_*"]` — **barrier** | R0은 fan-out 계획의 기대집합과 실제 집합을 정확 일치로 본다. 누락·초과·중복 전부 실패다. seed는 정적 이름이 아니라 계획의 `expected_output_path`로 읽는다 |
|
||||
| P2-B → P2-R0 | 후보 M개가 **전부** 도착한 뒤에만 합칠 수 있다. 하나라도 빠지면 도메인 커버리지가 조용히 줄어든다 | 집계 토큰 `wait_until: ["all Task_C_B_domain_worker_*"]` — **barrier** | R0은 fan-out 계획의 기대집합과 실제 집합을 정확 일치로 본다. 누락·초과·중복 전부 실패다. seed는 정적 이름이 아니라 계획의 `expected_output_path`로 읽는다 — 그리고 **읽기만** 한다. 구판의 제자리 재기록은 다섯째 회차에서 삭제됐고 worker 산출은 인터페이스 원본으로 보존된다 |
|
||||
| P2-R0 → P2-R1 | LLM 판정은 **좁혀진 예외에만** 건다(Part 1 T6 → T7과 같은 GB 패턴) | 파일 계약 + preflight — `quality_gates/stage1_part2_exception_pack.json` | pack의 `exception_count`가 R1 산출의 필수 여부를 정한다. 0이면 R1은 통과만 하고 `R1_SKIPPED`로 남는다 |
|
||||
| P2-R0 → P2-F0 | 최종 컴파일의 입력은 **파일 계약**이어야 재현된다. 메모리 전달을 쓰지 않는다 | 파일 계약 3종 — `postb_seed_ledger.json` · `stage1_part2_review_handoff.json` · `stage1_part2_exception_pack.json` | F0은 ledger를 BO 레코드로 컴파일하고, review handoff를 `FINALIZED`로 갱신해 다시 쓴다(공동 기록자) |
|
||||
| P2-R0 → P2-F0 | 최종 컴파일의 입력은 **파일 계약**이어야 재현된다. 메모리 전달을 쓰지 않는다 | 파일 계약 3종 — `postb_seed_ledger.json` · `stage1_part2_review_handoff.json` · `stage1_part2_exception_pack.json` | F0은 ledger 의 후보 payload — R0 투영기가 만든 **17키 고정 투영본** — 를 BO 레코드로 컴파일하고, review handoff를 `FINALIZED`로 갱신해 다시 쓴다(공동 기록자) |
|
||||
| P2-R1 → P2-F0 | 예외 판정 결과가 최종 BO에 반영되어야 한다 | 파일 계약 — `postb_adjudication_decisions.json` (**조건부**) | `exception_count > 0`이면 부재가 실패, `== 0`이면 부재를 허용한다 |
|
||||
| P2-F0 → P2-S0 | signal 거래는 **확정된 BO 위에서만** 기록할 수 있다 | 파일 계약 — `BO.json` | S0은 BO 레코드를 seed 어댑터에 물려 정본 signal을 생성하고, 기록 후 매니페스트 해시 왕복을 확인한다. `BO.json`은 최대 호환면이므로 **레코드 구조를 바꾸지 않는다** |
|
||||
| P2-S0 → Part 3 · Part 4 · Stage 2 | 하류가 읽을 **정본 집합을 선언**해 둔다 | `signals/signal_manifest.json`의 `downstream_read_sets` | 현재 Part 3·4는 구 이름 3종(`actio_case_signals.json` 등)을 읽고 있고, 정본 집합으로의 이관은 Part 3·4 개정의 몫으로 남아 있다. 그래서 S0이 루트 별칭 3종을 같은 바이트로 함께 쓴다 |
|
||||
|
||||
### 3.5 Part 2 작업용 assets — 정확한 배포 위치
|
||||
|
||||
YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다(추가 개정 4회에서 리터럴 수는 늘지 않았다 — 늘어난 것은 같은 자산을 검사하는 지점이다). 아래 크기는 전부 **정본 조립본** 기준이며, 후보 오버레이는 이제 조립본의 바이트 동일 부분집합이라 두 뿌리 값이 같다(§5.1).
|
||||
YAML이 참조하는 `Default_Agent/…` 자산은 **21개 리터럴**이다(다섯째 회차가 투영 정책 자산 하나를 더했다 — 앞 네 회차는 리터럴 수를 늘리지 않았다). 아래 크기는 전부 **배포 원본 `extension_research/Default_Agent` 트리** 실측이다(§5.1 — 이 회차부터 실행이 읽는 정본 트리다).
|
||||
|
||||
| 배포 경로 (`Default_Agent/` 기준) | 크기 | 형태 | 쓰는 task | 역할 |
|
||||
|---|---|---|---|---|
|
||||
| `domains/_registry_index.json` | 18,921 B | json | A0 | registry 색인. 봉인 대조 대상. (R0에도 경로 상수가 있으나 읽지 않는다) |
|
||||
| `domains/_common/common_worker_contract.md` | 3,451 B | md | A0 | 공통 worker 계약문. 사건 종류 이름을 라우팅 키로 쓰지 않는다는 규율을 여기서 선언한다 |
|
||||
| `domains/_common/common_worker_contract.md` | **3,766 B** | md | A0 | 공통 worker 계약문. 사건 종류 이름을 라우팅 키로 쓰지 않는다는 규율을 여기서 선언한다. 다섯째 회차가 출력 규칙 한 문장을 더했다 — 검토는 v3 두 키(`review_items` · `unknown_or_unrouted_reviews`)로만 보내고 `domain_review_queue`(오버레이에 남은 구 이름)는 금지, 방어 후보의 정본 키는 `defense_candidates`. rank 10 계약이 rank 30 오버레이를 이기므로 오버레이 25건 · 색인 · Part 1 봉인은 전부 바이트 무변이다 |
|
||||
| `domains/<id>/domain_config.json` ×26 | — | json | A0 | 8선언 가문 원문 (`element_slots` · `opposing_fact_slots` · `evidence_components` · `defense_map` · `calculation_bindings` · `emits_signals` · `structure_types` · `effect_projection`) |
|
||||
| `domains/<id>/seed_prompt_overlay.md` | — | md | A0 | 도메인 오버레이 산문. **파일명을 하드코딩하지 않고** config의 `prompt_overlay_ref`가 지목하는 것을 따른다 |
|
||||
| `platform/schemas/domain_slice.schema.v2.json` | **17,725 B** | json | A0 | 슬라이스 닫힌 스키마. 개정 내용 셋 — ① `domain_declarations` 블록 추가(패턴 7개 신규) ② `compiled_prompt.hash_kind` 추가 ③ 기존 패턴 1개 교체(`domain_registry.special_law_profiles.items`). 조립본 대비 패턴 자리 26 → 34이며 삭제된 자리는 없다. §6.5가 BLOCKER로 적은 `emits_signals`의 `anyOf`는 기존 패턴 교체가 아니라 **신규 블록 안에서 개정 중 교정한 것**이다 |
|
||||
@@ -382,10 +387,11 @@ YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다(추
|
||||
| `platform/schemas/domain_seed_output.schema.v3.json` | 21,965 B | json | R0 · (B 프롬프트가 이름으로 지목) | worker 산출 스키마 |
|
||||
| `routing/evidence_component_union.md` | 17,593 B | md | (B 프롬프트가 이름으로 지목) | 증거 구성요소 합집합 어휘 |
|
||||
| `routing/extension_payload_key_declarations.v1.json` | 23,071 B | json | F0 | 확장 payload 키 선언표(`stage1_extension_payload_key_declarations.v1`) |
|
||||
| `runtime_manifest.json` | **58,046 B · 370항** | json | A0 · R0 · F0 · S0 | 모듈 미러 sha256 선언표. A0 의 배포 게이트가 `runtime_artifact_count`와 자기 sha256 을 영수증에 적는다 |
|
||||
| `runtime_manifest.json` | **58,211 B · 371항** | json | A0 · R0 · F0 · S0 | 반입 자산 sha256 선언표. 다섯째 회차 델타 정확히 2 — 정책 1행 추가 + 공통 계약 1행 sha 교체. A0 의 배포 게이트가 `runtime_artifact_count`와 자기 sha256 을 영수증에 적는다 |
|
||||
| `signals/signal_registry.v2.json` | 10,907 B | json | S0 | signal 13종 registry |
|
||||
| `contracts/signals/s5_execution_contract.v2.json` | 1,451 B | json | S0 | 실행 계약. 모듈이 `_SIGNALS_ROOT.parents[1]/contracts/` 아래에서 찾는다 |
|
||||
| `stage1_runtime/prompt_composition_policy.json` | 1,715 B | json | A0 | 프롬프트 조립 정책. sha256을 fan-out row에 기록 |
|
||||
| `stage1_runtime/bo_surface_projection_policy.v1.json` | **6,355 B** | json | R0 · F0 (A0 게이트가 선검사) | **신설(다섯째 회차).** v3 seed 후보를 BO 호환면으로 투영하는 규칙 선언(`stage1_bo_surface_projection_policy.v1`) — 값의 정본은 registry 이고, registry 가 말하지 않는 칸은 만들지 않고 review 로 올린다는 원칙을 코드 밖에 둔다. status 정책 · 출처 3분할 · 필드 규칙 11 · 미투영 선언 · review 투영(덧붙이기 키 `source_review_code` · `action_source`) · F0 정규화(ActionType enum 5값) |
|
||||
|
||||
**반입 모듈 — `stage1_runtime/` (`.py` 정본 + 바이트 동일 `.txt` 미러 쌍)**
|
||||
|
||||
@@ -396,7 +402,7 @@ YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다(추
|
||||
| `registry_loader` | 6,404 B | A0 · R0 · (D0) | registry 적재 |
|
||||
| `registry_validator` | 11,080 B | A0 | registry 검증 |
|
||||
| `prompt_compiler` | 15,164 B | A0 | 프롬프트 조립. `collect_domain_fragments(extra_specs=…)` 훅 |
|
||||
| `domain_slice_compiler` | **32,300 B** | A0 | 슬라이스 컴파일. 개정으로 `_declaration_ids` · `_domain_declarations` 추가. 라벨의 정본은 이 모듈이 `label_ko`를 `stage_b_domain_slice.domain_label`에 실어 보내는 자리다(R0 의 `_domain_label`이 그것을 읽는다) |
|
||||
| `domain_slice_compiler` | **32,300 B** | A0 | 슬라이스 컴파일. 개정으로 `_declaration_ids` · `_domain_declarations` 추가. 라벨의 정본은 이 모듈이 `label_ko`를 `stage_b_domain_slice.domain_label`에 실어 보내는 자리다(구판 R0 의 `_domain_label`이 이것을 읽었으나, 그 유일 소비처였던 되쓰기와 함께 다섯째 회차에서 제거됐다 — 라벨은 슬라이스에 남아 하류가 그대로 쓸 수 있다) |
|
||||
| `domain_fanout_planner` | 12,282 B | A0 | fan-out 계획 |
|
||||
| `stage_a_context_builder` | 25,885 B | A0 | v3 A0의 `_build_meeting_clause_map` · `_build_event_candidate_map` · `_build_evidence_authority_map`를 원문 그대로 옮기고 `attach_registry_component_ids`(C-1)와 `build_stage_a_context` / `build_source_universe_manifest`를 더한 신설 모듈 |
|
||||
| `worker_output_validator` | **21,302 B** | R0 | worker 산출 검증. 개정으로 `domain_declarations` 기반 대조 2종 추가(서명 불변). A0 의 배포 게이트가 이 모듈의 `.txt` 미러를 R0 대신 미리 확인한다 |
|
||||
@@ -409,7 +415,7 @@ YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다(추
|
||||
| `Default_Agent/signals/adapters/` | `s3_domain_seed_adapter` · `s3_envelope_migration_adapter` · `s4_calculation_adapter` · `sg01_activation_adapter` | 4 |
|
||||
| `Default_Agent/signals/emitters/` | `emitter_runtime` + `emit_sg02` … `emit_sg13` | 13 |
|
||||
|
||||
**Part 2 개정이 함께 만든 검증·예행 자산**(런타임 입력이 아니다).
|
||||
**Part 2 개정이 함께 만든 검증·예행 자산**(런타임 입력이 아니다). 이 표의 자산은 배포 원본이 아니라 **조립본 `선행구축/Default_Agent_Stage_1/`** 트리에 있다 — 배포 원본 트리는 실행 자산 155건만 담는다(§5.1).
|
||||
|
||||
| 배포 경로 (`Default_Agent/` 기준) | 크기 | 형태 | 역할 |
|
||||
|---|---|---|---|
|
||||
@@ -424,7 +430,7 @@ YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다(추
|
||||
| `validation_assets/replay/_promote_seed_v2_to_v3.py` + `.txt` | — | py + 미러 | 구 seed 판본 승격기 |
|
||||
| `validation_assets/replay/_dry_run_stage1.py` + `.txt` | — | py + 미러 | 예행 실행기. `httpx.Client.post`를 대역해 실제 MCP 배관을 태운다 |
|
||||
| `validation_assets/replay/replay_manifest.v1.json` | — | json | 산출물별 출처 표기 (`case_input` / `v3_actual_output` / `replay_stub`) |
|
||||
| `validation_assets/replay/dry_run_receipt.v1.json` | **16,772 B** | json | 예행 영수증. 추가 개정으로 **시험 13건**(배포 게이트 회귀 R-a~R-i + 라벨 해석 + seed 보강 R-j~R-l)과 2패스 사슬 기록 `part2_full_chain`을 담는다 |
|
||||
| `validation_assets/replay/dry_run_receipt.v1.json` | **16,772 B** | json | 예행 영수증. 추가 개정으로 **시험 13건**(배포 게이트 회귀 R-a~R-i + 라벨 해석 + seed 보강 R-j~R-l)과 2패스 사슬 기록 `part2_full_chain`을 담는다. 다섯째 회차(BO 투영) 실측의 영수증 정본화는 이월돼 있다(§6.6 D) |
|
||||
| `routing/_build_extension_payload_declarations.py` + `.txt` | 8,842 B | py + 미러 | 확장 payload 키 선언표 생성기 |
|
||||
| **`validation_assets/replay/_build_domain_seed_v4_stub.py` + `.txt`** | 12,403 B | py + 미러 | **신설.** 활성 도메인의 seed 후보를 슬라이스의 `domain_declarations`와 Stage A 출처 목록에서 **규칙으로** 만든다. 사건 이름도 사실관계도 짓지 않으므로 137종 어느 사건이든 같은 규칙으로 선다. 이미 후보가 있는 seed 는 건드리지 않는다 |
|
||||
|
||||
@@ -479,54 +485,47 @@ Part 1이 만들어 **Part 2가 읽는** 파일은 여섯이다.
|
||||
| `evidence_shards/E-###.json` · `evidence_indexed_parts/E-###.json` · `evidence_event_candidate_parts/E-###.json` | Part 1 내부 fan-out 중간물. 소비자가 전부 Part 1 안에 있다 | 설계상 정합 |
|
||||
| **`client_goal.json`** | T1의 최종 산출이고 Part 1 밖(Part 3 이후)에서 읽힌다 | **선언표 미포함.** T1이 사슬의 끝이고 Part 2 소비자가 없어 표에 오르지 않았으나, Stage 1 전체 인계면으로 보면 빠진 줄이다. 선언표 갱신 후보 |
|
||||
| `signals/` 아래 정본 signal 개별 파일 (SG-02~SG-13 계열) | S0 산출 | 표에는 `signals/signal_manifest.json`과 구 이름 호환 3종만 오른다. 하류가 매니페스트의 `downstream_read_sets`를 읽는 구조이므로 정합이지만, Part 3·4 이관이 끝나면 개별 정본도 선언 후보 |
|
||||
| **`client_meeting.md`의 소비자 목록** | `entry_inputs[0].consumer_tasks`가 Part 1 다섯 task만 적는다 | **누락.** Part 2 A0가 `read_raw(MEETING)`로 직접 읽는데(통합본 515행) 소비자로 선언되어 있지 않다. 선언표 갱신 후보 |
|
||||
| **`runtime/domain_seed_outputs/<domain_id>.json`의 공동 기록자** | 생산자가 `Task_C_B_domain_worker_*` 하나로만 선언되어 있다 | **누락.** R0이 같은 경로를 제자리에서 다시 쓴다(§3.3). 표의 `conventions`에 `also_written_by` 항목이 있으므로 그 자리에 R0을 적어야 한다. 선언표 갱신 후보 |
|
||||
| **`client_meeting.md`의 소비자 목록** | `entry_inputs[0].consumer_tasks`가 Part 1 다섯 task만 적는다 | **누락.** Part 2 A0가 `read_raw(MEETING)`로 직접 읽는데(현행 통합본 642행) 소비자로 선언되어 있지 않다. 선언표 갱신 후보 |
|
||||
| **`runtime/domain_seed_outputs/<domain_id>.json`의 공동 기록자** | 생산자가 `Task_C_B_domain_worker_*` 하나로만 선언되어 있다 | **해소(2026-08-19).** R0 의 제자리 재기록이 다섯째 회차에서 삭제되어 단일 생산자 선언이 실측과 일치하게 됐다 — 선언표를 고치는 대신 코드가 선언표로 돌아온 경우다 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 자산 배포 지형
|
||||
|
||||
### 5.1 한 뿌리로 합쳐졌다
|
||||
### 5.1 배포 원본이 옮겨졌다
|
||||
|
||||
앞 판본은 자산이 **두 곳**에 있고 역할이 다르다고 적었다. 2026-08-18 회차에서 그 상태가 정리됐다.
|
||||
앞 판본은 정본 조립본 하나가 실제 배포 트리라고 적었다. 2026-08-19 회차에서 **실행이 읽는 배포 원본이 `extension_research/Default_Agent/` 트리로 확정**됐다 — 대응표 문서 `stage_1_2_assets_distfolder_location.md`(43,419 B)가 이 트리를 만들었고, 명세서 3곳(A0·R0·S0)의 `PART2_DEPLOYMENT_REMEDY` 문구가 이 트리를 배포 원본으로 지목한다. 뿌리는 이제 셋이고 역할이 다르다.
|
||||
|
||||
| 뿌리 | 경로 | 파일 수 | 지금의 역할 |
|
||||
|---|---|---|---|
|
||||
| **정본 조립본** | `v.7/extension_research/선행구축/Default_Agent_Stage_1/` | **1,322** | 런타임이 `Default_Agent/`로 보는 실제 배포 트리. 실행이 읽는 것은 여기 하나뿐이다 |
|
||||
| **후보 오버레이** | `v.7/extension_research/ver_8_yaml_candidates/Default_Agent_Stage_1/` | **560** | 개정 산출물을 배포 경로 그대로 두는 자리(제약 [2]). 지금은 조립본의 **바이트 동일 부분집합**이다 |
|
||||
| **배포 원본** | `v.7/extension_research/Default_Agent/` | **155** | 런타임이 `Default_Agent/`로 보는 실제 배포 트리. Part 1·2 실행이 읽는 자산 전부이자 **그것만** 담는다 |
|
||||
| 정본 조립본 | `v.7/extension_research/선행구축/Default_Agent_Stage_1/` | 1,322 | 재생성 원천 — 빌더·장부·검증/예행 하네스·계산기·법령판 등 Stage 1 전 계열. 다섯째 회차 산출이 아직 반영되지 않아 **세 파일이 낡았다**(아래) |
|
||||
| 후보 오버레이 | `v.7/extension_research/ver_8_yaml_candidates/Default_Agent_Stage_1/` | 560 | 개정 전 조립본의 부분집합으로 남은 확인용 사본(현재 559 동일 · 1 상이 — 빌더만 다섯째 회차의 조립본 내 수정을 안 따라갔다). 지위 정리는 이월(§6.6 D) |
|
||||
|
||||
**델타 30건은 한 벌로 반영됐다.** 반영 직전 실측으로 후보 558건이 세 갈래로 갈렸다 — **바이트 동일 528 · 내용 상이 7 · 후보에만 23**. 상이 7 은 스키마 1 + 모듈 4(`.py`/`.txt` 쌍 둘) + 매니페스트 2 이므로, 반영 대상은 **신규 23 + 변경 5 + 매니페스트 2 = 30건 · 712,193 B** 이다(같은 7건을 어느 쪽으로 세느냐의 차이일 뿐 대상은 하나다), 덮어써질 조립본 원본 7건을 `outdated/_assembly_pre_delta/`에 보존한 뒤 **한 번의 반복문 안에서** 통째로 옮겼다. 부분 복사가 성립할 여지를 두지 않기 위해 목록을 먼저 확정하고 통째로 옮기는 순서를 지켰다.
|
||||
**배포 원본 155 = 실행이 읽는 자산 154 + 신규 투영 정책 1.** 154 는 두 YAML 의 자산 리터럴에 폐포 — 색인이 지목하는 `domain_config.json` 26 · config 가 지목하는 오버레이 조각 26(EC-00 은 `common_fragment.md`) · signal registry 의 `$ref` 폐포 스키마 17 — 와 모듈 미러(`stage1_runtime/` 10 · `signals/` 24, 각 `.py`+`.txt` 쌍)를 더해 센 값이다(대응표 문서 154행 실측). 형태 분포는 `.json` 58 · `.md` 29 · `.py` 34 · `.txt` 34 다.
|
||||
|
||||
반영 후 대조는 **동일 558 · 상이 0 · 부재 0**이다. 이후 회차가 더한 두 자산(`_build_domain_seed_v4_stub.py`와 그 미러)까지 양쪽에 같은 경로로 두어, 현재 후보 560건은 전부 조립본과 바이트가 같다.
|
||||
|
||||
**그래서 §6.2 검사 10의 각주가 바뀐다.** 앞 판본은 "자산 실재 · 미존재 0"이 후보 오버레이 기준으로만 참이라고 적었다. 지금은 **정본 조립본 기준으로도 참**이며, 실증으로 `--asset-root`를 조립본 폴더 자체로 겨눈 예행이 통과한다(§6.4). 앞 판본이 "남은 것은 복사 한 단계"라고 적은 그 한 단계가 실행됐다.
|
||||
|
||||
**두 뿌리 체제가 남긴 것 하나** — 후보 오버레이를 지워도 실행에는 무방하다(조립본이 상위집합이므로). 다만 지워도 되는 것은 오버레이 `Default_Agent_Stage_1/` 한 겹이고, 그 **상위 폴더** `ver_8_yaml_candidates/`에는 작업명세서 본체와 개별 task yaml 이 들어 있어 함께 지우면 실행할 명세가 사라진다.
|
||||
**조립본이 배포 원본보다 낡은 곳은 정확히 세 파일이다** — 투영 정책 자산 부재, `common_worker_contract.md` 구 바이트(3,451 B · sha `9f03fb3a…`), `runtime_manifest.json` 370항(58,046 B). 반대로 조립본 안에서 앞서 간 것도 하나 있다 — 빌더는 제자리 수정(뿌리 6→10)됐는데 조립본 자신의 `release_manifest`가 그것을 아직 옛 바이트로 적고 있다(§5.3 · §6.2 검사 18). 다섯째 회차 지시가 "생성 자산은 `extension_research/Default_Agent` 에만 저장"이어서 조립본 반영은 의도적으로 이월됐고(§6.6 D), Part 2 실행 정합성에 무영향임은 검증자가 배포 원본 단독 재실행으로 실증했다(§6.4). 후보 오버레이를 지워도 실행에 무방하다는 앞 판본의 관찰은 그대로 유효하되 이유가 바뀌었다 — 실행이 읽는 것이 조립본도 후보도 아닌 배포 원본이기 때문이다. 오버레이의 **상위 폴더** `ver_8_yaml_candidates/`에 작업명세서 본체가 들어 있다는 경고도 그대로다.
|
||||
|
||||
### 5.2 미러 규약 실측
|
||||
|
||||
| 뿌리 | `.py` | 미러 존재·해시 일치 | 미러 없음 | 해시 불일치 |
|
||||
|---|---|---|---|---|
|
||||
| 정본 조립본 | **112** | **111** | 1 (`tools/build_default_agent_stage1.py` — 선언된 예외) | **0** |
|
||||
| 후보 오버레이 | **16** | **15** | 1 (같은 빌더) | **0** |
|
||||
| **배포 원본** | **34** | **34** (stage1_runtime 10 · signals 24) | 0 | **0** |
|
||||
| 정본 조립본 | 112 | 111 | 1 (`tools/build_default_agent_stage1.py` — 선언된 예외) | 0 |
|
||||
| 후보 오버레이 | 16 | 15 | 1 (같은 빌더) | 0 |
|
||||
|
||||
후보 오버레이에는 `.py` 없이 `.txt`만 있는 파일이 97개다. 정본 `.py`는 이미 조립본에 있고 개정이 새로 만든 것은 **미러뿐**인 경우가 그렇다(Part 1 델타 522의 `.txt` 미러 100).
|
||||
배포 원본에는 `.py` 없는 고아 `.txt` 가 없다 — `.txt` 34 전부가 `.py` 34 의 바이트 동일 형제다.
|
||||
|
||||
파일 형태 분포: 후보 오버레이 `.json` 431 · `.txt` 112 · `.py` 16 · `.md` 1 = 560. 정본 조립본 `.json` 1,051 · `.py` 112 · `.txt` 112 · `.md` 40 · `.whl` 6 · `.yml` 1 = 1,322. **조립본의 `.pyc` 3과 `__pycache__` 는 사라졌다**(앞 판본 §6.2 검사 20의 잔여 항목이었다).
|
||||
|
||||
### 5.3 매니페스트 3종
|
||||
### 5.3 매니페스트
|
||||
|
||||
| 매니페스트 | 값 | 성격 |
|
||||
|---|---|---|
|
||||
| `release_manifest.json` | **248,002 B · 1,320항** | 조립 전체 산출물 선언 (`stage1_assembly_release_manifest.v1`). 미선언은 둘 — 자기 자신과 `stage1_runtime/Stage_1_Registry_Runtime_v1.yml` |
|
||||
| `runtime_manifest.json` | **58,046 B · 370항** | 런타임 반입 모듈 sha256 선언 (`.py`와 `.txt`가 같은 해시를 선언해야 한다) |
|
||||
| `source_copy_map.json` | **2,128,630 B · `copy_rows` 1,158 · `source_dispositions` 5,961** | 복사 계보 (`stage1_source_copy_map.v1`) |
|
||||
| **배포 원본 `runtime_manifest.json`** | **58,211 B · 371항** | 반입 자산 sha256 선언표의 현행 정본. 다섯째 회차 델타 정확히 2 — 투영 정책 1행 추가 + 공통 계약 1행 sha 교체(직렬화 왕복 보존 확인). 등재 371 중 **배포 트리에 실재하는 94건은 전수 해시 일치 · 불일치 0**이고, 나머지 277건(계산기 205 · 법령판 63 · tools 4 · platform/router 3 · 기타 2)은 Part 1·2 실행이 반입하지 않는 모듈로 전부 조립본에 실재한다 — 이 매니페스트가 Stage 1 전 계열의 상위 장부이기 때문이다 |
|
||||
| 조립본 `runtime_manifest.json` | 58,046 B · 370항 | 다섯째 회차 델타 2 미반영 (이월 §6.6 D) |
|
||||
| 조립본 `release_manifest.json` | 248,002 B · **1,320항** | 조립 전체 산출물 선언 (`stage1_assembly_release_manifest.v1`). 빌더 제자리 수정(뿌리 6→10) 미반영으로 **불일치 1**(그 빌더 자신) — 정책·계약 반영과 함께 1,321 재생성이 이월돼 있다(D-2) |
|
||||
| 조립본 `source_copy_map.json` | `copy_rows` **1,158** | 복사 계보 (`stage1_source_copy_map.v1`). 같은 이월 |
|
||||
|
||||
셋 다 양 뿌리에서 **바이트 동일**이고, 앞의 둘은 조립본 전수 해시·크기 대조에서 표류 0이다.
|
||||
|
||||
**`source_copy_map` 은 이제 빌더가 실제로 만들 수 있는 것을 적는다.** 앞 판본 시점에는 이 표가 델타를 따라오지 못했다 — 신규 23건에 행이 없었고, 변경된 두 모듈은 표에 적힌 해시가 **반영 전** 값이었으며 원천 `S_1_GPT_v2/`도 옛 바이트를 쥐고 있었다. 그 상태에서 빌더를 돌리면 재생성에 실패하는 데 그치지 않고 두 모듈을 옛 판으로 되돌리려다 `EXISTING_TARGET_BYTE_CONFLICT`에서 섰다. 세 번째 회차가 상류 두 모듈을 조립본 내용으로 맞추고, 빌더에 조립본 작성 자산 15건을 `ASSEMBLY_ROOT` 앵커로 등록했으며(나머지 8건은 미러 규칙이 자동 생성), 네 번째 회차가 `copy_platform()`의 이름 패턴을 `*.schema*.json`으로 넓혀 판본이 붙은 스키마 둘을 마저 등록했다.
|
||||
|
||||
빈 target 신선 빌드 기준 파일 수는 891 → 893(스키마 2건) → **895**(seed 대역 생성기)로 늘었다. 다만 신선 빌드는 **아직 조립본을 재현하지 못한다**(895 vs 1,322). 결손의 대부분은 스크립트가 만들어 내는 137종 라우팅 회귀 픽스처 411건이며, 그 복사 규칙을 지금 빌더가 잃은 상태다(§6.6).
|
||||
빌더 `generate_runtime_manifest()`의 뿌리는 다섯째 회차에서 **6 → 10**이 됐다(`platform/schemas` · `contracts/signals` · `domains/_common` · `routing` 추가). 신선 생성 시뮬레이션은 395항 — 현행 370항의 진상위집합(결손 0 · 신규 25)이고, 정책 자산이 조립본에 반영되면 396이 된다(M-l 완전판, 이월). 신선 빌드가 조립본 전체를 재현하지 못하는 상태(895 vs 1,322 — 결손 대부분은 137종 라우팅 회귀 픽스처 411건)는 앞 판본 그대로다(§6.6 A).
|
||||
|
||||
## 6. 검증 상태
|
||||
|
||||
@@ -545,7 +544,7 @@ Part 1이 만들어 **Part 2가 읽는** 파일은 여섯이다.
|
||||
|
||||
조립 중 잡힌 오류 하나를 기록해 둔다. 첫 조립본은 `tasks:`와 `task_procedure:`가 각각 여섯 벌로 나왔다. 독립 스테이지 파일에서는 `task_procedure:`가 `tasks:`보다 **먼저** 나오므로 슬라이스 시작 행 추출의 첫 매치가 `task_procedure` 행이 되어, 각 조각이 자기 그래프와 `tasks:` 헤더까지 끌고 들어온 것이다. YAML은 파싱에 성공했다 — 같은 층 중복 키는 뒤엣것이 이기므로 조용히 통과한다. **구문 통과는 조립 정합의 증거가 아니고, 중복 키를 잡는 것은 파서가 아니라 선언 계수 검사다.**
|
||||
|
||||
### 6.2 Part 2 — 검사 20항 (전부 통과) + 추가 개정 회귀 13종
|
||||
### 6.2 Part 2 — 검사 20항 (19 통과 · 검사 18 은 조립본 장부 불일치 1 — 이월 D-2) + 추가 개정 회귀 13종 + BO 투영 회귀 M-a~M-r
|
||||
|
||||
| # | 검사 | 결과 |
|
||||
|---|---|---|
|
||||
@@ -553,19 +552,19 @@ Part 1이 만들어 **Part 2가 읽는** 파일은 여섯이다.
|
||||
| 2 | `task_name` ↔ 노드 1:1 | task 6 / 노드 6 · 차집합 0 |
|
||||
| 3 | 선언 1벌 | 각 1 |
|
||||
| 4 | DAG edge 정합 | 노드 8 · 오류 0 |
|
||||
| 5 | R1이 v3와 바이트 동일 | True (통합본 1,824–1,926행) |
|
||||
| 5 | R1이 v3와 바이트 동일 | True (통합본 1,794–1,896행 — 다섯째 회차 뒤 재확인) |
|
||||
| 6 | code-executor `parameters` 5키 | 위반 0 |
|
||||
| 7 · 8 · 9 | 구 slice 경로 · 구 seed 경로 · 정적 worker 이름(주석 외) | 0 · 0 · 0 |
|
||||
| 10 | `Default_Agent/…` 자산 실재 | 미존재 0 — **이제 정본 조립본 기준으로도 참**이다(§5.1). A0 의 배포 게이트가 매 실행마다 17건을 실측한다 |
|
||||
| 10 | `Default_Agent/…` 자산 실재 | 미존재 0 — 기준 트리는 이제 **배포 원본 `extension_research/Default_Agent`**다(§5.1). A0 의 배포 게이트가 매 실행마다 18경로를 실측한다 |
|
||||
| 11 | 계약 키 존재 | `domain_declarations` · `calculation_domains` · `emits_signals` · `candidate_profile_vocabulary` · `requested_calculation_domains` 전부 |
|
||||
| 12 | embedded python | AST 실패 0 · 미정의 이름 0 · 미사용 def 1(`clip`, v3 원문) |
|
||||
| 13 | 인계면 전수 대조 | PASS · finding 0 |
|
||||
| 14 | 스키마 미지원 키워드 | PASS · 3/3 |
|
||||
| 15 | 개별 6종 ↔ 통합본 | 불일치 0 (추가 개정 뒤 재대조 — R0 코드 본문 967행 양쪽 동일) |
|
||||
| 15 | 개별 6종 ↔ 통합본 | 불일치 0 (다섯째 회차 뒤 재대조 — P2-A0·R0·F0·S0 4종을 통합본 블록과 동기화한 뒤 블록 동일 재확인. R0 블록 946행) |
|
||||
| 16 | 26 도메인 전수 compile (스키마 주입) | READY / slice_count 26 / 스키마 실패 0 |
|
||||
| 17 | `calculation_registry` · `computations/` 참조 | 0 · 0 |
|
||||
| 18 | `release_manifest` 전수 해시·크기 | **1,320항** · 불일치 0 |
|
||||
| 19 | `runtime_manifest` 전수 해시 | **370항** · 불일치 0 |
|
||||
| 18 | `release_manifest` 전수 해시·크기 | **1,320항** · 불일치 **1** — `tools/build_default_agent_stage1.py`(장부 102,559 B vs 실물 102,997 B). 다섯째 회차의 빌더 제자리 수정(뿌리 6→10)이 조립본 장부에 미반영된 흔적으로, 이월 D-2 의 재생성 대상이다 |
|
||||
| 19 | `runtime_manifest` 전수 해시 | **371항**(배포 원본 정본) — 배포 트리 실재 등재 94건 전수 해시 일치 · 불일치 0. 조립본 370항 갱신은 이월(§5.3) |
|
||||
| 20 | `__pycache__` · `.pyc` | **양 뿌리 0 · 0.** 앞 판본이 잔여로 적은 조립본 `.pyc` 3개는 이후 회차에서 격리 폴더로 옮겨져 사라졌다 |
|
||||
|
||||
**추가 개정 4회가 세운 회귀 13종** — `validation_assets/replay/dry_run_receipt.v1.json`(16,772 B)의 `deployment_gate_regression.tests` 에 기록돼 있다. 변종마다 고정 스테이징 경로 `/tmp/s1` 과 `/tmp/s1_r0` 을 먼저 지운다(앞 시험이 남긴 사본이 다음 판정을 바꾼다 — 실제로 한 번 겪었고 영수증 `staging_note` 에 적었다).
|
||||
@@ -588,6 +587,26 @@ Part 1이 만들어 **Part 2가 읽는** 파일은 여섯이다.
|
||||
|
||||
R-b 와 R-g2 는 **장부 검사와 의미 검사가 서로 다른 실패를 잡는다**는 것을 보이려고 넣은 짝이다. 자산과 매니페스트 항목이 함께 옛 값으로 돌아가면 해시 대조는 전부 통과한다 — 그때 무는 것은 스키마가 무엇을 아는지 보는 검사(입력 쪽)와 컴파일러 산출에 투영이 실려 나오는지 보는 검사(출력 쪽)다.
|
||||
|
||||
**다섯째 회차(BO 투영)가 세운 회귀 — 관측점 M-a~M-r.** 함수 원문을 구판(백업본)과 신판에서 각각 꺼내 같은 v3 준수 후보에 적용하는 before/after 재현, 배포 게이트 시뮬레이션, 예행 실측(§6.4)으로 구성된다.
|
||||
|
||||
| 관측점 | 개정 전 (실측) | 개정 후 (실측) |
|
||||
|---|---|---|
|
||||
| M-a 이질 후보 둘의 중복 키 | 동일 `((),(),None,None,None,'','','')` — 전량 한 버킷 | 상이 — 분리 유지 |
|
||||
| M-b 원장 payload 의 worker 유래 값 | `extensions` 하나 | BOType · JuristicAct · Legal_Keywords · BehaviorTime · amount · registry_component_ids 전부 |
|
||||
| M-c 출처 3분할 (provenance) | 3갈래 전부 빈 배열 | Stage A universe 교집합 실값 |
|
||||
| M-d 버킷 수 (중복 아닌 후보 2) | 1 (전량 병합) | 2 |
|
||||
| M-e claim 선언 도메인의 BOType | 키 탈락 → `event` 침묵 폴백 | `claim` 유지 |
|
||||
| C-4 meeting_only 오발 | 전건 발화 | 불발 (`registry_component_ids` 도달) |
|
||||
| M-q status 5종 | 적법한 `NO_SUPPORT` 가 경성 중단 | READY 계열 수용 · `NO_SUPPORT` 빈 후보 수용+review · `BLOCKED`/`FAILED` 경성 |
|
||||
| M-r `slice_sha256` 변조 | 통과 (대조 부재) | stale seed 경성 중단 |
|
||||
| 투영 반환 키 집합 | 입력 따라 유동 | **17키 고정** (입력 무관) |
|
||||
| M-i·M-j 배포 게이트 | — | 정상 18경로 PASS · 정책 미등재 음성 → `PART2_ASSET_DEPLOYMENT_INCOMPLETE`(unregistered 가 정확히 그 경로 하나) · 정책 판본 변조 → `PART2_PROJECTION_POLICY_INVALID` |
|
||||
| M-l 신선 매니페스트 | 뿌리 6 (진부분집합) | 뿌리 10 → 395항 ⊇ 현행 370 (결손 0 · 신규 25) |
|
||||
| M-h worker seed 보존 | 재기록으로 v3 이탈 (구 B-3) | **3종 바이트 무변** |
|
||||
| M-n 결정론 | — | pass2 재실행 산출 전부 바이트 동일 (signal 번들 포함) |
|
||||
| M-o 음성 | — | `BLOCK: X1.X1:001: source_refs outside Stage A universe: ['E-999']` |
|
||||
| M-p near-dup 클러스터 | 값이 전부 비어 클러스터 불성립 | `near_duplicate_kept_separate` 3건 첫 생성. amount 충돌 관측은 함수층 재현 — 스텁 seed 에 충돌 값이 없어 예행 0건이 정답 |
|
||||
|
||||
### 6.3 registry 26 도메인 선언 투영 실측
|
||||
|
||||
Part 2 개정의 핵심 수치다. 26 도메인 `domain_config.json`을 전수로 투영한 결과다.
|
||||
@@ -604,39 +623,30 @@ Part 2 개정의 핵심 수치다. 26 도메인 `domain_config.json`을 전수
|
||||
|
||||
빈 넷은 구조적으로 옳다 — EC-00은 공통층이라 반대사실·항변·구조유형이 없고, E-00은 잔여 수집기라 계산이 없다.
|
||||
|
||||
### 6.4 예행 — 2패스 9단계 (실입력)
|
||||
### 6.4 예행 — 2패스 9단계 (실입력 · asset root = 배포 원본)
|
||||
|
||||
`client_meeting.md` 10,850 B · `evidence_all.json` 87,436 B를 물려 `_dry_run_stage1.py`로 돌린다. 앞 판본은 6단계였고, 지금은 **A0 뒤에 seed 대역 생성을 끼운 2패스**다. 실행 루트 하나를 이어 쓴다.
|
||||
`client_meeting.md` 10,850 B · `evidence_all.json` 87,436 B를 물려 `_dry_run_stage1.py`로 돌린다. 구성은 앞 판본과 같은 **2패스 9단계**이되, 이번 회차부터 `--asset-root` 가 **배포 원본 `extension_research/Default_Agent` 트리**다(하네스·재생 세트·대역 생성기는 조립본 `validation_assets/replay/`에서 온다).
|
||||
|
||||
| 패스 | 내용 | 결과 |
|
||||
|---|---|---|
|
||||
| pass1 | Part 1 코드 task 5종 + Part 2 A0 | **PASS · 6단계 · 기록 45건** |
|
||||
| (사이) | `_build_domain_seed_v4_stub.py` — 활성 도메인 seed 대역 | written 3 (X1·X2·X3) · skipped [] · 인용 출처 [E-001, E-002] |
|
||||
| pass2 | Part 2 R0 · F0 · S0 | **PASS · 3단계 · 기록 32건** |
|
||||
| pass1 | Part 1 코드 task 5종 + Part 2 A0 (18경로 배포 게이트 포함) | **PASS · 6단계 · 기록 45건** |
|
||||
| (사이) | `_build_domain_seed_v4_stub.py` — 활성 도메인 seed 대역 | written 3 (X1·X2·X3) |
|
||||
| pass2 | Part 2 R0 · F0 · S0 | **PASS · 3단계 · 기록 29건** |
|
||||
|
||||
| 단계 | 결과 | 기록 수 |
|
||||
|---|---|---|
|
||||
| `Task_A0_domain_screener_02` | READY_WITH_REVIEW | 1 |
|
||||
| `Task_A0_domain_screener_03` | READY | 1 |
|
||||
| `Task_Evidence_shard_planner` | 성공 | 31 |
|
||||
| `Task_D0_domain_activation_gate` | READY_WITH_REVIEW | 1 |
|
||||
| `Task_B2_SHA256_soft_gate_handoff_writer` | SOFT_GATE_HANDOFF_WRITTEN | 1 |
|
||||
| `Task_C_BO_A0_context_and_domain_slice_compiler` | **READY** | 10 |
|
||||
| `Task_C_BO_R0_seed_reducer_and_exception_planner` | **완주** | pass2 합 32 |
|
||||
| `Task_C_BO_F0_final_bo_compiler_gate_writer` | **완주** | 〃 |
|
||||
| `Task_C_BO_S0_signal_bundle_writer` | **완주** | 〃 |
|
||||
pass2 기록 수가 구판 32 → **29**로 준 것은 되쓰기 3건(worker seed 재기록)이 사라진 정확한 흔적이다. 완주 여부만이 아니라 **산출물을 값 수준으로** 검사한 것이 이 회차 예행의 핵심이다.
|
||||
|
||||
pass2 세 줄의 "완주"는 하네스가 실패로 세지 않았다는 뜻이며(영수증 `part2_code_task_completion` 이 넷 다 PASS 로 적는다), 각 task 가 스스로 낸 상태는 별개다 — R0 `READY` · F0 `PASS` · S0 `READY_WITH_REVIEW`(호환 뷰가 비어 `COMPATIBILITY_VIEW_EMPTY` 리뷰 둘이 달린다). pass1 여섯 줄 가운데 다섯은 각 task 가 낸 상태 그대로이고, `Task_Evidence_shard_planner` 한 줄만 다르다 — 이 task 는 `status` 를 내지 않고 `planner_status: READY` 를 낸다. 표의 "성공"은 하네스가 실패로 세지 않았다는 뜻이다.
|
||||
|
||||
**Part 2 의 코드 task 넷이 모두 완주한 것은 이 회차가 처음이다.** 앞 판본 시점에는 A0 하나만 돌았고, F0 는 예행 영수증에 이름이 오른 적조차 없었다. 산출로 `BO.json` 과 `signals/` 아래 signal 번들이 실제로 생겼다. Part 2 의 나머지 둘(`Task_C_B_domain_worker_*` · `Task_C_BO_R1_exception_adjudicator`)은 코드 블록이 없는 LLM task 라 하네스가 구조상 건너뛴다 — seed 와 무관하다.
|
||||
|
||||
**무엇이 막고 있었나.** "seed 재료가 없다"는 진단은 절반이었다. seed 파일 자체는 승격 스크립트가 이미 모든 도메인에 쓰고 있었고 비어 있던 것은 **후보**였다(구 이름 실산출 B1~B5 를 별칭표가 보내는 곳은 E-02·E-03·E-04·E-10·E-11·E-13·E-15 일곱인데 예행 활성은 X1·X2·X3 이라 겹치는 것이 없다). 후보를 채우자 다음 층이 드러났다 — R0 의 `CANDIDATE_REF_RE` 가 `^B[1-5]:[0-9]{3}$` 인데 같은 함수가 도메인 접두사도 요구해서 **registry ID 26종 어느 것으로도 동시에 만족될 수 없었다.** 게다가 v3 seed 스키마는 루트와 후보 모두 `additionalProperties: false` 로 봉인돼 있어 워커가 `candidate_ref` 를 실을 방법이 없다. 그래서 고칠 곳은 스키마가 아니라 R0 였다(R0 자신의 주석이 "v3 계약이 정본"이라고 적어 두었다).
|
||||
- **`BO.json` 2건** — 구판은 같은 조건에서 **증거 없는 1건**으로 접혔다(후보 전량이 빈 중복 키로 한 버킷에 병합). 지금은 각 레코드가 `Evidence` 2건(E-001 · E-002 — seed 의 `source_refs` 유래)을 갖고, `BOType` 은 registry 합집합 어휘의 `event`, `Action` 은 서술문이 아니라 registry 토큰(`event:general_legal_effect` · `event:asset_state`), 레코드 키는 구 계약 `ALLOWED_TOP_LEVEL` **18 그대로**다(`BO.json` 최대 호환면 불변).
|
||||
- **원장 후보 3건 보존** — `seed_payload` 17키 고정, meeting_only 오발 0. 병합 1건은 X1·X3 스텁의 투영 표면이 실제로 동일해 정당하고, 내용이 다른 X2 는 분리됐다(전량 병합 붕괴 아님).
|
||||
- **worker seed 파일 3종 바이트 무변**(M-h) — R0 는 읽기만 한다. validator 오류 채널 오염 0 (구판 B-3 의 원인 자체가 소멸).
|
||||
- **review handoff `FINALIZED` · 13항목** — worker 유래 6건은 원본 `review_code` 째(`REPLAY_STUB_NO_LEGACY_SEED` 3 · `REPLAY_STUB_REGISTRY_DERIVED` 3) 도달하고, 투영 유래 6건(ActionType 3 · Action 3 — `action_source` 덧붙임)과 near-dup 1건이 더해진다.
|
||||
- **signal 번들과 BO 가 같은 후보에 같은 증거를 연계**한다 — 구판의 "BO 는 증거 0 · signal 은 증거 연계 보유" 모순(C-3)이 사라졌다.
|
||||
- **M-n**: pass2 재실행 → BO · 원장 · handoff · signal 번들 전부 바이트 동일. **M-o**: `E-999` 주입 → 경성 BLOCK 후 원상복구.
|
||||
|
||||
**대역이 무엇을 근거로 만드는가.** 후보의 내용은 슬라이스의 `domain_declarations`(정본은 registry 의 `domain_config`)와 Stage A 의 출처 목록에서만 온다. 요건·반대사실 슬롯은 `evidence_slot_status` 에 `missing` 으로 이름만 옮기고, `element_fact_candidates` 에는 슬롯이 아니라 **출처**를 넣는다(슬롯 ID 를 출처 자리에 넣으면 검증기가 `WORKER_SOURCE_MEMBERSHIP_FAILED` 로 막는다 — 실측으로 확인하고 고친 지점이다). 산출은 조립본 자신의 `worker_output_validator` 로 검사해 **X1·X2·X3 모두 오류 0 · 경고 0**이다.
|
||||
|
||||
예행의 범위 한계는 영수증이 적어 둔다. 첫째, **Part 1 code task 8종 중 5종만 돌았다** — `Task_B1_quality_gate_evidence_indexed` · `Task_B2_quality_gate_event_candidates` · `Task_B12_gate_audit_finalizer` 셋은 B1·B2 와일드카드 fan-out 인스턴스의 산출을 `{{item.*}}` 경로로 요구하는데 재생 세트가 그 단계를 완성본으로 통째 대역하므로 다시 돌릴 입력이 없다. 둘째, 예행의 활성 도메인이 X1·X2·X3 셋뿐이다(대역이 증거 단서 기반 활성 판정을 하지 않기 때문이며 결함이 아니다). 셋째, 예행의 스크리닝 후보 11개 전부에 `requested_calculation_domains` 가 부재하다 — 그래서 교집합 경로를 `calculation_intersection_probe` 로 따로 실측했다. 26 도메인 경로도 마찬가지로 따로 실측했다 — 26 전부를 `execution_eligible` 로 둔 **합성** 활성 매니페스트에 슬라이스 스키마를 주입해 `compile_domain_slices` 를 돌려 READY / 26 / 실패 0 을 확인했다.
|
||||
**배포 원본 하나로 선다.** 재검증 sub-agent 가 `/tmp` 복제 환경에서 asset root 를 배포 원본만으로 지정해 R0·F0·S0 를 독립 재실행했고, 3단계 PASS + 산출 8파일·signals 트리 전체가 본 실행과 바이트 동일임을 재현했다. 통합본 전수에서 조립본·빌더·조립본 장부 참조는 0건이다 — 배포 원천 이관(§5.1)을 선언이 아니라 실행으로 닫은 근거이며, 조립본 동기화 이월(§6.6 D)이 실행을 막지 않는 근거이기도 하다.
|
||||
|
||||
**조립본 하나로 선다.** `--asset-root` 를 임시 사본이 아니라 정본 조립본 폴더 자체로 겨눈 예행이 통과하고, 그때 남은 배포 게이트 영수증의 `runtime_manifest_sha256` 이 조립본 매니페스트의 실제 해시와 일치한다. 하네스는 asset-root 에 쓰지 않으므로(경로 해석기를 타는 기록 대상에 `Default_Agent/` 접두사가 하나도 없다) 실행 뒤 조립본은 드리프트 0 으로 그대로다.
|
||||
예행의 범위 한계는 앞 판본과 같다. 첫째, Part 1 code task 8종 중 5종만 돈다(B1·B2 fan-out 인스턴스 산출을 재생 세트가 완성본으로 대역하므로). 둘째, 활성 도메인이 X1·X2·X3 셋뿐이다 — 대역 스크리너가 registry 단서만 쓰므로 상시 계열만 켜지며, 실체 도메인 활성은 실제 LLM 스크리너의 몫이다. 그래서 오버레이 보유 도메인의 rank 10 공통 계약 vs rank 30 오버레이 실프롬프트 대결은 정적 근거(합성본 주입 실측 + 우선순위 선언 + 계약의 "narrow not widen" 규율)로 닫았다. 셋째, 스크리닝 후보에 `requested_calculation_domains` 가 없어 교집합 경로는 별도 탐침으로 실측한다. 이번 회차 고유의 한계 하나 — M-p 의 amount 충돌 관측은 함수층 재현이다(스텁 seed 에 충돌 값이 없다). 예행 증거는 실행 루트 `/tmp/dry_v6/` 와 내역서에 있고, 트리 내 영수증(`dry_run_receipt.v1.json`) 정본화는 이월돼 있다(§6.6 D).
|
||||
|
||||
### 6.5 검증이 잡은 것 — 결함의 성격
|
||||
|
||||
@@ -649,9 +659,18 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
|
||||
둘 다 **스키마를 실제로 주입해서 검증이 돌기 때문에** 드러났다. 주입하지 않던 시절이라면 둘 다 조용히 통과했다. 같은 계열의 결함 하나가 더 있었다 — `domain_screening.json`이 `{"domain_screening": …}`로 래핑돼 있어 `.get("candidates")`가 늘 `None`이었고, 계산 통과가 조용한 무효였다.
|
||||
|
||||
**다섯째 회차(2026-08-19)가 닫은 결함은 열한 건이고, 그 검증이 새로 잡은 결함이 두 건이다.** 열한 건 — 실행 결손 C-1~C-8 · 잠복 계약 결손 C-11(적법한 `NO_SUPPORT`가 R0 전체를 중단시키는 status 게이트) · 비실행 C-9(빌더 뿌리)·C-10(처방 문구) — 은 재검토 문서 v2 가 완수 기준(산출물 정합 + 상하류 consistency)으로 전건 CONFIRMED 한 것이며, 공통 형태는 §1.5 말미와 같다. 적대적 sub-agent 1차 검증은 그 처방의 구현 자체에서 둘을 더 잡았다.
|
||||
|
||||
| 검증이 잡은 것 | 내용 | 수정 |
|
||||
|---|---|---|
|
||||
| `amount.value_text` 영구 null | 투영기가 v3 `amount_facts` 닫힌 스키마에 **없는** 필드 `value_text` 를 읽었다 — BO 의 `amount.value_text` 가 항상 null 이 되고, 그것을 참조하는 R0 근접중복 amount 충돌 검출이 죽는다 | `value_text = decimal_value` 원문 (정책 규칙 이행). 충돌 2값 투입 재현으로 사전순 최소 채택 · `amount_or_date_uncertain` review 발화 · 검출부 소생 확인 |
|
||||
| `source_review_code` 원본 상실 | v3 검토 항목의 **필수** 키는 `review_code`인데 선택 키 `unresolved_type`을 싣고 있었다 — 정책 목적문("원본 review_code 를 잃지 않기 위해 덧붙인다")과 구현의 모순 | 원본 `review_code` 우선 + `reason` → handoff `template_note` + `NO_SUPPORT` 합성 항목에도 부여. 예행 재실측으로 원본 코드·사유문 도달 확인 |
|
||||
|
||||
수정 반영 후 재검증 sub-agent 판정은 **"잔여 필수 수정 없음"**이다. 두 건 모두 정책 선언(닫힌 스키마 · additive_keys 의 목적문)이 검사 오라클 노릇을 했다 — 투영 규칙을 코드 밖 선언 자산에 둔 설계가 검증 가능성으로 돌아온 자리다.
|
||||
|
||||
### 6.6 남은 것
|
||||
|
||||
앞 판본 §6.6 의 14줄 중 셋이 닫혔다 — 델타 30건 반영(1) · 부분 복사 방어(1b) · 조립본 `__pycache__` 제거(12). 표에 줄로 오르지는 않았지만 함께 닫힌 것이 하나 더 있다 — 예행이 A0 에서 멈춰 하류 셋을 한 번도 태우지 못하던 상태다(§6.4). 지금 남은 것을 **실행이 그 자산을 읽는가**로 갈라 적는다. 이 기준으로 보면 아래 어느 것도 Part 2 실행을 막지 않는다.
|
||||
앞 판본 §6.6 의 14줄 중 셋이 닫혔고(델타 30건 반영 · 부분 복사 방어 · 조립본 `__pycache__` 제거), 다섯째 회차가 둘을 더 닫았다 — **B-3**(R0 되쓰기의 v3 이탈과 경고 채널 오염: 되쓰기 자체가 삭제되어 원인 소멸)과 **C-8 의 한 줄**(`also_written_by: R0`: 코드가 선언표로 돌아왔다, §4.4). 지금 남은 것을 **실행이 그 자산을 읽는가**로 갈라 적는다. 이 기준으로 보면 아래 어느 것도 Part 2 실행을 막지 않는다.
|
||||
|
||||
**A. 실행 경로 밖 — 빌드·재생성 쪽**
|
||||
|
||||
@@ -668,7 +687,7 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
|---|---|---|
|
||||
| B-1 | `_promote_seed_v2_to_v3.py` 산출이 v3 스키마를 위반한다 | X1 하나에서 오류 17건 — `completion_receipt` 가 필수 5키(`task_instance_id` · `domain_id` · `seed_count` · `emitted_seed_ids` · `r0_membership_key`)를 빠뜨리고 금지 3키를 싣는다. review 항목도 `severity` 가 enum 밖이고 `source_legacy_ids` 는 금지 키다. 이번 사슬은 이 스크립트를 부르지 않아 드러나지 않았으나 `replay_manifest.v1.json` 은 여전히 그 경로의 생성기로 이것을 지목한다 |
|
||||
| B-2 | 같은 스크립트가 `domain_config_sha256` 을 슬라이스 **루트**에서 읽는다 | 실제 위치는 `domain_registry` 아래라 항상 빈 문자열이 실린다 |
|
||||
| B-3 | R0 가 되쓰는 seed 파일이 v3 스키마를 벗어난다 | `expand_candidate` 가 v2 필드를 붙여 다시 쓰기 때문이다. **재실행은 선다** — R0 를 자기 산출 위에 다시 돌려 PASS(기록 6건)를 확인했다. 검증기 오류를 예외로 올리지 않고 원장에 적기 때문이며, 그래서 실제 비용은 완주 실패가 아니라 **경고 채널 오염**이다(재실행 시 원장에 `WORKER_OUTPUT_ERROR` 45건이 쌓여 진짜 워커 위반이 묻힌다). 넷 중 먼저 손볼 값어치가 여기 있다 |
|
||||
| B-3 | ~~R0 가 되쓰는 seed 파일이 v3 스키마를 벗어난다~~ | **닫힘(2026-08-19).** 되쓰기와 `expand_candidate` 가 함께 삭제되어 원인 소멸 — 예행 실측 seed 3종 바이트 무변(M-h) · validator 오류 채널 오염 0 |
|
||||
|
||||
**C. 앞 판본에서 이월된 것**
|
||||
|
||||
@@ -681,22 +700,35 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
| C-5 | `BO.json` · 구 signal 3종 등가 대조기 | 미착수 (P-14 · P-15) |
|
||||
| C-6 | overlay CE id 도달률 62% → 승격 시 R-4 를 review 에서 실패로 | 도달률이 오른 뒤 |
|
||||
| C-7 | Part 3·4 를 정본 signal 집합(`downstream_read_sets`)으로 이관 | Part 3·4 개정 범위 |
|
||||
| C-8 | 인계면 선언표 3줄 갱신 — `client_meeting.md` 소비자에 Part 2 A0, `runtime/domain_seed_outputs/` 에 `also_written_by: R0`, `client_goal.json` 등재 | §4.4 |
|
||||
| C-8 | 인계면 선언표 **2줄** 갱신 — `client_meeting.md` 소비자에 Part 2 A0, `client_goal.json` 등재 (`also_written_by: R0` 줄은 되쓰기 삭제로 불필요해졌다) | §4.4 |
|
||||
| C-9 | E-09 `legacy_domain_id` 대 별칭표 불일치 | registry 소유자 판단 |
|
||||
| C-10 | `Stage_1_Registry_Runtime_v1.yml` 경계 결정 | D-2 §3.3 |
|
||||
| C-10 | `Stage_1_Registry_Runtime_v1.yml` 경계 결정 | 앞 판본 D-2 §3.3 |
|
||||
|
||||
**D. 다섯째 회차가 이월한 것 — 조립본 동기화 (내역서 §5)**
|
||||
|
||||
배포 원본이 `extension_research/Default_Agent` 로 이관되면서(§5.1), 조립본 쪽 반영은 다음 회차 한 벌로 묶여 이월됐다. Part 2 실행 정합성에 무영향임은 배포 원본 단독 재실행이 실증한다(§6.4).
|
||||
|
||||
| # | 항목 | 주의 |
|
||||
|---|---|---|
|
||||
| D-1 | 정책 자산·개정 공통 계약을 조립본에 반영 + 빌더 `PART2_ASSEMBLY_AUTHORED` 16→17 등록 | **파일 반영과 등록은 한 벌** — 등록만 선행하면 `MISSING_SELECTED_SOURCE` 로 빌드 즉사 |
|
||||
| D-2 | 조립본 `release_manifest` 1,320→1,321 · `source_copy_map` 1,158→1,159 재생성, 신선 빌드 매니페스트 396 도달 | M-l 완전판 |
|
||||
| D-3 | 후보 오버레이 트리(`ver_8_yaml_candidates/Default_Agent_Stage_1`)의 지위 정리 | 현재는 개정 전 조립본의 부분집합 사본으로 남아 있다 |
|
||||
| D-4 | 오버레이 5건의 낡은 `domain_review_queue` 문장 정리 | 색인 갱신 회차에 — 효력은 rank 10 공통 계약이 이긴다 |
|
||||
| D-5 | 예행 영수증(`dry_run_receipt.v1.json`) 정본화 — 다섯째 회차 실측(M-a~M-r)은 실행 루트 `/tmp/dry_v6/` 와 내역서에 있다 | 분석 문서 갱신(본 판본)은 완료 |
|
||||
| D-6 | (선택) 재검토 문서 §4.1 의 정책 JSON 에 `action_type_enum` 추가분 역반영 | 문서-자산 등가 유지 |
|
||||
|
||||
## 7. 근거
|
||||
|
||||
| 주장 | 근거 |
|
||||
|---|---|
|
||||
| 두 통합본의 크기·행수·sha256 | 원문 바이트 재계산 — Part 1 467,668 B / 6,667행 / `195b43edfaf1df14…`, Part 2 **193,933 B / 3,307행 / `73644c5620b1bfbc…`** |
|
||||
| 두 통합본의 크기·행수·sha256 | 원문 바이트 재계산 — Part 1 467,668 B / 6,667행 / `195b43edfaf1df14…`, Part 2 **195,938 B / 3,315행 / `ec4c43027ad85195…`** |
|
||||
| YAML 구문 PASS · 최상위 키 `Agent` | `yaml.safe_load` 재실행 |
|
||||
| task 13 / 6 및 행 범위 | `- task_name:` 정규식 전수 추출 |
|
||||
| DAG 노드·edge | `task_procedure` 블록 원문 (Part 1 6,589–6,664행 · Part 2 **3,269–3,304행**) |
|
||||
| DAG 노드·edge | `task_procedure` 블록 원문 (Part 1 6,589–6,664행 · Part 2 **3,277–3,312행**) |
|
||||
| task별 IN/OUT | 프롬프트의 `<ALLOWED_IO_AND_FORBIDDEN_ACTIONS>` 블록(LLM task) · `*_PATH` 상수와 `read_raw`/`write_doc` 호출(code task) 전수 추출 |
|
||||
| task별 실행기 설정 | `llm_provider`/`llm_model`/`llm_reasoning`/`llm_verbosity`/`mcp`/`tool_name`/`language`/`network`/`timeout`/`use_tools`/`preflight_files`/`max_concurrency`/`max_iterations` 전수 추출 |
|
||||
| 자산 참조 19 / 20 및 실재 여부 | `Default_Agent/…` 리터럴 전수 추출 후 두 뿌리에서 `os.path.exists` 대조 |
|
||||
| 반영 전 두 뿌리 대조 (528 / 7 / 23) · 반영 후 (558 / 0 / 0) · 현재 560 전량 동일 | 후보 오버레이 전수 sha256 대조를 반영 전후로 두 번 |
|
||||
| 자산 참조 19 / **21** 및 실재 여부 | `Default_Agent/…` 리터럴 전수 추출 후 **배포 원본 트리**에서 `os.path.exists` 대조 |
|
||||
| 반영 전 두 뿌리 대조 (528 / 7 / 23) · 반영 후 (558 / 0 / 0) · 현재 560 중 **559 동일 · 1 상이**(빌더 — 다섯째 회차의 조립본 내 수정이 오버레이에 없다) | 후보 오버레이 전수 sha256 대조를 반영 전후와 다섯째 회차 뒤 세 번 |
|
||||
| 미러 규약 실측 | 두 뿌리에서 `.py`↔`.txt` 전수 sha256 대조 |
|
||||
| 매니페스트 수치 | `release_manifest.json` · `runtime_manifest.json` · `source_copy_map.json` 직접 파싱 |
|
||||
| 인계면 34 및 구간 분포 | `handoffs/stage1_part_interface.v1.json` 직접 파싱 |
|
||||
@@ -706,6 +738,8 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
| Part 2 검사 20항 · 결함 10건 · 26 도메인 투영 · 예행 6단계 | `stage_1_part_2_레지스트리기반개정완료_보고서.md` §3~§5 |
|
||||
| **추가 개정 4회 — 배포 게이트 F-1~F-7 · 회귀 R-a~R-l · 델타 30건 반영 · 라벨 해석 · 원천 정합 · 예행 2패스 9단계** | `stage_1_part_2_추가수정작업.md` · `_더.md` · `_더더.md` · `_더더더.md`. 각 회차의 수치는 회차 문서가 독립 sub-agent 검증(각 3~4라운드)을 통과한 값이며, 이 문서에 옮길 때 자산 트리에서 다시 실측했다 |
|
||||
| 예행 2패스 결과·seed 대역 검증 | `_dry_run_stage1.py` 재실행 + `worker_output_validator` 직접 호출 |
|
||||
| **다섯째 회차(BO 투영) — 결함 C-1~C-11 · 처방 · 회귀 M-a~M-r · 적대 검증 2회** | `stage_1_part_2_여전히남은문제해결방안.md`(v2) · `stage_1_part_2_여전히남은문제해결내역.md` · 예행 증거 `/tmp/dry_v6/`. 이 문서에 옮긴 수치는 통합본과 배포 트리에서 다시 실측했다 |
|
||||
| 배포 원본 트리 155 · 형태 분포 · 미러 34/34 · 매니페스트 371(트리 실재 94 전수 일치) | `extension_research/Default_Agent` 전수 순회 + `runtime_manifest.json` 파싱·sha256 재계산 |
|
||||
| 설계 판정·계측 재정의 배경 (preflight 의미, 압축본을 쓰는 이유, 모듈 반입 우회책, 봉인 위치) | `ver_8_yaml_candidates/8월12_to_16일작업압축요약본.md` (316,036 B, Q&A 형식 설계 일지) |
|
||||
| 개정 이력 누적 요약 | `v.7/MEMORY.md` (항목 ⑦~⑭) |
|
||||
|
||||
@@ -744,9 +778,9 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
|
||||
---
|
||||
|
||||
## 9. 이번 개정(2026-08-18)의 범위와 검증
|
||||
## 9. 앞 개정(2026-08-18)의 범위와 검증
|
||||
|
||||
이 판본은 **Part 2 에 관한 서술만 incremental 로 갱신**했다. 두 Part 공통 절인 §1.4 에서 한 줄(미러 규약 실측)이 함께 바뀌었는데, 그 수치가 자산 트리 전체를 세는 값이라 Part 2 델타 반영으로 달라졌기 때문이다. 손댄 곳과 손대지 않은 곳을 분명히 적어 둔다.
|
||||
그 판본은 **Part 2 에 관한 서술만 incremental 로 갱신**했다. 두 Part 공통 절인 §1.4 에서 한 줄(미러 규약 실측)이 함께 바뀌었는데, 그 수치가 자산 트리 전체를 세는 값이라 Part 2 델타 반영으로 달라졌기 때문이다. 손댄 곳과 손대지 않은 곳을 분명히 적어 둔다.
|
||||
|
||||
| 절 | 처리 |
|
||||
|---|---|
|
||||
@@ -759,6 +793,30 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
| §7 | 근거표에 회차 문서 4종과 재실측 항목 추가 |
|
||||
| **손대지 않은 곳** | §1.1 · §1.2 · §1.3 · §2 전체 · §3.4 · §4 · §6.1 · §6.3 · §6.5 · §8 — 계보, Part 1 서술, 첫 판본의 Part 2 개정 범위표, upstream–downstream 연결표, 인계면(수치 34가 그대로다), registry 투영 실측, 그리고 앞 판본의 검증 이력이다 |
|
||||
|
||||
앞 판본은 `ver_8_yaml_candidates/outdated/stage_1_part_1_and_2_updated_yaml_analysis_old.md`(86,634 B)로 보존했다.
|
||||
그 판본이 갈음한 앞앞 판본(2026-08-16, 86,634 B)은 지금은 git 이력에만 있다 — `outdated/` 의 `_old.md` 자리는 현행 직전 판(2026-08-18, 106,290 B)이 차지한다.
|
||||
|
||||
검증은 앞 판본과 같은 방식이다 — 독립 sub-agent 가 문서의 주장을 믿지 않고 `stage_1_part_2_v.8.yml` 원문과 자산 트리를 직접 측정해 대조했고, 지적이 0 이 될 때까지 반복했다.
|
||||
|
||||
---
|
||||
|
||||
## 10. 이번 개정(2026-08-19)의 범위와 검증
|
||||
|
||||
이 판본도 **Part 2 에 관한 서술만 incremental 로 갱신**했다. 근거는 다섯째 회차(BO 투영)의 두 문서 — 재검토 `stage_1_part_2_여전히남은문제해결방안.md`(v2)와 내역서 `stage_1_part_2_여전히남은문제해결내역.md` — 이며, 이 문서에 실은 수치는 전부 통합본 `stage_1_part_2_v.8.yml`(195,938 B)과 배포 원본 `extension_research/Default_Agent` 트리에서 다시 실측했다.
|
||||
|
||||
| 절 | 처리 |
|
||||
|---|---|
|
||||
| 머리말 · §0 | Part 2 파일 크기·행수·sha256 갱신(195,938 B / 3,315행 / `ec4c43027ad85195…`), 추가 개정 라운드 4→5회, 근거 자료 2종 추가 |
|
||||
| §1.3 (한 칸) · §1.4 (두 칸) | R1 행 번호 현행화 · 미러 규약 실측에 배포 원본 트리 34/34 추가 · 「실행 뿌리 3개」의 A0 `ASSET_ROOT` 실사용 반영 |
|
||||
| §1.5 | 제목 4회→5회, 다섯째 회차(BO 투영) 행 추가, 공유 진단 형태 문단 확장 |
|
||||
| §3.1 · §3.2 · §3.3 | task 행 범위 재측정(전부 이동 — R0 −31행 · F0 +38행), A0 게이트 10 자산/18경로, R0 의 투영기·검토 채널·status 정책·계획 행 sha 대조·되쓰기 삭제, F0 의 registry 합집합 폴백·정책 반입·소리 나는 정규화, IO 표의 R0 산출 셋 축소와 정책 자산 추가 |
|
||||
| §3.4 (두 칸) | R0 의 seed 읽기 전용 · F0 이 읽는 원장 payload 가 17키 고정 투영본임을 명시 |
|
||||
| §3.5 | 리터럴 20→21, 투영 정책 자산 행 신설, 매니페스트·공통 계약 행 갱신, 크기 기준을 배포 원본 트리로 |
|
||||
| §4.4 (두 줄) | seed 공동 기록자 누락 → **해소** (되쓰기 삭제) · `read_raw(MEETING)` 행 번호 현행화 |
|
||||
| §5 전체 | 두 뿌리 → 세 뿌리(배포 원본 승격)로 재작성, 155 구성 산식, 조립본 낡음 3파일, 매니페스트 371/94 실측, 빌더 뿌리 6→10 |
|
||||
| §6.2 · §6.4 · §6.5 · §6.6 | 검사 5·10·15·18·19 갱신(18은 빌더 장부 불일치 1 실측), 회귀 M-a~M-r 표 추가, 예행을 배포 원본 기준으로 재작성(pass2 29건 · `BO.json` 2건 값 검사), 검증이 새로 잡은 결함 2건, B-3 닫힘 · C-8 축소 · 이월 D-1~D-6 |
|
||||
| §7 · §9 | 근거표 4행 갱신·2행 추가, §9 를 "앞 개정"으로 개칭 |
|
||||
| **손대지 않은 곳** | §1.1 · §1.2 · §2 전체 · §4.1~§4.3 · §6.1 · §6.3 · §8 — 계보, Part 1 서술, 인계면 선언·봉인 서술, registry 투영 실측, 앞 판본들의 검증 이력 |
|
||||
|
||||
앞 판본(2026-08-18)은 `ver_8_yaml_candidates/outdated/stage_1_part_1_and_2_updated_yaml_analysis_old.md`(106,290 B)로 보존했다.
|
||||
|
||||
검증은 앞 판본과 같은 방식이다 — 독립 sub-agent 가 문서의 주장을 믿지 않고 `stage_1_part_2_v.8.yml` 원문과 배포 원본 트리를 직접 측정해 대조했고, 지적이 0 이 될 때까지 반복했다. 라운드 1 은 지적 9건(MAJOR 6 · MINOR 3)이었고 그중 여덟을 반영했다(나머지 하나는 배치 순서에 대한 것 — 앞 판본의 `outdated/` 회전이 이 판본 배치보다 먼저 실행되어 해소). 라운드 1 이 실측으로 새로 잡은 사실 둘은 그대로 본문이 됐다 — 조립본 `release_manifest` 의 빌더 불일치 1(검사 18)과 후보 오버레이 559/1(§5.1·§7). 라운드 2 는 지적 1건(MINOR — §6.2 제목의 "전부 통과"가 검사 18 과 어긋남)으로 반영했고, 라운드 3 은 지적 0건이다.
|
||||
|
||||
+181
-101
@@ -3,9 +3,11 @@
|
||||
- 문서 위치: `YAML_Prompts/1. Stage_1/v.7/extension_research/stage_1_part_1_and_2_updated_yaml_analysis.md`
|
||||
- 분석 대상 정본 2종
|
||||
- `ver_8_yaml_candidates/stage_1_part_1_v.8.yml` — 467,668 B / 6,667행 / sha256 `195b43edfaf1df1414acc118c17d544c…`
|
||||
- `ver_8_yaml_candidates/stage_1_part_2_v.8.yml` — 175,266 B / 3,026행 / sha256 `9bf771b72984093684d73316f62c6f13…`
|
||||
- `ver_8_yaml_candidates/stage_1_part_2_v.8.yml` — **193,933 B / 3,307행 / sha256 `73644c5620b1bfbc…`** (2026-08-18 추가 개정 4회 반영본. 개정 전 값은 175,266 B / 3,026행 / `9bf771b729840936…`)
|
||||
- 근거 자료: `v.7/MEMORY.md` · `stage_1_part_1_개정작업_리포트.md` · `ver_8_yaml_candidates/part_1_remaining_update_report.md` · `stage_1_part_2_레지스트리기반개정완료_보고서.md` · `ver_8_yaml_candidates/8월12_to_16일작업압축요약본.md`(316,036 B) · `Default_Agent_Stage_1/handoffs/stage1_part_interface.v1.json`(34 인계면 선언표)
|
||||
- 실측 기준: 이 문서의 모든 수치·경로·키는 위 두 YAML 원문과 자산 트리 두 뿌리를 **직접 파싱·해시**하여 얻은 것이다. 리포트 본문에서 옮겨 온 값은 §7 근거표에 출처를 적었고, 리포트와 실측이 갈린 곳은 그 자리에 명시했다.
|
||||
- **Part 2 추가 개정 4회의 작업 내역서** — `stage_1_part_2_추가수정작업.md`(배포 완전성 게이트 F-1~F-7) · `stage_1_part_2_추가수정작업_더.md`(델타 30건 조립본 반영 · R0 라벨 해석) · `stage_1_part_2_추가수정작업_더더.md`(빌더 등록 · 상류 동기화) · `stage_1_part_2_추가수정작업_더더더.md`(스키마 2건 등록 · 예행 seed 보강)
|
||||
- 실측 기준: 이 문서의 모든 수치·경로·키는 위 두 YAML 원문과 자산 트리를 **직접 파싱·해시**하여 얻은 것이다. 리포트 본문에서 옮겨 온 값은 §7 근거표에 출처를 적었고, 리포트와 실측이 갈린 곳은 그 자리에 명시했다.
|
||||
- **개정 방식**: 이 문서는 Part 2 절만 incremental 로 갱신한 판본이다. Part 1 에 관한 서술(§2 전체, §1.2, §6.1)은 앞 판본에서 손대지 않았다. 앞 판본은 `ver_8_yaml_candidates/outdated/stage_1_part_1_and_2_updated_yaml_analysis_old.md`(86,634 B)에 보존돼 있다.
|
||||
|
||||
---
|
||||
|
||||
@@ -24,8 +26,12 @@
|
||||
| 사건 입력 | `client_meeting.md` · `evidence_all.json` | `client_meeting.md` (A0가 직접 읽는다) + Part 1 산출 6종 |
|
||||
| 최종 산출 | `routing/domain_activation_manifest.json` · `quality_gates/stage1_part1_soft_gate_handoff.json` 외 | `BO.json` · `signals/signal_manifest.json` 외 |
|
||||
| 개정 분류 | 신설 4 · 개정 3 · 무변경 6 | 신설 1 · 개정 4 · 무변경 1 (+ 정적 worker 5 삭제) |
|
||||
| 추가 개정 라운드 | 없음 | **4회** — 배포 완전성 게이트 · 델타 반영과 라벨 해석 · 원천 정합 · 예행 seed 보강 (§1.5) |
|
||||
| 예행 완주 코드 task | 5 / 8 | **4 / 4** (A0 · R0 · F0 · S0, §6.4) |
|
||||
| YAML 구문 | PASS | PASS |
|
||||
|
||||
Part 2 는 첫 판본(레지스트리 기반 전환) 이후 네 차례 더 개정됐다. 그 네 회차가 바꾼 것은 task 구성이 아니라 **실행 전 자산 검사 · 도메인 라벨 해석 · 후보 식별자 계약 · 예행 재료**이며, task 6종과 DAG 모양은 그대로다. 회차별 내용은 §1.5 에 있다.
|
||||
|
||||
두 파일 모두 **스테이지 하나 · 선언 1벌**이다. `Agent` 1 · `Stages` 1 · stage명 1 · `tasks` 1 · `task_procedure` 1 · `prevs`/`nexts` 각 1벌이며, 조각 후보본들이 각자 갖고 있던 스테이지 껍데기와 자기 `task_procedure`는 조립 시 전부 걷어냈다.
|
||||
|
||||
---
|
||||
@@ -80,7 +86,7 @@ Part 2 통합본의 개별 6종 ↔ 통합본 대조는 불일치 0으로 확인
|
||||
|
||||
| 규약 | 내용 | 실측 |
|
||||
|---|---|---|
|
||||
| **미러 규약 M-1~M-5** | 모든 `.py` 옆에 바이트 동일한 `.txt` 형제를 배포한다. localdocs가 `.py`를 서빙하지 않기 때문이다. 미러는 정본 옆에 놓이므로 `sg01_activation_adapter`의 미러는 `signals/adapters/`에 있다 | 조립본 `.py` 103 중 102 미러 · 해시 불일치 0. 유일한 예외는 빌더 `tools/build_default_agent_stage1.py` |
|
||||
| **미러 규약 M-1~M-5** | 모든 `.py` 옆에 바이트 동일한 `.txt` 형제를 배포한다. localdocs가 `.py`를 서빙하지 않기 때문이다. 미러는 정본 옆에 놓이므로 `sg01_activation_adapter`의 미러는 `signals/adapters/`에 있다 | 조립본 `.py` **112 중 111 미러** · 해시 불일치 0. 유일한 예외는 빌더 `tools/build_default_agent_stage1.py` (앞 판본의 103/102 는 델타 반영 전 값이다) |
|
||||
| **모듈 반입 규약 R-1~R-5** | `.txt` 미러를 `read_raw`로 읽고 `runtime_manifest.json`의 sha256과 대조한 뒤 `/tmp/…`에 `.py`로 기록하고 `sys.path.insert`. 실패 코드는 `MODULE_MIRROR_UNREGISTERED` / `MODULE_MIRROR_HASH_MISMATCH` | D0 · P2-A0 · P2-R0 · P2-S0 네 task가 사용 |
|
||||
| **실행 뿌리 3개** | `--asset-root` · `--execution-root` · `--logical-root`를 argv로만 넘긴다. 값은 `Default_Agent/` · `/tmp/s1` · `/tmp/s1` (R0만 `/tmp/s1_r0`) | argv 3벌을 실제로 넘기는 곳은 **D0 하나뿐**이다(Part 1 5,943–5,945행, `activation_gate.main`). Part 2의 네 code task는 값을 상수로만 두며 실제 사용은 갈린다 — A0는 `EXECUTION_ROOT`만 쓰고 `ASSET_ROOT`·`LOGICAL_ROOT`는 대입 1회뿐, S0는 `ASSET_ROOT`·`EXECUTION_ROOT`를 쓰고 `LOGICAL_ROOT`는 대입 1회뿐, R0는 `EXECUTION_ROOT = /tmp/s1_r0` 하나만, F0는 셋 다 없다 |
|
||||
| **P0 설계판정 C** | 봉인된 스키마를 늘릴 때 기존 키의 값은 등가로 두고 신규 키만 더한다. `required`에 올리지 않는다 | `domain_slice.schema.v2.json` 루트 properties 20→21 · `required` 19 불변, 그리고 `compiled_prompt.properties` 4→5(`hash_kind` 추가) · `compiled_prompt.required` 4 불변. T3 `registry_component_ids` 슬롯 1개 additive |
|
||||
@@ -88,6 +94,21 @@ Part 2 통합본의 개별 6종 ↔ 통합본 대조는 불일치 0으로 확인
|
||||
|
||||
---
|
||||
|
||||
### 1.5 Part 2 추가 개정 4회
|
||||
|
||||
§1.3 의 레지스트리 기반 전환을 마친 뒤, Part 2 는 실행 직전에 걸리는 결손 넷을 차례로 닫았다. 회차마다 독립 sub-agent 검증을 통과할 때까지 반복했고, 작업 내역서는 회차별로 따로 있다.
|
||||
|
||||
| 회차 | 문서 | 무엇을 닫았나 | 명세서에 남은 흔적 |
|
||||
|---|---|---|---|
|
||||
| 1 | `stage_1_part_2_추가수정작업.md` | **부분 복사 방어.** 자산 트리가 두 뿌리로 갈려 있는 동안, 델타 30건 중 일부만 옮기면 조용히 어긋난 상태로 실행이 시작될 수 있었다 | A0 에 `assert_deployment()` · `PART2_REQUIRED_ASSETS`(9 리터럴 → 실측 17건 검사) · `PART2_SLICE_SCHEMA_STALE` · `PART2_COMPILER_STALE` · 오버레이 4코드 승격 · `deployment_gate` 영수증. R0·S0 에 공유 헬퍼 `_verify_asset`(두 task 에서 바이트 동일), R0 에 `_assert_mirror_consistent` |
|
||||
| 2 | `stage_1_part_2_추가수정작업_더.md` | **델타 30건의 정본 반영**과 **도메인 라벨 해석**. R0 640행이 구 이름 다섯 개짜리 표를 대괄호로 조회해 registry ID 마다 `KeyError` 로 죽었다 | R0 에 `_domain_label()` 3단 해석(슬라이스 → 구 이름 표 → ID). 슬라이스 적재를 검증기 분기 밖으로 인상 |
|
||||
| 3 | `stage_1_part_2_추가수정작업_더더.md` | **원천 정합.** 조립본이 재생성 불가능한 유일본이 돼 있었다 — 빌더가 신규 23건을 모르고, 변경된 두 모듈은 상류가 옛 바이트를 쥐고 있었다 | 명세서 변경 없음. 빌더·상류·기록 표 쪽 작업이다 |
|
||||
| 4 | `stage_1_part_2_추가수정작업_더더더.md` | **스키마 2건 등록**과 **예행 seed 보강**. 후자에서 R0 의 후보 식별자 계약이 registry ID 로는 만족 불가능하다는 것이 드러났다 | R0 의 `CANDIDATE_REF_RE` 를 형식만 보도록 넓히고 `ensure_candidate_ref()` 추가, v3 의 평평한 `source_refs` 를 membership 게이트가 보도록 검사 1개 추가 |
|
||||
|
||||
**네 회차가 공유하는 진단 형태가 하나 있다.** v3 시절의 리터럴이 registry 기반 전환 뒤에도 남아 있었고, 그 리터럴이 registry 어휘와 **동시에 만족될 수 없는** 형태였다는 것이다. 라벨 조회(`DOMAIN_LABELS[domain_id]`)와 후보 식별자(`^B[1-5]:[0-9]{3}$` + 도메인 접두사 요구)가 같은 계열이며, §6.5 가 적은 두 BLOCKER(스키마 패턴이 registry 어휘보다 좁았다)도 같다. 넷 다 **실제로 실행해 보기 전에는 드러나지 않았다.**
|
||||
|
||||
---
|
||||
|
||||
## 2. Part 1 — `stage_1_part_1_v.8.yml`
|
||||
|
||||
### 2.1 전체 작업 DAG
|
||||
@@ -253,7 +274,7 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
|
||||
### 3.1 전체 작업 DAG
|
||||
|
||||
`task_procedure`는 통합본 2,988–3,023행에 있다(스테이지 층 `prevs`/`nexts`는 3,025–3,026행이다). 노드 8개(IN · task 6 · OUT), edge 오류 0. Part 1과 달리 **완전 직렬**이다 — A0가 fan-out 계획을 낸 뒤에야 worker 인스턴스가 생기기 때문이다.
|
||||
`task_procedure`는 통합본 3,269–3,304행에 있다(3,305행은 공백, 스테이지 층 `prevs`/`nexts`는 3,306–3,307행이다). 노드 8개(IN · task 6 · OUT), edge 오류 0. Part 1과 달리 **완전 직렬**이다 — A0가 fan-out 계획을 낸 뒤에야 worker 인스턴스가 생기기 때문이다. 추가 개정 4회는 노드도 edge도 늘리지 않았다.
|
||||
|
||||
```
|
||||
┌────────┐
|
||||
@@ -261,6 +282,10 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
└───┬────┘
|
||||
▼
|
||||
P2-A0 Task_C_BO_A0_context_and_domain_slice_compiler code · timeout 300
|
||||
⓪ assert_deployment — 필수 자산 9 리터럴 + 모듈 미러를 한 벌로 검사(실측 17건)
|
||||
· 하나라도 없거나 해시가 다르면 PART2_ASSET_DEPLOYMENT_INCOMPLETE 로 선다
|
||||
· 슬라이스 스키마 능력 검사(PART2_SLICE_SCHEMA_STALE)
|
||||
· 컴파일러 산출 검사(PART2_COMPILER_STALE — 서명 불일치도 같은 코드)
|
||||
① 모듈 8종 미러 반입·해시 대조
|
||||
② 봉인 3해시 검증 (verify_seal ↔ Part 1 T9 digest_guard)
|
||||
③ registry 26 도메인 적재·검증
|
||||
@@ -268,6 +293,9 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
⑤ slice 컴파일 (domain_declarations 투영 · 계산 교집합)
|
||||
⑥ fan-out 계획 수립
|
||||
⑦ 기록 — slice M · prompt M · plan 1 · stage_a 1 · manifest 1 · receipt 1
|
||||
(receipt 에 deployment_gate 영수증 — checked_count · runtime_artifact_count ·
|
||||
runtime_manifest_sha256 · schema_capability_checked · compiler_output_checked ·
|
||||
overlay_codes_enforced 를 실측값으로 적는다. 상수 PASS 를 적지 않는다)
|
||||
│
|
||||
▼ nexts: ["Task_C_B_domain_worker_*"]
|
||||
P2-B Task_C_B_domain_worker_* LLM ×M · max_concurrency 8
|
||||
@@ -276,7 +304,10 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
│
|
||||
▼ wait_until: ["all Task_C_B_domain_worker_*"] ← barrier · 정확 일치
|
||||
P2-R0 Task_C_BO_R0_seed_reducer_and_exception_planner code · timeout 240
|
||||
기대집합 대조(누락·초과·중복 전부 실패) → seed 검증 → ledger · pack · review_handoff
|
||||
try 밖에서 seed 스키마와 검증기 미러를 먼저 검사(_verify_asset · _assert_mirror_consistent)
|
||||
기대집합 대조(누락·초과·중복 전부 실패) → 후보 식별자 해석(ensure_candidate_ref)
|
||||
→ membership 대조(provenance 3갈래 + v3 의 평평한 source_refs)
|
||||
→ seed 검증 → 도메인 라벨 해석(_domain_label) → ledger · pack · review_handoff
|
||||
│
|
||||
▼ 조건부 — exception_count == 0 이면 통과만 (R1_SKIPPED)
|
||||
P2-R1 Task_C_BO_R1_exception_adjudicator LLM · max_iterations 1
|
||||
@@ -299,12 +330,12 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
|
||||
| # | task 명칭 | 실행기 / 설정 | 작업 목적 | 작업 내역 |
|
||||
|---|---|---|---|---|
|
||||
| P2-A0 | `Task_C_BO_A0_context_and_domain_slice_compiler` | code-executor · timeout 300 · 통합본 60–581행 | Part 1의 봉인된 산출을 받아 **도메인별 작업 재료를 컴파일하고 fan-out을 계획**한다 | 모듈 8종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `registry_validator` · `prompt_compiler` · `domain_slice_compiler` · `domain_fanout_planner` · `stage_a_context_builder`)을 미러로 반입한다. 봉인 3해시를 검증한다. registry 26 config를 적재한다. `prompt_compiler.collect_domain_fragments(extra_specs=…)`로 Part 1의 어휘 사전을 도메인 프롬프트에 붙인다(조립 프롬프트 6,967 B → 24,942 B 실측). 슬라이스에 `domain_declarations` 7갈래를 투영한다. 스크리닝의 `candidates[].requested_calculation_domains`를 파싱해 도메인 `calculation_bindings`와 교집합하고, 교집합 밖은 `CALC_NOT_IN_BINDINGS` 리뷰로 남기며 `router_status`를 `READY_WITH_REVIEW`로 내린다. **도메인 상수를 두지 않는다** |
|
||||
| P2-B | `Task_C_B_domain_worker_*` | LLM `google / gemini-3.1-flash-lite` · reasoning high · verbosity medium · `max_concurrency: 8` · cache 15m · preflight 2 · 통합본 582–711행 | 단일 도메인의 **BO seed 후보**를 만든다 | 읽는 것은 두 파일뿐 — 조립 프롬프트와 슬라이스. **프롬프트를 다시 조립하지 않는다.** 산출 최상위는 `stage_b_domain_bo_seed_output` 한 키, `schema_version`은 `task_c_bo_stage_b_domain_bo_seed.v3` 고정. 다섯 배열(`element_fact_candidates` · `opposing_fact_candidates` · `defense_candidates` · `calculation_requests` · `dependency_refs`) 이름은 스키마가 정한 것이다. `dependency_refs`는 연결만 남기고 의존 도메인의 결론을 복사하지 않는다. 자기검증 6항(최상위 단일 키, `domain_id`·`task_instance_id` 주입값 일치, `source_refs` ⊆ slice source_universe, `bo_type` ∈ `allowed_legal_effect_bo_types`, `registry_component_ids` ⊆ 합집합, 금지 키 `BO_ID`·`Evidence`·`EvidenceTitles`·`final_*` 부재). **결론을 내리지 않는다 — 후보만 남긴다** |
|
||||
| P2-R0 | `Task_C_BO_R0_seed_reducer_and_exception_planner` | code-executor · timeout 240 · 통합본 712–1,583행 | worker 산출 M개를 **결정론으로 합치고 예외를 좁힌다** | fan-out 계획의 기대집합과 실제 seed 집합을 **정확 일치**로 대조한다(누락·초과·중복 모두 실패). 모듈 4종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `worker_output_validator`)을 반입해 `validate_worker_output`을 **실제로 호출**한다. 슬라이스의 `domain_declarations`로 두 대조를 걸어 `CALCULATION_DOMAIN_NOT_DECLARED`와 `EVIDENCE_SLOT_NOT_DECLARED`를 **review 등급**으로 남긴다. 산출은 넷이다 — seed ledger · 예외 pack · review handoff, 그리고 **worker seed 파일 M개를 제자리에서 다시 쓴다**(`transport_metadata`와 `handoff_guard`를 주입한다. 경로는 fan-out 계획의 `expected_output_path`) |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | LLM · reasoning low · verbosity low · `max_iterations: 1` · cache 20m · preflight 1 · 통합본 1,584–1,686행 | R0이 non-deferrable로 판정한 **compact exception만 판정**한다 | pack 하나만 읽는다. 병합·최종 파일 작성·사실 창작을 하지 않는다. v3 3,621–3,723행과 바이트 동일 |
|
||||
| P2-F0 | `Task_C_BO_F0_final_bo_compiler_gate_writer` | code-executor · timeout 240 · 통합본 1,687–2,437행 | **최종 `BO.json`을 확정**하고 게이트를 쓴다 | PostB_3(final compiler) + PostB_4(final gate/writer) 통합. 입력은 전부 파일 계약(ledger · decisions · stage_a)이다. BOType 어휘를 하드코딩하지 않고 **registry 합집합**에서 해시 검증과 함께 만든다. 확장 payload 키를 `extension_payload_key_declarations.v1.json`과 대조해 미선언 키는 `EXTENSION_PAYLOAD_KEY_UNDECLARED`로 남긴다. R1 산출은 **조건부**로 요구한다(pack의 `exception_count`가 0이면 부재 허용) |
|
||||
| P2-S0 | `Task_C_BO_S0_signal_bundle_writer` | code-executor · timeout 300 · 통합본 2,438–2,987행 | **정본 signal 거래 1건**을 기록한다 | 생성기·사영기·기록기를 여기서 만들지 않는다. 조립본 모듈 24종을 반입한다 — compiler 7(`common` · `projections` · `schema_validator` · `signal_compiler` · `signal_gate` · `transaction_writer` · `writer_boundary`) + adapter 4(`s3_domain_seed_adapter` · `s3_envelope_migration_adapter` · `s4_calculation_adapter` · `sg01_activation_adapter`) + emitter 13(`emitter_runtime` + `emit_sg02`~`emit_sg13`). 정본 기록기가 유일한지 검사한다(`S0_CANONICAL_WRITER_NOT_UNIQUE`). `transaction_id`는 `^S5TX-[a-f0-9]{20}$`. 슬라이스의 `emits_signals` 선언과 실제 방출을 대조해 선언 밖 방출은 `SIGNAL_EMISSION_NOT_DECLARED`로 남긴다(**선언보다 적게 나오는 것은 정상**이므로 그 방향은 세지 않는다). 기록 후 `signal_manifest.json`을 다시 읽어 해시 왕복 일치를 확인한다 |
|
||||
| P2-A0 | `Task_C_BO_A0_context_and_domain_slice_compiler` | code-executor · timeout 300 · 통합본 60–716행 | Part 1의 봉인된 산출을 받아 **도메인별 작업 재료를 컴파일하고 fan-out을 계획**한다 | 모듈 8종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `registry_validator` · `prompt_compiler` · `domain_slice_compiler` · `domain_fanout_planner` · `stage_a_context_builder`)을 미러로 반입한다. 봉인 3해시를 검증한다. registry 26 config를 적재한다. `prompt_compiler.collect_domain_fragments(extra_specs=…)`로 Part 1의 어휘 사전을 도메인 프롬프트에 붙인다(조립 프롬프트 6,967 B → 24,942 B 실측). 슬라이스에 `domain_declarations` 7갈래를 투영한다. 스크리닝의 `candidates[].requested_calculation_domains`를 파싱해 도메인 `calculation_bindings`와 교집합하고, 교집합 밖은 `CALC_NOT_IN_BINDINGS` 리뷰로 남기며 `router_status`를 `READY_WITH_REVIEW`로 내린다. **도메인 상수를 두지 않는다**. 추가 개정 1회차로 `main()` 첫 문장이 `assert_deployment()`가 되었다 — 필수 자산 9 리터럴과 모듈 미러를 **한 벌로** 검사해(실측 17건) 하나라도 빠지거나 해시가 어긋나면 `PART2_ASSET_DEPLOYMENT_INCOMPLETE`로 세운다. 이어 슬라이스 스키마가 `domain_declarations`와 `compiled_prompt.hash_kind`를 아는지 보고(`PART2_SLICE_SCHEMA_STALE`), 컴파일러 산출에 투영이 실제로 실려 나오는지 본다(`PART2_COMPILER_STALE` — 옛 판본은 알 수 없는 인자로 `TypeError`가 먼저 나므로 같은 코드에 `detail: signature_mismatch`를 붙인다). 프롬프트 오버레이 실패 4코드를 승격 대상으로 강제한다 |
|
||||
| P2-B | `Task_C_B_domain_worker_*` | LLM `google / gemini-3.1-flash-lite` · reasoning high · verbosity medium · `max_concurrency: 8` · cache 15m · preflight 2 · 통합본 717–846행 | 단일 도메인의 **BO seed 후보**를 만든다 | 읽는 것은 두 파일뿐 — 조립 프롬프트와 슬라이스. **프롬프트를 다시 조립하지 않는다.** 산출 최상위는 `stage_b_domain_bo_seed_output` 한 키, `schema_version`은 `task_c_bo_stage_b_domain_bo_seed.v3` 고정. 다섯 배열(`element_fact_candidates` · `opposing_fact_candidates` · `defense_candidates` · `calculation_requests` · `dependency_refs`) 이름은 스키마가 정한 것이다. `dependency_refs`는 연결만 남기고 의존 도메인의 결론을 복사하지 않는다. 자기검증 6항(최상위 단일 키, `domain_id`·`task_instance_id` 주입값 일치, `source_refs` ⊆ slice source_universe, `bo_type` ∈ `allowed_legal_effect_bo_types`, `registry_component_ids` ⊆ 합집합, 금지 키 `BO_ID`·`Evidence`·`EvidenceTitles`·`final_*` 부재). **결론을 내리지 않는다 — 후보만 남긴다** |
|
||||
| P2-R0 | `Task_C_BO_R0_seed_reducer_and_exception_planner` | code-executor · timeout 240 · 통합본 847–1,823행 | worker 산출 M개를 **결정론으로 합치고 예외를 좁힌다** | fan-out 계획의 기대집합과 실제 seed 집합을 **정확 일치**로 대조한다(누락·초과·중복 모두 실패). 모듈 4종(`runtime_common` · `schema_subset_validator` · `registry_loader` · `worker_output_validator`)을 반입해 `validate_worker_output`을 **실제로 호출**한다. 슬라이스의 `domain_declarations`로 두 대조를 걸어 `CALCULATION_DOMAIN_NOT_DECLARED`와 `EVIDENCE_SLOT_NOT_DECLARED`를 **review 등급**으로 남긴다. 산출은 넷이다 — seed ledger · 예외 pack · review handoff, 그리고 **worker seed 파일 M개를 제자리에서 다시 쓴다**(`transport_metadata`와 `handoff_guard`를 주입한다. 경로는 fan-out 계획의 `expected_output_path`). 추가 개정으로 넷이 더 붙었다 — ① seed 스키마와 검증기 미러 검사를 **`try` 밖**에서 먼저 한다(안에 두면 swallow-all 이 삼킨다) ② 도메인 라벨을 슬라이스 → 구 이름 표 → ID 순으로 해석한다(`_domain_label`. 개정 전에는 구 이름 다섯 개짜리 표를 대괄호로 조회해 registry ID 마다 `KeyError`였다) ③ v3 봉인 스키마가 `candidate_ref`를 금지하므로 R0가 순번에서 만든다(`ensure_candidate_ref`. 형식 검사는 도메인에 묶지 않고 접두사 검사가 도메인 일치를 맡는다) ④ v3의 평평한 `source_refs`를 Stage A universe 와 대조한다(이 검사가 없으면 v3 산출에서 membership 게이트가 통과만 하는 빈 검사가 된다) |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | LLM · reasoning low · verbosity low · `max_iterations: 1` · cache 20m · preflight 1 · 통합본 1,824–1,926행 | R0이 non-deferrable로 판정한 **compact exception만 판정**한다 | pack 하나만 읽는다. 병합·최종 파일 작성·사실 창작을 하지 않는다. v3 3,621–3,723행과 바이트 동일(추가 개정 4회에서도 손대지 않았다) |
|
||||
| P2-F0 | `Task_C_BO_F0_final_bo_compiler_gate_writer` | code-executor · timeout 240 · 통합본 1,927–2,677행 | **최종 `BO.json`을 확정**하고 게이트를 쓴다 | PostB_3(final compiler) + PostB_4(final gate/writer) 통합. 입력은 전부 파일 계약(ledger · decisions · stage_a)이다. BOType 어휘를 하드코딩하지 않고 **registry 합집합**에서 해시 검증과 함께 만든다. 확장 payload 키를 `extension_payload_key_declarations.v1.json`과 대조해 미선언 키는 `EXTENSION_PAYLOAD_KEY_UNDECLARED`로 남긴다. R1 산출은 **조건부**로 요구한다(pack의 `exception_count`가 0이면 부재 허용) |
|
||||
| P2-S0 | `Task_C_BO_S0_signal_bundle_writer` | code-executor · timeout 300 · 통합본 2,678–3,268행 | **정본 signal 거래 1건**을 기록한다 | 생성기·사영기·기록기를 여기서 만들지 않는다. 조립본 모듈 24종을 반입한다 — compiler 7(`common` · `projections` · `schema_validator` · `signal_compiler` · `signal_gate` · `transaction_writer` · `writer_boundary`) + adapter 4(`s3_domain_seed_adapter` · `s3_envelope_migration_adapter` · `s4_calculation_adapter` · `sg01_activation_adapter`) + emitter 13(`emitter_runtime` + `emit_sg02`~`emit_sg13`). 정본 기록기가 유일한지 검사한다(`S0_CANONICAL_WRITER_NOT_UNIQUE`). `transaction_id`는 `^S5TX-[a-f0-9]{20}$`. 슬라이스의 `emits_signals` 선언과 실제 방출을 대조해 선언 밖 방출은 `SIGNAL_EMISSION_NOT_DECLARED`로 남긴다(**선언보다 적게 나오는 것은 정상**이므로 그 방향은 세지 않는다). 기록 후 `signal_manifest.json`을 다시 읽어 해시 왕복 일치를 확인한다. 추가 개정으로 `signal_registry.v2.json` · `s5_execution_contract.v2.json` · `$ref` 폐포가 닿는 signal 스키마 17종을 `_verify_asset`으로 읽으면서 매니페스트 해시와 대조한다 |
|
||||
|
||||
**모듈의 디렉터리 산술** — S0은 signal 모듈들이 `_SIGNALS_ROOT.parents[1]/contracts/s5_execution_contract.v2.json`을 읽는다는 실측 사실에 맞춰 staging 배치를 재현한다(`/tmp/s1/_sig/contracts/` + `/tmp/s1/_sig/pkg/signals/`). 모듈을 고치면 미러 해시가 깨지므로 배치로 맞춘 것이다.
|
||||
|
||||
@@ -312,9 +343,9 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
|
||||
| # | task | IN | OUT |
|
||||
|---|---|---|---|
|
||||
| P2-A0 | `Task_C_BO_A0_…slice_compiler` | **Part 1 산출 6종** — `quality_gates/stage1_part1_soft_gate_handoff.json` · `routing/domain_activation_manifest.json` · `routing/domain_screening.json` · `evidence_indexed.json` · `evidence_event_candidates.json` · `routing/candidate_profile_vocabulary.md` + **사건 입력** `client_meeting.md` (md) + **자산** `runtime_manifest.json` · `domains/_registry_index.json` · `domains/_common/common_worker_contract.md` · `domains/<id>/domain_config.json` ×26 · `domains/<id>/seed_prompt_overlay.md` (config의 `prompt_overlay_ref`가 지목) · `stage1_runtime/prompt_composition_policy.json` · `platform/schemas/domain_slice.schema.v2.json` · `platform/schemas/domain_fanout_plan.schema.json` + 모듈 미러 8종(`.txt`) | `runtime/domain_slices/<domain_id>.json` (json ×M, `task_c_bo_stage_b_domain_slice.v2`, 루트 키 `stage_b_domain_slice`) · `runtime/compiled_prompts/<domain_id>.md` (md ×M) · `fanout/domain_fanout_plan.json` (json, `domain_fanout_plan.v1`) · `stage1_tmp/task_c_bo/stage_a_context.json` (json, 루트 `stage_a_context`) · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) · `validation_assets/routing/stage_receipt.json` (json, `stage1_stage_receipt.v2`) |
|
||||
| P2-A0 | `Task_C_BO_A0_…slice_compiler` | **Part 1 산출 6종** — `quality_gates/stage1_part1_soft_gate_handoff.json` · `routing/domain_activation_manifest.json` · `routing/domain_screening.json` · `evidence_indexed.json` · `evidence_event_candidates.json` · `routing/candidate_profile_vocabulary.md` + **사건 입력** `client_meeting.md` (md) + **자산** `runtime_manifest.json` · `domains/_registry_index.json` · `domains/_common/common_worker_contract.md` · `domains/<id>/domain_config.json` ×26 · `domains/<id>/seed_prompt_overlay.md` (config의 `prompt_overlay_ref`가 지목) · `stage1_runtime/prompt_composition_policy.json` · `platform/schemas/domain_slice.schema.v2.json` · `platform/schemas/domain_fanout_plan.schema.json` + 모듈 미러 8종(`.txt`) + **배포 게이트가 존재·해시만 확인하는 자산 5종**(`domain_seed_output.schema.v3.json` · `signals/signal_registry.v2.json` · `contracts/signals/s5_execution_contract.v2.json` · `routing/extension_payload_key_declarations.v1.json` · `stage1_runtime/worker_output_validator.txt` — 하류 R0·F0·S0 이 쓸 것을 A0 가 미리 본다) | `runtime/domain_slices/<domain_id>.json` (json ×M, `task_c_bo_stage_b_domain_slice.v2`, 루트 키 `stage_b_domain_slice`) · `runtime/compiled_prompts/<domain_id>.md` (md ×M) · `fanout/domain_fanout_plan.json` (json, `domain_fanout_plan.v1`) · `stage1_tmp/task_c_bo/stage_a_context.json` (json, 루트 `stage_a_context`) · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) · `validation_assets/routing/stage_receipt.json` (json, `stage1_stage_receipt.v2`) |
|
||||
| P2-B | `Task_C_B_domain_worker_*` | `{{item.compiled_prompt_path}}` (md) · `{{item.slice_path}}` (json) — **둘뿐** | `{{item.expected_output_path}}` = `runtime/domain_seed_outputs/<domain_id>.json` (json, `task_c_bo_stage_b_domain_bo_seed.v3`) |
|
||||
| P2-R0 | `Task_C_BO_R0_…exception_planner` | `fanout/domain_fanout_plan.json` · `runtime/domain_slices/<id>.json` ×M · `runtime/domain_seed_outputs/<id>.json` ×M · `stage1_tmp/task_c_bo/stage_a_context.json` · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) + 자산 `platform/schemas/domain_seed_output.schema.v3.json` · `runtime_manifest.json` + 모듈 미러 4종 · **선언만 하고 읽지 않는 상수 2개**(`ACTIVATION_MANIFEST_PATH` · `REGISTRY_INDEX_PATH` — 각각 대입 1회뿐이고 read 0회) | `stage1_tmp/task_c_bo/postb_seed_ledger.json` (json) · `quality_gates/stage1_part2_exception_pack.json` (json) · `quality_gates/stage1_part2_review_handoff.json` (json) · **`runtime/domain_seed_outputs/<domain_id>.json` (json ×M, 제자리 갱신 재기록 — `transport_metadata` + `handoff_guard` 주입)** |
|
||||
| P2-R0 | `Task_C_BO_R0_…exception_planner` | `fanout/domain_fanout_plan.json` · `runtime/domain_slices/<id>.json` ×M · `runtime/domain_seed_outputs/<id>.json` ×M · `stage1_tmp/task_c_bo/stage_a_context.json` · `stage1_tmp/task_c_bo/source_universe_manifest.json` (json) + 자산 `platform/schemas/domain_seed_output.schema.v3.json` · `runtime_manifest.json` + 모듈 미러 4종 · **선언만 하고 읽지 않는 상수 2개**(`ACTIVATION_MANIFEST_PATH` · `REGISTRY_INDEX_PATH` — 각각 대입 1회뿐이고 read 0회). 추가 개정으로 seed 스키마와 검증기 미러는 `_verify_asset`이 **매니페스트 해시와 대조하며** 읽는다 | `stage1_tmp/task_c_bo/postb_seed_ledger.json` (json) · `quality_gates/stage1_part2_exception_pack.json` (json) · `quality_gates/stage1_part2_review_handoff.json` (json) · **`runtime/domain_seed_outputs/<domain_id>.json` (json ×M, 제자리 갱신 재기록 — `transport_metadata` + `handoff_guard` 주입)** |
|
||||
| P2-R1 | `Task_C_BO_R1_exception_adjudicator` | `quality_gates/stage1_part2_exception_pack.json` (json, preflight) | `stage1_tmp/task_c_bo/postb_adjudication_decisions.json` (json, **조건부**) |
|
||||
| P2-F0 | `Task_C_BO_F0_…gate_writer` | `stage1_tmp/task_c_bo/stage_a_context.json` · `postb_seed_ledger.json` · `postb_adjudication_decisions.json`(조건부) · `quality_gates/stage1_part2_review_handoff.json` · `stage1_part2_exception_pack.json` (json) + 자산 `routing/extension_payload_key_declarations.v1.json` · `runtime_manifest.json` | **`BO.json`** (json) · `stage1_tmp/task_c_bo/postb_compiled_bundle_compact.json` (json) · `quality_gates/stage1_part2_review_handoff.json` (json, `FINALIZED`로 **갱신 재기록** — R0과 공동 기록자) |
|
||||
| P2-S0 | `Task_C_BO_S0_signal_bundle_writer` | `BO.json` · `routing/domain_activation_manifest.json` · `fanout/domain_fanout_plan.json` · `stage1_tmp/task_c_bo/source_universe_manifest.json` · `runtime/domain_slices/<id>.json` ×M (json) + 자산 `signals/signal_registry.v2.json` · `contracts/signals/s5_execution_contract.v2.json` · `runtime_manifest.json` + 모듈 미러 24종 | `signals/…` 아래 정본 signal 집합 — `signals/signal_manifest.json` 포함 + 호환 뷰 3종 `signals/compatibility_views/{actio_case,case_liability,legal_effect}_signals.json` + **루트 별칭 3종** `actio_case_signals.json` · `case_liability_signals.json` · `legal_effect_signals.json` (구 이름 호환면, 같은 바이트) |
|
||||
@@ -338,7 +369,7 @@ Part 1 개정이 함께 만든 **검증·회귀 자산**(런타임 입력이 아
|
||||
|
||||
### 3.5 Part 2 작업용 assets — 정확한 배포 위치
|
||||
|
||||
YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다.
|
||||
YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다(추가 개정 4회에서 리터럴 수는 늘지 않았다 — 늘어난 것은 같은 자산을 검사하는 지점이다). 아래 크기는 전부 **정본 조립본** 기준이며, 후보 오버레이는 이제 조립본의 바이트 동일 부분집합이라 두 뿌리 값이 같다(§5.1).
|
||||
|
||||
| 배포 경로 (`Default_Agent/` 기준) | 크기 | 형태 | 쓰는 task | 역할 |
|
||||
|---|---|---|---|---|
|
||||
@@ -346,12 +377,12 @@ YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다.
|
||||
| `domains/_common/common_worker_contract.md` | 3,451 B | md | A0 | 공통 worker 계약문. 사건 종류 이름을 라우팅 키로 쓰지 않는다는 규율을 여기서 선언한다 |
|
||||
| `domains/<id>/domain_config.json` ×26 | — | json | A0 | 8선언 가문 원문 (`element_slots` · `opposing_fact_slots` · `evidence_components` · `defense_map` · `calculation_bindings` · `emits_signals` · `structure_types` · `effect_projection`) |
|
||||
| `domains/<id>/seed_prompt_overlay.md` | — | md | A0 | 도메인 오버레이 산문. **파일명을 하드코딩하지 않고** config의 `prompt_overlay_ref`가 지목하는 것을 따른다 |
|
||||
| `platform/schemas/domain_slice.schema.v2.json` | 13,786 B (조립본) / **17,725 B (후보 오버레이)** | json | A0 | 슬라이스 닫힌 스키마. 개정 내용 셋 — ① `domain_declarations` 블록 추가(패턴 7개 신규) ② `compiled_prompt.hash_kind` 추가 ③ 기존 패턴 1개 교체(`domain_registry.special_law_profiles.items`). 조립본 대비 패턴 자리 26 → 34이며 삭제된 자리는 없다. §6.5가 BLOCKER로 적은 `emits_signals`의 `anyOf`는 기존 패턴 교체가 아니라 **신규 블록 안에서 개정 중 교정한 것**이다 |
|
||||
| `platform/schemas/domain_slice.schema.v2.json` | **17,725 B** | json | A0 | 슬라이스 닫힌 스키마. 개정 내용 셋 — ① `domain_declarations` 블록 추가(패턴 7개 신규) ② `compiled_prompt.hash_kind` 추가 ③ 기존 패턴 1개 교체(`domain_registry.special_law_profiles.items`). 조립본 대비 패턴 자리 26 → 34이며 삭제된 자리는 없다. §6.5가 BLOCKER로 적은 `emits_signals`의 `anyOf`는 기존 패턴 교체가 아니라 **신규 블록 안에서 개정 중 교정한 것**이다 |
|
||||
| `platform/schemas/domain_fanout_plan.schema.json` | 11,148 B | json | A0 | fan-out 계획 스키마 |
|
||||
| `platform/schemas/domain_seed_output.schema.v3.json` | 21,965 B | json | R0 · (B 프롬프트가 이름으로 지목) | worker 산출 스키마 |
|
||||
| `routing/evidence_component_union.md` | 17,593 B | md | (B 프롬프트가 이름으로 지목) | 증거 구성요소 합집합 어휘 |
|
||||
| `routing/extension_payload_key_declarations.v1.json` | **23,071 B (후보 오버레이 전용)** | json | F0 | 확장 payload 키 선언표(`stage1_extension_payload_key_declarations.v1`) |
|
||||
| `runtime_manifest.json` | 47,340 B (조립본, 362항) / **57,247 B (후보 오버레이, 365항)** | json | A0 · R0 · F0 · S0 | 모듈 미러 sha256 선언표 |
|
||||
| `routing/extension_payload_key_declarations.v1.json` | 23,071 B | json | F0 | 확장 payload 키 선언표(`stage1_extension_payload_key_declarations.v1`) |
|
||||
| `runtime_manifest.json` | **58,046 B · 370항** | json | A0 · R0 · F0 · S0 | 모듈 미러 sha256 선언표. A0 의 배포 게이트가 `runtime_artifact_count`와 자기 sha256 을 영수증에 적는다 |
|
||||
| `signals/signal_registry.v2.json` | 10,907 B | json | S0 | signal 13종 registry |
|
||||
| `contracts/signals/s5_execution_contract.v2.json` | 1,451 B | json | S0 | 실행 계약. 모듈이 `_SIGNALS_ROOT.parents[1]/contracts/` 아래에서 찾는다 |
|
||||
| `stage1_runtime/prompt_composition_policy.json` | 1,715 B | json | A0 | 프롬프트 조립 정책. sha256을 fan-out row에 기록 |
|
||||
@@ -365,10 +396,10 @@ YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다.
|
||||
| `registry_loader` | 6,404 B | A0 · R0 · (D0) | registry 적재 |
|
||||
| `registry_validator` | 11,080 B | A0 | registry 검증 |
|
||||
| `prompt_compiler` | 15,164 B | A0 | 프롬프트 조립. `collect_domain_fragments(extra_specs=…)` 훅 |
|
||||
| `domain_slice_compiler` | 28,861 B (조립본) / **32,300 B (후보)** | A0 | 슬라이스 컴파일. 개정으로 `_declaration_ids` · `_domain_declarations` 추가 |
|
||||
| `domain_slice_compiler` | **32,300 B** | A0 | 슬라이스 컴파일. 개정으로 `_declaration_ids` · `_domain_declarations` 추가. 라벨의 정본은 이 모듈이 `label_ko`를 `stage_b_domain_slice.domain_label`에 실어 보내는 자리다(R0 의 `_domain_label`이 그것을 읽는다) |
|
||||
| `domain_fanout_planner` | 12,282 B | A0 | fan-out 계획 |
|
||||
| `stage_a_context_builder` | **25,885 B (후보 오버레이 전용)** | A0 | v3 A0의 `_build_meeting_clause_map` · `_build_event_candidate_map` · `_build_evidence_authority_map`를 원문 그대로 옮기고 `attach_registry_component_ids`(C-1)와 `build_stage_a_context` / `build_source_universe_manifest`를 더한 신설 모듈 |
|
||||
| `worker_output_validator` | 18,701 B (조립본) / **21,302 B (후보)** | R0 | worker 산출 검증. 개정으로 `domain_declarations` 기반 대조 2종 추가(서명 불변) |
|
||||
| `stage_a_context_builder` | 25,885 B | A0 | v3 A0의 `_build_meeting_clause_map` · `_build_event_candidate_map` · `_build_evidence_authority_map`를 원문 그대로 옮기고 `attach_registry_component_ids`(C-1)와 `build_stage_a_context` / `build_source_universe_manifest`를 더한 신설 모듈 |
|
||||
| `worker_output_validator` | **21,302 B** | R0 | worker 산출 검증. 개정으로 `domain_declarations` 기반 대조 2종 추가(서명 불변). A0 의 배포 게이트가 이 모듈의 `.txt` 미러를 R0 대신 미리 확인한다 |
|
||||
|
||||
**반입 모듈 — S0이 쓰는 signal 계열 24종 (전부 `.txt` 미러로 반입)**
|
||||
|
||||
@@ -393,8 +424,9 @@ YAML이 참조하는 `Default_Agent/…` 자산은 **20개 리터럴**이다.
|
||||
| `validation_assets/replay/_promote_seed_v2_to_v3.py` + `.txt` | — | py + 미러 | 구 seed 판본 승격기 |
|
||||
| `validation_assets/replay/_dry_run_stage1.py` + `.txt` | — | py + 미러 | 예행 실행기. `httpx.Client.post`를 대역해 실제 MCP 배관을 태운다 |
|
||||
| `validation_assets/replay/replay_manifest.v1.json` | — | json | 산출물별 출처 표기 (`case_input` / `v3_actual_output` / `replay_stub`) |
|
||||
| `validation_assets/replay/dry_run_receipt.v1.json` | 4,478 B | json | R-6 예행 영수증 |
|
||||
| `validation_assets/replay/dry_run_receipt.v1.json` | **16,772 B** | json | 예행 영수증. 추가 개정으로 **시험 13건**(배포 게이트 회귀 R-a~R-i + 라벨 해석 + seed 보강 R-j~R-l)과 2패스 사슬 기록 `part2_full_chain`을 담는다 |
|
||||
| `routing/_build_extension_payload_declarations.py` + `.txt` | 8,842 B | py + 미러 | 확장 payload 키 선언표 생성기 |
|
||||
| **`validation_assets/replay/_build_domain_seed_v4_stub.py` + `.txt`** | 12,403 B | py + 미러 | **신설.** 활성 도메인의 seed 후보를 슬라이스의 `domain_declarations`와 Stage A 출처 목록에서 **규칙으로** 만든다. 사건 이름도 사실관계도 짓지 않으므로 137종 어느 사건이든 같은 규칙으로 선다. 이미 후보가 있는 seed 는 건드리지 않는다 |
|
||||
|
||||
---
|
||||
|
||||
@@ -454,74 +486,47 @@ Part 1이 만들어 **Part 2가 읽는** 파일은 여섯이다.
|
||||
|
||||
## 5. 자산 배포 지형
|
||||
|
||||
### 5.1 두 뿌리
|
||||
### 5.1 한 뿌리로 합쳐졌다
|
||||
|
||||
자산은 **두 곳**에 있고 역할이 다르다. 이 구분이 문서를 읽는 데 가장 중요하다.
|
||||
앞 판본은 자산이 **두 곳**에 있고 역할이 다르다고 적었다. 2026-08-18 회차에서 그 상태가 정리됐다.
|
||||
|
||||
| 뿌리 | 경로 | 파일 수 | 역할 |
|
||||
| 뿌리 | 경로 | 파일 수 | 지금의 역할 |
|
||||
|---|---|---|---|
|
||||
| **정본 조립본** | `v.7/extension_research/선행구축/Default_Agent_Stage_1/` | 1,300 | 런타임이 `Default_Agent/`로 보는 실제 배포 트리. `domains/` 26 · `special_law_profiles/` · `computations/` 등 전부 여기 있다 |
|
||||
| **후보 오버레이** | `v.7/extension_research/ver_8_yaml_candidates/Default_Agent_Stage_1/` | 558 | 개정이 만들거나 고친 것만 **배포 경로 그대로** 놓은 델타 트리 (제약 [2]) |
|
||||
| **정본 조립본** | `v.7/extension_research/선행구축/Default_Agent_Stage_1/` | **1,322** | 런타임이 `Default_Agent/`로 보는 실제 배포 트리. 실행이 읽는 것은 여기 하나뿐이다 |
|
||||
| **후보 오버레이** | `v.7/extension_research/ver_8_yaml_candidates/Default_Agent_Stage_1/` | **560** | 개정 산출물을 배포 경로 그대로 두는 자리(제약 [2]). 지금은 조립본의 **바이트 동일 부분집합**이다 |
|
||||
|
||||
후보 오버레이 558 파일을 정본 조립본과 전수 해시 대조한 결과다.
|
||||
**델타 30건은 한 벌로 반영됐다.** 반영 직전 실측으로 후보 558건이 세 갈래로 갈렸다 — **바이트 동일 528 · 내용 상이 7 · 후보에만 23**. 상이 7 은 스키마 1 + 모듈 4(`.py`/`.txt` 쌍 둘) + 매니페스트 2 이므로, 반영 대상은 **신규 23 + 변경 5 + 매니페스트 2 = 30건 · 712,193 B** 이다(같은 7건을 어느 쪽으로 세느냐의 차이일 뿐 대상은 하나다), 덮어써질 조립본 원본 7건을 `outdated/_assembly_pre_delta/`에 보존한 뒤 **한 번의 반복문 안에서** 통째로 옮겼다. 부분 복사가 성립할 여지를 두지 않기 위해 목록을 먼저 확정하고 통째로 옮기는 순서를 지켰다.
|
||||
|
||||
| 갈래 | 수 | 내용 |
|
||||
|---|---|---|
|
||||
| 바이트 동일 | **528** | 이미 조립본에 반영된 것 (Part 1 W-B 단계에서 522 파일 반영 완료) |
|
||||
| 내용 상이 | **7** | `platform/schemas/domain_slice.schema.v2.json` · `stage1_runtime/domain_slice_compiler.py`+`.txt` · `stage1_runtime/worker_output_validator.py`+`.txt` · `release_manifest.json` · `runtime_manifest.json` |
|
||||
| 후보에만 존재 | **23** | 아래 표 |
|
||||
반영 후 대조는 **동일 558 · 상이 0 · 부재 0**이다. 이후 회차가 더한 두 자산(`_build_domain_seed_v4_stub.py`와 그 미러)까지 양쪽에 같은 경로로 두어, 현재 후보 560건은 전부 조립본과 바이트가 같다.
|
||||
|
||||
**후보 오버레이에만 있는 신규 자산 23**
|
||||
**그래서 §6.2 검사 10의 각주가 바뀐다.** 앞 판본은 "자산 실재 · 미존재 0"이 후보 오버레이 기준으로만 참이라고 적었다. 지금은 **정본 조립본 기준으로도 참**이며, 실증으로 `--asset-root`를 조립본 폴더 자체로 겨눈 예행이 통과한다(§6.4). 앞 판본이 "남은 것은 복사 한 단계"라고 적은 그 한 단계가 실행됐다.
|
||||
|
||||
```
|
||||
handoffs/stage1_part_interface.v1.json
|
||||
handoffs/stage1_stage_chain.v1.json
|
||||
routing/_build_extension_payload_declarations.py + .txt
|
||||
routing/extension_payload_key_declarations.v1.json
|
||||
stage1_runtime/stage_a_context_builder.py + .txt
|
||||
validation_assets/replay/_build_screening_draft_stub.py + .txt
|
||||
validation_assets/replay/_dry_run_stage1.py + .txt
|
||||
validation_assets/replay/_promote_seed_v2_to_v3.py + .txt
|
||||
validation_assets/replay/dry_run_receipt.v1.json
|
||||
validation_assets/replay/replay_manifest.v1.json
|
||||
validation_assets/routing/_check_schema_keyword_support.py + .txt
|
||||
validation_assets/routing/_check_stage1_interface.py + .txt
|
||||
validation_assets/routing/_compare_legacy_seed_equivalence.py + .txt
|
||||
validation_assets/routing/legacy_seed_baseline_manifest.json
|
||||
validation_assets/routing/legacy_seed_equivalence_contract.json
|
||||
```
|
||||
|
||||
**조립본 미반영 (기록)** — 반영해야 할 것은 **델타 30건 한 벌**이고(신규 23 · 내용 상이 5 · 매니페스트 2), 그중 `stage_1_part_2_v.8.yml`이 **런타임 입력으로 참조하는** 자산은 아래 둘이다. 둘은 후보 오버레이의 정확한 배포 경로에 **이미 있고** 오버레이 매니페스트에 등재까지 되어 있다 — 새로 만들 것은 없다. 정본 조립본에만 없을 뿐이며, 다른 28건보다 더 "없는" 것이 아니다.
|
||||
|
||||
| 참조 | 후보 오버레이 | 정본 조립본 |
|
||||
|---|---|---|
|
||||
| `Default_Agent/routing/extension_payload_key_declarations.v1.json` | 23,071 B | **부재** |
|
||||
| `Default_Agent/stage1_runtime/stage_a_context_builder.txt` (+`.py`) | 25,885 B | **부재** |
|
||||
|
||||
Part 2 완료 보고서의 검사 10(`Default_Agent/…` 자산 실재 · 미존재 0)은 **후보 오버레이 기준**으로 참이고, 정본 조립본 기준으로는 델타 30건이 미반영이다. 두 진술은 서로 다른 뿌리를 가리키므로 모순이 아니다. Part 1은 개정 후 조립본 반영(W-B)까지 마쳤고 Part 2는 후보 트리까지 마친 상태이므로, 남은 것은 **복사 한 단계**다 — 새 자산을 만드는 일이 아니다. 그리고 **부분 복사는 허용되지 않는다.** 파일만 옮기고 매니페스트를 두면 `MODULE_MIRROR_HASH_MISMATCH`/`_UNREGISTERED`, 매니페스트만 옮기면 읽기 실패, `domain_slice.schema.v2.json`을 빠뜨리면 26 도메인 슬라이스가 전멸한다. 통합본이 이 부분 복사를 완전히 막지는 못한다는 진단과 그 최소 수정안은 `stage_1_part_2_additional_fix_strategy.md`에 있다.
|
||||
**두 뿌리 체제가 남긴 것 하나** — 후보 오버레이를 지워도 실행에는 무방하다(조립본이 상위집합이므로). 다만 지워도 되는 것은 오버레이 `Default_Agent_Stage_1/` 한 겹이고, 그 **상위 폴더** `ver_8_yaml_candidates/`에는 작업명세서 본체와 개별 task yaml 이 들어 있어 함께 지우면 실행할 명세가 사라진다.
|
||||
|
||||
### 5.2 미러 규약 실측
|
||||
|
||||
| 뿌리 | `.py` | 미러 존재·해시 일치 | 미러 없음 | 해시 불일치 |
|
||||
|---|---|---|---|---|
|
||||
| 정본 조립본 | 103 | **102** | 1 (`tools/build_default_agent_stage1.py` — 선언된 예외) | **0** |
|
||||
| 후보 오버레이 | 15 | **14** | 1 (같은 빌더) | **0** |
|
||||
| 정본 조립본 | **112** | **111** | 1 (`tools/build_default_agent_stage1.py` — 선언된 예외) | **0** |
|
||||
| 후보 오버레이 | **16** | **15** | 1 (같은 빌더) | **0** |
|
||||
|
||||
후보 오버레이에는 `.py` 없이 `.txt`만 있는 파일이 97개다. 정본 `.py`는 이미 조립본에 있고 개정이 새로 만든 것은 **미러뿐**인 경우가 그렇다(Part 1 델타 522의 `.txt` 미러 100).
|
||||
|
||||
파일 형태 분포: 후보 오버레이 `.json` 431 · `.txt` 111 · `.py` 15 · `.md` 1 = 558. 정본 조립본 `.json` 1,044 · `.py` 103 · `.txt` 103 · `.md` 40 · `.whl` 6 · `.pyc` 3 · `.yml` 1 = 1,300.
|
||||
파일 형태 분포: 후보 오버레이 `.json` 431 · `.txt` 112 · `.py` 16 · `.md` 1 = 560. 정본 조립본 `.json` 1,051 · `.py` 112 · `.txt` 112 · `.md` 40 · `.whl` 6 · `.yml` 1 = 1,322. **조립본의 `.pyc` 3과 `__pycache__` 는 사라졌다**(앞 판본 §6.2 검사 20의 잔여 항목이었다).
|
||||
|
||||
### 5.3 매니페스트 2종
|
||||
### 5.3 매니페스트 3종
|
||||
|
||||
| 매니페스트 | 정본 조립본 | 후보 오버레이 | 성격 |
|
||||
|---|---|---|---|
|
||||
| `release_manifest.json` | 199,028 B · **1,295**항 | 247,609 B · **1,318**항 | 조립 전체 산출물 선언 (`stage1_assembly_release_manifest.v1`). 정책 `NON_CIRCULAR_SELF_EXCLUDED` — 자기 자신만 미등재 |
|
||||
| `runtime_manifest.json` | 47,340 B · **362**항 | 57,247 B · **365**항 | 런타임 반입 모듈 sha256 선언 (`.py`와 `.txt`가 같은 해시를 선언해야 한다) |
|
||||
| `source_copy_map.json` | 2,116,485 B | 2,116,485 B (**양 뿌리 바이트 동일**) | 복사 계보 (`stage1_source_copy_map.v1`) — `copy_rows` 1,140 · `source_dispositions` 5,943 · collision 0 · byte mismatch 0 · missing source 0 |
|
||||
| 매니페스트 | 값 | 성격 |
|
||||
|---|---|---|
|
||||
| `release_manifest.json` | **248,002 B · 1,320항** | 조립 전체 산출물 선언 (`stage1_assembly_release_manifest.v1`). 미선언은 둘 — 자기 자신과 `stage1_runtime/Stage_1_Registry_Runtime_v1.yml` |
|
||||
| `runtime_manifest.json` | **58,046 B · 370항** | 런타임 반입 모듈 sha256 선언 (`.py`와 `.txt`가 같은 해시를 선언해야 한다) |
|
||||
| `source_copy_map.json` | **2,128,630 B · `copy_rows` 1,158 · `source_dispositions` 5,961** | 복사 계보 (`stage1_source_copy_map.v1`) |
|
||||
|
||||
둘 다 전수 해시·크기 대조에서 표류 0이다. 후보 오버레이 쪽 수치는 Part 2 개정 완료 시점 값이고, 조립본 쪽은 Part 1 반영 완료 시점 값이다.
|
||||
셋 다 양 뿌리에서 **바이트 동일**이고, 앞의 둘은 조립본 전수 해시·크기 대조에서 표류 0이다.
|
||||
|
||||
---
|
||||
**`source_copy_map` 은 이제 빌더가 실제로 만들 수 있는 것을 적는다.** 앞 판본 시점에는 이 표가 델타를 따라오지 못했다 — 신규 23건에 행이 없었고, 변경된 두 모듈은 표에 적힌 해시가 **반영 전** 값이었으며 원천 `S_1_GPT_v2/`도 옛 바이트를 쥐고 있었다. 그 상태에서 빌더를 돌리면 재생성에 실패하는 데 그치지 않고 두 모듈을 옛 판으로 되돌리려다 `EXISTING_TARGET_BYTE_CONFLICT`에서 섰다. 세 번째 회차가 상류 두 모듈을 조립본 내용으로 맞추고, 빌더에 조립본 작성 자산 15건을 `ASSEMBLY_ROOT` 앵커로 등록했으며(나머지 8건은 미러 규칙이 자동 생성), 네 번째 회차가 `copy_platform()`의 이름 패턴을 `*.schema*.json`으로 넓혀 판본이 붙은 스키마 둘을 마저 등록했다.
|
||||
|
||||
빈 target 신선 빌드 기준 파일 수는 891 → 893(스키마 2건) → **895**(seed 대역 생성기)로 늘었다. 다만 신선 빌드는 **아직 조립본을 재현하지 못한다**(895 vs 1,322). 결손의 대부분은 스크립트가 만들어 내는 137종 라우팅 회귀 픽스처 411건이며, 그 복사 규칙을 지금 빌더가 잃은 상태다(§6.6).
|
||||
|
||||
## 6. 검증 상태
|
||||
|
||||
@@ -540,7 +545,7 @@ Part 2 완료 보고서의 검사 10(`Default_Agent/…` 자산 실재 · 미존
|
||||
|
||||
조립 중 잡힌 오류 하나를 기록해 둔다. 첫 조립본은 `tasks:`와 `task_procedure:`가 각각 여섯 벌로 나왔다. 독립 스테이지 파일에서는 `task_procedure:`가 `tasks:`보다 **먼저** 나오므로 슬라이스 시작 행 추출의 첫 매치가 `task_procedure` 행이 되어, 각 조각이 자기 그래프와 `tasks:` 헤더까지 끌고 들어온 것이다. YAML은 파싱에 성공했다 — 같은 층 중복 키는 뒤엣것이 이기므로 조용히 통과한다. **구문 통과는 조립 정합의 증거가 아니고, 중복 키를 잡는 것은 파서가 아니라 선언 계수 검사다.**
|
||||
|
||||
### 6.2 Part 2 — 검사 20항 (전부 통과)
|
||||
### 6.2 Part 2 — 검사 20항 (전부 통과) + 추가 개정 회귀 13종
|
||||
|
||||
| # | 검사 | 결과 |
|
||||
|---|---|---|
|
||||
@@ -548,20 +553,40 @@ Part 2 완료 보고서의 검사 10(`Default_Agent/…` 자산 실재 · 미존
|
||||
| 2 | `task_name` ↔ 노드 1:1 | task 6 / 노드 6 · 차집합 0 |
|
||||
| 3 | 선언 1벌 | 각 1 |
|
||||
| 4 | DAG edge 정합 | 노드 8 · 오류 0 |
|
||||
| 5 | R1이 v3와 바이트 동일 | True (통합본 1,584–1,686행) |
|
||||
| 5 | R1이 v3와 바이트 동일 | True (통합본 1,824–1,926행) |
|
||||
| 6 | code-executor `parameters` 5키 | 위반 0 |
|
||||
| 7 · 8 · 9 | 구 slice 경로 · 구 seed 경로 · 정적 worker 이름(주석 외) | 0 · 0 · 0 |
|
||||
| 10 | `Default_Agent/…` 자산 실재 | 미존재 0 (후보 오버레이 기준 — §5.1 참조) |
|
||||
| 10 | `Default_Agent/…` 자산 실재 | 미존재 0 — **이제 정본 조립본 기준으로도 참**이다(§5.1). A0 의 배포 게이트가 매 실행마다 17건을 실측한다 |
|
||||
| 11 | 계약 키 존재 | `domain_declarations` · `calculation_domains` · `emits_signals` · `candidate_profile_vocabulary` · `requested_calculation_domains` 전부 |
|
||||
| 12 | embedded python | AST 실패 0 · 미정의 이름 0 · 미사용 def 1(`clip`, v3 원문) |
|
||||
| 13 | 인계면 전수 대조 | PASS · finding 0 |
|
||||
| 14 | 스키마 미지원 키워드 | PASS · 3/3 |
|
||||
| 15 | 개별 6종 ↔ 통합본 | 불일치 0 |
|
||||
| 15 | 개별 6종 ↔ 통합본 | 불일치 0 (추가 개정 뒤 재대조 — R0 코드 본문 967행 양쪽 동일) |
|
||||
| 16 | 26 도메인 전수 compile (스키마 주입) | READY / slice_count 26 / 스키마 실패 0 |
|
||||
| 17 | `calculation_registry` · `computations/` 참조 | 0 · 0 |
|
||||
| 18 | `release_manifest` 전수 해시·크기 | 1,318항 · 불일치 0 |
|
||||
| 19 | `runtime_manifest` 전수 해시 | 365항 · 불일치 0 |
|
||||
| 20 | `__pycache__` · `.pyc` | **후보 오버레이 0 · 0.** 정본 조립본은 `stage1_runtime/__pycache__/` 1개와 그 안의 `.pyc` 3개(`runtime_common` · `registry_loader` · `schema_subset_validator`)가 아직 남아 있다(§5.2의 `.pyc` 3과 같은 것이다). 격리 폴더 `outdated/_pycache_from_candidate/`(5)와 `part_2_prerequisite/_to_delete/`(1)에 6개가 더 있고, 마운트가 삭제를 허용하지 않아 이동만 했다 |
|
||||
| 18 | `release_manifest` 전수 해시·크기 | **1,320항** · 불일치 0 |
|
||||
| 19 | `runtime_manifest` 전수 해시 | **370항** · 불일치 0 |
|
||||
| 20 | `__pycache__` · `.pyc` | **양 뿌리 0 · 0.** 앞 판본이 잔여로 적은 조립본 `.pyc` 3개는 이후 회차에서 격리 폴더로 옮겨져 사라졌다 |
|
||||
|
||||
**추가 개정 4회가 세운 회귀 13종** — `validation_assets/replay/dry_run_receipt.v1.json`(16,772 B)의 `deployment_gate_regression.tests` 에 기록돼 있다. 변종마다 고정 스테이징 경로 `/tmp/s1` 과 `/tmp/s1_r0` 을 먼저 지운다(앞 시험이 남긴 사본이 다음 판정을 바꾼다 — 실제로 한 번 겪었고 영수증 `staging_note` 에 적었다).
|
||||
|
||||
| id | 시나리오 | 관측된 것 |
|
||||
|---|---|---|
|
||||
| R-a | 매니페스트만 옛 판본(362항) | `PART2_ASSET_DEPLOYMENT_INCOMPLETE` |
|
||||
| R-b | 스키마와 그 매니페스트 항목을 **함께** 옛 판본으로 | `PART2_SLICE_SCHEMA_STALE` (장부 검사만으로는 통과하므로 의미 검사가 잡는다) · 기록된 슬라이스 0 |
|
||||
| R-c | `worker_output_validator.txt` 만 옛 판본 | A0 `hash_mismatch` 1건 · R0 `PART2_ASSET_DEPLOYMENT_INCOMPLETE` |
|
||||
| R-d | **완전 반영 — 대조군** | `PASS · step 6 · write 45 · P2-A0 READY · 슬라이스 3 · 프롬프트 3` |
|
||||
| R-e | 하류 단독 실행 | 자산을 되돌린 트리에서 R0 는 `domain_seed_output.schema.v3.json` unregistered, S0 는 `s5_execution_contract.v2.json` unregistered. 기준 트리에서는 배포 오류 0. 완주는 이 회차에서 미도달이었다 |
|
||||
| R-f | 26 도메인 전수 compile (합성 활성 매니페스트) | READY / 26 / 스키마 실패 0 |
|
||||
| R-g | 실제 옛 컴파일러 | `PART2_COMPILER_STALE · detail signature_mismatch` |
|
||||
| R-g2 | 서명은 같고 투영만 잃은 합성 컴파일러 | `PART2_COMPILER_STALE` · 기록된 슬라이스 0 |
|
||||
| R-h | `seed_prompt_overlay.md` 한 개 누락 | `PART2_ASSET_DEPLOYMENT_INCOMPLETE · detail prompt_overlay · codes [PROMPT_OVERLAY_NOT_FOUND]` |
|
||||
| R-i | R0 의 도메인 라벨 조회가 registry ID 로 도는가 | 개정 전 `KeyError: 'X1'` → 개정 후 통과. 단위 탐침 `X1` → `통지·의사표시 도달 lifecycle` · 미등록 `E-99` → `E-99` · 구 이름 `B1_Money_Successor` → `금전채권 및 상호속용 책임` |
|
||||
| R-j | registry 유래 seed 대역으로 R0 완주 | PASS · 기록 6건 (개정 전에는 `candidate_ref invalid` 로 섰다) |
|
||||
| R-k | F0 · S0 완주 | PASS · 두 단계 합 기록 32건. **F0 는 이번이 예행 첫 실행**이다 |
|
||||
| R-l | v3 `source_refs` membership 음성 시험 | `BLOCK: X1.X1:001: source_refs outside Stage A universe: ['E-999']` |
|
||||
|
||||
R-b 와 R-g2 는 **장부 검사와 의미 검사가 서로 다른 실패를 잡는다**는 것을 보이려고 넣은 짝이다. 자산과 매니페스트 항목이 함께 옛 값으로 돌아가면 해시 대조는 전부 통과한다 — 그때 무는 것은 스키마가 무엇을 아는지 보는 검사(입력 쪽)와 컴파일러 산출에 투영이 실려 나오는지 보는 검사(출력 쪽)다.
|
||||
|
||||
### 6.3 registry 26 도메인 선언 투영 실측
|
||||
|
||||
@@ -579,9 +604,15 @@ Part 2 개정의 핵심 수치다. 26 도메인 `domain_config.json`을 전수
|
||||
|
||||
빈 넷은 구조적으로 옳다 — EC-00은 공통층이라 반대사실·항변·구조유형이 없고, E-00은 잔여 수집기라 계산이 없다.
|
||||
|
||||
### 6.4 예행 6단계 (실입력)
|
||||
### 6.4 예행 — 2패스 9단계 (실입력)
|
||||
|
||||
`client_meeting.md` 10,850 B · `evidence_all.json` 87,436 B를 물려 `_dry_run_stage1.py`로 6단계 전부 통과했다. 영수증은 `validation_assets/replay/dry_run_receipt.v1.json`(4,478 B).
|
||||
`client_meeting.md` 10,850 B · `evidence_all.json` 87,436 B를 물려 `_dry_run_stage1.py`로 돌린다. 앞 판본은 6단계였고, 지금은 **A0 뒤에 seed 대역 생성을 끼운 2패스**다. 실행 루트 하나를 이어 쓴다.
|
||||
|
||||
| 패스 | 내용 | 결과 |
|
||||
|---|---|---|
|
||||
| pass1 | Part 1 코드 task 5종 + Part 2 A0 | **PASS · 6단계 · 기록 45건** |
|
||||
| (사이) | `_build_domain_seed_v4_stub.py` — 활성 도메인 seed 대역 | written 3 (X1·X2·X3) · skipped [] · 인용 출처 [E-001, E-002] |
|
||||
| pass2 | Part 2 R0 · F0 · S0 | **PASS · 3단계 · 기록 32건** |
|
||||
|
||||
| 단계 | 결과 | 기록 수 |
|
||||
|---|---|---|
|
||||
@@ -591,10 +622,21 @@ Part 2 개정의 핵심 수치다. 26 도메인 `domain_config.json`을 전수
|
||||
| `Task_D0_domain_activation_gate` | READY_WITH_REVIEW | 1 |
|
||||
| `Task_B2_SHA256_soft_gate_handoff_writer` | SOFT_GATE_HANDOFF_WRITTEN | 1 |
|
||||
| `Task_C_BO_A0_context_and_domain_slice_compiler` | **READY** | 10 |
|
||||
| `Task_C_BO_R0_seed_reducer_and_exception_planner` | **완주** | pass2 합 32 |
|
||||
| `Task_C_BO_F0_final_bo_compiler_gate_writer` | **완주** | 〃 |
|
||||
| `Task_C_BO_S0_signal_bundle_writer` | **완주** | 〃 |
|
||||
|
||||
예행의 범위 한계는 영수증이 세 줄로 적어 두었다. 첫째, **Part 1 code task 8종 중 5종만 돌았다** — `Task_B1_quality_gate_evidence_indexed` · `Task_B2_quality_gate_event_candidates` · `Task_B12_gate_audit_finalizer` 셋은 B1·B2 와일드카드 fan-out 인스턴스의 산출을 `{{item.*}}` 경로로 요구하는데 재생 세트가 그 단계를 완성본으로 통째 대역하므로 다시 돌릴 입력이 없다(`part1_code_task_coverage`). 둘째, 예행의 활성 도메인이 X1·X2·X3 셋뿐이다. 셋째, 예행의 스크리닝 후보 11개 전부에 `requested_calculation_domains`가 부재하다(대역이 그 판단을 지어내지 않는다) — 그래서 교집합 경로를 `calculation_intersection_probe`로 따로 실측했다.
|
||||
pass2 세 줄의 "완주"는 하네스가 실패로 세지 않았다는 뜻이며(영수증 `part2_code_task_completion` 이 넷 다 PASS 로 적는다), 각 task 가 스스로 낸 상태는 별개다 — R0 `READY` · F0 `PASS` · S0 `READY_WITH_REVIEW`(호환 뷰가 비어 `COMPATIBILITY_VIEW_EMPTY` 리뷰 둘이 달린다). pass1 여섯 줄 가운데 다섯은 각 task 가 낸 상태 그대로이고, `Task_Evidence_shard_planner` 한 줄만 다르다 — 이 task 는 `status` 를 내지 않고 `planner_status: READY` 를 낸다. 표의 "성공"은 하네스가 실패로 세지 않았다는 뜻이다.
|
||||
|
||||
예행이 대역한 것과 실제 산출을 `replay_manifest.v1.json`이 산출물별로 `case_input` / `v3_actual_output` / `replay_stub`으로 표기한다. 대역의 한계로 예행의 활성 도메인이 셋(X1·X2·X3)뿐이므로 **26 도메인 경로는 별도로 실측**했다 — 26 도메인 전부를 `execution_eligible`로 둔 합성 매니페스트에 슬라이스 스키마를 주입해 `compile_domain_slices`를 돌려 READY / 26 / 실패 0을 확인했다.
|
||||
**Part 2 의 코드 task 넷이 모두 완주한 것은 이 회차가 처음이다.** 앞 판본 시점에는 A0 하나만 돌았고, F0 는 예행 영수증에 이름이 오른 적조차 없었다. 산출로 `BO.json` 과 `signals/` 아래 signal 번들이 실제로 생겼다. Part 2 의 나머지 둘(`Task_C_B_domain_worker_*` · `Task_C_BO_R1_exception_adjudicator`)은 코드 블록이 없는 LLM task 라 하네스가 구조상 건너뛴다 — seed 와 무관하다.
|
||||
|
||||
**무엇이 막고 있었나.** "seed 재료가 없다"는 진단은 절반이었다. seed 파일 자체는 승격 스크립트가 이미 모든 도메인에 쓰고 있었고 비어 있던 것은 **후보**였다(구 이름 실산출 B1~B5 를 별칭표가 보내는 곳은 E-02·E-03·E-04·E-10·E-11·E-13·E-15 일곱인데 예행 활성은 X1·X2·X3 이라 겹치는 것이 없다). 후보를 채우자 다음 층이 드러났다 — R0 의 `CANDIDATE_REF_RE` 가 `^B[1-5]:[0-9]{3}$` 인데 같은 함수가 도메인 접두사도 요구해서 **registry ID 26종 어느 것으로도 동시에 만족될 수 없었다.** 게다가 v3 seed 스키마는 루트와 후보 모두 `additionalProperties: false` 로 봉인돼 있어 워커가 `candidate_ref` 를 실을 방법이 없다. 그래서 고칠 곳은 스키마가 아니라 R0 였다(R0 자신의 주석이 "v3 계약이 정본"이라고 적어 두었다).
|
||||
|
||||
**대역이 무엇을 근거로 만드는가.** 후보의 내용은 슬라이스의 `domain_declarations`(정본은 registry 의 `domain_config`)와 Stage A 의 출처 목록에서만 온다. 요건·반대사실 슬롯은 `evidence_slot_status` 에 `missing` 으로 이름만 옮기고, `element_fact_candidates` 에는 슬롯이 아니라 **출처**를 넣는다(슬롯 ID 를 출처 자리에 넣으면 검증기가 `WORKER_SOURCE_MEMBERSHIP_FAILED` 로 막는다 — 실측으로 확인하고 고친 지점이다). 산출은 조립본 자신의 `worker_output_validator` 로 검사해 **X1·X2·X3 모두 오류 0 · 경고 0**이다.
|
||||
|
||||
예행의 범위 한계는 영수증이 적어 둔다. 첫째, **Part 1 code task 8종 중 5종만 돌았다** — `Task_B1_quality_gate_evidence_indexed` · `Task_B2_quality_gate_event_candidates` · `Task_B12_gate_audit_finalizer` 셋은 B1·B2 와일드카드 fan-out 인스턴스의 산출을 `{{item.*}}` 경로로 요구하는데 재생 세트가 그 단계를 완성본으로 통째 대역하므로 다시 돌릴 입력이 없다. 둘째, 예행의 활성 도메인이 X1·X2·X3 셋뿐이다(대역이 증거 단서 기반 활성 판정을 하지 않기 때문이며 결함이 아니다). 셋째, 예행의 스크리닝 후보 11개 전부에 `requested_calculation_domains` 가 부재하다 — 그래서 교집합 경로를 `calculation_intersection_probe` 로 따로 실측했다. 26 도메인 경로도 마찬가지로 따로 실측했다 — 26 전부를 `execution_eligible` 로 둔 **합성** 활성 매니페스트에 슬라이스 스키마를 주입해 `compile_domain_slices` 를 돌려 READY / 26 / 실패 0 을 확인했다.
|
||||
|
||||
**조립본 하나로 선다.** `--asset-root` 를 임시 사본이 아니라 정본 조립본 폴더 자체로 겨눈 예행이 통과하고, 그때 남은 배포 게이트 영수증의 `runtime_manifest_sha256` 이 조립본 매니페스트의 실제 해시와 일치한다. 하네스는 asset-root 에 쓰지 않으므로(경로 해석기를 타는 기록 대상에 `Default_Agent/` 접두사가 하나도 없다) 실행 뒤 조립본은 드리프트 0 으로 그대로다.
|
||||
|
||||
### 6.5 검증이 잡은 것 — 결함의 성격
|
||||
|
||||
@@ -609,37 +651,52 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
|
||||
### 6.6 남은 것
|
||||
|
||||
앞 판본 §6.6 의 14줄 중 셋이 닫혔다 — 델타 30건 반영(1) · 부분 복사 방어(1b) · 조립본 `__pycache__` 제거(12). 표에 줄로 오르지는 않았지만 함께 닫힌 것이 하나 더 있다 — 예행이 A0 에서 멈춰 하류 셋을 한 번도 태우지 못하던 상태다(§6.4). 지금 남은 것을 **실행이 그 자산을 읽는가**로 갈라 적는다. 이 기준으로 보면 아래 어느 것도 Part 2 실행을 막지 않는다.
|
||||
|
||||
**A. 실행 경로 밖 — 빌드·재생성 쪽**
|
||||
|
||||
| # | 항목 | 실측 |
|
||||
|---|---|---|
|
||||
| A-1 | 신선 빌드가 조립본을 재현하지 못한다 | 895 vs 1,322. 결손 대부분은 스크립트가 만드는 137종 라우팅 회귀 픽스처 411건이며 그 복사 규칙을 지금 빌더가 잃었다. 빌드 검증 상태는 `FAIL`(`ABSOLUTE_PATH_POLICY` · `FORMAL_SCHEMA_CHECK` · `S3_S6_PROFILE_REPAIR_VALIDATION`)이고 이 셋은 추가 개정 전후가 동일하다 |
|
||||
| A-2 | `validation_assets/routing/routing_regression_contract.json` 이 상류와 갈라져 있다 | 상류 S6 `429e9260…` · 조립본 `76c51f29…` · 기록은 상류와 같다. 앞서 고친 두 모듈과 같은 종류이며 지시 범위 밖이라 두었다 |
|
||||
| A-3 | `platform/schemas/domain_fanout_plan.schema.json` 은 기록만 낡았다 | 상류와 조립본이 이미 같다. 신선 빌드가 한 번 성립하면 저절로 맞는다 |
|
||||
| A-4 | 빌더는 제자리 재빌드를 지원하지 않는다 | 이미 있는 `.txt` 미러에서 `MODULE_MIRROR_COLLISION` 으로 선다. 검증은 언제나 빈 target 에 짓고 조립본과 대조하는 방식이어야 한다 |
|
||||
|
||||
**B. 예행 보조물 쪽 — 실행 경로 밖이지만 관측을 흐린다**
|
||||
|
||||
| # | 항목 | 실측 |
|
||||
|---|---|---|
|
||||
| B-1 | `_promote_seed_v2_to_v3.py` 산출이 v3 스키마를 위반한다 | X1 하나에서 오류 17건 — `completion_receipt` 가 필수 5키(`task_instance_id` · `domain_id` · `seed_count` · `emitted_seed_ids` · `r0_membership_key`)를 빠뜨리고 금지 3키를 싣는다. review 항목도 `severity` 가 enum 밖이고 `source_legacy_ids` 는 금지 키다. 이번 사슬은 이 스크립트를 부르지 않아 드러나지 않았으나 `replay_manifest.v1.json` 은 여전히 그 경로의 생성기로 이것을 지목한다 |
|
||||
| B-2 | 같은 스크립트가 `domain_config_sha256` 을 슬라이스 **루트**에서 읽는다 | 실제 위치는 `domain_registry` 아래라 항상 빈 문자열이 실린다 |
|
||||
| B-3 | R0 가 되쓰는 seed 파일이 v3 스키마를 벗어난다 | `expand_candidate` 가 v2 필드를 붙여 다시 쓰기 때문이다. **재실행은 선다** — R0 를 자기 산출 위에 다시 돌려 PASS(기록 6건)를 확인했다. 검증기 오류를 예외로 올리지 않고 원장에 적기 때문이며, 그래서 실제 비용은 완주 실패가 아니라 **경고 채널 오염**이다(재실행 시 원장에 `WORKER_OUTPUT_ERROR` 45건이 쌓여 진짜 워커 위반이 묻힌다). 넷 중 먼저 손볼 값어치가 여기 있다 |
|
||||
|
||||
**C. 앞 판본에서 이월된 것**
|
||||
|
||||
| # | 항목 | 성격 |
|
||||
|---|---|---|
|
||||
| 1 | **Part 2 델타 30건의 정본 조립본 반영** (§5.1 — 신규 23 · 상이 5 · 매니페스트 2를 한 벌로) | 실행 선행 조건 |
|
||||
| 1b | 반영 전 부분 복사 방어 보강 (`PART2_ASSET_DEPLOYMENT_INCOMPLETE` 게이트 등) | `stage_1_part_2_additional_fix_strategy.md` |
|
||||
| 2 | 게이트 회귀 하네스 **실행** (137 레코드) | 하네스는 작성됐다. jsonschema 4.26 + python3.12(code-executor) 환경 필요 |
|
||||
| 3 | 사건 1건 실주행 · 2회 실행 바이트 동일 | Part 1 완료 판정 1·2·3·5 |
|
||||
| 4 | 승계 leaf 도메인 활성 (Q-2 투영 대조) | 증거 단서 기반 활성 판정에 실제 LLM이 필요. 대역으로 닫히지 않는 유일한 항목 |
|
||||
| 5 | `slice_freeze` 동결기 · Q-3·Q-4 착수 게이트 | 미착수 (P-9 · P-10) |
|
||||
| 6 | `BO.json` · 구 signal 3종 등가 대조기 | 미착수 (P-14 · P-15) |
|
||||
| 7 | overlay CE id 도달률 62% → 승격 시 R-4를 review에서 실패로 | 도달률이 오른 뒤 |
|
||||
| 8 | Part 3·4를 정본 signal 집합(`downstream_read_sets`)으로 이관 | Part 3·4 개정 범위 |
|
||||
| 9 | `client_goal.json`의 인계면 선언표 등재 | §4.4 관찰 |
|
||||
| 10 | E-09 `legacy_domain_id` 대 별칭표 불일치 | registry 소유자 판단 |
|
||||
| 11 | `Stage_1_Registry_Runtime_v1.yml` 경계 결정 | D-2 §3.3 |
|
||||
| 12 | 정본 조립본 `stage1_runtime/__pycache__/` 제거 (`.pyc` 3) | 마운트가 삭제를 허용하지 않는다. 사용자 조치 |
|
||||
| 13 | 인계면 선언표 3줄 갱신 — `client_meeting.md` 소비자에 Part 2 A0, `runtime/domain_seed_outputs/`에 `also_written_by: R0`, `client_goal.json` 등재 | §4.4 |
|
||||
|
||||
---
|
||||
| C-1 | 게이트 회귀 하네스 **실행**(137 레코드) | 하네스는 작성됐다 |
|
||||
| C-2 | 사건 1건 실주행 · 2회 실행 바이트 동일 | Part 1 완료 판정 1·2·3·5 |
|
||||
| C-3 | 승계 leaf 도메인 활성 (Q-2 투영 대조) | 증거 단서 기반 활성 판정에 실제 LLM 이 필요. 대역으로 닫히지 않는 유일한 항목 |
|
||||
| C-4 | `slice_freeze` 동결기 · Q-3·Q-4 착수 게이트 | 미착수 (P-9 · P-10) |
|
||||
| C-5 | `BO.json` · 구 signal 3종 등가 대조기 | 미착수 (P-14 · P-15) |
|
||||
| C-6 | overlay CE id 도달률 62% → 승격 시 R-4 를 review 에서 실패로 | 도달률이 오른 뒤 |
|
||||
| C-7 | Part 3·4 를 정본 signal 집합(`downstream_read_sets`)으로 이관 | Part 3·4 개정 범위 |
|
||||
| C-8 | 인계면 선언표 3줄 갱신 — `client_meeting.md` 소비자에 Part 2 A0, `runtime/domain_seed_outputs/` 에 `also_written_by: R0`, `client_goal.json` 등재 | §4.4 |
|
||||
| C-9 | E-09 `legacy_domain_id` 대 별칭표 불일치 | registry 소유자 판단 |
|
||||
| C-10 | `Stage_1_Registry_Runtime_v1.yml` 경계 결정 | D-2 §3.3 |
|
||||
|
||||
## 7. 근거
|
||||
|
||||
| 주장 | 근거 |
|
||||
|---|---|
|
||||
| 두 통합본의 크기·행수·sha256 | 원문 바이트 재계산 — Part 1 467,668 B / 6,667행 / `195b43edfaf1df14…`, Part 2 175,266 B / 3,026행 / `9bf771b729840936…` |
|
||||
| 두 통합본의 크기·행수·sha256 | 원문 바이트 재계산 — Part 1 467,668 B / 6,667행 / `195b43edfaf1df14…`, Part 2 **193,933 B / 3,307행 / `73644c5620b1bfbc…`** |
|
||||
| YAML 구문 PASS · 최상위 키 `Agent` | `yaml.safe_load` 재실행 |
|
||||
| task 13 / 6 및 행 범위 | `- task_name:` 정규식 전수 추출 |
|
||||
| DAG 노드·edge | `task_procedure` 블록 원문 (Part 1 6,589–6,664행 · Part 2 2,988–3,023행) |
|
||||
| DAG 노드·edge | `task_procedure` 블록 원문 (Part 1 6,589–6,664행 · Part 2 **3,269–3,304행**) |
|
||||
| task별 IN/OUT | 프롬프트의 `<ALLOWED_IO_AND_FORBIDDEN_ACTIONS>` 블록(LLM task) · `*_PATH` 상수와 `read_raw`/`write_doc` 호출(code task) 전수 추출 |
|
||||
| task별 실행기 설정 | `llm_provider`/`llm_model`/`llm_reasoning`/`llm_verbosity`/`mcp`/`tool_name`/`language`/`network`/`timeout`/`use_tools`/`preflight_files`/`max_concurrency`/`max_iterations` 전수 추출 |
|
||||
| 자산 참조 19 / 20 및 실재 여부 | `Default_Agent/…` 리터럴 전수 추출 후 두 뿌리에서 `os.path.exists` 대조 |
|
||||
| 두 뿌리 대조 (528 / 7 / 23) | 후보 오버레이 558 파일 전수 sha256 대조 |
|
||||
| 반영 전 두 뿌리 대조 (528 / 7 / 23) · 반영 후 (558 / 0 / 0) · 현재 560 전량 동일 | 후보 오버레이 전수 sha256 대조를 반영 전후로 두 번 |
|
||||
| 미러 규약 실측 | 두 뿌리에서 `.py`↔`.txt` 전수 sha256 대조 |
|
||||
| 매니페스트 수치 | `release_manifest.json` · `runtime_manifest.json` · `source_copy_map.json` 직접 파싱 |
|
||||
| 인계면 34 및 구간 분포 | `handoffs/stage1_part_interface.v1.json` 직접 파싱 |
|
||||
@@ -647,8 +704,10 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
| Part 1 검사 8항 · 조립 오류 1건 | `stage_1_part_1_개정작업_리포트.md` §3 · §4 |
|
||||
| Part 1 델타 522 구성 · 이동 4건 | `ver_8_yaml_candidates/part_1_remaining_update_report.md` §4.2 |
|
||||
| Part 2 검사 20항 · 결함 10건 · 26 도메인 투영 · 예행 6단계 | `stage_1_part_2_레지스트리기반개정완료_보고서.md` §3~§5 |
|
||||
| **추가 개정 4회 — 배포 게이트 F-1~F-7 · 회귀 R-a~R-l · 델타 30건 반영 · 라벨 해석 · 원천 정합 · 예행 2패스 9단계** | `stage_1_part_2_추가수정작업.md` · `_더.md` · `_더더.md` · `_더더더.md`. 각 회차의 수치는 회차 문서가 독립 sub-agent 검증(각 3~4라운드)을 통과한 값이며, 이 문서에 옮길 때 자산 트리에서 다시 실측했다 |
|
||||
| 예행 2패스 결과·seed 대역 검증 | `_dry_run_stage1.py` 재실행 + `worker_output_validator` 직접 호출 |
|
||||
| 설계 판정·계측 재정의 배경 (preflight 의미, 압축본을 쓰는 이유, 모듈 반입 우회책, 봉인 위치) | `ver_8_yaml_candidates/8월12_to_16일작업압축요약본.md` (316,036 B, Q&A 형식 설계 일지) |
|
||||
| 개정 이력 누적 요약 | `v.7/MEMORY.md` (196,781 B) |
|
||||
| 개정 이력 누적 요약 | `v.7/MEMORY.md` (항목 ⑦~⑭) |
|
||||
|
||||
---
|
||||
|
||||
@@ -682,3 +741,24 @@ Part 2 개정은 독립 sub-agent 검증 3라운드에서 결함 10건을 닫았
|
||||
**라운드 4 — 지적 1건(MINOR), 반영. 그 밖에 잔여 0.** 라운드 3의 §4.2 수정이 두 함수를 같은 이름으로 묶어 버렸다. 실제 이름은 다르다 — A0측이 `verify_seal`(Part 2 통합본 309행), T9측이 `verify_seal_consistency`(Part 1 통합본 6,415행)다. 이름을 넣어 고쳤고, 라운드 3의 나머지 두 수정은 깨끗함이 확인됐다.
|
||||
|
||||
네 라운드에서 지적 22건(BLOCKER 1 · MAJOR 6 · MINOR 15)을 받아 전부 반영했다. **오류의 성격이 라운드마다 옮겨 갔다는 점을 남겨 둔다** — 1라운드는 원문을 덜 읽은 데서 온 누락, 2라운드는 규약 문장의 근거를 실측으로 확인하지 않은 데서 온 과잉 일반화, 3·4라운드는 앞선 수정이 만든 새 부정확이었다. 마지막 종류는 검증을 한 번 더 돌리지 않으면 잡히지 않는다.
|
||||
|
||||
---
|
||||
|
||||
## 9. 이번 개정(2026-08-18)의 범위와 검증
|
||||
|
||||
이 판본은 **Part 2 에 관한 서술만 incremental 로 갱신**했다. 두 Part 공통 절인 §1.4 에서 한 줄(미러 규약 실측)이 함께 바뀌었는데, 그 수치가 자산 트리 전체를 세는 값이라 Part 2 델타 반영으로 달라졌기 때문이다. 손댄 곳과 손대지 않은 곳을 분명히 적어 둔다.
|
||||
|
||||
| 절 | 처리 |
|
||||
|---|---|
|
||||
| 머리말 · §0 | Part 2 파일 크기·행수·sha256 갱신, 추가 개정 4회와 예행 완주 코드 task 행 추가, 회차 문서 4종을 근거 자료에 추가 |
|
||||
| §1.4 (한 줄) | 미러 규약 실측을 델타 반영 후 값으로 — 조립본 `.py` 103/102 → **112/111**. 이 절의 나머지 네 줄은 손대지 않았다 |
|
||||
| §1.5 (신설) | 추가 개정 4회의 목적·닫은 결손·명세서에 남은 흔적 |
|
||||
| §3.1 · §3.2 · §3.3 · §3.5 | task 행 범위 재측정(전부 이동), A0 의 배포 게이트, R0 의 네 갈래 보강, S0 의 자산 검사, 자산 크기를 단일 뿌리 값으로, 신설 자산 1종 추가 |
|
||||
| §5 전체 | 두 뿌리 → 한 뿌리(상위집합·부분집합)로 재작성, 미러·매니페스트 수치 갱신, `source_copy_map` 이 델타를 따라오게 된 경위 |
|
||||
| §6.2 · §6.4 · §6.6 | 회귀 13종 표 추가, 예행을 2패스 9단계로 재작성, 남은 것을 실행 경로 안팎으로 갈라 재작성 |
|
||||
| §7 | 근거표에 회차 문서 4종과 재실측 항목 추가 |
|
||||
| **손대지 않은 곳** | §1.1 · §1.2 · §1.3 · §2 전체 · §3.4 · §4 · §6.1 · §6.3 · §6.5 · §8 — 계보, Part 1 서술, 첫 판본의 Part 2 개정 범위표, upstream–downstream 연결표, 인계면(수치 34가 그대로다), registry 투영 실측, 그리고 앞 판본의 검증 이력이다 |
|
||||
|
||||
앞 판본은 `ver_8_yaml_candidates/outdated/stage_1_part_1_and_2_updated_yaml_analysis_old.md`(86,634 B)로 보존했다.
|
||||
|
||||
검증은 앞 판본과 같은 방식이다 — 독립 sub-agent 가 문서의 주장을 믿지 않고 `stage_1_part_2_v.8.yml` 원문과 자산 트리를 직접 측정해 대조했고, 지적이 0 이 될 때까지 반복했다.
|
||||
|
||||
+95
-1
@@ -1969,6 +1969,11 @@ Part 2 작업 실행으로 작업명세서가 원래 의도한 결과물들이
|
||||
|
||||
==================================
|
||||
|
||||
┌────────────────────────────────────────────┐
|
||||
│ │
|
||||
│ Back to Part 2 -- Again │
|
||||
│ │
|
||||
└────────────────────────────────────────────┘
|
||||
<goal>
|
||||
`stage_1_part_2_여전히남은문제해결방안.md`이 제시하는 `§4. 해결 방안`에 제시된 작업들을 수행하여 `완수`한다.
|
||||
</goal>
|
||||
@@ -2007,6 +2012,91 @@ Part 2 작업 실행으로 작업명세서가 원래 의도한 결과물들이
|
||||
|
||||
==================================
|
||||
|
||||
이전 작업에서 생성한 'v.7/extension_research/stage_1_part_2_여전히남은문제해결내역.md'에 대한 아래 질문에 답하라.
|
||||
|
||||
`§5. 이월 항목 (다음 회차 — 조립본 동기화)`에 제시된 `6개 항목`은 Liti-agent가 stage 1 -- part 2 작업을 `완수`하도록 하기 위해 필수적으로 해결해야 하는 문제들인가? 한 문단 이내로 답변하라.
|
||||
|
||||
`§6. 한계 (정직 선언)`에 제시된 "E-02·E-05 등 오버레이 보유 도메인이 예행에서 비활성(X1~X3만 활성)이라 rank 10 vs 30의 실프롬프트 대결은 정적 근거(합성본 주입 확인 + 우선순위 선언)로 닫았다."에서 오버레이 보유 도메인이 예행에서 비활성(X1~X3만 활성)이라는 것의 의미는 무엇인가? Part 2 yaml 작업 명세서가 올바로 수행되지 않은 것인가? 아니면 단순히 예행에서만 비활성된 것인가? 한 문단 이내로 답변하라.
|
||||
|
||||
==================================
|
||||
|
||||
┌────────────────────────────────────────────┐
|
||||
│ Stage 1 -- Part 2 Analysis Update │
|
||||
└────────────────────────────────────────────┘
|
||||
|
||||
<goal>
|
||||
기존 stage 1 -- part 1|2 분석문서 `stage_1_part_1_and_2_updated_yaml_analysis.md`를 개정한다.
|
||||
</goal>
|
||||
|
||||
<context>
|
||||
`Stage 1 -- Part 3`에 대한 최적 개정 작업 내역을 조사하던 중 `Stage 1 -- Part 2` 작업명세서(stage_1_part_2_v.8.yml)에 해결할 문제점이 존재함을 발견했다.
|
||||
문제점을 해결하는 개정 작업명세서(`stage_1_part_2_여전히남은문제해결방안.md`)를 작성하여 이를 실행하여 `stage_1_part_2_v.8.yml`를 개정했다. 그리고 개정 과정에서 얻은 outcome 자산들은 `v.7/extension_research/Default_Agent`의 정확한 배포 위치 폴더에 저장했다.
|
||||
언급한 Stage 1 -- Part 2 작업내역서 개정 작업 내용은 `stage_1_part_2_여전히남은문제해결내역.md`에 제시되어 있다.
|
||||
|
||||
Stage 1 -- Part 2 작업내역서를 개정한 작업 내용을 바탕으로 기존 stage 1 -- part 1|2 분석문서 `stage_1_part_1_and_2_updated_yaml_analysis.md`를 개정하려고 한다.
|
||||
</context>
|
||||
|
||||
<method>
|
||||
1. MEMORY.md, `stage_1_part_2_여전히남은문제해결내역.md`, `stage_1_part_2_v.8.yml`를 읽고 Part 2 작업이 어떻게 진행되며 어떤 결과물들이 생성되는지 파악한다.
|
||||
2. Liti-agent가 Stage 1 -- Part 1,2 yaml 작업명세서를 실행할 때 사용하는 자산들이 저장된 `v.7/extension_research/Default_Agent` 폴더 내 자산들의 위치와 파일들을 점검한다.
|
||||
3. 1,2에서 얻은 지식을 바탕으로 `stage_1_part_1_and_2_updated_yaml_analysis.md`에서 part 2에 해당하는 부분만 재작성한다.
|
||||
4. 3번 작업 완료 후, sub-agent를 띄워 재작성한 내용이, 실제로 `stage_1_part_2_v.8.yml`가 규정하는 작업내역을 100% 정확하게 설명하는지 검증한다. 100% 정확할 때까지 `검증 작업` + `stage_1_part_1_and_2_updated_yaml_analysis.md`의 part 2 해당 내용 재작성`을 반복한다.
|
||||
5. 4번 작업에서 sub-agent가 100% 통과라고 판단하면, 작성한 문서를 `stage_1_part_1_and_2_updated_yaml_analysis.md`로 overwrite하여 저장한다. 기존 `stage_1_part_1_and_2_updated_yaml_analysis.md`문서는 `stage_1_part_1_and_2_updated_yaml_analysis_old.md`로 파일명을 바꾸어서 `v.7/extension_research/ver_8_yaml_candidates/outdated` 폴더로 옮긴다.
|
||||
</method>
|
||||
|
||||
<global_constraints>
|
||||
- `v.7/CLAUDE.md`가 제시하는 Fable 5 행동 규칙을 준수한다.
|
||||
- 작업 완료 시 작업 내역을 압축 요약하여 `v.7/MEMORY.md`에 추가 기입한다.
|
||||
</global_constraints>
|
||||
|
||||
|
||||
==================================
|
||||
|
||||
┌────────────────────────────────────────────┐
|
||||
│ │
|
||||
│ Re-Beginning of Part 3 Update │
|
||||
│ │
|
||||
└────────────────────────────────────────────┘
|
||||
|
||||
<goal>
|
||||
`stage_1_update_strategy.md`에 제시된 stage 1 -- part 3 개정작업에 대한 상세한 작업명세서를 작성한다.
|
||||
</goal>
|
||||
|
||||
<context>
|
||||
지금까지 stage 1 -- part 1|2 개정작업을 완료했다.
|
||||
최종 yaml 작업 명세서는 각각 `v.7/extension_research/ver_8_yaml_candidates/stage_1_part_1_v.8.yml`, `v.7/extension_research/ver_8_yaml_candidates/stage_1_part_2_v.8.yml`이다.
|
||||
|
||||
MEMORY.md 파일에는 지금까지의 작업 내역들이 압축적으로 요약되어 있다.
|
||||
|
||||
그리고 2개 yaml 작업명세서의 작업 흐름과 내역을 상세히 분석하여 제시한 문서가 `stage_1_part_1_and_2_updated_yaml_analysis.md`이다.
|
||||
|
||||
이제 `stage_1_update_strategy.md`에 제시된 stage 1 -- 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`로 생성한다.
|
||||
|
||||
<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`가 제시하는 #### 5 행동 규칙을 준수한다.
|
||||
- 작업 완료 시 작업 내역을 압축 요약하여 `v.7/MEMORY.md`에 추가 기입한다.
|
||||
</global_constraints>
|
||||
|
||||
|
||||
|
||||
@@ -2035,7 +2125,11 @@ Part 2 작업 실행으로 작업명세서가 원래 의도한 결과물들이
|
||||
|
||||
|
||||
|
||||
|
||||
<global_constraints>
|
||||
- `v.7/CLAUDE.md`가 제시하는 #### 5 행동 규칙을 준수한다.
|
||||
- 작업 완료 시 작업 내역을 압축 요약하여 `v.7/MEMORY.md`에 추가 기입한다.
|
||||
- yaml 작성을 할 때는 <v.7/SKILL.md>의 규칙을 엄격하게 준수하며, python code를 작성할 때는 <v.7/extension_research/test_code_executor.ipynb>가 제시하는 Python code 작성 규칙을 엄수한다.
|
||||
</global_constraints>
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user