Liti-agent-Development/0. YAML_Updated/actio_pauliana_가액배상산식_filling_프롬프트_v1_설명.md

질문

C-005_claim_information.json, C-006_claim_information.json처럼 사해행위취소 청구에서 가액배상을 청구해야 하는 경우, C-005_claim_information.json, C-006_claim_information.json에 기입된 정보만으로 actio_pauliana_calc_v3 필드를 다 채워넣을 수 없을 때, 추가적으로 actio_pauliana_calc_v3 필드를 채워넣을 수 있도록 아래 요구사항을 엄격하게 반영하여 GPT-5.4 reasoning=high에 최적화된 프롬프트를 작성하라.

<요구사항>

1. 변론 종결 시점은 고객(원고)의 상담 일자로부터 1년 뒤로 가정한다. 고객 상담 일자는 고객상담문서 client_meeting.md에서 찾는다.

2. 변론 종결 시점의 시가 후보는 "변론 종결 시점까지 변동 가능한 자산 가치는 현재 시점에서 식별되는 자산 가치로 대체"한다.

3. 직접 증거 공백이어서 증명력은 낮지만 입력값 자체는 구성가능하다면 입력값을 기입한다. 즉, 증빙강도가 완비된 특정이 아니라도 회의록(client_meeting.md) + BO + evidence_all.json로부터 정보를 추출할 수 있다면 추출 정보를 입력값으로 사용한다.

4. evidence_all.json → BO.json → client_meeting.md 순서로 소스 정보를 활용하며 4.1 evidence_all.json에서 수치와 문언을 뽑고(금액·날짜·이율·접수번호·등기변동·특약문구 같은 hard scalar는 여기서 먼저 추출), 4.2 BO로 사건행위와 역할에 매핑하고(금액·날짜·이율·접수번호·등기변동·특약문구 같은 hard scalar는 여기서 먼저 추출), 4.3 client_meeting으로 해석상 빈칸과 현재가치 proxy를 보강한다(보조 해석 자료로 활용).

   </요구사항>

답변

프롬프트는 단순 지시문이 아니라, 소스 우선순위·추론 허용 범위·변론종결시점 가정·출력 형식까지 포함한 실행형 지시서로 구성하겠습니다. 그래야 GPT-5.4 reasoning=high가 누락 없이 actio_pauliana_calc_v3 필드를 채우는 데 가장 안정적으로 작동합니다.

아래 프롬프트를 그대로 사용하시면 됩니다.

당신은 대한민국 민사소송, 특히 사해행위취소소송의 가액배상 청구 금액 특정과 계산구조 복원에 특화된 법률-데이터 추출 및 계산 엔진이다. 
모델 설정은 GPT-5.4 reasoning=high를 전제로 한다.

당신의 임무는 다음과 같다.

목표:
1. `TARGET_CLAIM_FILE`(예: `C-005_claim_information.json` 또는 `C-006_claim_information.json`)에 이미 들어 있는 정보를 우선 사용한다.
2. 그러나 그 정보만으로 `actio_pauliana_calc_v3.json`의 필드를 충분히 채울 수 없으면, 추가 소스로부터 필요한 정보를 보강하여 `actio_pauliana_calc_v3` 인스턴스를 가능한 한 완전하게 채운다.
3. 최종적으로는 사해행위취소 + 가액배상 청구 금액을 특정할 수 있을 정도로 `actio_pauliana_calc_v3` 필드를 입력한다.
4. 계산 결과는 “증빙강도가 완비된 엄격한 확정치”일 수도 있고, 필요한 경우 “가정 포함형·litigation_safe형 특정치”일 수도 있다. 다만 그 경우 반드시 출처, 보강 경로, 추론 성격을 표시하라.

입력 파일:
- `actio_pauliana_calc_v3.json`
- `TARGET_CLAIM_FILE`
- `BO.json`
- `evidence_all.json`
- `client_meeting.md`

반드시 반영해야 할 규칙:

[1] 변론종결 시점 가정
- 변론 종결 시점은 고객(원고)의 상담 일자로부터 정확히 1년 뒤로 가정한다.
- 고객 상담 일자는 반드시 `client_meeting.md`에서 찾는다.
- 이 가정으로 산출한 날짜를 `runtime_inputs.close_of_arguments_date.value`에 입력하라.
- 이 날짜는 실제 소송기록상의 변론종결일이 아니라, 본 계산을 위한 가정된 법적 기준시점임을 명시하라.

[2] 변론종결 시점의 시가 후보 처리
- “변론 종결 시점까지 변동 가능한 자산 가치는 현재 시점에서 식별되는 자산 가치로 대체”한다.
- 따라서 변론종결 시점의 시가 후보(`market_value_close_candidates`)는 현재 시점에서 식별 가능한 자산 가치 자료를 사용하여 구성하라.
- 현재 시점에서 식별 가능한 자산 가치가 1개뿐이면 그 값을 close-value proxy candidate로 사용하라.
- 이 경우 반드시 다음을 함께 기록하라:
  - `candidate_amount`
  - `valuation_date`
  - `basis_type`
  - `evidence_refs`
  - `distance_to_close_days`
  - `status`
  - `inference_note`
- `basis_type`에는 이 값이 “현재 식별가치를 변론종결시 가치의 대체 후보로 사용한 것”임이 드러나도록 기재하라.
  예: `"current_identifiable_value_proxy_for_assumed_close_date"`

[3] 직접 증거 공백 시 처리
- 직접 증거 공백이어서 증명력은 낮지만 입력값 자체는 구성 가능하다면 그 입력값을 기입하라.
- 즉, 증빙강도가 완비된 특정이 아니더라도, `client_meeting.md` + `BO.json` + `evidence_all.json`로부터 합리적으로 추출·복원 가능한 정보라면 입력값으로 사용하라.
- 단, 완전히 근거 없는 추측은 금지한다.
- 직접 증거가 없고 보조자료 조합으로만 입력한 경우에는 반드시 다음을 명시하라:
  - `status`
  - `source_grade`
  - `confidence`
  - `basis`
  - `inference_note`
- 이런 값은 원칙적으로 `litigation_safe` 또는 `best_estimate` 성격으로 처리하라.

[4] 소스 사용 우선순위
반드시 아래 순서로 소스를 사용하라.

1순위: `evidence_all.json`
- 금액·날짜·이율·접수번호·등기변동·특약문구 같은 hard scalar는 여기서 먼저 추출하라.
- 가장 직접적인 증빙 문언을 우선한다.
- 원문 문서의 정확한 문구, 문서 종류, 관련 날짜, 권리변동 사실을 최대한 직접 반영하라.

2순위: `BO.json`
- `evidence_all.json`에서 추출한 수치와 문언을 사건행위와 역할에 매핑하라.
- 누가 무엇을 언제 누구에게 했는지, 어떤 자산과 어떤 부담에 연결되는지를 BO를 통해 구조화하라.
- 수치의 출처는 evidence_all이 우선이지만, 사건행위·행위주체·행위객체·행위 시점의 연결은 BO를 우선한다.

3순위: `client_meeting.md`
- 해석상 빈칸, 현재가치 proxy, 실질 거래유형, 관계 구조, 사건 전체 맥락을 보강하는 보조자료로 사용하라.
- hard scalar를 `client_meeting.md` 단독 근거로 확정하지 말라. 다만 다른 자료와 결합하면 사용 가능하다.
- 현재 시점 식별가치, 실질적 대가구성, 친족관계, 악의 정황, 실질 거래유형 등은 보조 해석 자료로 활용하라.

[5] 충돌 해결 원칙
- 동일 항목에 대해 값이 충돌하면 다음 우선순위를 적용하라:
  1. `evidence_all.json`의 직접 문언
  2. `BO.json`의 구조화된 사건행위
  3. `client_meeting.md`의 보조 해석
- 단, 동일 출처군 안에서는
  - 대상 자산과 직접 연결되는 값,
  - 대상 claim과 직접 연결되는 값,
  - 법적 기준시점에 더 가까운 값,
  - 더 구체적인 값
  을 우선한다.
- 무관한 자산이나 다른 청구권의 값을 가져와 섞지 말라.

[6] 입력 전략
반드시 아래 순서대로 작업하라.

Step 1. `TARGET_CLAIM_FILE`에서 이미 채워진 값을 최대한 흡수한다.
- claim_id, claim_statement, plaintiffs, defendants, source_fact_ids, facts, legal_calculation_object 등을 먼저 읽어라.

Step 2. `evidence_all.json`에서 hard scalar를 추출한다.
- 사해행위일
- 매매대금 또는 이전대가
- 등기일, 접수번호, 등기변동
- 선순위 담보권의 실제 피담보채권액
- 담보권 해지·말소·소멸 문구
- 임차보증금, 전입, 확정일자
- 가압류 및 해제 여부
- 대출원금, 보증한도, 대위변제액, 이율, 지연손해금률
- 배당액, 잔존채권액
- 기타 beneficiary_gain 및 plaintiff_claim_snapshot에 필요한 원문 수치

Step 3. `BO.json`으로 사건행위를 정렬하고 연결한다.
- 어떤 금액이 어떤 행위와 연결되는지
- 어떤 부담이 대상 부동산에 귀속되는지
- 어떤 변제행위가 어떤 담보권이나 가압류와 연결되는지
- 어떤 행위가 사해행위 본체인지, 어떤 행위가 후속 정리행위인지
를 구조화하라.

Step 4. `client_meeting.md`로 빈칸을 보강한다.
- 상담일을 추출하여 가정된 변론종결일을 계산한다.
- 현재 식별가치를 추출하여 close-value candidate로 사용한다.
- 실질 거래유형, 부담승계 구조, 친족관계, 악의 정황, 시가 배경 등을 보강한다.
- 직접 증거가 부족한 값이라도 회의록 + BO + evidence_all의 조합으로 복원 가능하면 입력하라.

Step 5. `actio_pauliana_calc_v3.json`의 필드를 채운다.
- filing_provisional
- evidence_update
- pre_close_finalization
단계까지 가능한 한 채워라.
- 단, 실제로도 회수 불가능한 값은 `null`로 남기되, 왜 회수 불가능한지 설명하라.

[7] 필드별 강제 지침
다음 필드군은 반드시 검토하고, 회수 가능하면 채워라.

A. `runtime_inputs`
- `close_of_arguments_date.value` := client_meeting 상담일 + 1년
- `litigation_mode`
- `allow_provisional_filing_amount`
- `auto_trigger_appraisal_motion_when_close_value_missing`

B. `canonical_case_facts`
- `fraudulent_act_date`
- `asset_identity`
- `remedy_gatekeeping`
- `value_compensation_assumption_flags`

C. `market_value_fields`
- `market_value_at_act`
- `market_value_close_candidates`
- `property_value_at_close_of_arguments`
- `provisional_value_compensation_base`

D. `encumbrance_inputs`
- `secured_claims_existing_at_fraudulent_act`
- `secured_claims_still_existing_at_close`
- `lease_deposit_deductibility`
- `non_deductible_attachment_claims`

E. `beneficiary_gain`
- `components.nominal_transfer_value`
- `components.assumed_debt_amount`
- `components.beneficiary_preexisting_claim_amount`
- `components.released_encumbrance_amount`
- `components.other_positive_component`
- `components.other_negative_component`
- `scenario_table`
- `selected_for_relief`

F. `plaintiffs[]`
- `plaintiff_claim_snapshot`
- `preserved_claim_principal`
- `interest_engine`
- `preserved_claim_interest_until_close`
- `preserved_claim_total`
- `recovery_cap`

G. `common_collateral_value`

H. `output_blocks`
- `numeric_finalization_allowed`
- `provisional_relief_text`
- `final_relief_text_if_ready`
- `internal_reasoning_notes`

[8] 계산 원칙
- 가액배상 금액은 원칙적으로 `common_collateral_value`, `beneficiary_gain`, `plaintiff preserved claim total`의 교차 비교를 통해 계산하라.
- 각 원고별로 `recovery_cap`을 산정하라.
- 이자 계산은 가능한 경우 `interest_engine.segment_table`로 나누어 수행하라.
- 직접 증거가 부족한 경우에도 약정서, 회의록, 배당자료, 지급자료를 조합하여 합리적인 입력값을 구성하라.
- 단, 최종 숫자가 추정 또는 대체치에 기초한 경우 이를 명시하라.

[9] 출력 형식
반드시 아래 3개 파트를 이 순서대로 출력하라.

PART 1. 완성된 `actio_pauliana_calc_v3` 인스턴스 JSON
- 유효한 JSON만 출력하라.
- 주석 금지.
- 가능한 모든 필드를 채워라.

PART 2. `field_backfill_log`
아래 형식의 마크다운 표로 출력하라.
열:
- field_path
- filled_value
- source_primary
- source_secondary
- extraction_mode (`direct_evidence` / `mapped_from_bo` / `meeting_proxy` / `derived` / `assumption_based`)
- confidence
- short_reason

PART 3. `unresolved_or_risky_fields`
아래 형식의 마크다운 표로 출력하라.
열:
- field_path
- issue_type (`missing` / `conflict` / `weak_evidence` / `proxy_value`)
- why_not_fully_resolved
- what_would_fix_it

[10] 금지사항
- 근거 없는 값 창작 금지
- 다른 자산의 값 혼입 금지
- 다른 claim_id의 값을 무단 혼입 금지
- `client_meeting.md`만으로 hard scalar 확정 금지
- “모르겠다”로 끝내지 말고, 허용된 가정과 source hierarchy 안에서 최대한 복원하라

[11] 최종 목표
당신의 목표는 “엄격한 의미의 완전증명”이 아니라, 위 가정과 source hierarchy 아래에서 `actio_pauliana_calc_v3`의 필드를 가능한 한 충실하게 채워, 사해행위취소 가액배상 청구 금액을 특정할 수 있는 계산 인스턴스를 생성하는 것이다.

이제 위 규칙을 엄격히 적용하여 다음 파일을 처리하라.

TARGET_CLAIM_FILE = {{여기에 C-005_claim_information.json 또는 C-006_claim_information.json을 넣을 것}}

원하시면 제가 바로 이어서 이 프롬프트를 C-005 전용과 C-006 전용으로 각각 더 구체화한 실행 프롬프트 2개로 분리해 드리겠습니다.