- Shipped
- August 15, 2026 at 12:34 AM UTC
- Author
- Kamo
- Commit
- e797ced
EVENT_SOUND_ASSETS: a sound file somebody uploaded, ready to be assigned. Scope mirrors EVENT_SOUND_PROFILES exactly — same three layers, same SCOPE_ID convention — so "which sounds may I choose from" and "which layer am I editing" are one model asked of two tables. DELIBERATELY NOT an imgs/img_dats row. The imaging pipeline is built for documents: content-addressed dedup, thumbnails, folders, doc types, per-assoc delete and overwrite rules. A sound effect is a two-second file with a name and a description and needs none of it. More to the point, a fifteenth ImageAssocType obliges EVERY imaging service to redeploy in lockstep — they resolve associations by values()[ordinal] and a stale enum throws ArrayIndexOutOfBounds — and a sound effect should not be able to break document uploads by existing. What it keeps from that pipeline is what matters: the bytes go through ConversionService, which malware-scans them and transcodes to Opus, and they land in the same MinIO bucket under their own prefix. ORG_ID is separate from SCOPE_ID because a MEMBER-scoped sound has the member's id in the scope and is still bytes on that organization's shelf. Platform sounds carry a null org and are charged to nobody — that catalogue is Kamo's. Hence the EVENT_SOUNDS storage domain rather than a line inside DOCUMENTS: these are a distinct product an organization can be surprised by, and burying them would repeat the mistake that hid 5.08 GB of chat traffic inside a "Documents" figure. Schema applied via KamoInitializer and verified in Yugabyte before this push. 1418 tests pass, StorageDomainCoverageTest included.