Best practices in naming and defining procedures when they don't fit into standard buckets? - tRPC

I am loving TRPC and its type safety, but I feel like I'm struggling with the naming of procedures. I'm pretty confused with why I need to fit my procedures into one of the 3 buckets: query, mutation, or subscription. For example, I have `items`. They can be queried, mutated and subscribed to. And maybe a few more things - items can be generated, created, pulled from a remote source, deleted, renamed, aliased, etc. But let's try to fit this into these prescribed buckets. I felt inclined to define `items` as a `publicProcedure` with all 3 verbs. But I have to choose only one, not all three. The api does not support chaining on multiple verbs. If I want to support all 3, I have to differentiate them as separate procedure definitions such as `getItems`, `updateItems`, and `subscribeToItems`... but then, what's the point of query/mutate/subscribe if I am already differentiating them as separate procedure names? Now the client api surface is weird: I wanted the client code to read: `client.items.query()`, or `client.items.mutate(...)` I'm fine with it if I can just have `client.getItems()` or `client.updateItems(...)` Instead I have redundancy in the naming: `client.getItems.query()`, `client.updateItems.mutate(...)` To make things more confusing, some procedures just don't fit into these buckets. I can have procedures which read nothing, write nothing, but perform some action like open a file in vscode. None of the above conventions work in this case. My expectation when using it was simply to have an execute call, and let the author decide their naming conventions. If there is nothing special about a query or mutation, why introduce weird things that mess with the naming conventions and don't work in every case?