gitea-impl-agent/jarca-ledger-mcp
1
0
Fork 0
forked from jsfamily/jarca-ledger-mcp
Code Pull Requests Activity
Files
df27284d1488bb663a2a93b07bfd774474915f05
jarca-ledger-mcp/docs/discovery/dcy-012_20260703_review-queue-reconciliation-workbench-persistence.md
T

26 KiB
Raw Blame History

0. 문서 상태

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

  • 상태: draft
  • 문서 ID: dcy-012_20260703_review-queue-reconciliation-workbench-persistence
  • 이슈명: 확인필요 큐 / 잔액대조 워크벤치 영속화 및 운영 모델 정립
  • 작성 시각(KST): 2026-07-03 10:31 KST
  • 마지막 갱신 시각(KST): 2026-07-03 10:31 KST
  • 대체됨: 없음
  • 후속 Discovery 참조: 없음
  • 생성된 REQ 참조: 없음

1. 계획 상태 요약

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

  • 연계 문서 현황:
    • 선행 Discovery: docs/discovery/dcy-003_20260629_statement-unavailable-manual-evidence-balance-reconciliation.md (statement-unavailable 계좌 수동 증빙/잔액대조 기준 확정), docs/discovery/dcy-005_20260629_dashboard-operations-hub-liquidity-monthly-cashflow.md (운영 경고 허브에 확인필요/잔액대조 필요 상태를 집계 노출)
    • 관련 후속 구현: docs/discovery/dcy-011_20260703_backend-refactor-phase4-write-import-workflow-adapter-narrowing.md 및 REQ-017/BAT-013 (cross-transfer, reconciliation, uncategorized workbench service 분리), REQ-018/BAT-014 (Streamlit/MCP adapter surface 축소)
    • 관련 baseline 문서: docs/data-model.md, docs/project-structure.md, docs/runtime-flows.md
    • 관련 project board: GitHub Project 4(Jarca)에서 statement-unavailable workflow와 Phase 4~7 refactor는 Done 상태이며, 본 Discovery에 직접 대응하는 review decision/workbench 영속화 TODO는 아직 없다.
  • 해석:
    • 현재 저장소에는 list_cross_transfer_review_queue, run_cross_account_transfer_match, get_balance_reconciliation_report, get_uncategorized_workbench가 존재해 확인필요 큐·대조 preview·미분류 추천까지는 가능하지만, 운영자가 내린 판정과 예외 사유를 영속적으로 저장하고 다음 회차에 재사용하는 review-decision 모델은 없다.
    • 따라서 이번 Discovery는 dcy-003이 정의한 수동 증빙/잔액대조 규칙을 "preview/report" 단계에서 멈추지 않고, 확인필요 큐·잔액대조·미분류 검토를 하나의 운영 워크벤치로 묶는 후속 주기로 정식화한다. Phase 8 optional HTTP adapter는 별도 Deferred 후보로 유지하고 본 주기 범위에 포함하지 않는다.

2. 요구사항 판정 결과

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

  • 판정: 신규
  • 근거
    • dcy-003은 statement-unavailable 계좌의 수동 증빙 입력, 기준 잔액 대비 reconciliation preview, 확인필요 판정 기준을 정의했지만, 전용 잔액대조 워크벤치 전체 신설은 명시적으로 Out of Scope였다. 이번 요청은 그때 제외한 "결정 영속화 + 운영 워크벤치"를 독립 성공 기준으로 다룬다.
    • dcy-005는 운영 허브에서 미분류/확인필요/잔액대조 필요 상태를 집계해 보여주는 정보구조를 다뤘고, dcy-011/REQ-017은 내부 서비스 분리를 완료했다. 그러나 review decision persistence, reconciliation session 기록, 대량 검토 UX, 재검토/예외 관리 모델은 별도 문제 정의와 범위 경계를 필요로 하므로 새 Discovery로 분리하는 것이 명확하다.

판정이 완전 중복인 경우: 이하 섹션 작성을 중단하고 # 9. 파일 처리 결과에 중복 판정 사유와 참조 문서 경로를 기록한 뒤 문서를 닫는다. REQ 초안 작성으로 넘기지 않는다.

3. 문제점의 요약

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

  • 현재 상태
    • jarca_ledger_mcp.application.cross_transfer_service.list_cross_transfer_review_queue()는 transactions.memo LIKE '%cross_transfer_review:%' 태그가 붙은 active 거래를 최신순으로 조회하는 큐를 제공한다. 하지만 review item의 판정 상태, 결정자, 결정 시각, 재검토 메모, 예외 사유를 별도 엔터티로 저장하지 않고 거래 메모 태그와 현재 카테고리/타입 상태에 암묵적으로 의존한다.
    • jarca_ledger_mcp.application.reconciliation_service.get_balance_reconciliation_report()는 statement_status in (manual_only, partial_import) 계좌에 대한 baseline 대비 차이를 preview/report 형태로 계산하고 REVIEW_NEEDED 여부와 권장 결정값을 반환한다. 그러나 이 결과는 실행 시점 계산값이며, 어떤 차이를 어떤 사유로 인정/보류/재검토했는지 persist하지 않는다.
    • jarca_ledger_mcp.application.uncategorized_workbench_service.get_uncategorized_workbench()는 미분류 거래와 추천 분류를 제공하지만, 운영자가 추천을 채택/거부/보류한 결정 이력과 이유는 구조화되어 있지 않다.
    • docs/data-model.md는 현재 gap으로 “dedicated reconciliation workbench and persistent review-decision queue”를 명시하고 있다. docs/runtime-flows.md와 docs/project-structure.md도 확인필요 큐/미분류/잔액대조가 개별 화면과 게이트웨이로는 존재하나, 공통 review-decision persistence 계층은 아직 없음을 암시한다.
    • GitHub Project 4 기준으로 statement-unavailable workflow와 Phase 4~7 refactor는 완료되었지만, review queue persistence/workbench 운영 모델을 대표하는 활성 보드 항목은 아직 없다. 즉 현재는 기능 조각은 있으나 운영 워크플로우 단위의 후속 주기가 비어 있다.
  • 기대 상태
    • 운영자는 확인필요 큐, 잔액대조 차이, 미분류 추천 항목을 단순 조회가 아니라 하나의 workbench에서 검토하고, 각 항목을 확인필요, 계좌이동, 실지출, 실수입, 투자이동, 분석제외, 보류/재검토 등 구조화된 결정으로 저장할 수 있어야 한다.
    • review decision은 거래 row의 현재 상태와 별개로 영속 기록되어 결정 시각, 근거 메모, 관련 짝거래/계좌, 재검토 필요 여부를 남기고, 이후 재대조/재import/월마감 시 재사용 가능해야 한다.
    • 잔액대조는 preview report를 넘어 “이번 기준 시점의 차이를 어떤 판단으로 정리했는가”를 session 또는 decision log로 남겨 미해결 항목과 완료 항목을 구분해야 한다.
    • Streamlit과 MCP는 공통 application/domain 모델 위에서 같은 review-decision 규칙을 사용해야 하고, 운영 허브는 미처리 review queue/보류 항목/미대조 계좌 상태를 신뢰성 있게 집계할 수 있어야 한다.
  • 이해관계자
    • 가계부 운영자(진환 고) — 확인필요/대조/미분류 항목을 직접 판정하고 월말 운영 상태를 정리하는 1차 사용자
    • 구현 담당자/검수 담당자 — review decision 모델, workbench UI, MCP tool contract를 설계·구현·검증하는 주체
    • 향후 자동화/리포트 소비자 — 월말 close, 운영 경고, 향후 HTTP adapter 또는 외부 자동화에서 review 상태를 읽게 될 잠재적 소비자
  • 제약사항
    • 기존 MCP tool 이름, 주요 응답 필드, 카테고리·현금흐름 의미, import 증빙 필드 보존 원칙은 유지되어야 하며, review decision 도입이 기존 실지출/실수입 해석을 깨뜨리면 안 된다.
    • 금융 데이터 특성상 원본 계좌정보·비밀번호·raw payload는 저장/커밋하지 않아야 하고, review 근거 메모도 최소 보관/마스킹 원칙을 따라야 한다.
    • destructive migration 없이 additive schema만 허용되며, 운영 DB가 아닌 fixture/validation DB에서 흐름을 검증해야 한다.
    • 이번 주기는 review-decision/workbench 모델 정립에 집중하며, Phase 8 HTTP adapter, 멀티유저 권한, 원격 운영 재설계로 확장하지 않는다.

주요 사용자 시나리오

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

  • 운영자가 KB↔토스 거래를 자동 매칭한 뒤 확인필요 큐에 남은 항목을 열어 “내 계좌 간 이동”, “타인 송금”, “실제 소비”, “보류/재검토”로 판정하고 그 근거를 저장한다.
  • 운영자가 get_balance_reconciliation_report로 차이가 발생한 계좌를 검토하면서, 어떤 차이를 허용 예외로 남겼는지, 어떤 거래를 추가 보완해야 하는지, 언제 다시 확인할지를 workbench에 기록한다.
  • 운영자가 미분류 거래 추천을 검토할 때 추천을 수락/거부하고, 동일 merchant 패턴에 대해 이후 자동화가 재사용할 수 있도록 결정 이력을 남긴다.
  • 월말에 운영 허브에서 “미처리 review 항목”, “재검토 대기”, “미대조 계좌”를 한 번에 보고, 남은 정리 작업을 workbench로 이동해 마감한다.

4. 이번에 정의할 변경

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

  • review decision persistence 도입: 확인필요 큐, 잔액대조 차이, 미분류 추천에 공통으로 적용 가능한 review-decision 엔터티(상태, 결정 유형, 근거 메모, 관련 거래/계좌/session, 재검토 플래그)를 정의한다.
  • reconciliation/workbench 운영 모델 정립: preview-only 대조 리포트를 session/decision 기록으로 연결하고, Streamlit workbench와 MCP workflow가 동일한 review queue 상태를 읽고 갱신하는 흐름을 정의한다.
  • 운영 허브 연계 기준 확정: 운영 경고·월마감·미처리 review 집계가 어떤 상태 정의를 source of truth로 삼는지 정하고, docs/data-model.md, docs/project-structure.md, docs/runtime-flows.md 갱신 요구를 포함한다.

영향 범위

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

  • 코드 영향:
    • 신규 review decision / reconciliation session persistence 계층 후보 (jarca_ledger_mcp/application/*, infrastructure/sqlite, schema additive migration)
    • cross_transfer_service, reconciliation_service, uncategorized_workbench_service의 preview/report 결과를 persisted decision 상태와 연결하는 service 확장
    • adapters/streamlit/transfers_gateway.py, reconciliation_gateway.py, categorization_gateway.py, dashboard/app.py의 workbench UI 액션 추가
    • adapters/mcp/tool_contracts.py, adapters/mcp/server.py의 review queue decision mutation/조회 도구 추가 여부 검토
  • 문서 영향:
    • docs/data-model.md — review decision/session 엔터티와 상태 정의 반영 필요
    • docs/project-structure.md — workbench/review persistence 계층 추가 시 구조 반영 필요
    • docs/runtime-flows.md — review queue 처리, 대조 session 정리, 운영 허브 집계 흐름 반영 필요
    • 관련 runbook 또는 월마감 운영 절차 문서 신설 후보
  • 운영 영향:
    • 미처리/보류/재검토 항목을 운영적으로 추적하는 월말 루틴이 생기며, review decision이 실제 현금흐름/분류/대조 마감 상태의 source of truth 역할을 하게 된다.

5. 요구사항 목록

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

기능 요구사항

  • FR-1: 확인필요 큐, 잔액대조 차이, 미분류 추천 항목에 대해 공통 또는 호환 가능한 review decision 저장 모델을 제공해야 한다. 최소 필드는 대상 타입(queue/reconciliation/uncategorized), 대상 식별자, 결정 상태, 결정 유형, 근거 메모, 결정 시각, 재검토 필요 여부여야 한다.
  • FR-2: list_cross_transfer_review_queue와 get_balance_reconciliation_report, get_uncategorized_workbench는 persisted decision 상태를 반영해 미처리/처리완료/보류 항목을 구분할 수 있어야 한다. preview 결과만 반환하더라도 현재 결정 상태를 함께 참조할 수 있어야 한다.
  • FR-3: Streamlit workbench는 운영자가 review decision을 생성/수정/보류/재검토 표시할 수 있는 최소 작업 흐름을 제공해야 한다. 결정 결과는 해당 거래/계좌/추천 항목의 후속 집계(운영 허브, 월마감, 대조 상태)에 반영되어야 한다.
  • FR-4: MCP surface는 review queue decision 조회·기록·보류/해제 등 운영 자동화에 필요한 최소 도구를 제공하거나, 제공하지 않는다면 그 제외 경계를 명확히 정의해야 한다. 기존 tool 이름은 유지하고 필요한 경우 additive new tools로 확장한다.
  • FR-5: docs/data-model.md, docs/project-structure.md, docs/runtime-flows.md에 review decision persistence, reconciliation/workbench 흐름, 운영 허브 집계 기준을 반영해야 한다.

비기능 요구사항

  • NFR-1 (contract preservation): 기존 MCP/Streamlit 동작과 cashflow/category 의미는 review decision 도입 후에도 호환되어야 하며, 기존 응답 필드 변경은 additive 수준을 넘지 않아야 한다.
  • NFR-2 (auditability): review decision은 누가/언제/어떤 근거로 판단했는지 최소한의 감사 흔적을 남겨야 하며, raw payload나 민감 원문은 저장하지 않는다.
  • NFR-3 (DB safety): schema 변화는 additive/idempotent여야 하고, preview/report 재실행이 기존 persisted decision을 파괴하지 않아야 한다.
  • NFR-4 (operational determinism): 같은 기준 데이터와 같은 persisted decision 세트에 대해 운영 허브의 미처리 건수, 대조 상태, 추천 수락 여부 집계가 재현 가능해야 한다.

범위 경계

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

  • In Scope
    • 확인필요 큐 / 잔액대조 / 미분류 추천에 대한 review decision persistence 모델 정의
    • reconciliation session 또는 동등한 정리 단위의 최소 운영 모델 정의
    • Streamlit/MCP workbench에서 persisted decision을 읽고 갱신하는 흐름 정의
    • baseline 문서와 운영 허브 집계 기준 갱신 요구
  • Out of Scope
    • Phase 8 optional HTTP adapter(adapters/http/*) 구현 또는 원격 운영 재설계
    • 멀티유저 권한/승인 체계, 역할별 접근제어
    • 자동 스케줄링, 푸시 알림, 외부 메시징 연동
    • AI 기반 자동 판정 확정. 이번 주기는 추천/후보 제시와 운영자 수동 결정을 전제로 한다.
    • raw financial evidence 원문 저장 확대 또는 민감자료 보관 범위 확장

6. 리스크/가정 목록

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

리스크

  • R-1 (High): review decision 모델을 거래 상태와 별도로 도입할 때 source of truth가 이원화되어, 같은 항목이 현재 category/cashflow와 persisted decision 사이에서 불일치할 수 있다.
    • 완화 방안: 어떤 필드가 "운영 판정 기록"이고 어떤 필드가 "최종 회계 반영값"인지 명시하고, decision 적용 규칙과 미적용 preview 상태를 분리한다.
  • R-2 (High): 잔액대조 차이와 cross-transfer review를 같은 workbench로 묶는 과정에서 항목 단위(거래 1건 vs pair vs 계좌-session)가 섞여 UX와 데이터 모델이 복잡해질 수 있다.
    • 완화 방안: review target type을 명시적으로 분리하고, 공통 decision envelope + 타입별 payload 구조를 사용하는 방안을 우선 검토한다.
  • R-3 (Medium): 운영 메모/근거 필드가 자유 텍스트로만 남으면 구조화된 보고나 재자동화에 재사용하기 어려워질 수 있다.
    • 완화 방안: 자유 메모와 함께 결정 유형, 보류 이유 코드, 재검토 여부 같은 구조화 필드를 최소셋으로 둔다.
  • R-4 (Medium): 운영 허브 집계가 persisted decision을 읽기 시작하면 미처리/보류 상태 정의가 바뀌어 기존 대시보드 지표와 어긋날 수 있다.
    • 완화 방안: baseline 문서에 상태 정의를 명시하고 representative fixture/browser evidence로 운영 허브 표시를 검증한다.

가정

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

  • A-1: accounts.statement_status, last_balance, transactions.balance_after, cross_transfer_review memo tag, uncategorized recommendation 흐름을 review decision persistence의 입력 신호로 재사용할 수 있다.
  • A-2: 현재 single-user 운영 모델에서는 결정자 identity를 최소 수준(예: operator string 또는 system default)으로 기록해도 충분하다. 정교한 권한 모델은 후속 범위다.
  • A-3: review decision persistence는 additive schema와 기존 service 분리 구조(REQ-017/BAT-013, REQ-018/BAT-014)를 활용해 구현할 수 있다.
  • A-4: GitHub Project 4에는 아직 직접 대응 카드가 없으므로, 이 Discovery가 승인되면 새 project board item 또는 후속 REQ/BAT 항목으로 대표 주제를 생성해야 한다.

오픈 질문

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

  • OQ-1: review decision을 별도 테이블로 둘지, 기존 transaction/account row의 상태 필드 확장과 혼합할지?
    • 상태: Open
    • 처리 방안: REQ 초안에서 대안 A(별도 decision table) / 대안 B(기존 row 상태 확장) / 대안 C(공통 envelope + 타입별 payload) 비교 후 결정한다.
    • 종료 조건: persistence source of truth와 migration 경로가 REQ에서 단일안으로 확정되면 종료한다.
  • OQ-2: reconciliation 결과를 계좌 단위 session으로 영속화할지, 차이 항목별 decision만 남길지?
    • 상태: Open
    • 처리 방안: 운영 허브/월마감에서 필요한 집계(미대조 계좌, 보류 예외, 완료 시각)를 기준으로 session 단위의 필요성을 판단한다.
    • 종료 조건: REQ에서 session entity 필요 여부와 최소 필드가 확정되면 종료한다.
  • OQ-3: 미분류 추천 거부/수락 이력을 향후 자동 규칙 학습 입력으로 재사용할지, 이번 주기에서는 단순 감사 로그로만 남길지?
    • 상태: Deferred
    • 처리 방안: 이번 주기 기본값은 감사 로그 우선이며, 규칙/추천 자동화 재사용 여부는 후속 categorization intelligence 주기로 넘긴다.
    • 종료 조건: 후속 Discovery 또는 REQ에서 학습/재사용 범위를 다룰 때 재오픈한다.

오픈 질문 처리 기준

  • Open: 아직 답이 없고 다음 단계 진행에 영향이 있는 상태다. 문서에 유지한다.
  • Answered: 답이 확정된 상태다. 관련 본문/요구사항에 반영한 뒤 오픈 질문 목록에서는 제거하거나 resolved 기록으로 이동한다.
  • Deferred: 지금 단계에서 결정하지 않고 다음 단계 또는 후속 이슈로 넘기는 상태다. 넘길 대상과 이유를 반드시 적는다.
  • Dropped: 더 이상 유효하지 않은 질문이다. 삭제 사유를 짧게 남기고 목록에서 제거한다.
  • 처리 원칙 1: 질문만 남기지 말고 반드시 상태, 처리 방안, 종료 조건을 함께 적는다.
  • 처리 원칙 2: 답이 나온 질문은 본문 반영 없이 단순 삭제하지 않는다. 반영 위치를 먼저 갱신한다.
  • 처리 원칙 3: High 영향 질문은 Deferred 처리 후 처리 방안에 REQ 인계 추적 방식을 명시한다.

7. 초기 성공 기준

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

  • S-1: 운영자는 확인필요 큐, 잔액대조 차이, 미분류 추천 항목에 대해 persisted review decision을 남길 수 있고, 재조회 시 미처리/처리완료/보류 상태가 유지된다.
  • S-2: 운영 허브 또는 동등한 집계 화면에서 미처리 review 항목 수, 보류/재검토 항목 수, 미대조 계좌 상태가 persisted decision 기준으로 일관되게 표시된다.
  • S-3: review decision persistence와 reconciliation/workbench 흐름이 docs/data-model.md, docs/project-structure.md, docs/runtime-flows.md에 반영되어 이후 REQ/BAT/verification에서 기준선으로 재사용 가능하다.
  • S-4: 기존 MCP tool contract와 Streamlit 페이지 흐름은 additive 확장만 발생하고, representative pytest/AppTest/browser evidence 기준으로 회귀 없이 유지된다.

측정 방식 및 데이터 출처

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

  • S-1 측정 방식: synthetic/validation DB에서 review decision 생성 후 동일 항목 재조회 시 상태 유지 확인 / 데이터 출처: 신규 persistence 테이블 또는 상태 필드, list_cross_transfer_review_queue, get_balance_reconciliation_report, get_uncategorized_workbench
  • S-2 측정 방식: 운영 허브/워크벤치 표시 건수와 persisted decision 상태별 count 비교 / 데이터 출처: Streamlit UI, MCP 응답, decision/session persistence rows
  • S-3 측정 방식: baseline 문서 diff에서 review decision entity, workbench runtime flow, 운영 경고 집계 기준 반영 여부 확인 / 데이터 출처: docs/data-model.md, docs/project-structure.md, docs/runtime-flows.md
  • S-4 측정 방식: representative pytest/AppTest/contract regression/browser evidence 통과 여부 확인 / 데이터 출처: tests/, browser evidence artifact, MCP discovery/contract tests

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

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

  • 범위(In Scope/Out of Scope) 초안 제시
    • 기준: review decision persistence/workbench 모델은 포함하고, HTTP adapter/멀티유저/알림/자동 판정 확정은 제외로 제안했다.
  • 성공 지표의 측정 방식/데이터 출처 초안 제시
    • 기준: persisted decision 재조회, 운영 허브 집계, baseline 문서 반영, 대표 회귀 검증을 데이터 출처와 함께 연결했다.
  • High 영향 리스크에 대한 구조 대안 확정
    • 기준: OQ-1/OQ-2에서 persistence source of truth와 session 모델이 확정되어야 한다.
  • 병렬 주기 충돌 여부 검토
    • 기준: 현재 GitHub Project Todo는 Import provenance 및 민감자료 저장 정책 정리, Phase 8: optional HTTP adapter 준비 2개이며, 본 Discovery는 review decision/workbench persistence라는 별도 문제 정의를 다루므로 병렬 신규 주기로 생성 가능하다.
  • Freeze 확정 담당자(CONFIRMED_BY) 지정
    • 기준: 사용자가 범위/판정 모델 초안을 승인하면 Confirmed By/At를 기록한다.

9. 파일 처리 결과

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

  • 처리 결과: 생성
  • 생성 경로: docs/discovery/dcy-012_20260703_review-queue-reconciliation-workbench-persistence.md
  • 참조 문서:
    • docs/discovery/dcy-003_20260629_statement-unavailable-manual-evidence-balance-reconciliation.md
    • docs/discovery/dcy-005_20260629_dashboard-operations-hub-liquidity-monthly-cashflow.md
    • docs/discovery/dcy-011_20260703_backend-refactor-phase4-write-import-workflow-adapter-narrowing.md
    • docs/data-model.md
    • docs/project-structure.md
    • docs/runtime-flows.md
    • stage-pilot/templates/project-structure.md
    • stage-pilot/templates/runtime-flows.md

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

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

DECIDE

  • {{DECIDE_REVIEW_DECISION_STORAGE_MODEL}} — review decision을 별도 테이블 중심으로 둘지, 기존 거래/계좌 상태 확장 중심으로 둘지, 혼합 모델로 둘지 결정 필요
  • {{DECIDE_RECONCILIATION_SESSION_MODEL}} — 잔액대조를 계좌별 session 단위로 기록할지, decision 단위 기록만으로 충분한지 결정 필요

CONFIRM

  • {{CONFIRM_REVIEW_DECISION_VALUE_SET}} — 확인필요, 계좌이동, 실지출, 실수입, 투자이동, 분석제외, 보류/재검토를 기본 결정 집합으로 사용할지 확인 필요
  • {{CONFIRM_MCP_SURFACE_SCOPE}} — MCP에 review decision mutation 도구를 추가하는 것을 이번 주기 범위에 포함할지, Streamlit 우선으로 두고 MCP는 조회만 허용할지 확인 필요

DATA

  • {{DATA_RECONCILIATION_WORKBENCH_PRIORITIES}} — 월마감/운영 허브에서 가장 먼저 보고 싶은 상태 지표(예: 미처리 review 건수, 보류 건수, 미대조 계좌 수, 마지막 대조 완료 시각) 우선순위 필요

11. Discovery Freeze

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

섹션 참조

Freeze 플래그

  • Handoff Decision: 보류
  • Handoff Rationale: 초기 Discovery 초안 생성 완료. persistence source of truth, reconciliation session 모델, MCP surface 범위에 대한 사용자 확인이 남아 있어 REQ 초안 작성 전 confirm-discovery 단계가 필요하다.
  • Ready for REQ Drafting: false
  • Confirmed By: {{CONFIRMED_BY}}
  • Confirmed At (KST): {{CONFIRMED_AT_KST}}
View Git Blame Copy Permalink