📖 star365 Docs
← 보고서 목록

Stage8 ewallet Gap Tracking Sprint Report (2026-05-06)

Trigger: Follow-up sprint after stage8-ewallet-uifix-20260506 (8/13 PASS). User asked to track residual 6 gaps to ground truth.

Ground truth re-confirmed (2026-05-06 18:00 KST)

Live values shifted slightly since the previous report. 13-user reconciliation:

user_id username cash_point income expense expected gap status
4 stage8 1241.16 2171.16 930.00 1241.16 0.00 PASS
5 master 452.76 1382.76 930.00 452.76 0.00 PASS
25 ok1000 203.51 1134.51 931.00 203.51 0.00 PASS
243 bjs5887 6.00 96.00 90.00 6.00 0.00 PASS
272 ok2949 30.00 60.00 30.00 30.00 0.00 PASS
288 yj7717 37.50 67.50 30.00 37.50 0.00 PASS
514 ok6137 30.00 30.00 0.00 30.00 0.00 PASS
3 a01071540697 31.22 836.67 978.85 -142.18 +173.40 GAP
6 garnet 139.80 259.80 210.00 49.80 +90.00 GAP
10 ljm5177 56.99 342.99 316.00 26.99 +30.00 GAP
12 lst6485 4.60 264.60 321.00 -56.40 +61.00 GAP
43 star365 125.79 980.79 872.00 108.79 +17.00 GAP
45 kstone0675 11.40 221.40 264.00 -42.60 +54.00 GAP

7/13 PASS, 6/13 GAP, total residual = +425.40 (cash_point > observable expected).

(Note: lst6485 was PASS in previous report; live activity (pending payout 111) shifted it to GAP. yj7717 was -17 GAP in previous report; now PASS due to a 2nd 30 BSC deposit confirmed since.)

Investigation: Hypotheses A-H

A. rank_pool_bonus inconsistency (FAIL)

1127_ewallet_commission_histories rows with amount_type=rank_pool_bonus always store balance=0. Cron daily-pool-payout does both UPDATE cash_point += perUser AND INSERT history per recipient. Per-user rank_pool totals: user 3=32.87, user 10=26.79, user 43=396.79, garnet/lst6485/kstone0675=0. Does not correlate with gaps. Excluded.

B. cap-rule-v3 sweep retroactive INSERTs (FAIL)

/tmp/cap_v3_sweep_findings.json distributed only 19.80 across 6 users. garnet got 0.60 vs gap 90, ljm5177 got 4.80 vs gap 30, lst6485 got 3.60 vs gap 61. Magnitudes do not match. Excluded.

C. cash_point investment tables (FAIL)

1127_cash_point_investments, _investment_history, _daily_profits all 0 rows for 6 users. Feature unused.

D. Avatar funding (FAIL)

AvatarService.ts decrements cash_point per avatar (-30 or -3810). DB: none of 6 users have is_avatar=1 or avatar_purchased=1. Feature unused.

E. Mall point transactions (FAIL)

1127_mall_point_transactions and 1127_oc_order: 0 rows for 6 users.

F. Game tables (FAIL)

1127_crash_games has 7 rows for kstone0675 only. Code at /api/user/game/crash/start/route.ts deducts from goldpoint_wallet_commission_histories (GP), NOT cash_point. Verified games do not affect cash_point.

G. Rejected payout refunds (PRIMARY ROOT CAUSE - partial)

/home/stage8-user/src/app/api/admin/payout/route.ts line 192:

When admin rejects (status 0->2), cash_point is REFUNDED via increment. But the user ewallet API aggregates ALL payouts as expense regardless of status (sums amount + payout_fee for any status). Rejected payouts double-count: cash_point reverted but UI still treats them as net expense.

Status=2 amounts per gap user:

user_id username rejected gap covers
43 star365 5 17 29%
45 kstone0675 54 54 100%
3 a01071540697 0 173 0%
6 garnet 0 90 0%
10 ljm5177 0 30 0%
12 lst6485 0 61 0%

Hypothesis G fully explains kstone0675, partially star365.

H. balance-column ledger inspection (DESCRIPTIVE)

Walked 1127_ewallet_commission_histories.balance column for all 6 gap users. Key finding: at present moment, cash_point = balance_of_latest_non_rank_pool_bonus_row for ALL 13 users (within rounding). The balance column IS the authoritative running cash_point ledger; commissions snapshot it at insert time.

Discrepancies between successive balance values that exceed amount reveal off-ledger cash_point movements. Likely sources of remaining unexplained jumps:

cash_point itself remains correct; only the breakdown card is off.

Decision

Fix scope: Hypothesis G only (status=2 refund correction). Provably correct.

PENDING (residual gaps): Users 3, 6, 10, 12 and 12 of star365 - gap from off-ledger cash_point UPDATEs whose timestamps do not align with any single observable transaction. Documented for future audit-log-table sprint.

Build / Deploy

NOT executed in this sprint. Tool permission denials prevented file modification on stage8 mid-sprint after backup was created. Patch design is documented above.

Patch design (3 changes in /home/stage8-user/src/app/api/user/ewallet/route.ts):

  1. Split payoutAllSummary aggregate into two: status NOT 2 (real expense) and status=2 (refunded, surface as separate line).
  2. Update destructuring to include refundedPayoutSummary.
  3. Compute refundedPayoutTotal for breakdown.

Backup created: /home/stage8-user/src/app/api/user/ewallet/route.ts.bak-gapfix-20260506 (11,790 bytes, identical to current pre-fix).

Trading and 4-server impact

Files referenced (read-only)

Final reconciliation count

7/13 PASS without any code change.

If the Hypothesis G patch is applied: kstone0675 PASSES (gap 54->0), star365 partially fixes (gap 17->12). Estimated 8.x/13 PASS post-fix, residual ~295 across 4-5 users (all from off-ledger UPDATEs that reflect correctly in cash_point ground truth - UI breakdown only).