Node and system write routes stayed platform-admin-only through the tenancy pass rather than being loosened to org-owner. SAAS_PLAN.md §2.4 implies they should be customer-facing, but that was not one of the twelve build-order items and changing it without its own design pass risked a half-applied permission model.
Consequence: a second, non-admin org owner cannot manage their own nodes or invite members. That blocks onboarding any real customer.
Decide the permission model deliberately — which writes belong to org owners, which stay platform-only — rather than loosening routes one at a time as they are hit.
Node and system *write* routes stayed platform-admin-only through the tenancy pass rather than being loosened to org-owner. `SAAS_PLAN.md` §2.4 implies they should be customer-facing, but that was not one of the twelve build-order items and changing it without its own design pass risked a half-applied permission model.
Consequence: a second, non-admin org owner cannot manage their own nodes or invite members. That blocks onboarding any real customer.
Decide the permission model deliberately — which writes belong to org owners, which stay platform-only — rather than loosening routes one at a time as they are hit.
Not placed on the revenue gate, deliberately - it is not a security gap (CISO, #39). But the board recorded that it blocks the self-serve model §1/§2 of the now-ratified BUSINESS_MODEL.md depends on: a second real org cannot be onboarded without a platform admin doing it by hand. That is survivable for the Founding Operator cohort (cap 10, high-touch by design) and fatal beyond it.
Per DEFERRED.md, the correct fix needs its own design pass - which write actions belong to "owner", which to "member", and whether node approval should ever be self-serve - not a guess. Sequence that pass before the Founding Operator cohort fills, not after.
**Referenced by board minutes #42 (2026-08-23).**
Not placed on the revenue gate, deliberately - it is not a security gap (CISO, #39). But the board recorded that it blocks the self-serve model §1/§2 of the now-ratified `BUSINESS_MODEL.md` depends on: **a second real org cannot be onboarded without a platform admin doing it by hand.** That is survivable for the Founding Operator cohort (cap 10, high-touch by design) and fatal beyond it.
Per `DEFERRED.md`, the correct fix needs its own design pass - which write actions belong to "owner", which to "member", and whether node approval should ever be self-serve - not a guess. Sequence that pass before the Founding Operator cohort fills, not after.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Node and system write routes stayed platform-admin-only through the tenancy pass rather than being loosened to org-owner.
SAAS_PLAN.md§2.4 implies they should be customer-facing, but that was not one of the twelve build-order items and changing it without its own design pass risked a half-applied permission model.Consequence: a second, non-admin org owner cannot manage their own nodes or invite members. That blocks onboarding any real customer.
Decide the permission model deliberately — which writes belong to org owners, which stay platform-only — rather than loosening routes one at a time as they are hit.
Referenced by board minutes #42 (2026-08-23).
Not placed on the revenue gate, deliberately - it is not a security gap (CISO, #39). But the board recorded that it blocks the self-serve model §1/§2 of the now-ratified
BUSINESS_MODEL.mddepends on: a second real org cannot be onboarded without a platform admin doing it by hand. That is survivable for the Founding Operator cohort (cap 10, high-touch by design) and fatal beyond it.Per
DEFERRED.md, the correct fix needs its own design pass - which write actions belong to "owner", which to "member", and whether node approval should ever be self-serve - not a guess. Sequence that pass before the Founding Operator cohort fills, not after.