trex-core/docs/discovery/dcy-018_20260608_ledger-response-cash-position-writeback.md

0. 문서 상태

이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.

• 상태: confirmed
• 문서 ID: dcy-018_20260608_ledger-response-cash-position-writeback
• 이슈명: ledger write 응답의 cash/quantity 를 portfolio 스냅샷에 write-back — option D 활성화 + 수량 source 통일
• 작성 시각(KST): 2026-06-08 20:08 KST
• 마지막 갱신 시각(KST): 2026-06-08 21:45 KST
• 대체됨: 없음
• 후속 Discovery 참조: 없음
• 생성된 REQ 참조: REQ-017/019/029 change-req + REQ-030 Approved→Implemented (전부 change-req, 신규 REQ 없음 — OQ-3 a). REQ-017/019=CHG-20260608-02, REQ-029/030=CHG-20260608-01. delivery: BAT-023

1. 계획 상태 요약

현재 Discovery가 어떤 배경에서 작성되고 있는지, 연계 문서가 있는지, 지금 시점의 해석이 무엇인지 짧게 요약한다.

• 연계 문서 현황:
  • 관련 점수 파일: 미생성
  • 관련 TODO/메모: 운영 관측(매수 후 universe asset_quantity 는 1로 바뀌나 cash_balance 는 불변), portfolio-hub#8(ledger 응답에 cash/quantity 반환) 요청
• 해석:
  • 의도된 설계는 "ledger write → portfolio-hub 응답(cash/quantity) → trex-core SnapshotStore 갱신"(REQ-030 option D)이다. 그런데 trex-core 측에서 응답 파싱·write-back 배선이 누락되어, 현금은 일일 스냅샷 전까지 반영되지 않고 수량만 슬롯 오버레이로 살아있어 보이는 비대칭이 발생한다.
  • 이번 Discovery에서는 (1) ledger write 응답의 cash/quantity 를 파싱·운반, (2) SnapshotStore write-back 배선(option D 활성화), (3) 수량 source 를 portfolio-hub 권위값으로 통일(슬롯 오버레이 정합)하는 범위를 판정한다. portfolio-hub#8 응답 계약 의존과 거버넌스도 함께 정한다.

2. 요구사항 판정 결과

이번 요청이 기존 요구사항과 비교해 신규인지, 유사한지, 중복인지 판단하고 그 근거를 남긴다.

• 판정: 신규
• 근거
  • REQ-030(option D 현금/포지션 갱신)은 Approved 상태로 "wired but no-op until portfolio-hub#8 ships" 로 연기되어 구현되지 않았다. 본 Discovery 는 그 연기된 경로를 실제 활성화하고, ledger 응답 파싱(REQ-017)·write-back 배선(REQ-019)·수량 source 통일(REQ-029)을 함께 다룬다.
  • dcy-005(snapshot read)는 option D 를 정의했으나 portfolio-hub#8 대기로 미구현 상태로 남겼다. 운영 환류로 갭이 확인되어 독립 주기로 활성화·정합하는 것이 명확하다.

3. 문제점의 요약

문제의 현재 상태, 기대 상태, 관련 이해관계자, 제약사항을 정리한다. Discovery의 핵심 맥락을 가장 먼저 이해할 수 있어야 한다.

• 현재 상태
  • (1) ledger 응답 폐기: trex_core/adapters/ledger/portfolio_hub.py 의 record_trade(portfolio_hub.py:78~94)는 2xx 응답에서 resp.json() 을 읽지만 오직 duplicate 플래그만 보고 LedgerWriteResult.NEW/DUPLICATE_OK 만 반환한다. portfolio-hub 가 cash/quantity 를 응답에 실어도 추출·반환하지 않는다.
  • (2) write-back 배선 부재: trex_core/application/ledger_outbox.py 의 LedgerWriter(ledger_outbox.py:132~)는 SnapshotStore 참조가 없어, 응답에 값이 있어도 갱신할 경로가 없다.
  • (3) sink 만 존재, 호출자 없음: trex_core/application/portfolio.py 의 SnapshotStore.update_cash_position(portfolio.py:148~)은 cash_balance·asset_quantity 를 쓰는 메서드로 구현돼 있으나, ledger 경로에서 호출되지 않는다(snapshot_scheduler 의 코멘트만 참조).
  • 수량 비대칭(슬롯 오버레이): build_snapshot_envelope(portfolio.py:426~427)는 universe 의 asset_quantity 를 로컬 슬롯 holding qty 로 override(REQ-029)한다. 그래서 매수 직후 수량은 슬롯에서 살아있게 보이지만 portfolio-hub 권위값이 아니고, 현금은 오버레이가 없어 옛 스냅샷 값 그대로다.
  • option D 미구현: REQ-030(option D 현금/포지션 갱신)은 Approved(미구현). snapshot_scheduler.py:5~6 주석 — "wired through SnapshotStore.update_cash_position but disabled at the ledger layer until portfolio-hub#8 ships".
  • baseline 문서(docs/project-structure.md, docs/runtime-flows.md, docs/data-model.md)는 존재하며 최신이다. ledger 기록·스냅샷 read 는 기존 runtime flow 에 속한다.
• 기대 상태
  • ledger NEW write 후 portfolio-hub 응답의 cash/quantity 가 SnapshotStore 에 write-back 되어, 매수/매도 직후 cash_balance 와 asset_quantity 가 모두 portfolio-hub 권위값으로 갱신된다.
  • 수량과 현금이 동일 source(portfolio-hub) 로 통일되어, "수량은 살아있고 현금은 stale" 한 비대칭이 사라진다.
  • portfolio-hub 불가/응답 누락 시에도 best-effort 로 degrade 하며 ledger 기록·청산 동작을 막지 않는다.
• 이해관계자
  • 문서 작성자(AI agent) — Discovery/REQ/Batch 산출물 작성
  • 리뷰어/승인자 — ledger 응답 계약·write-back·수량 source 변경 승인
  • 운영 담당자 — 실시간 현금/포지션 정합 관측
  • portfolio-hub 팀 — ledger write 응답에 cash/quantity 반환(portfolio-hub#8) 제공 측
• 제약사항
  • ledger write 응답의 cash/quantity 필드 계약은 portfolio-hub#8 배포·응답 스키마에 의존한다(외부 의존).
  • write-back 부수효과가 ledger 기록 멱등(REQ-019)·청산 동작을 깨지 않아야 한다(best-effort 격리).
  • 수량 source 변경(슬롯 오버레이 → portfolio-hub)은 매수~ledger 반영 사이의 타이밍 공백 처리가 필요하다.

주요 사용자 시나리오

사용자 또는 운영자가 실제로 어떤 상황에서 이 변경을 필요로 하는지 대표 시나리오를 적는다.

• 운영자가 trex-core enter 로 매수 후 trex-core universe 를 보면, asset_quantity 와 cash_balance 가 모두 portfolio-hub 권위값으로 갱신되어 있다(현재는 수량만).
• 매도 후에도 동일하게 현금 증가·수량 감소가 즉시 스냅샷에 반영된다.
• portfolio-hub 가 일시 불가하면 cash/quantity 가 stale 임을 degraded 로 신호하고, ledger 기록은 outbox 로 계속 진행된다.

4. 이번에 정의할 변경

이번 Discovery에서 다루는 핵심 변경 항목을 목록으로 적는다. 기능, 구조, 규칙 변경을 함께 포함해도 된다.

• ledger 어댑터 record_trade 가 portfolio-hub 응답의 cash/quantity 를 파싱·운반하도록 결과 타입을 확장한다(현재 LedgerWriteResult 만 → cash/quantity 동반).
• LedgerWriter 에 SnapshotStore 를 주입하고, new(201)·duplicate(200) 응답의 cash_balance_after/asset_quantity_after(절대 권위값) 로 update_cash_position(asset_id, cash, quantity) write-back 한다(option D 활성화, best-effort; 409/422 는 *_after 미정의라 skip — OQ-2 b).
• 수량/현금 source 정합(OQ-1 B): 슬롯 오버레이(REQ-029)는 유지(lifecycle 중인 슬롯은 코어 권위 즉시값, 불변식 A), write-back 은 현금 + 슬롯 밖(미보유) base 수량을 portfolio-hub 권위값으로 신선화. 비대칭(수량 live·현금 stale) 제거.
• 체결~write-back 공백 동안 현금을 추정 오버레이로 즉시 표시(OQ-4 (i)): base 권위 현금 ± 미정산 체결 cash_delta(체결가×수량 ∓ 수수료/세금), "추정/미정산" 라벨 필수, write-back 권위값 도착 시 교체.
• 응답 계약·write-back·수량/현금 정합을 baseline 문서(interface-contract/runtime-flows)에 반영한다.

영향 범위

변경이 미칠 코드/문서/운영 범위를 명시해 REQ 정제와 batch planning에서 추정 누락을 줄인다.

• 코드 영향:
  • trex_core/adapters/ledger/portfolio_hub.py — record_trade 응답 파싱(cash/quantity) + 결과 타입 확장
  • trex_core/application/ledger_outbox.py — LedgerWriter 에 SnapshotStore 주입 + NEW write 후 update_cash_position 호출(best-effort)
  • trex_core/application/portfolio.py — update_cash_position 활용, 수량 source 정합(build_snapshot_envelope 의 슬롯 오버레이 처리)
  • trex_core/runtime/daemon.py — LedgerWriter 에 SnapshotStore 배선
• 문서 영향:
  • docs/interface-contract.md — ledger write 응답 계약(cash/quantity) + 스냅샷 cash/quantity source 반영
  • docs/runtime-flows.md — ledger write → 응답 → SnapshotStore write-back 흐름 추가
• 운영 영향:
  • 매매 직후 실시간 현금/포지션 정합 → 운영 관측 정확도 향상
  • portfolio-hub#8 응답 계약 의존 — 배포 조율 필요

5. 요구사항 목록

실제로 구현과 검증으로 이어질 요구사항을 기능/비기능으로 나누어 정리하고, 범위 경계를 명확히 적는다.

기능 요구사항

• FR-1: record_trade 는 portfolio-hub ledger write 응답 root 의 flat 필드 cash_balance_after/asset_quantity_after(절대 권위값)를 파싱해 운반한다(결과 타입 확장, new/duplicate 구분 유지). status별: new(201)·duplicate(200) = 권위값 있음, 409·422 = *_after 미정의(dcy-005 A-7 / portfolio-hub#8 확정·동작 중).
• FR-2: LedgerWriter 는 new·duplicate write 성공 시 SnapshotStore.update_cash_position(asset_id, cash_balance_after, asset_quantity_after) 로 write-back 한다(OQ-2 b — *_after가 delta 아닌 절대 권위값이라 덮어써도 멱등). 409/422 는 skip. 부수효과는 best-effort — 실패가 ledger 기록 멱등(REQ-019)·청산을 막지 않는다(write 성공 이후 분리 수행, 예외 무시).
• FR-3: 수량 source 정합(OQ-1 B) — 슬롯 오버레이(REQ-029)는 유지(lifecycle 중 슬롯은 코어 권위 즉시값, 불변식 A). write-back 은 현금 + 슬롯 밖 base 수량을 portfolio-hub 권위값으로 신선화. 슬롯 권위와 write-back 권위가 어긋나면 숨기지 않고 포지션 정합 경고(REQ-031)로 노출.
• FR-3a: 임시 현금 추정 오버레이(OQ-4 (i)) — 체결~write-back 공백 동안 base 권위 현금 ± 미정산 체결 cash_delta(체결가×수량 ∓ 수수료/세금)를 "추정/미정산" 라벨과 함께 노출하고, write-back 권위값 도착 시 교체·미정산 delta 제거. 코어 수수료(calculate_fee)는 근사라 추정 오차는 라벨로 커버.
• FR-4: portfolio-hub 불가·응답 누락(또는 dead-letter, dcy-015) 시 권위 현금/수량을 갱신하지 못하므로 추정·pending 유지 + degraded(REQ-028)로 신호하고 write-back 을 건너뛴다(best-effort).
• FR-5: docs/interface-contract.md·docs/runtime-flows.md 에 응답 계약(*_after)·write-back 흐름·수량/현금 source·추정 오버레이를 반영한다.

비기능 요구사항

성능, 운영성, 일관성, 자동화 안정성 등 기능 외 요구사항을 적는다.

• NFR-1: 안전 격리 — write-back 부수효과는 best-effort 이며, 어떤 실패도 ledger 기록 멱등(REQ-019)·청산 동작을 차단하지 않아야 한다.
• NFR-2: 권위 일관성 — cash 와 quantity 가 동일 source(portfolio-hub)에서 와 비대칭(수량 live·현금 stale)이 재발하지 않아야 한다.
• NFR-3: 멱등 정합 — DUPLICATE write 응답으로 인한 cash/quantity 중복 적용이 없어야 한다(멱등 write-back).

범위 경계

이번 반복에서 반드시 포함할 범위와 명시적으로 제외할 범위를 구분한다.

• In Scope
  • ledger write 응답 cash_balance_after/asset_quantity_after 파싱(record_trade) + write-back 배선(LedgerWriter→update_cash_position, new+duplicate)
  • 수량/현금 source 정합(슬롯 오버레이 유지 + write-back 권위 신선화, OQ-1 B)
  • 임시 현금 추정 오버레이(라벨, OQ-4 (i)) + write-back 권위 수렴
  • degraded/best-effort 처리 + 문서 갱신 + REQ-030 Approved→Implemented
• Out of Scope
  • portfolio-hub#8 자체(외부 — 이미 배포·동작 중, 본 주기는 trex-core 소비 측)
  • 일일 스냅샷 스케줄러 자체 재설계(REQ-030 의 fetch 부분은 유지)
  • 슬롯 오버레이 제거(OQ-1 B 로 유지 확정 — 제거 안 함)

6. 리스크/가정 목록

불확실성과 전제 조건을 분리해서 적는다. 리스크는 영향과 완화 방안을, 가정은 현재 판단의 전제를 기록한다.

리스크

• R-1 (High): write-back 부수효과가 실패·지연하면 ledger 기록 루프·청산을 막을 수 있다.
  • 완화 방안: FR-2 best-effort 격리(RedisTokenCache/dcy-017 패턴) — 예외를 no-op 무시, ledger 멱등·청산 동작 불변. write-back 은 write 성공 이후 분리 수행.
• R-2 (해소): portfolio-hub#8 응답 스키마 미확정 위험.
  • 해소: 응답 스키마 = root flat cash_balance_after/asset_quantity_after(dcy-005 A-7 확정) + portfolio-hub#8 배포·동작 중(2026-06-08). 필드 부재(409/422) 시 write-back skip(보수). 잔여 위험 없음.
• R-3 (Low, OQ-1 B + OQ-4 로 완화): 매수~write-back 공백에 현금이 잠깐 stale 할 수 있다.
  • 완화 방안: 수량은 슬롯 오버레이(정확값) 유지, 현금은 추정 오버레이(OQ-4 i, "추정/미정산" 라벨)로 즉시 표시 후 권위값 수렴. 공백 구간은 outbox drain(~1s)으로 짧다.
• R-4 (Medium): DUPLICATE write 응답에 cash/quantity 가 와도 중복 적용하면 정합이 깨진다.
  • 완화 방안: NEW write 에만 write-back 적용(또는 멱등 키 기준), DUPLICATE 는 스킵(NFR-3).

가정

아직 확정되지 않았지만 현재 문서 작성의 기반이 되는 전제를 적는다.

• A-1: portfolio-hub 가 ledger write 응답에 갱신된 cash/quantity 를 반환한다(portfolio-hub#8). 미배포 시 본 변경은 write-back 스킵(stale)으로 안전 동작하며, 배포 후 활성화된다.
• A-2: SnapshotStore.update_cash_position 이 이미 구현돼 있어 sink 는 재사용 가능하고, 누락된 것은 source(응답 파싱)와 배선(writer→store)뿐이다.
• A-3: ledger 기록 멱등(correlation_id, REQ-019)은 그대로 유지되며, write-back 은 그 위의 관측 갱신이다.

오픈 질문

답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 REQ 초안 작성 이전에 확인할 질문으로 남긴다.

• OQ-1: 수량 source 통일 방식 — 슬롯 오버레이(REQ-029)를 제거하고 portfolio-hub write-back 값으로 일원화하는가, 아니면 슬롯 오버레이를 유지하고 write-back 으로 수렴하는가?
  • 상태: Answered (2026-06-08, 사용자 결정 — B: 슬롯 오버레이 유지 + write-back 수렴)
  • 결정: 슬롯 오버레이(REQ-029)는 유지한다 — lifecycle 중인 슬롯은 코어 자체 권위·즉시·외부 무관(불변식 A). portfolio-hub write-back 은 현금과 슬롯 밖(미보유) base 수량을 권위값으로 신선화해 비대칭(수량 live·현금 stale)을 제거한다. (A)는 매수 직후 공백에 수량을 옛값으로 후퇴시키고 portfolio-hub 불가 시 보유 수량이 0 으로 보이는 안전 리스크가 있어 미채택.
  • 반영 위치: FR-3, 4. 변경 항목, 범위 경계
• OQ-2: write-back 시점/실패 처리 — 어떤 응답에 write-back 하고, 불가·DUPLICATE·잔고부족 시 규칙은?
  • 상태: Answered (2026-06-08, 사용자 결정 — b)
  • 결정: *_after 가 delta 가 아니라 절대 권위값이므로 new(201)·duplicate(200) 둘 다 write-back(덮어써도 멱등). 409·422 는 *_after 미정의라 skip. 시점은 LedgerWriter 가 ledger write 성공 응답을 받은 직후(별도 read round-trip 불요). write-back 부수효과는 best-effort — 예외/누락은 무시하고 ledger 멱등(REQ-019)·청산을 막지 않는다.
  • 반영 위치: FR-2, FR-4, NFR-1/3
• OQ-3: 거버넌스 경로 — change-req 로 처리할지, 신규 REQ 로 추적할지?
  • 상태: Answered (2026-06-08, 사용자 결정 — a: 전부 change-req)
  • 결정: 기존 Implemented/Approved REQ 본문 수정(change-req)으로 처리한다. 대상 — REQ-017(어댑터 *_after 응답 파싱 + 결과 타입 확장), REQ-019(LedgerWriter write-back 배선 + SnapshotStore 주입), REQ-029(수량 source 정합 — 슬롯 오버레이 유지 명시), REQ-030(option D 활성화 — Approved→Implemented; REQ-030 Change Log Follow-up 의 "portfolio-hub#8 배포 후 minor-change 로 option D 구현" 예고대로). 신규 REQ 는 생성하지 않는다. (임시 현금 추정은 REQ-029/030 범위 내 관측 갱신으로 흡수.)
  • 반영 위치: 1. 거버넌스 해석, 범위 경계
• OQ-4: 체결~write-back 공백 동안 임시 현금 처리 — 추정값을 계산해 보여줄지(라벨), 아니면 마지막 권위값 + pending 플래그만 노출할지?
  • 상태: Answered (2026-06-08, 사용자 결정 — (i) 추정 오버레이)
  • 결정: 공백 동안 추정 현금을 계산해 노출한다 — base 권위 현금 ± 미정산 체결 cash_delta(체결가×수량 ∓ 수수료/세금), "추정/미정산" 라벨 필수. write-back 권위값(cash_balance_after) 도착 시 교체하고 해당 미정산 delta 를 제거한다. 코어 수수료(calculate_fee)는 근사라 추정 오차가 있으나 라벨로 커버하고, 추정 노출 구간은 outbox drain(~1s)으로 짧다. (수량은 슬롯 오버레이가 정확값이라 추정 불요 — OQ-1 B 와 짝.)
  • 반영 위치: FR-3a, 4. 변경 항목, R-3

오픈 질문 처리 기준

• Open: 아직 답이 없고 다음 단계 진행에 영향이 있는 상태다. 문서에 유지한다.
• Answered: 답이 확정된 상태다. 관련 본문/요구사항에 반영한 뒤 오픈 질문 목록에서는 제거하거나 resolved 기록으로 이동한다.
• Deferred: 지금 단계에서 결정하지 않고 다음 단계 또는 후속 이슈로 넘기는 상태다. 넘길 대상과 이유를 반드시 적는다.
• Dropped: 더 이상 유효하지 않은 질문이다. 삭제 사유를 짧게 남기고 목록에서 제거한다.

7. 초기 성공 기준

이 변경이 성공했다고 판단할 기준을 측정 가능하게 정의한다. 가능하면 데이터 출처까지 연결한다.

• S-1: 매수/매도 후 universe 스냅샷의 cash_balance 와 asset_quantity 가 모두 portfolio-hub 응답 권위값으로 갱신된다(현재: 수량만 live, 현금 stale).
• S-2: portfolio-hub 응답에 cash/quantity 가 없거나 불가하면 write-back 을 스킵하고 ledger 기록·청산이 정상 동작한다(best-effort).
• S-3: DUPLICATE write 응답이 cash/quantity 를 중복 적용하지 않는다(멱등).

측정 방식 및 데이터 출처

각 성공 기준을 어떻게 측정할지와 어떤 데이터나 문서를 근거로 쓸지 적는다.

• S-1 측정 방식: ledger write 응답 fixture(cash/quantity 포함) 주입 후 SnapshotStore 갱신·universe 출력 확인 / 데이터 출처: record_trade/LedgerWriter 테스트, universe 응답
• S-2 측정 방식: 응답 누락/portfolio-hub 불가 주입 시 write-back 스킵·ledger 정상 확인 / 데이터 출처: 장애 주입 테스트, outbox 상태
• S-3 측정 방식: 동일 execution_id 중복 write 시 cash/quantity 1회만 적용 확인 / 데이터 출처: 멱등 write-back 테스트

8. REQ로 넘기기 전 확인 체크

REQ 초안 작성 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다.

• 범위(In Scope/Out of Scope) 확정
  • 기준: 수량 source(OQ-1 B)·write-back 규칙(OQ-2 b)·임시 현금(OQ-4 i)·거버넌스(OQ-3 a) 확정으로 In/Out of Scope 채워짐
• 성공 지표의 측정 방식/데이터 출처 확정
  • 기준: S-1~S-3 의 테스트/검증 출처가 실제 실행 가능한 형태로 지정됨
• High 영향 리스크 우선순위 및 해소 책임자 지정
  • 기준: R-1(write-back best-effort 격리)·R-2(응답 스키마 = *_after 확정, portfolio-hub#8 동작 중)의 해소 방식과 change-req 추적(OQ-3 a)이 확정됨. 해소 실무 책임자 배정은 REQ/batch planning 단계로 넘김(비차단).
• 모든 오픈 질문(OQ) Open 상태 없음 확인
  • 기준: OQ-1~OQ-4 모두 Answered, Open 0개
• Freeze 확정 담당자(CONFIRMED_BY) 지정
  • 기준: Confirmed By = Justin (confirm-discovery 단계 지정)

9. 파일 처리 결과

이 Discovery 문서 생성/갱신 결과와 참조 문서를 기록한다. 이후 추적과 리뷰 시 근거로 사용한다.

• 처리 결과: 생성
• 생성 경로: docs/discovery/dcy-018_20260608_ledger-response-cash-position-writeback.md
• 참조 문서:
  • 운영 환류(매수 후 cash_balance 미반영 관측) + portfolio-hub#8 요청
  • docs/discovery/dcy-005_20260604_portfolio-hub-asset-snapshot-api.md — REQ-029(슬롯 오버레이)/REQ-030(option D) 도입 근거
  • docs/discovery/dcy-004_20260604_portfolio-hub-ledger-integration.md — ledger 기록 경로
  • trex_core/adapters/ledger/portfolio_hub.py:78-94 — record_trade 응답 폐기 지점
  • trex_core/application/ledger_outbox.py:132 — LedgerWriter(SnapshotStore 부재)
  • trex_core/application/portfolio.py:148, 426-427 — update_cash_position(호출자 없음)·슬롯 오버레이

10. 사용자 결정 필요 항목 요약

사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. 결정, 확인, 데이터 요청을 구분해서 적는다.

결정 완료(2026-06-08): OQ-1 수량 source = B(슬롯 오버레이 유지 + write-back 수렴) / OQ-2 write-back = b(new+duplicate 둘 다, 409·422 skip, best-effort) / OQ-3 거버넌스 = a(전부 change-req: REQ-017·019·029·030) / OQ-4 임시 현금 = (i) 추정 오버레이(라벨)+권위 수렴. DATA(portfolio-hub#8 응답 스키마)는 해소.

DECIDE

• (없음 — OQ-1/OQ-4 확정으로 수량/현금 source 해소)

CONFIRM

• (없음 — 거버넌스 경로 OQ-3 a 로 확정: REQ-017/019/029/030 change-req, 신규 REQ 없음)

DATA

• (해소) portfolio-hub#8 ledger write 응답 = root flat cash_balance_after/asset_quantity_after(절대 권위값), status별 new(201)/duplicate(200)=값 있음·409/422=미정의. dcy-005 A-7 에서 확정됐고 portfolio-hub#8 배포·동작 중(사용자 확인 2026-06-08) — "배포 대기" 조건부 해제됨.

11. Discovery Freeze

REQ 초안 작성 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.

섹션 참조

• 범위: # 5. 요구사항 목록 > 범위 경계
• 리스크/오픈 질문: # 6. 리스크/가정 목록
• 성공 기준: # 7. 초기 성공 기준
• 인계 전 확인: # 8. REQ로 넘기기 전 확인 체크
• 사용자 결정 필요: # 10. 사용자 결정 필요 항목 요약

Freeze 플래그

• Handoff Decision: 승인
• Handoff Rationale: confirm-discovery 완료. 저장소 사실관계 일치 확인(record_trade 는 duplicate만 파싱·*_after 미파싱 / update_cash_position 정의만 있고 호출자 없음 / LedgerWriter 에 SnapshotStore 없음 / REQ-030 Approved). 오픈 질문 OQ-1~OQ-4 모두 Answered (수량 source=B 슬롯 오버레이 유지+write-back 수렴 / write-back=b new+duplicate 둘 다·409/422 skip / 거버넌스=a 전부 change-req REQ-017·019·029·030 / 임시 현금=(i) 추정 오버레이 라벨). DATA(portfolio-hub#8 응답 스키마)는 dcy-005 A-7 cash_balance_after/asset_quantity_after 확정 + portfolio-hub#8 배포·동작 중(사용자 확인)으로 해소. C 유형 플레이스홀더 0개. REQ 초안 작성 인계 가능.
• Ready for REQ Drafting: true
• Confirmed By: Justin Ko
• Confirmed At (KST): 2026-06-08 21:45 KST