| # | Problem (before) | Fix (now) | Risk |
| A1 | Publishing an album or EP skipped the collaborator check and never locked the split. Example: A and B agree 90/10, A publishes the song inside an EP, tips get paid 50/50. A pending invite could still be accepted after release and start earning. | Album / EP publish now checks every song going live, the same way single publish does. It stops with the song name and who it is waiting for. After publishing, the split is locked. | High · money |
| A2 | Pressing Publish again on a live song reset its publish time, so a creator could keep it at the top of "New releases" and followers' feeds. | Says "This song is already live" and changes nothing. | Medium |
| A3 | Tapping re-compose twice quickly on the same song could overwrite one version's audio with the other's, show an error and use 2 daily songs. | One compose at a time per song. The second tap says "This song is already being composed" and uses no quota. | Medium |
| A4 | If the AI made the song but our server failed to save it, the user still lost 1 of 10 daily songs. Being blocked (not your song, song locked) also used a daily song. | The daily song is given back when we fail. Blocked requests no longer use one. | Low |
| A5 | If Redis had a problem, the daily limits on compose, magic pen and AI covers stopped counting. Every one of those is a paid AI call. | When the counter fails, the request is refused with "busy, try again in a moment". | Low |
| A6 | The 3 genres / 2 moods limit was only in the app. A direct API call could put one song in 5 genre pages. | The server keeps the first 3 genres and 2 moods and drops the rest. | Low |
| A7 | Small leaks and races: a stranger could see collaborator names through the publish error, or check who is on a song. The collaborator cap allowed 11 people instead of 10. Parallel requests could go past the 10 a day genre-suggestion limit. | Owner is checked first ("This isn't your song", no names). Max 9 collaborators plus the owner, also under parallel invites. Suggestion limit holds under parallel requests. | Low |
How it was checked: for every item a test against a real database (or Redis) was written, then the fix was removed on purpose to confirm the test fails. One test was too weak the first time (it passed with the fix removed) and was replaced with a stricter one. The running server binary was checked to contain the new code. Tests: release_split_gate_1002_db_test, republish_1002_db_test, compose_lock_1002_test, song_tags_caps_1002_db_test, leaks_races_1002_db_test in backend/internal/domain/music/. No database migration; the app only changed its version number.
What users notice: almost nothing in normal use, since these only show when someone misuses the API or something fails. The one visible change: publishing an EP with a collaborator who hasn't accepted now stops and names them.