music is where the richer permission model gets designed

offscale is deliberately the simple case — one shared resource, read or write.
music is the next extraction and the right place to build the in-plugin
visibility system, because it has real per-user data (favourites, playlists,
now-playing) on top of a real shared one (a single global library index). so
'whose is this row' has a non-uniform answer there, where offscale's is just
'the owner's'.

not designed yet and deliberately not designed here. recorded so the intent
survives the gap.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/offscale-plugin.md

@@ -262,6 +262,16 @@ Two implementation consequences, both inside the plugin:
    feature rather than a withheld permission. Everything else — activate, rename, tags, routes, expire,
    delete, policy `PUT` — is a genuine write.
 
+### Music is where the richer model gets designed
+
+Offscale is deliberately the simple case. **The next plugin extracted is most likely music, and that is
+the right place to develop the in-plugin visibility system** — it has genuinely per-user data (favourites,
+playlists, now-playing) sitting on top of a genuinely shared one (a single global library index, noted in
+`TODO.md` as one household, one library). So "whose is this row" has a real and non-uniform answer there,
+where offscale's is just "the owner's".
+
+Not designed yet, and deliberately not designed here. Recorded so the intent survives.
+
 ### Three different things are called "capability" here
 
 A manifest needs three names, not one: