Prayer_for_Relief_Docs/청구취지규칙문서_2차드래프트작성_프롬프트.txt

<prompt_metadata>
name: 대한민국 민사소송 사건종류별 청구취지작성규칙 v2 작성 프롬프트
version: 1.0
optimized_for: GPT-5.6 Sol Ultra
jurisdiction: 대한민국
artifact_type: LLM용 decision-tree 규칙문서
</prompt_metadata>

<role>
20년 이상 대한민국 민사소송 실무를 수행한 최고 수준의 법조인이자, 대규모 법률 지식 시스템을 설계하는 세계적 수준의 인공지능 아키텍트로 행동한다.
</role>

<working_directory>
Default_Agent_청구취지기재방법/
</working_directory>

<task_contract>
대한민국 민사소송 사건종류 "<####>"의 다음 세 입력을 하나의 증거 묶음으로 사용하여, 정확하고 연결된 decision tree 형식의 청구취지작성규칙 v2를 작성한다.

필수 입력:
1. 사건종류_<####>/청구취지작성규칙_<####>_v1.md
2. 사건종류_<####>/청구취지작성규칙_<####>_평가서_fable5_v1.md
3. 사건종류_<####>/청구취지작성규칙_<####>_평가서_opus5_v1.md

필수 참조:
4. case_kind_registry.json
5. 저장소에 존재하는 적용 가능한 AGENTS.md 또는 CLAUDE.md

유일한 최종 산출물:
사건종류_<####>/청구취지작성규칙_<####>_v2.md

v1, 두 평가서, registry 및 다른 사건종류의 파일은 수정하지 않는다. 사용자가 별도로 요구하지 않은 보조 보고서, 메모리 갱신, 커밋은 만들지 않는다.
</task_contract>

<placeholder_and_path_rules>
1. 본문의 "<####>"는 case_kind_registry.json의 "사건 종류" 값과 정확히 일치하는 표시용 사건명이다. 예: "대여금 청구".
2. 경로와 파일명에서는 위 사건명에서 공백과 특수문자를 제거한 사건키를 사용한다. 예: "전부금 청구" → "전부금청구".
3. 기존 사건 폴더가 있으면 그 폴더와 실제 파일명의 정규화·유니코드 표기를 우선한다. 정규화 결과가 같은 후보가 둘 이상이면 임의 선택하지 않는다.
4. 실행 전에 표시용 사건명, 사건키, 입력 3개, 출력 1개를 각각 확정하여 identity ledger에 기록한다.
5. "<####>"가 미치환 상태이거나 registry에서 정확히 한 건으로 확인되지 않으면 STOP-I01로 종료한다.
6. 세 입력 중 하나라도 없거나, 세 문서가 서로 다른 사건종류를 다루면 STOP-I02로 종료한다. 평가서가 아직 생성되지 않은 상태를 추론으로 보충하지 않는다.
7. 출력 파일이 이미 존재하면 자동 덮어쓰기하지 않는다. 사용자의 명시적 갱신 지시가 없으면 STOP-I03으로 종료한다.
</placeholder_and_path_rules>

<goal>
v1의 유효한 법리·분기·문형을 보존하면서 fable5와 opus5 평가서의 타당한 제안을 검증·통합하고, 대한민국 현행 법령과 판례에 맞으며 LLM이 빠르고 정확하게 실행할 수 있는 청구취지작성규칙 v2를 생성한다.
</goal>

<non_goals>
- 특정 의뢰인의 사실관계를 가정하여 실제 소장을 작성하는 작업이 아니다.
- 평가서 두 개의 문장을 단순 합치거나 v1 말미에 수정 목록을 덧붙이는 작업이 아니다.
- 청구원인·증거·소송전략 전반을 백과사전식으로 설명하는 문서가 아니다.
- 다른 사건종류의 규칙을 유사하다는 이유만으로 이식하는 작업이 아니다.
</non_goals>

<success_criteria>
다음 여섯 조건을 모두 충족해야 성공이다.
1. Identity: 사건명·폴더·파일명·본문의 사건종류가 동일하다.
2. Legal correctness: 실행 기준일 현재의 대한민국 공식 원문과 판례의 실제 판시 범위에 맞는다.
3. Completeness: 해당 사건종류의 실무상 필요한 청구취지 경로를 필요충분하게 다룬다.
4. Reachability: 모든 결정트리 노드와 문형이 연결되고, 고아 노드·고아 문형·막힌 측면 분기가 없다.
5. Enforceability: 금액, 당사자, 목적물, 행위, 기간, 등기사항 등 주문에 필요한 대상과 범위를 구체적으로 특정할 수 있다.
6. Token economy: 같은 법리와 문형을 중복 서술하지 않고 ID와 상호참조를 사용한다.
</success_criteria>

<source_priority>
S1. 실행 기준일 현재 시행 중인 대한민국 법령·대법원규칙·등기예규 및 공식 판례 원문
    - 국가법령정보센터: https://www.law.go.kr
    - 대한민국 법원·대법원: https://www.scourt.go.kr
S2. 대한민국 법원의 공식 소장 양식·작성안내·공식 판결문
S3. 정부기관·대한법률구조공단·학술논문·법률신문·전문 법조인의 서명된 실무자료
S4. 그 밖의 일반 웹 자료
S5. 세계법제정보센터: https://world.moleg.go.kr
    - 대한민국 국내법의 현행성 판단 자료가 아니라 외국법·비교법 쟁점 탐색 자료로만 사용한다.

충돌 시 S1이 우선한다. S2 이하는 쟁점 발견과 문형 참고 자료일 뿐 S1과 충돌하는 법률 명제를 확정하지 못한다. 검색결과 스니펫, 생성형 요약, 접속 성공 여부만으로 법령이나 판례를 검증하지 않는다.
</source_priority>

<common_legal_anchors>
문서 구조를 설계할 때 아래 공통 앵커의 적용 여부를 확인하되, 사건과 무관한 조문을 장식적으로 나열하지 않는다.
- 민사소송법 제249조: 소장의 청구취지·청구원인 기재
- 민사소송법 제203조: 처분권주의
- 민사소송법 제251조: 장래이행의 소와 미리 청구할 필요
- 민사소송법 제253조: 소의 객관적 병합
- 민사소송법 제65조: 공동소송
- 민사소송법 제98조부터 제104조: 소송비용
- 민사소송법 제213조: 재산권 청구의 가집행
- 민사소송법 제254조: 소장 심사와 보정
- 민사소송규칙 제62조(소장의 기재사항): 청구원인에는 청구를 뒷받침하는 구체적 사실, 피고가 주장할 것이 명백한 방어방법에 대한 구체적 진술, 입증이 필요한 사실의 증거방법을 적는다. 다만 청구취지 문형에는 청구원인을 혼입하지 않는다.
- 민사소송규칙 제63조(소장의 첨부서류): 법정대리인·대표자·관리인의 자격증명 및 사건유형별 등기사항증명서·가족관계기록사항 증명서·어음·수표 사본과 중요 증거문서 사본의 첨부 여부를 확인한다.
- 대법원 2024. 1. 4. 선고 2023다282040 판결: 청구취지의 내용·범위 특정과 보정
- 대법원 2023. 6. 1. 선고 2021다260343 판결: 주문 자체의 특정성과 집행상 명확성
- 금전청구라면 소송촉진 등에 관한 특례법 제3조 및 그 법정이율 규정
- 확인청구라면 확인의 이익과 현재의 불안·위험, 가장 유효·적절한 수단인지에 관한 최신 판례
- 비금전 집행·의사표시·등기청구라면 민사집행법과 부동산등기법의 사건별 관련 규정

조문번호와 판례를 기계적으로 복사하지 말고 실행 기준일의 현행 원문, 시행일, 부칙, 후속 변경판례를 확인한다.
</common_legal_anchors>

<execution_policy>
1. Stage 0부터 Stage 7까지 순서대로 수행한다.
2. main agent가 세 입력의 전문, 최종 채택 판단, v2 작성, 최종 저장을 직접 책임진다.
3. sub-agent는 기본적으로 사용하지 않는다. 직접 도구 호출만으로 충분하지 않고 독립 병렬화의 이익이 큰 경우에 한하여 한 차례, 최대 2개만 사용한다.
   - Agent A: 공식 원문·판례·현행성 검증
   - Agent B: 트리 연결성·분기-문형 커버리지의 적대적 감사
   - 하위 agent 재위임과 재귀적 spawn은 금지한다.
   - 각 agent는 지정된 표 스키마만 반환하고 최종 문서를 작성하지 않는다.
4. 독립적인 파일 확인과 웹 검색은 가능한 한 배치한다. 이미 확인한 문서를 이유 없이 반복해서 읽지 않는다.
5. 내부 분석표는 간결하게 유지하고 최종 규칙문서에 사고과정이나 조사 일지를 그대로 노출하지 않는다.
</execution_policy>

<stage_0_identity_and_preflight>
[0-A] 경로 확정
- case_kind_registry.json에서 표시용 사건명 "<####>"를 정확히 한 건 확인한다.
- 사건키, 사건 폴더, 세 입력 경로, v2 출력 경로를 확정한다.
- 경로·파일명은 실제 존재하는 표기를 사용하고 유사 사건 폴더로 대체하지 않는다.

[0-B] 의미적 동일성 게이트
- 세 입력의 제목·메타데이터·핵심 본문을 확인한다.
- 기대 사건명과 특징적 용어가 일치하는지, 인접 사건종류의 용어가 본문을 지배하지 않는지 확인한다.
- 해시·UTF-8·마크다운 문법이 정상이어도 사건종류가 다르면 실패로 판정한다.

[0-C] 입력 상태
- 파일 존재, 읽기 가능, UTF-8 해석 가능 여부를 확인한다.
- v1과 두 평가서의 작성일 또는 기준일을 기록한다.
- 평가서에 "미검증", "비공식 출처", "접속 실패", "최신 확인 필요"가 표시된 항목을 별도 검증 큐에 넣는다.
</stage_0_identity_and_preflight>

<stage_1_extract_and_map>
[1-A] v1 구조 지도
v1을 전문 읽고 다음만 압축 추출한다.
- 제목·절·노드·분기·STOP ID
- 필수 입력사실
- 청구유형과 세부 유형
- 당사자 구조
- 금전·기간·이율 모듈
- 병합·주위적·예비적·선택적 구성
- 문형 ID와 적용 조건
- 금지 규칙
- 법령·판례·예규 인용

[1-B] 평가서 정규화
두 평가서의 모든 실질적 제안을 하나의 issue ledger로 정규화한다. 한 항목에 여러 결함이 섞였으면 원자 단위로 분해한다.
평가서 파일명만으로 동일한 평가 프롬프트 버전·스키마라고 가정하지 말고 실제 section, 검증상태, 심각도, 수정문을 읽어 정규화한다.

issue ledger 필드:
| Issue ID | v1 위치 | 제안 출처(F/O/BOTH) | 결함 유형 | 주장 | 제안 수정 | 인용 근거 | 원 평가의 검증상태 | 중요도 | 재검증 필요 |

결함 유형은 최소한 다음을 구분한다.
- LEGAL: 법령·판례·법리 오류 또는 현행성 문제
- CITATION: 사건 동일성·링크·판시 범위·후속 변경 문제
- TREE: 고아 노드, 막힌 분기, 복귀 누락, 순환, STOP 누락
- COVERAGE: 필요한 분기 또는 문형 누락
- CONSISTENCY: 절·계산·문형 간 모순
- SPECIFICITY: 금액·대상·행위·등기·기간의 특정 부족
- USABILITY: 불명확한 입력, 미확정값 처리, LLM 실행성 문제
- STYLE: 중복·과잉 서술·용어·가독성

[1-C] 구조 비교
v1의 구조를 <canonical_output_structure>와 비교하여 유지, 이동, 통합, 신설, 삭제 후보를 표시한다. 구조를 맞추기 위해 사건에 불필요한 내용을 억지로 추가하지 않는다.
</stage_1_extract_and_map>

<stage_2_targeted_research>
전면 재조사 대신 다음 항목만 검증 큐에 넣어 집중 조사한다.
1. 두 평가서가 충돌하는 항목
2. 한 평가서만 제시한 법률상 중대 결함
3. 미검증·비공식·접속 실패로 표시된 항목
4. 시행일, 이율, 부칙, 예규번호, 최근 판례처럼 시간에 민감한 항목
5. v1에 근거 없이 단정된 강한 규칙
6. <canonical_output_structure>상 새로 필요한 사건특유 분기

<official_research_rules>
- 국가법령정보센터와 대한민국 법원의 현행 정식 원문을 먼저 확인한다.
- 판례는 사건번호, 선고일, 재판유형·전원합의체 여부, 실제 판시 요지, 공식 원문 링크, 후속 변경·폐기 여부를 확인한다.
- evtNo·검색어 링크만 신뢰하지 말고 가능하면 공식 원문의 사건 동일성을 직접 확인한다.
- 법령은 현행 본문, 시행일, 부칙·경과규정, 미시행 장래법 여부를 분리한다.
- DRF 또는 사이트 검색이 0건이거나 페이지 접근이 실패해도 "판례·규정 부존재"로 추론하지 않는다.
- 일반 웹 자료는 쟁점 발견에만 사용하고, 채택 전 공식 원문으로 역검증한다.
- 검증할 수 없는 명제는 "미검증"으로 남기고 operative rule이나 확정 문형의 근거로 쓰지 않는다.
</official_research_rules>

각 조사 항목을 다음 evidence ledger에 기록한다.
| Evidence ID | 쟁점 | 출처 등급 | 법령·사건 식별자 | 현행/과거/장래 | 확인된 범위 | 공식 URL | 검증상태 |
</stage_2_targeted_research>

<stage_3_adjudicate_evaluations>
각 Issue에 ADOPT, MODIFY, REJECT, DEFER 중 하나를 부여한다.

판정 규칙:
1. BOTH이고 공식 원문과 일치하며 사건특유성이 있으면 우선 ADOPT한다.
2. 한 평가서만 제안한 법률 변경은 공식 원문 검증 후에만 ADOPT 또는 MODIFY한다.
3. 두 평가서가 충돌하면 다수결하지 않는다. 공식 원문 → 판례 실제 범위 → v1 해당 절 순서로 판정한다.
4. "잘 작성됨" 평가는 동결 명령이 아니다. 현행법·내부 정합성에 어긋나면 수정한다.
5. 문장 교체안이 법리는 맞지만 다른 분기와 충돌하면 전체 트리 기준으로 MODIFY한다.
6. 일반 웹에서만 확인되고 공식 검증이 안 된 법률 명제는 DEFER하거나 operative rule에서 제외한다.
7. 사건과 무관한 범용 제안, 중복, 과도한 백과사전식 확장은 REJECT한다.
8. 평가서에 없더라도 검증 과정에서 발견한 중대한 오류는 NEW 이슈로 추가한다.

판정 결과는 다음 고정 스키마의 내부 revision ledger에 남긴다.
| Issue ID | 판정(ADOPT/MODIFY/REJECT/DEFER/NEW) | 판정 근거 Evidence ID | v2 반영 위치(Section/Node/Rule/Leaf/Form) | 미반영 사유 또는 잔여 위험 |
v2 본문에는 평가서 문장을 장황하게 인용하지 않는다.
</stage_3_adjudicate_evaluations>

<decision_tree_specification>
결정트리는 연결된 유향 그래프로 설계한다.

ID namespace를 분리한다.
- Q-*: 판단 질문
- RULE-*: 재사용 법리
- LEAF-*: 트리 말단
- FORM-*: 표준 문형
- CHECK-*: 검증 노드
- STOP-*: 종료 또는 전환

각 노드의 고정 스키마:
- Node ID와 한 줄 질문
- 필요한 입력
- 판단 기준
- 선택지별 다음 Node ID, Leaf ID 또는 STOP ID. Form 선택은 반드시 Leaf의 Form ID 필드를 통해서만 이루어지며 Node에서 Form으로 직접 이동하지 않는다.
- 적용 근거 Evidence ID
- 사실 또는 법률이 미확정일 때의 ASK, VERIFY, STOP 행동

각 말단의 고정 스키마:
- Leaf ID
- 도달 조건
- 사용할 Form ID
- 필수 변수
- 금지되는 대체 문형
- 최종 검증 노드로의 합류

연결성 규칙:
1. Root를 제외한 모든 노드에는 유입 경로가 있어야 한다.
2. 모든 비종결 말단은 정확히 하나 이상의 검증된 Form으로 이어져야 한다.
3. 모든 Form은 하나 이상의 Leaf에서 도달 가능해야 한다.
4. 특별법·예외·불성립 등 측면 분기도 당사자, 특정성, 금전 모듈, 병합, 최종 검증 중 적용 가능한 공통 후속 노드로 복귀해야 한다.
5. 종료 분기는 이유와 STOP 코드를 명시한다.
6. 동일 법리를 여러 노드에 복제하지 말고 단일 Rule ID를 참조한다.
7. STOP은 다음 세 종류를 구별한다.
   - HARD STOP: 법률상 청구 불능 또는 이 프롬프트의 필수 계약 위반
   - CURE/VERIFY: 보완 가능한 사실·근거 부족. 필요한 입력과 재개 노드를 명시
   - ROUTE/TRANSFORM: 다른 청구형태·절차·사건종류로 전환해야 함. 전환 목적지를 명시
8. 제척기간·출소기간·소멸시효 등 권리보전 시급성이 있는 경로에서 단순 정보 부족을 곧바로 HARD STOP으로 만들지 않는다. 현행법상 허용되는 범위에서 필요한 즉시 확인사항, 보완 또는 권리보전 선택지를 표시하되 확인되지 않은 소송행위를 단정하지 않는다.
</decision_tree_specification>

<canonical_output_structure>
v2는 아래 13개 section을 기본 골격으로 한다. 사건에 해당하지 않는 조건부 모듈은 한 줄로 "해당 없음 — 이유"를 적고 빈 형식 문구를 늘리지 않는다. 사건특유 분기는 추가할 수 있으나 순서와 핵심 목적은 유지한다.

# <####> — 청구취지 작성 규칙 v2

## 0. 문서 메타데이터와 30초 사용법
- 사건종류, 사건키, 적용범위, 기준일, 버전
- 권위 우선순위와 미확정값 처리 원칙
- Root Node에서 시작하는 사용법

## 1. 필수 입력사실 스키마
- 입력명, 의미, 필수/조건부, 허용값, 근거자료, 미확정 시 행동
- 실제 사실·날짜·금액·이율을 추정하지 않는 규칙

## 2. 마스터 결정트리
- 한 화면에서 전체 경로를 파악할 수 있는 연결된 트리
- 최소 공통 게이트:
  A. 사건 및 청구유형 분류: 이행·확인·형성
  B. 현재·장래·조건부·정기적 이행 여부
  C. 당사자적격과 복수 당사자 부담구조
  D. 청구 대상과 범위의 특정
  E. 이행기·조건·동시이행·선이행 여부
  F. 금전 모듈 적용 여부
  G. 병합·주위적·예비적·선택적 구성
  H. 비용·가집행 등 부수 주문
  I. Leaf → Form → 최종 검증

## 3. 사건특유 세부 유형과 분기 규칙
- v1의 유효한 세부 유형을 유지하되 평가서가 지적한 누락·오류를 보정
- 각 Rule에 적용요건, 효과, 예외, 다음 Node, 근거 ID를 부여

## 4. 당사자·적격·부담구조 모듈
- 원고·피고 적격, 대리·승계·수탁·중개 등 사건특유 주체
- 복수 원고·피고, 분할·연대·부진정연대·공동 의무를 법률상 근거에 따라 구별
- 근거 없이 "연대하여", "공동하여", "각자"를 선택하지 않는 규칙

## 5. 청구 대상·범위·집행가능성 특정 모듈
- 금전, 물건, 부동산, 등기, 문서, 지위·법률관계, 금지·작위·부작위 등 해당 유형별 식별요소
- 목적물·위치·면적·도면·별지·행위·기간·등기원인과 일자 등 필요한 특정요소
- 판결 주문만으로 이행·등기·집행 대상과 범위를 식별할 수 있는지 확인

## 6. 시기·조건·금전 계산 모듈
- 이행기, 장래이행 필요성, 조건성취, 동시이행과 지체책임
- 적용 시 원금, 공제, 기지급액, 이자, 지연손해금, 기산일, 종료일, 구간별 이율
- 약정이율·민법·상법·특별법 이율의 적용 관계와 제출일 재확인
- 청구기초 또는 송달일이 다른 금액은 구간을 분리
- 계산식과 반올림·단위·중복합산 금지
- 금전청구 공통 게이트: 회생·파산 등 도산절차가 청구·가집행·집행경로에 미치는 영향, 소송촉진 등에 관한 특례법 제3조 제1항 단서의 적용 여부, 약정이율과 특례이율의 대소·적용기간을 명시적으로 판정한다. 복수 채무자 표현은 §4의 부담구조 판정을 참조한다.

## 7. 복수 청구·병합·부수 주문 모듈
- 단순·누적적·선택적·주위적/예비적 청구의 요건과 순서
- 양립 가능한 일부인용 관계를 불필요한 예비적 청구로 만들지 않음
- 중복배상·이중집행 방지
- 소송비용, 가집행, 반대급부와 상환이행 문구의 적용 여부

## 8. Leaf–Form 커버리지 매트릭스
| Leaf ID | 도달 조건 | Form ID | 필수 변수 | 적용 Rule/Evidence | 최종 검증 |
- 모든 Leaf와 Form을 전수 대응시킨다.

## 9. 표준 청구취지 문형
각 문형에 다음을 붙인다.
- Form ID와 사용 조건
- 필수 변수 사전
- 청구취지 문형
- 사용 금지 조건
- 관련 Rule/Evidence ID

문형은 주문 문장만 제시하고 청구원인 사실을 섞지 않는다. 예시는 가상의 사실임을 표시하고 실제 값이 없으면 대괄호 placeholder를 유지한다.

## 10. 금지 규칙과 실패 안전장치
- 사건특유 오답, 과잉청구, 근거 없는 당사자 결합, 이율·기산일 오류, 목적물 불특정, 문형 간 중복을 부정형 규칙으로 차단
- 확인 불가 시 "확인한 것처럼" 쓰지 않고 ASK, VERIFY 또는 STOP

## 11. 근거 대장
| Evidence ID | 법령·판례·예규 | 핵심 범위 | 시행·선고일 | 공식 URL | 검증상태 |
- 강한 법률 명제와 Form의 근거를 추적 가능하게 한다.
- 판례 판시를 사실관계 밖으로 일반화하지 않는다.

## 12. 최종 검증 체크리스트와 Stop Rule
- identity, 현행성, 특정성, 계산, 트리 연결성, Leaf–Form 커버리지, 금지 규칙을 확인
- 필요충분성을 충족한 시점에 종료하고 유사한 설명을 반복하지 않는다.
</canonical_output_structure>

<stage_4_design_v2>
1. issue adjudication 결과를 반영하여 먼저 v2의 node map과 Form map을 확정한다.
2. v1의 유효한 내용은 의미를 보존하되 <canonical_output_structure>의 단일 위치로 이동·통합한다.
3. 평가서가 지적한 측면 분기 복귀, 누락 문형, 무출처 규칙, 하드코딩 값, 미확정값 fallback 문제를 구조적으로 해결한다.
4. 사건특유 분기와 범용 공통 모듈을 구별한다. 범용 공통 모듈이 사건특유 법리를 덮어쓰지 않게 한다.
5. 모든 Leaf–Form 대응을 작성한 뒤에 본문을 쓴다. 문형 없는 말단이나 도달 불가능한 문형을 허용하지 않는다.
</stage_4_design_v2>

<stage_5_write_and_save_first_complete_draft>
1. v2를 완결된 새 문서로 작성한다. 수정 흔적, 평가자 간 대화, 미완성 TODO를 본문에 남기지 않는다.
2. 사실·금액·날짜·이율을 알 수 없으면 대괄호 placeholder와 필요한 사용자 입력을 명시한다.
3. 실행 기준일에 확인된 법률만 "현행"이라고 표시한다. 과거법과 미시행 장래법은 별도 라벨을 붙인다.
4. 법적 결론을 바꾸지 않는 범위에서 표, 짧은 문장, ID 상호참조를 사용한다.
5. 같은 법리, 금지 규칙, 문형을 반복 복제하지 않는다.
6. 첫 완성본을 정확한 v2 출력 경로에 저장한다.
</stage_5_write_and_save_first_complete_draft>

<stage_6_single_validation_pass>
첫 완성본 저장 후 정확히 한 번의 독립 검증을 실시한다. 검증자는 초안 작성자의 결론을 전제로 하지 않고 다음 순서로 반증을 시도한다.

V1. Identity
- registry 사건명, 사건키, 폴더, 입력 3개, 출력 파일명, 제목·메타데이터가 일치하는가.
- 다른 사건종류의 중심 법리나 문형이 섞이지 않았는가.

V2. Evaluation reconciliation
- 두 평가서의 실질적 제안이 revision ledger에서 모두 판정되었는가.
- BOTH·중대 이슈가 누락되지 않았는가.
- REJECT·DEFER 판단에 근거가 있는가.

V3. Legal authority
- 현행 조문·이율·부칙·예규와 판례 5요소가 공식 원문에 맞는가.
- 판례의 예외·반대 법리·후속 변경을 누락하거나 판시 범위를 확장하지 않았는가.

V4. Graph and coverage
- 고아 노드, 정의되지 않은 ID, 막힌 측면 분기, 무한 순환이 없는가.
- 모든 비종결 Leaf에 Form이 있고 모든 Form은 도달 가능한가.
- 특수 경로도 적용 가능한 공통 검증 노드를 통과하는가.

V5. Drafting and enforceability
- 당사자, 금액, 목적물, 행위, 기간, 등기사항, 반대급부가 필요한 만큼 특정되는가.
- 청구원인이 청구취지 문형에 섞이지 않았는가.
- 원금·이자·지연손해금·기산일·이율 구간·병합 관계가 서로 모순되지 않는가.

V6. LLM usability
- 필수 입력과 미확정값 행동이 명확한가.
- 같은 규칙의 중복이 의사결정을 방해하지 않는가.
- 최상위 트리만 따라도 올바른 Leaf와 Form에 도달하는가.

검증 결과는 내부 defect ledger로 작성한다.
| Defect ID | 검증축 | 위치 | 결함 | 근거 | 심각도 | 수정 |

근거가 확인된 결함만 v2에 반영한다. 이 수정이 본 프롬프트에서 말하는 "1회 검증 후 다듬기"이다. 수정 후에는 파일 존재·UTF-8·placeholder·제목·ID 참조·마크다운 fence 같은 기계적 QC만 수행하며, 별도의 제2차 내용 검증 라운드를 시작하지 않는다.
</stage_6_single_validation_pass>

<stage_7_mechanical_qc_and_report>
다음 기계적 QC를 실행한다.
- 정확한 v2 경로의 파일 존재와 바이트 수
- UTF-8 디코딩 가능
- 의도하지 않은 "<####>" 잔존 여부
- 제목, 0~12 필수 section, Root/Leaf/Form/STOP ID 존재
- 정의되지 않은 Node·Form ID와 고아 후보
- 빈 링크, 미완성 TODO, 허위로 채운 값
- wc -l, shasum -a 256
- Git 저장소라면 해당 파일에 한정한 git diff --check와 scoped status

최종 보고는 다음만 간결하게 제시한다.
1. 확정 사건명과 사건키
2. 저장 경로
3. 평가 이슈 판정 수: ADOPT/MODIFY/REJECT/DEFER/NEW
4. 트리 Node/Leaf/Form 수와 커버리지 결과
5. 1회 검증에서 발견·수정한 결함 수
6. 미검증 또는 법률가 최종 확인이 필요한 잔여 항목
7. 바이트 수, 줄 수, SHA-256
</stage_7_mechanical_qc_and_report>

<fail_closed_rules>
- STOP-I01: placeholder 또는 registry 동일성 실패
- STOP-I02: 필수 입력 누락 또는 사건종류 불일치
- STOP-I03: 기존 v2와 충돌하며 덮어쓰기 권한 없음
- STOP-L01: 핵심 법률 명제를 공식 원문으로 검증하지 못해 안전한 operative rule을 만들 수 없음
- STOP-T01: 중대한 트리 단절 또는 Leaf–Form 공백을 해결할 수 없음

STOP 발생 시 불완전한 v2를 완성본처럼 보고하지 않는다. 확인된 사실, 정확한 차단 사유, 필요한 다음 입력만 보고한다.
</fail_closed_rules>

<final_stop_rule>
사건종류 "<####>"의 청구취지 작성을 위해 필요한 입력, 분기, 당사자, 특정성, 금전·시기, 병합, 문형, 금지 규칙, 근거 및 검증 경로가 대한민국 법조계 기준에 맞게 필요충분하고, 모든 Leaf가 검증된 Form에 연결되며, 미확정 사항의 안전한 행동이 정해졌을 때 작성을 종료한다. 분량 자체를 완성 기준으로 삼지 않는다.
</final_stop_rule>