feat: implement asset snapshot and manual asset read model

docs/discovery/dcy-008_20260630_asset-snapshot-manual-valuation-system.md

@@ -0,0 +1,225 @@
+# 0. 문서 상태
+이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
+
+- 상태: confirmed
+- 문서 ID: dcy-008_20260630_asset-snapshot-manual-valuation-system
+- 이슈명: 자산 스냅샷/수기 자산 테이블/평가 체계 정립
+- 작성 시각(KST): 2026-06-30 20:38 KST
+- 마지막 갱신 시각(KST): 2026-06-30 21:17 KST
+- 대체됨: 없음
+- 후속 Discovery 참조: 없음
+- 생성된 REQ 참조: `REQ-009`, `REQ-010`
+
+# 1. 계획 상태 요약
+현재 Discovery가 어떤 배경에서 작성되고 있는지, 연계 문서가 있는지, 지금 시점의 해석이 무엇인지 짧게 요약한다.
+
+- 연계 문서 현황:
+	- 선행 Discovery: dcy-005(`docs/discovery/dcy-005_20260629_dashboard-operations-hub-liquidity-monthly-cashflow.md`) — 자산 유동성/순자산 표시를 확정했지만 별도 자산 스냅샷·수기 자산 테이블·평가 자동화는 Out of Scope로 남김
+	- 관련 TODO/메모: `docs/data-model.md` Current Gaps와 `docs/runtime-flows.md` Current Gaps가 "별도 자산 스냅샷/수기 자산 테이블·자동 시세/부동산 평가"를 후속 REQ로 명시 보류
+- 해석:
+	- 현재 자산/순자산은 `accounts.liquidity_bucket`과 가변 단일값 `accounts.last_balance`로만 산출돼, 시점별 평가 이력이 남지 않고 거래로 산출되지 않는 비거래 자산(부동산·예적금·대출·기타)의 평가 기준·갱신 책임이 계좌 한 줄에 묶여 있어 평가 체계가 부재하다.
+	- 이번 Discovery는 dcy-005가 명시적으로 후속으로 미룬 "자산 스냅샷 이력 + 수기 자산 테이블 + 평가 체계"를 독립 주기로 정의하고, `asset_snapshots`/`manual_assets` 별도 테이블 도입, 계좌 `last_balance` + 수기 자산 보강 기반 권위 소스, 월말 수동 스냅샷 정책, 조회성 MCP 포함 범위를 확정한다.
+
+# 2. 요구사항 판정 결과
+이번 요청이 기존 요구사항과 비교해 신규인지, 유사한지, 중복인지 판단하고 그 근거를 남긴다.
+
+- 판정: 신규
+- 근거
+	- 가장 근접한 dcy-005는 대시보드 운영 허브와 `accounts.liquidity_bucket`/`last_balance` 기반 유동성·순자산 "표시"를 confirmed 범위로 다루며, 별도 자산 스냅샷 테이블·수기 자산 테이블·평가 자동화를 Out of Scope로 명시 제외했다. 이번 요청은 그 제외된 평가 이력·자산 테이블·평가 체계를 신규로 정의하므로 dcy-005의 미세 조정이 아니다.
+	- dcy-005는 confirmed 상태로 BAT-005(release-candidate)까지 진행돼 변경 전제가 고정돼 있어, 평가 이력·신규 엔티티 도입을 같은 문서에 누적하면 책임 경계가 흐려진다. 후속 반복을 독립 주기로 추적하는 편이 명확하다.
+
+# 3. 문제점의 요약
+문제의 현재 상태, 기대 상태, 관련 이해관계자, 제약사항을 정리한다. Discovery의 핵심 맥락을 가장 먼저 이해할 수 있어야 한다.
+
+- 현재 상태
+	- `dashboard/app.py`의 `get_asset_liquidity_report`는 활성 계좌를 `accounts.liquidity_bucket`으로 묶고 자산/부채 값으로 `accounts.last_balance`만 사용한다(`docs/runtime-flows.md` 51~53행). 즉 자산 평가값이 계좌별 단일 가변 컬럼에만 존재한다.
+	- `docs/data-model.md`의 LedgerAccount는 `last_balance`(최신 잔액), `last_synced_at`(기준 스냅샷 시각), `liquidity_bucket`만 갖고 있고, 시점별 자산 평가 이력을 보존하는 별도 엔티티가 없다. 비거래 자산/부채는 "별도 평가 테이블 없이 `last_balance`/`last_synced_at`/`memo`로 처리"하도록 규정돼 있다(data-model 43행).
+	- `docs/data-model.md` Current Gaps(164행)와 `docs/runtime-flows.md`(131행)는 "별도 자산 스냅샷/수기 자산 테이블과 자동 시세·부동산 평가는 REQ-005 이후로 보류, 신규 REQ 필요"라고 명시한다. 즉 이번 주제는 기존 baseline이 의도적으로 비워 둔 갭이다.
+	- `liquidity_bucket`/`last_balance` 관련 구현은 `jarca_ledger_mcp/service.py`, `jarca_ledger_mcp/db.py`, `jarca_ledger_mcp/server.py`, `dashboard/app.py`에 존재하나, 스냅샷 이력 테이블·수기 자산 엔티티·평가 규칙 모듈은 존재하지 않는다.
+	- `docs/project-structure.md`, `docs/runtime-flows.md` baseline 문서는 존재하나 자산 스냅샷 이력·수기 자산 테이블·평가 체계 데이터 흐름을 아직 반영하지 않는다.
+- 기대 상태
+	- 자산 평가값이 시점별 스냅샷으로 보존돼 "특정 기준일 순자산"과 순자산 시계열(추이)을 재현·조회할 수 있다.
+	- 거래로 산출되지 않는 비거래 자산(부동산·예적금·대출·기타)을 수기 자산 항목으로 명시 등록·갱신하고, 평가 출처·기준일·평가 방법이 일관된 평가 체계로 기록된다.
+	- 자산 평가 규칙(자산성 항목 합계 − 부채(`loan`) 차감, 미입력 자산 제외 표기 등)이 단일 정의로 문서·집계·화면에서 동일하게 적용된다.
+- 이해관계자
+	- 가계 재무를 운영하며 자산/순자산 추이를 관리하는 사용자(대시보드 1차 사용자)
+	- 문서/요구사항 리뷰어 및 승인자(Hermes/사용자)
+	- 데이터 모델·서비스·DB·대시보드를 구현/운영하는 개발 담당자
+- 제약사항
+	- DB 스키마 변경은 additive/idempotent 원칙을 따르며 파괴적 마이그레이션은 명시 승인·백업 후에만 한다(`docs/data-model.md` Persistence Notes).
+	- 기존 dcy-005/REQ-005 confirmed 범위(`accounts.liquidity_bucket`/`last_balance` 기반 표시)와 충돌하지 않고, 평가 권위 소스 이중화로 비율·순자산이 어긋나지 않아야 한다.
+	- 본 Discovery 단계에서는 소스 코드/테스트/스키마를 변경하지 않고 사양만 정의한다.
+
+## 주요 사용자 시나리오
+사용자 또는 운영자가 실제로 어떤 상황에서 이 변경을 필요로 하는지 대표 시나리오를 적는다.
+
+- 사용자가 월말에 부동산·예적금·투자·대출 잔액을 수기 자산 항목으로 입력/갱신하면, 해당 시점의 자산 평가 스냅샷이 기준일과 함께 보존된다.
+- 사용자가 대시보드에서 "이번 달 말 순자산"과 "최근 N개월 순자산 추이"를 조회해 자산이 늘었는지 줄었는지 시점 비교로 확인한다.
+- 사용자가 특정 자산(예: 전세보증금, 차량)의 평가값을 갱신할 때, 과거 평가값을 덮어쓰지 않고 새 스냅샷으로 누적해 평가 이력을 추적한다.
+
+# 4. 이번에 정의할 변경
+이번 Discovery에서 다루는 핵심 변경 항목을 목록으로 적는다. 기능, 구조, 규칙 변경을 함께 포함해도 된다.
+
+- 자산 평가 스냅샷 이력 모델 정의: 시점별 자산 평가값을 보존하는 스냅샷 엔티티(`asset_snapshots` 권장)와 기준일·평가 출처·스냅샷 단위(계좌/자산 항목)·생성 정책(월말 자동 vs 수동)을 사양으로 정의한다.
+- 수기 자산 테이블 정의: 거래로 산출되지 않는 비거래 자산/부채(부동산·예적금·대출·기타)를 계좌와 분리해 명시 등록하는 수기 자산 엔티티(`manual_assets` 권장)와 평가값·기준일·`liquidity_bucket`·출처 메모 필드를 정의한다.
+- 평가 체계 규칙 정의: 자산성 항목 합계에서 부채(`loan`)를 차감하는 순자산 산식, 평가 권위 소스(계좌 `last_balance` vs 수기 자산 vs 스냅샷)의 단일화/우선순위, 미입력·미평가 자산의 제외·표기 규칙을 단일 정의로 확정한다.
+- 조회성 MCP 범위 정의: 자산 스냅샷/순자산 시계열/수기 자산을 대시보드 내부 모델에만 가두지 않고, 동일한 평가 권위 소스와 순자산 산식을 사용하는 조회성 MCP 응답 계약까지 범위에 포함한다. 초기 범위는 조회(read) 중심으로 한정하고 스냅샷 생성·수기 자산 CRUD 같은 mutation MCP는 후속 범위로 둔다.
+- baseline 문서 반영: 위 자산 스냅샷·수기 자산·평가 체계 데이터 모델과 평가/스냅샷 데이터 흐름을 `docs/data-model.md`, `docs/project-structure.md`, `docs/runtime-flows.md` 갱신 요구로 등록한다.
+
+## 영향 범위
+변경이 미칠 코드/문서/운영 범위를 명시해 REQ 정제와 batch planning에서 추정 누락을 줄인다.
+
+- 코드 영향:
+	- `jarca_ledger_mcp/db.py` 스키마(스냅샷·수기 자산 테이블 additive 추가), `jarca_ledger_mcp/service.py` 자산 평가/스냅샷 집계·순자산 시계열 함수, `jarca_ledger_mcp/server.py`의 조회성 MCP 응답 계약(기준일 스냅샷 조회, 순자산 시계열 조회, 수기 자산 조회).
+	- `dashboard/app.py`의 `get_asset_liquidity_report`/순자산 표시부가 단일 권위 소스(스냅샷/수기 자산)를 참조하도록 조정.
+- 문서 영향:
+	- `docs/data-model.md`(`asset_snapshots`/`manual_assets` 엔티티, 순자산 산식·평가 권위 소스 규칙), `docs/project-structure.md`, `docs/runtime-flows.md`(스냅샷 생성·순자산 시계열 데이터 흐름) 갱신.
+	- dcy-005/REQ-005와의 평가 권위 소스 정합성 명시.
+- 운영 영향:
+	- 비거래 자산 평가 입력/갱신과 월말 스냅샷 생성 절차가 신설돼 운영 입력 루틴·잔액대조 흐름에 영향을 준다.
+
+# 5. 요구사항 목록
+실제로 구현과 검증으로 이어질 요구사항을 기능/비기능으로 나누어 정리하고, 범위 경계를 명확히 적는다.
+
+## 기능 요구사항
+- FR-1: 시점별 자산 평가값을 보존하는 자산 스냅샷 이력을 도입한다. 각 스냅샷은 최소한 기준일, 평가 대상(계좌 또는 수기 자산 항목), 평가 금액, `liquidity_bucket`, 평가 출처/메모를 보존하며, 과거 값은 덮어쓰지 않고 누적한다.
+- FR-2: 거래로 산출되지 않는 비거래 자산/부채를 계좌와 분리해 등록하는 수기 자산 테이블을 도입한다. 각 항목은 자산명, 평가 금액, 기준일, `liquidity_bucket`(`cash`/`investment`/`deposit`/`real_estate`/`loan`/`other`), 출처 메모를 갖는다.
+- FR-3: 순자산 평가 규칙을 단일 정의로 확정한다. 자산성 항목(`cash`/`investment`/`deposit`/`real_estate`/`other`) 평가값 합계에서 `loan` 부채를 차감하고, 평가값이 없는 항목은 임의 거래 합계로 추정하지 않고 제외하며 화면에 제외 사실을 표기한다.
+- FR-4: 대시보드/리포트와 조회성 MCP가 자산·순자산을 산출할 때 평가 권위 소스를 단일화한다. 계좌 `last_balance`, 수기 자산, 스냅샷이 동시에 존재할 때의 우선순위와 폴백을 명시하고, dcy-005/REQ-005의 `accounts.liquidity_bucket` 기반 표시와 충돌하지 않게 정합성 규칙을 정의한다.
+- FR-5: 조회성 MCP 범위에 기준일 자산 스냅샷 조회, 순자산 시계열 조회, 수기 자산 조회를 포함한다. 각 응답은 최소한 기준일/집계 구간, 평가 권위 소스, `liquidity_bucket`, 순자산 산식 적용 기준, 포함·제외 항목을 설명할 수 있어야 한다.
+- FR-6: `docs/data-model.md`, `docs/project-structure.md`, `docs/runtime-flows.md` baseline 문서에 `asset_snapshots`/`manual_assets` 모델과 스냅샷 생성·순자산 시계열·조회성 MCP 데이터 흐름 갱신을 포함한다.
+
+## 비기능 요구사항
+성능, 운영성, 일관성, 자동화 안정성 등 기능 외 요구사항을 적는다.
+
+- NFR-1 (일관성): 순자산·자산 구성 계산은 단일 평가 권위 소스와 단일 산식(자산 합계 − `loan` 차감)을 모든 섹션·집계·MCP 응답에서 동일하게 적용한다.
+- NFR-2 (이력 보존성): 자산 평가값 갱신은 기존 스냅샷을 파괴적으로 덮어쓰지 않고 신규 스냅샷으로 누적해 기준일별 재현 가능성을 보장한다.
+- NFR-3 (안정성): `asset_snapshots`/`manual_assets` 스키마 변경은 additive/idempotent로 적용하고, 신규 테이블이 비어 있어도 기존 대시보드·`get_asset_liquidity_report` 동작을 깨지 않는다.
+
+## 범위 경계
+이번 반복에서 반드시 포함할 범위와 명시적으로 제외할 범위를 구분한다.
+
+- In Scope
+	- 자산 스냅샷 이력 엔티티, 수기 자산 테이블 엔티티, 순자산 평가 규칙·평가 권위 소스 단일화 사양 정의 및 baseline 문서 갱신 요구.
+	- 기준일 자산 스냅샷 조회, 순자산 시계열 조회, 수기 자산 조회를 포함한 조회성 MCP 범위 정의.
+	- dcy-005/REQ-005 표시 범위와의 평가 정합성 규칙 정의.
+- Out of Scope
+	- 외부 시세/부동산 평가 자동 연동, 실시간 잔액 연동.
+	- 자산 평가 알림/리밸런싱 추천, 세금·수익률 자동 계산.
+	- 스냅샷 생성, 수기 자산 생성/수정/삭제 같은 mutation MCP 범위.
+	- 본 단계에서의 실제 스키마/코드/테스트 변경(사양 정의만 수행).
+
+# 6. 리스크/가정 목록
+불확실성과 전제 조건을 분리해서 적는다. 리스크는 영향과 완화 방안을, 가정은 현재 판단의 전제를 기록한다.
+
+## 리스크
+- R-1 (High): 자산 평가 권위 소스가 계좌 `last_balance`, 수기 자산, 스냅샷으로 삼중화되면 동일 자산이 중복 집계되거나 순자산이 어긋날 수 있다.
+	- 완화 방안: FR-4에서 단일 권위 소스와 우선순위/폴백을 먼저 확정하고, dcy-005/REQ-005 표시 경로와 조회성 MCP 응답이 모두 같은 규칙을 따르도록 REQ 초안에 명시한다.
+- R-2 (Medium): 신규 테이블(`asset_snapshots`/`manual_assets`) 도입이 기존 `get_asset_liquidity_report`/대시보드 집계와 동작 충돌을 일으킬 수 있다.
+	- 완화 방안: additive/idempotent 스키마와 빈 테이블 안전 폴백을 NFR-3로 고정하고, 단계적 전환(표시는 기존 유지 → 권위 소스 전환) 경로를 설계 단계에서 분리한다.
+- R-3 (Medium): 수기 자산 평가는 사용자 입력 의존도가 높아 입력 누락/기준일 불일치 시 순자산 추이가 왜곡된다.
+	- 완화 방안: 기준일·출처 메모를 필수 필드로 두고, 미평가/오래된 평가 항목을 화면 경고로 노출하는 규칙을 요구사항에 포함한다.
+
+## 가정
+아직 확정되지 않았지만 현재 문서 작성의 기반이 되는 전제를 적는다.
+
+- A-1: `liquidity_bucket` 분류 축과 그 허용값(`cash`/`investment`/`deposit`/`real_estate`/`loan`/`other`)은 dcy-005/REQ-005 정의를 그대로 재사용한다.
+- A-2: 순자산 산식의 기본 골격(자산성 합계 − `loan` 차감, 미평가 제외)은 dcy-005에서 확정된 정의를 계승해 스냅샷/수기 자산으로 확장한다.
+- A-3: 비거래 자산 평가값은 초기에는 사용자 수기 입력을 권위 소스로 하며 외부 자동 연동은 후속 범위로 둔다.
+
+## 오픈 질문
+답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 REQ 초안 작성 이전에 확인할 질문으로 남긴다.
+
+- OQ-1: 자산 평가 권위 소스를 어떻게 단일화할지(① 계좌 `last_balance` 유지 + 수기 자산 보강, ② 모든 자산을 수기 자산/스냅샷으로 일원화) 결정한다.
+	- 상태: Answered
+	- 답: 계좌 `last_balance`를 기존 권위 소스로 유지하되, 거래로 산출되지 않는 비거래 자산/부채는 `manual_assets`로 보강한다. 스냅샷은 이 둘을 기준일별로 고정하는 기록층으로 사용한다.
+	- 반영 위치: FR-4, In Scope, `docs/data-model.md`/조회성 MCP 응답 규칙
+- OQ-2: 자산 스냅샷 생성 정책(월말 자동 생성 vs 사용자 수동 생성 vs 둘 다)과 스냅샷 단위(계좌 단위 vs 자산 항목 단위)를 결정한다.
+	- 상태: Answered
+	- 답: 초기 운영 정책은 월말 수동 생성으로 확정한다. 스냅샷 구조는 계좌와 수기 자산 항목을 모두 담을 수 있는 항목 단위 집계를 수용하되, 운영 입력은 월말 마감 기준으로 단순화한다.
+	- 반영 위치: FR-1, 운영 영향, runtime-flows 후속 갱신
+
+- OQ-3: 조회성 MCP 범위를 어디까지 포함할지(① 기준일 자산 스냅샷 조회 + 순자산 시계열 조회 + 수기 자산 조회 포함, ② 일부만 포함) 결정한다.
+	- 상태: Answered
+	- 답: 기준일 자산 스냅샷 조회, 순자산 시계열 조회, 수기 자산 조회를 `dcy-008`의 조회성 MCP 범위에 포함한다. 스냅샷 생성과 수기 자산 CRUD 같은 mutation MCP는 후속 범위로 분리한다.
+	- 반영 위치: FR-5, In Scope/Out of Scope, `docs/interface-contract.md`/`docs/runtime-flows.md` 후속 갱신
+
+### 오픈 질문 처리 기준
+- `Open`: 아직 답이 없고 다음 단계 진행에 영향이 있는 상태다. 문서에 유지한다.
+- `Answered`: 답이 확정된 상태다. 관련 본문/요구사항에 반영한 뒤 오픈 질문 목록에서는 제거하거나 resolved 기록으로 이동한다.
+- `Deferred`: 지금 단계에서 결정하지 않고 다음 단계 또는 후속 이슈로 넘기는 상태다. 넘길 대상과 이유를 반드시 적는다.
+- `Dropped`: 더 이상 유효하지 않은 질문이다. 삭제 사유를 짧게 남기고 목록에서 제거한다.
+- 처리 원칙 1: 질문만 남기지 말고 반드시 `상태`, `처리 방안`, `종료 조건`을 함께 적는다.
+- 처리 원칙 2: 답이 나온 질문은 본문 반영 없이 단순 삭제하지 않는다. 반영 위치를 먼저 갱신한다.
+- 처리 원칙 3: High 영향 질문은 `Deferred` 처리 후 처리 방안에 REQ 인계 추적 방식을 명시한다.
+
+# 7. 초기 성공 기준
+이 변경이 성공했다고 판단할 기준을 측정 가능하게 정의한다. 가능하면 데이터 출처까지 연결한다.
+
+- S-1: 기준일별 자산 평가 스냅샷이 보존돼 "특정 기준일 순자산"과 순자산 시계열을 재현할 수 있는 데이터 모델이 사양으로 정의된다.
+- S-2: 비거래 자산/부채를 수기 자산 테이블로 등록·갱신하고, 자산성 합계 − `loan` 차감 순자산 산식이 단일 평가 권위 소스 기준으로 일관되게 정의된다.
+- S-3: `asset_snapshots`/`manual_assets` 데이터 모델과 스냅샷 생성·순자산 시계열·조회성 MCP 데이터 흐름이 `docs/data-model.md`, `docs/project-structure.md`, `docs/runtime-flows.md`에 반영되고, dcy-005/REQ-005 표시 경로와의 정합성이 문서로 확인된다.
+
+## 측정 방식 및 데이터 출처
+각 성공 기준을 어떻게 측정할지와 어떤 데이터나 문서를 근거로 쓸지 적는다.
+
+- S-1 측정 방식: 표본 자산/기준일로 스냅샷 누적·기준일 순자산 재현을 손검증과 비교 / 데이터 출처: `asset_snapshots` 모델 사양, `accounts.last_balance`/`last_synced_at`
+- S-2 측정 방식: 표본 수기 자산·부채로 순자산 산식 결과를 손검증과 비교 / 데이터 출처: `manual_assets` 모델 사양, `liquidity_bucket` 분류 규칙, dcy-005 순자산 정의
+- S-3 측정 방식: baseline 문서 diff에서 `asset_snapshots`/`manual_assets`·스냅샷/시계열/조회성 MCP 흐름·dcy-005 정합성 반영 여부 확인 / 데이터 출처: `docs/data-model.md`, `docs/project-structure.md`, `docs/runtime-flows.md`
+
+# 8. REQ로 넘기기 전 확인 체크
+REQ 초안 작성 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다.
+
+- [x] 범위(In Scope/Out of Scope) 확정
+	- 기준: `asset_snapshots`/`manual_assets` 별도 테이블, 조회성 MCP 포함 범위, 외부 시세 연동 제외를 이번 confirm에서 확정했다.
+- [x] 성공 지표의 측정 방식/데이터 출처 확정
+	- 기준: S-1~S-3 검수 방식과 데이터 출처가 REQ 초안으로 내릴 수 있을 정도로 정의됐다.
+- [x] High 영향 리스크 우선순위 및 해소 책임자 지정
+	- 기준: R-1의 정책 답은 이번 confirm에서 확정했고, 구현/검수 책임자 지정은 REQ·batch planning 단계에서 배정한다.
+- [x] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
+	- 기준: OQ-1~OQ-3을 모두 Answered 처리했다.
+- [x] Freeze 확정 담당자(CONFIRMED_BY) 지정
+	- 기준: 사용자가 권위 소스 단일화·스냅샷 정책·조회성 MCP 포함 권장안을 승인하고 `dcy-008 confirm`을 지시했다.
+
+# 9. 파일 처리 결과
+이 Discovery 문서 생성/갱신 결과와 참조 문서를 기록한다. 이후 추적과 리뷰 시 근거로 사용한다.
+
+- 처리 결과: 생성
+- 생성 경로: docs/discovery/dcy-008_20260630_asset-snapshot-manual-valuation-system.md
+- 참조 문서:
+	- docs/discovery/dcy-005_20260629_dashboard-operations-hub-liquidity-monthly-cashflow.md (자산 유동성·순자산 표시 범위 및 본 Discovery의 후속 보류 출처)
+	- docs/data-model.md (LedgerAccount `last_balance`/`liquidity_bucket`, Current Gaps의 자산 스냅샷 보류 근거; `asset_snapshots`/`manual_assets` 도입 대상)
+	- docs/runtime-flows.md, docs/project-structure.md, docs/interface-contract.md (스냅샷 생성·순자산 시계열·조회성 MCP 흐름/응답 계약 갱신 대상; stage-pilot/templates/runtime-flows.md, stage-pilot/templates/project-structure.md를 논리 템플릿 참조로 사용)
+	- dashboard/app.py `get_asset_liquidity_report`, jarca_ledger_mcp/service.py, jarca_ledger_mcp/db.py (현재 자산/순자산 집계 구현 근거)
+
+# 10. 사용자 결정 필요 항목 요약
+사용자나 승인자가 결정해야 하는 항목만 모아 정리한다. 결정, 확인, 데이터 요청을 구분해서 적는다.
+
+## DECIDE
+- DECIDE_AUTHORITY_SOURCE: ① 계좌 `last_balance` 유지 + 수기 자산 보강으로 확정.
+- DECIDE_NEW_TABLES: `asset_snapshots`, `manual_assets` 별도 테이블 도입으로 확정.
+
+## CONFIRM
+- CONFIRM_SNAPSHOT_POLICY: 월말 수동 생성으로 확정. 스냅샷 구조는 계좌와 수기 자산 항목을 모두 담을 수 있는 항목 단위를 수용한다.
+- CONFIRM_NETWORTH_FORMULA: dcy-005 정의(자산성 합계 − `loan` 차감, 미평가 제외)를 그대로 계승해 스냅샷/수기 자산으로 확장하는 방향으로 확정.
+- CONFIRM_MCP_SNAPSHOT_READ_SCOPE: 자산 스냅샷 조회, 순자산 시계열 조회, 수기 자산 조회를 조회성 MCP 범위에 포함하고, 스냅샷 생성/수기 자산 CRUD 같은 mutation MCP는 후속 범위로 확정.
+
+## DATA
+- DATA_MANUAL_ASSET_INVENTORY: 실제 초기 수기 등록 목록(부동산·예적금·대출·기타)과 평가값·기준일·출처는 REQ/delivery 단계 입력 데이터로 수집한다. Discovery confirm의 차단 항목으로 남기지 않는다.
+
+# 11. Discovery Freeze
+REQ 초안 작성 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
+
+## 섹션 참조
+- 범위: [# 5. 요구사항 목록 > 범위 경계](#5-요구사항-목록)
+- 리스크/오픈 질문: [# 6. 리스크/가정 목록](#6-리스크가정-목록)
+- 성공 기준: [# 7. 초기 성공 기준](#7-초기-성공-기준)
+- 인계 전 확인: [# 8. REQ로 넘기기 전 확인 체크](#8-req로-넘기기-전-확인-체크)
+- 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약)
+
+## Freeze 플래그
+- Handoff Decision: 승인
+- Handoff Rationale: 권장안 기준으로 권위 소스, 신규 테이블, 월말 수동 스냅샷 정책, 조회성 MCP 포함 범위를 확정했다. 남은 수기 자산 실제 목록은 REQ/delivery 단계 입력 데이터이며 REQ 초안 작성을 막지 않는다.
+- Ready for REQ Drafting: true
+- Confirmed By: 진환 고
+- Confirmed At (KST): 2026-06-30 21:15 KST

docs/discovery/index.md

@@ -13,3 +13,4 @@
 | dcy-005_20260629_dashboard-operations-hub-liquidity-monthly-cashflow | 20260629 | Jarca Ledger 대시보드 운영 허브 사양 정립 (이번 달 현금흐름 + 자산 유동성 + 운영 미처리) | [Discovery](./dcy-005_20260629_dashboard-operations-hub-liquidity-monthly-cashflow.md) | confirmed |
 | dcy-006_20260630_pytest-apptest-smoke-ci-automation | 20260630 | pytest/AppTest/Smoke CI 자동화 | [Discovery](./dcy-006_20260630_pytest-apptest-smoke-ci-automation.md) | confirmed |
 | dcy-007_20260630_mcp-response-contract-ci-contract-versioning | 20260630 | MCP response contract / CI contract versioning 정립 | [Discovery](./dcy-007_20260630_mcp-response-contract-ci-contract-versioning.md) | confirmed |
+| dcy-008_20260630_asset-snapshot-manual-valuation-system | 20260630 | 자산 스냅샷/수기 자산 테이블/평가 체계 정립 | [Discovery](./dcy-008_20260630_asset-snapshot-manual-valuation-system.md) | confirmed |