- تم شحنها
- 28 أغسطس 2026 في 12:49 ص UTC
- صاحب البلاغ
- Kamo
- إرتكب
- 8dd52ec
It was the one read in this controller that took no right, deliberately: the two master notes were called fixtures of the home launchpad rather than the Notes app, so "every member always has one" was read as every member SEES one. What that produced was a member whose role withholds the Notes app — no icon, no /notes page, every other endpoint here refusing them — opening their home page onto their own master note and the organisation's, with no way to reach either anywhere else in the product. That is the same shape as the bug the 2026-08-14 pass fixed for the other ten endpoints, where VIEW_NOTES was enforced only by navRegistry.ts hiding the app in the browser. Provisioning is unchanged and still unconditional: the notes exist for every member from first ask and appear the day the right is granted. A member who may write the organisation's note but not read notes at all is a role misconfiguration, not a case to serve — VIEW_NOTES is the read, MANAGE_ORG_MASTER_NOTE is the write on top of it.