[Chore] : 아이콘 교체 및 홍보 포인트 조정 등 자잘한 수정 (#247) by GulSam00 · Pull Request #248 · GulSam00/singcode

GulSam00 · 2026-06-04T17:01:49Z

📌 PR 제목

[Chore] : 아이콘 교체 및 홍보 포인트 조정 등 자잘한 수정

📌 변경 사항

PWA 아이콘 4종 교체 (icon-192, icon-512, maskable-192, maskable-512) 및 sitemap 재생성
곡 홍보 하루 비용 50P → 15P 조정 (홍보 등록 songs/promotions, 환불 user/promotions, 모달 SongPromotionModal)
홍보 모달 안내 문구를 "하루 15P로 전광판에 곡을 홍보할 수 있어요" 로 수정
번호 검색 시 5자리 초과 입력 차단 (HomePage)

💬 추가 참고 사항

close 아이콘 교체 및 홍보 포인트 조정 등 자잘한 수정 #247

vercel · 2026-06-04T17:01:55Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
singcode	Ready	Preview, Comment	Jun 4, 2026 5:03pm

GulSam00 · 2026-06-04T17:01:56Z

/describe

GulSam00 · 2026-06-04T17:01:57Z

/review

GulSam00 · 2026-06-04T17:01:58Z

/improve

qodo-code-review · 2026-06-04T17:02:04Z

Review Summary by Qodo

(Agentic_describe updated until commit `a37a526`)

Adjust promotion cost to 15P and fix search input validation

✨ Enhancement 🐞 Bug fix

Walkthroughs

Description

• Reduce song promotion daily cost from 50P to 15P
• Update promotion modal guidance text with new cost
• Prevent number search input exceeding 5 digits
• Regenerate sitemap with updated timestamps

Diagram

flowchart LR
  A["Promotion Cost"] -->|"Reduce 50P to 15P"| B["API Routes"]
  A -->|"Update guidance text"| C["SongPromotionModal"]
  D["Search Input"] -->|"Limit to 5 digits"| E["HomePage"]
  F["Sitemap"] -->|"Regenerate"| G["Updated timestamps"]

File Changes

1. apps/web/src/app/api/songs/promotions/route.ts ✨ Enhancement +1/-1

Reduce promotion cost to 15P per day
• Changed promotion cost calculation from days * 50 to days * 15
• Reduces daily promotion expense for song registration
apps/web/src/app/api/songs/promotions/route.ts

2. apps/web/src/app/api/user/promotions/route.ts ✨ Enhancement +1/-1

Adjust refund calculation to 15P per day
• Changed refund calculation from days * 50 to days * 15
• Aligns refund amount with new promotion pricing
apps/web/src/app/api/user/promotions/route.ts

3. apps/web/public/sitemap-0.xml ⚙️ Configuration changes +3/-3

Regenerate sitemap with updated timestamps
• Updated lastmod timestamps for all URLs
• Regenerated sitemap with current date (2026-06-04)
apps/web/public/sitemap-0.xml

View more (2)

4. apps/web/src/app/search/HomePage.tsx 🐞 Bug fix +3/-1

Limit number search input to 5 digits

• Added validation to prevent number search input exceeding 5 digits
• Checks searchType === 'number' and limits value.length to 5
• Returns early if input exceeds limit without updating state

apps/web/src/app/search/HomePage.tsx

5. apps/web/src/components/SongPromotionModal.tsx ✨ Enhancement +2/-2

Update promotion cost and modal guidance text

• Changed cost calculation from days * 50 to days * 15
• Updated DialogDescription text from generic to specific: "하루 15P로 전광판에 곡을 홍보할 수 있어요"
• Provides clearer guidance on promotion cost to users

apps/web/src/components/SongPromotionModal.tsx

qodo-code-review · 2026-06-04T17:02:05Z

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

Context used

✅ Tickets: 🎫 아이콘 교체 및 홍보 포인트 조정 등 자잘한 수정

1. Refund recalculated with new rate 🐞 Bug ≡ Correctness

Description

DELETE /api/user/promotions computes refunds as days * 15, so a promotion created under the old
50P/day pricing will refund too little and permanently lose user points when canceled. The creation
flow doesn’t persist the charged amount (or a point-change reference), so the correct historical
refund cannot be derived later.

Code

apps/web/src/app/api/user/promotions/route.ts[R103-105]

    const days =
      differenceInCalendarDays(new Date(promotion.end_date), new Date(promotion.start_date)) + 1;
-    const refund = days * 50;
+    const refund = days * 15;

Evidence

Creation charges points using a computed cost but does not store that cost on the
song_promotions row, while cancellation later recomputes refund from the current constant and
dates; therefore promotions created under the old rate cannot be correctly refunded after this PR
changes the constant.

apps/web/src/app/api/songs/promotions/route.ts[116-158]
apps/web/src/app/api/user/promotions/route.ts[75-118]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Promotion cancellation refunds are recalculated from the current price (`days * 15`) rather than the amount actually paid at creation time. This breaks refunds for any promotions created before/after a price change and can cause permanent user point loss.

### Issue Context
- Creation charges points based on `days * 15` and inserts a `song_promotions` row without storing the paid amount.
- Cancellation later recomputes `refund` from dates, so it cannot know the originally-paid rate.

### Fix Focus Areas
- Add a persisted field on the promotion record (e.g. `paid_points` or `cost_per_day`/`total_cost`) and populate it at creation time.
- Refund using the persisted value, not a recalculation.
- Consider a data backfill/migration strategy for existing rows created under the old 50P/day pricing.

### Fix Focus Areas (code references)
- apps/web/src/app/api/songs/promotions/route.ts[116-158]
- apps/web/src/app/api/user/promotions/route.ts[75-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Promotion price duplicated in code 🐞 Bug ⚙ Maintainability

Description

The 15P/day price is hardcoded in multiple frontend/backend locations, increasing the chance of
UI/server/refund logic diverging on the next price change. This PR already had to update three
separate call sites to keep behavior consistent.

Code

apps/web/src/components/SongPromotionModal.tsx[R44-48]

  const days = range?.from ? differenceInCalendarDays(range.to ?? range.from, range.from) + 1 : 0;

-  const cost = days * 50;
+  const cost = days * 15;
  const canAfford = point >= cost;
  const canSubmit = days > 0 && content.trim().length > 0 && canAfford;

Evidence
The same pricing multiplier is repeated across the create API, cancel API, and the modal UI
calculation, so any future change requires synchronized edits and is prone to drift.
apps/web/src/app/api/songs/promotions/route.ts[116-118]
apps/web/src/app/api/user/promotions/route.ts[103-106]
apps/web/src/components/SongPromotionModal.tsx[41-47]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The promotion price (15P/day) is duplicated across multiple files (POST charge, DELETE refund, UI display). This duplication is a maintainability hazard and can easily cause mismatched behavior.

### Issue Context
This PR updated the same number in 3 places. Future changes risk missing one.

### Fix Focus Areas
- Extract a shared constant (e.g. `PROMOTION_POINT_PER_DAY`) into a shared package/module and import it.
- Preferably, move pricing to persisted/configured data (DB or server config) and have UI read it from an API.

### Fix Focus Areas (code references)
- apps/web/src/app/api/songs/promotions/route.ts[116-118]
- apps/web/src/app/api/user/promotions/route.ts[103-106]
- apps/web/src/components/SongPromotionModal.tsx[44-48]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Number length limit not centralized 🐞 Bug ≡ Correctness

Description

The 5-character limit is enforced only in the input onChange, but other flows can still set/search
a longer value (e.g., history/autocomplete setters and searchType switching don’t normalize the
existing search). This makes the “number max 5 digits” rule inconsistent depending on how the
search term was populated.

Code

apps/web/src/app/search/HomePage.tsx[R103-106]

  const handleChangeSearch = (e: React.ChangeEvent<HTMLInputElement>) => {
-    setSearch(e.target.value);
+    const value = e.target.value;
+    if (searchType === 'number' && value.length > 5) return;
+    setSearch(value);

Evidence

HomePage blocks only direct typing beyond 5 chars, but it also has other codepaths that call
setSearch(term) without any limit, and the hook’s handleSearchTypeChange doesn’t adjust the
already-entered search value; handleSearch then submits whatever is stored.

apps/web/src/app/search/HomePage.tsx[103-117]
apps/web/src/hooks/useSearchSong.ts[57-92]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The 5-char restriction for `searchType === 'number'` is only applied in `HomePage` input onChange. Other setters (`setSearch(...)` from history/autocomplete) and changing the search type do not enforce the limit, so overlong values can still be searched.

### Issue Context
`useSearchSong` owns the canonical `search` state and performs the actual search submission; validation belongs there to be consistent across all UI entry points.

### Fix Focus Areas
- In `useSearchSong`, enforce: when `searchType` is `number`, normalize `search` to max length 5 (truncate) or reject with an error/toast.
- Optionally also validate in `handleSearch` before setting `query`.

### Fix Focus Areas (code references)
- apps/web/src/app/search/HomePage.tsx[103-117]
- apps/web/src/hooks/useSearchSong.ts[57-92]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-code-review · 2026-06-04T17:02:05Z

Code Review by Qodo

New Review Started

This review has been superseded by a new analysis

qodo-code-review · 2026-06-04T17:06:06Z

    const days =
      differenceInCalendarDays(new Date(promotion.end_date), new Date(promotion.start_date)) + 1;
-    const refund = days * 50;
+    const refund = days * 15;


1. Refund recalculated with new rate 🐞 Bug ≡ Correctness

DELETE /api/user/promotions computes refunds as days * 15, so a promotion created under the old 50P/day pricing will refund too little and permanently lose user points when canceled. The creation flow doesn’t persist the charged amount (or a point-change reference), so the correct historical refund cannot be derived later.

Agent Prompt

### Issue description Promotion cancellation refunds are recalculated from the current price (`days * 15`) rather than the amount actually paid at creation time. This breaks refunds for any promotions created before/after a price change and can cause permanent user point loss. ### Issue Context - Creation charges points based on `days * 15` and inserts a `song_promotions` row without storing the paid amount. - Cancellation later recomputes `refund` from dates, so it cannot know the originally-paid rate. ### Fix Focus Areas - Add a persisted field on the promotion record (e.g. `paid_points` or `cost_per_day`/`total_cost`) and populate it at creation time. - Refund using the persisted value, not a recalculation. - Consider a data backfill/migration strategy for existing rows created under the old 50P/day pricing. ### Fix Focus Areas (code references) - apps/web/src/app/api/songs/promotions/route.ts[116-158] - apps/web/src/app/api/user/promotions/route.ts[75-118]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

GulSam00 added 3 commits June 5, 2026 01:59

chore : PWA 아이콘 4종 교체 및 sitemap 재생성 (#247)

64e50c2

chore : 곡 홍보 비용 50P에서 15P로 조정 및 안내 문구 수정 (#247)

186ea14

fix : 번호 검색 시 5자리 초과 입력 차단 (#247)

a37a526

vercel Bot deployed to Preview June 4, 2026 17:03 View deployment

qodo-code-review Bot reviewed Jun 4, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Chore] : 아이콘 교체 및 홍보 포인트 조정 등 자잘한 수정 (#247)#248

[Chore] : 아이콘 교체 및 홍보 포인트 조정 등 자잘한 수정 (#247)#248
GulSam00 wants to merge 3 commits into
developfrom
chore/247-minorFixes

GulSam00 commented Jun 4, 2026

Uh oh!

vercel Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

GulSam00 commented Jun 4, 2026

Uh oh!

GulSam00 commented Jun 4, 2026

Uh oh!

GulSam00 commented Jun 4, 2026

Uh oh!

qodo-code-review Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Jun 4, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot Jun 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

GulSam00 commented Jun 4, 2026

📌 PR 제목