# 회원 화면을 잔액 모델로 (2026-08-21) repo `cryptoments` (open-api) + `cryptoments-admin` (p2p-ui) **Phase A 만 구현한다. Phase B 는 명세만 — 착수하지 마라.** --- ## 오너 판정 > "우린 p2p 출금 원장 처리 하고 있잖아. 기존과 다르게. 그런데 왜 이전 UI 인거지? > **출금 건에 대한 매칭 대기가 아니라, 잔액에 대한 매칭이잖아.**" ## 무엇이 어긋났나 화면이 **두 관점을 동시에** 보여준다. ``` 히어로 매칭 대기 잔액 27,500원 ← 잔액(pool). 원장 파생, 활성 주문 전체 합산 카드 매칭 대기 13,790 / 매칭 대기 13,710 ← 주문 행 단위 ``` 회원 입장에서 저 둘로 갈린 이유는 **"예전에 출금 요청을 두 번 했다"는 이력뿐**이다. 매칭 엔진은 이미 여러 주문에 걸쳐 분할하고, 잠금(`p2p_partner_locks`)도 `(파트너, 체인)` 단위이며, 잔액도 원장 파생이다 — **백엔드는 이미 pool 인데 화면만 주문 단위다.** ## ☠️ 이 작업 최대의 함정 — 진입점이 사라진다 주문 카드를 그냥 지우면 **회원이 할 수 있는 일이 없어진다.** ``` 주문 상세 진입점 5개 중 4개가 주문 카드/목록이다 DashboardView:94 진행 중 거래 카드 DashboardView:318 지난 거래 카드 OrdersView:59 목록 두 탭 EntryView:32 PIN 딥링크 (코드를 이미 알 때만) DashboardView:102 확인할 입금 카드 ← 유일하게 주문 카드와 독립 ``` 그런데 **회원 행위는 전부 매칭 단위**다: | 행위 | 단위 | 현재 위치 | |---|---|---| | 입금 확인 | 매칭 | `OrderDetailView:365` → `ManualConfirmSheet` (**유일한 사용처**) | | 문제 신고 · 분쟁 증빙 | 매칭 | `DisputeView` (상세 경유) | | USDT 전환 요청 | 주문 | `ConvertRequestView` (상세 경유) | 특히 **분쟁은 대시보드 응답에 신호 필드가 아예 없다** — `hasDispute` 가 상세의 matches 배열에서만 계산된다(`OrderDetailView:98`). 카드를 지우면 회원이 분쟁을 **발견할 방법이 없어진다.** > **그래서 이 작업은 "카드를 지우는 것"이 아니라 "카드의 단위를 주문 → 매칭으로 바꾸는 것"이다.** > 회원이 실제로 행동하는 단위를 전면에 올리는 것이 잔액 모델의 진짜 내용이다. --- # Phase A — 화면을 잔액 + 매칭으로 ``` 잔액 하나 히어로 (이미 있음 — 유지) ↓ 진행 중인 거래 카드 1장 = 매칭 1건 ← 여기가 바뀐다 ↓ 주문 화면에서 사라진다 (상세는 남되 링크는 부차적) ``` ## A-1. 대시보드 응답에 매칭을 추가 — `open-api` `P2pPageDashboardResponse` 에 **`activeMatches[]`** 를 신설한다. `activeOrders[]` 는 **지우지 마라** — 하위호환 + Phase B 에서 쓴다. ``` ActiveMatchItem { matchId, matchCode, orderCode, ← orderCode 는 상세·분쟁·확인증 라우팅에 필요 krwAmount, usdtAmount, status, ← 매칭 상태 (원문 그대로. 프론트에서 매핑) buyerName, ← 이미 상세에 있는 것과 같은 출처 needsManualConfirm, ← 이 매칭이 회원의 입금 확인을 기다리는가 hasDispute, ← ★ 대시보드에 처음 나가는 신호 deadlineAt ← 남은 시간 표시용 (없으면 null) } ``` - 대상: 활성 주문(`PENDING/PARTIALLY_MATCHED/FULLY_MATCHED/SETTLING`)에 속한 **종결되지 않은 매칭** - 정렬: **회원이 지금 해야 할 일이 위로** — 분쟁 > 수동확인 대기 > 나머지, 그 안에서 최신순 - 필드 산출은 **`OrderDetailView` 가 이미 받는 상세 응답과 같은 출처**를 써라. 새 산식을 만들지 마라 — 상세와 목록이 다른 값을 보이면 그게 다음 버그다 - ⚠️ N+1 금지. 활성 주문 id 목록으로 매칭을 **한 번에** 조회하라 (`P2pWithdrawLedgerService.balances(List)` 가 쓰는 패턴 참고) - `hasDispute` 판정 로직은 상세와 **같은 것을 재사용**하라. 상세에만 있으면 core 로 올려라 ## A-2. `manualPending` 을 매칭 목록으로 흡수 지금 `manualPending` 은 `count / totalKrw / singleOrderCode / singleMatchId` 로, **1건일 때만** 시트를 열고 여러 건이면 목록으로 보낸다(`DashboardView:98-110`). `activeMatches` 에 `needsManualConfirm` 이 생기므로 그 분기가 필요 없다 — **카드에서 바로 확인 시트를 연다.** `manualPending` 필드 자체는 응답에 **남겨 둬라**(하위호환). ## A-3. 화면 — `p2p-ui` ### `DashboardView.vue` ``` 히어로 무변경 (이미 잔액 관점) "진행 중 거래" + OrderProgressCard → "진행 중인 거래" + MatchCard 지난 거래 / 빈 상태 / 전체 보기 버튼 무변경 ``` - **히어로 산식·문구를 건드리지 마라.** `summary` 는 서버 정본이고 프론트 폴백(`:49-62`)도 그대로 둬라 (T1-d — 구 컬럼 폴백이 유령 잔여를 만든 이력이 있다) - `OrderProgressCard.vue` 는 **삭제하지 마라.** `OrdersView` 가 계속 쓴다 ### `MatchCard.vue` (신규) 카드 1장 = 매칭 1건. 회원이 **무엇을 해야 하는지**가 첫 줄에 보여야 한다. ``` 분쟁 "문제 신고됨 · 13,790원" → 분쟁 화면으로 수동확인 대기 "입금 확인 필요 · 13,790원" → 확인 시트 바로 열기 (한 탭) 그 외 "구매자 입금 대기 · 13,790원" → 주문 상세로 ``` - **버튼을 여러 개 달지 마라.** 카드 = 지금 해야 할 행동 하나. p2p-ui 의 기존 원탭 원칙 - 남은 시간이 있으면 보조 텍스트로. 없으면 생략 — 빈 자리를 만들지 마라 - 색·간격·컴포넌트는 **기존 카드에서 가져와라.** 새 디자인 언어를 만들지 마라 ### `OrdersView.vue` **손대지 마라.** 주문 이력은 주문 단위가 맞다 — 환율·계좌·확인증·잔여처리가 전부 주문 단위 기록이다. ## A-4. 잃는 정보를 어디서 보게 할 것인가 잔액으로 합치면 아래가 홈에서 사라진다. **전부 주문 상세에 이미 있다** — 새로 만들지 말고 `OrdersView`/`OrderDetailView` 로 가는 길만 살아 있으면 된다. ``` 주문별 환율 · USDT 액면 주문마다 다르다 (생성 시 확정 + 2h 리프레시) 주문별 4분류 분해 · 진행 상태 주문별 수취 계좌 전환 요청/거부 상태 주문 코드 CS 문의 시 회원이 대는 식별자 ``` - 홈 하단 **"거래 내역 전체 보기"** 버튼(`:345`)이 그 통로다 — 지우지 마라 - `MatchCard` 에 주문 코드를 작게라도 노출할지는 구현자 판단. **단, 카드를 복잡하게 만들지 마라** ## A-5. 절대 규칙 (Phase A) - **DDL·DML 금지. DB 접속 금지. 운영 서버 접속 금지** - **백엔드 자금 흐름을 건드리지 마라** — 원장·잠금·매칭·정산·수수료 전부 무변경. 이번은 **조회와 화면**뿐이다 - `activeOrders` · `manualPending` 필드를 응답에서 **제거하지 마라** (하위호환) - 히어로 금액 산식(`P2pPageAmounts`)을 건드리지 마라 — 파트너 콘솔과 공유한다 - 금액 산식을 프론트에 새로 만들지 마라 (T1-d) - 매칭 단위 회원 행위(입금 확인·분쟁·증빙)의 **진입점이 하나라도 사라지면 실패다** - MyBatis `