Docs LGTM

This is a good deletion. Net -138 lines, the minimumImplicitMember atomic.Bool mirror is gone from object.go, and OrgMemberPermissions / OrgServiceAccountPermissions are now pure functions of OrgSettings instead of reading process-global state on every call. RoleOptions is left describing only deploy-time deny toggles, and the startup ordering dependency between ReloadBuiltinRoles and ReconcileSystemRoles disappeared with the global.

The panel independently traced the two things that could have broken, and neither did. Cross-role negation: the workspace:share deny stays on organization-member while the positive workspace grant moved to organization-workspace-access, and check_all_org_permissions in policy.rego:120-133 votes across all of a subject's roles at a level, so the deny still overrides the allow in the other role. Upgrade path: migration 000516 unconditionally backfills every existing org, the column is NOT NULL with no SQL default so no insert path can silently omit it, ReconcileSystemRoles runs after ReloadBuiltinRoles in the same New(), and both role-union queries include the column for service accounts too. Deployments still passing --experiments=minimum-implicit-member warn and boot. Repo-wide greps for the removed identifier return nothing.

Round 1 count: 1 P1, 6 P2, 14 P3, 1 P4, 8 Nit, 5 Note. Three of the P2s are process findings and are below rather than inline.

The P1 and most of the P2s are not about the RBAC edit. They are about the surface the experiment flag was hiding. Seven findings land on the Default Roles editor and the member-roles dialog, and the chain is worse than any single one: the copy misstates the blast radius (CRF-11) in a term no operator can resolve (CRF-12), the dialog offers organization-admin as an org-wide default (CRF-22), an overlapping explicit grant then becomes unremovable from the members page (CRF-13), and a viewer without editSettings cannot see any of it (CRF-25). They are filed separately because the fixes are independent, but they ship together.

Process, three items:

CRF-15 (P2, verification scope). Commit a31ad5de1f states "Verified: go build ./..., TestPatchOrganizationsByUser + TestMemberWorkspaceElevation pass, tsc --noEmit clean" while go test ./coderd/rbac/ was red at that commit. Mafu-san ran both directions: at a31ad5de1f, TestAuthorizeDomain/Member/Set0/Case2 fails with rbac: forbidden on ssh and stop, package FAIL in 1.09s; at the merge base 6e5f02bfbe the same run is ok. The named test lives in the same package as the failing one, so the claim reports the result of a -run filter inside a red package as verification of the change. The fixtures that fix it land one commit later, so head is green. The standard for the rest of this PR: when a change edits a coderd/rbac permission set, the minimum evidence is go test ./coderd/rbac/ with no -run filter. Related, Kite: taken alone, 0e36260b2c deletes TestMinimumImplicitMember and ships the unconditional elevation removal with nothing asserting it, and a31ad5de1f adds TestMemberWorkspaceElevation back. A squash merge makes that moot; a merge commit does not.

CRF-16 (P2, emdash in commit metadata). a31ad5de1f's message body contains a U+2014 in "...(pages, view, stories) — required once codegen drops the value...". AGENTS.md forbids U+2014 outright, and scripts/check_emdash.sh scans git ls-files, so it has no reach into commit messages: make lint/emdash is clean. Rewrite the body before merge. The rule applies to commit and PR text, not only tracked files.

CRF-28 (P2, empty PR description). The body is the empty string for a change that permanently alters the default permission set of every deployment on upgrade. The permanent record becomes one line naming a Go identifier: it does not say that organization-member stops granting workspace access, that the elevation moves to organization-workspace-access, that 000516 plus ReconcileSystemRoles covers the upgrade, or that org admins can now clear default_org_member_roles without a flag. Write it. While there, the release notes should name the removed experiment value: operators who set it keep logging "ignoring unknown experiment" on every restart with nothing telling them to remove it. And Leorio on the subject line: "promote MinimumImplicitMember experiment to GA" names an internal Go field and describes the process, not the effect.

Two things the panel tried hard to break and could not, recorded so they are not re-litigated: no production code path builds a member subject outside the SQL union (coderdtest.go:933-943 and idpsync/role.go:182-204 already mirror it explicitly), and the removed 403 left no ungated path, because PATCH /organizations/{organization} sits behind RequireFeatureMW(FeatureMultipleOrganizations), dbauthz.UpdateOrganization runs canAssignRoles over the delta, the handler still rejects non-built-in names, and enterprise/audit/table.go:361 tracks the column. Kite's praise on TestMemberWorkspaceElevation stands too: replacing a toggle test with an invariant test, and updating the fixtures to keep their effective permissions equal to what a real member gets rather than weakening the assertions, is the harder and correct direction.

Hisoka, on the whole thing: "I came looking for a fight. ♦ ... Rating: ★ curiosity only. I wanted a ★★★★. You didn't give me one."

site/src/pages/OrganizationSettingsPage/CustomRolesPage/CustomRolesPageView.tsx:154

P1 [CRF-11] The Default Roles copy tells the admin an empty selection affects "new members", but clearing the list revokes workspace access from every existing member of the org on their next request. (Kite P1, Leorio P1, Pariston P2, Razor P2, Chopper P2, Luffy P2)

Six reviewers reached this independently. The section contradicts itself in one paragraph, and the wrong half is the one an admin reads while deciding whether to confirm:

• CustomRolesPageView.tsx:154: "Roles attached to every member of this organization. An empty selection limits new members to the floor permissions only."
• CustomRolesPageView.tsx:169: "No default roles. New members receive only the floor."
• DefaultRolesDialog.tsx:80: "These roles are attached to every member of this organization. Use an empty selection to grant new members only the floor."

The behavior is settled, not inferred. Pariston: "TestGetAuthorizationUserRolesUnionsDefaultOrgMemberRoles at coderd/database/querier_test.go:3301 shrinks an org's defaults to [] and asserts the scoped organization-workspace-access role disappears from an already-existing member's effective roles, and from an existing service account's." users.sql:637 unions the column at request time, and 000516_org_default_member_roles.up.sql states "changes propagate to all members on the next request".

Kite traced how far the loss reaches: "The site member role's user permissions are allPermsExcept(ResourceWorkspaceDormant, ResourcePrebuiltWorkspace, ResourceWorkspace, ...) (coderd/rbac/roles.go:437), so a user's access to their own workspaces comes only from the org elevation that organization-workspace-access now carries exclusively." Luffy states the outcome: "Their workspaces keep running and they can't touch them."

This PR is what makes the copy load-bearing. showDefaultRoles dropped defaultRolesEnabled (:63) and the 403 on deviation was deleted from enterprise/coderd/organizations.go, so every deployment entitled for multiple_organizations now has a one-click path from a settings page to revoking read, ssh, start, stop and delete on running workspaces for every member of an org.

P1 rather than P2, against the four reviewers who said P2: their reason for P2 was that an attentive admin may notice the contradiction, which is a mitigation that depends on the reader catching the page lying to them. The consequence does not: it is an org-wide authorization revocation triggered from a settings control that describes it as a forward-only default, with no confirmation of scope. Reversible by re-adding the role, but only for someone who already knows the roles are unioned per request.

Fix all three strings, not one. Leorio's draft for the dialog: "These roles are added to every member of this organization, including existing members, and take effect on their next request. Removing organization-workspace-access revokes workspace create, build, ssh, and delete for every member who is not granted it directly." Kite's stronger option, worth taking: have DefaultRolesDialog warn on confirm when the submitted set drops organization-workspace-access while the org has members, naming the count. The copy fix removes the false statement; the warning is what makes the blast radius visible at the moment of the click.

🤖

site/src/pages/OrganizationSettingsPage/CustomRolesPage/CustomRolesPageView.tsx:154

P2 [CRF-12] The same three strings explain the feature with "the floor", an rbac package term that is defined nowhere an operator can reach, and this PR deleted the last place in the tree that defined it. (Gon P2, Leorio P2, Mafuuu P3, Luffy P3, Zoro P3)

Separate from CRF-11: fixing the "new members" claim does not remove the jargon, and removing the jargon does not fix the claim.

Leorio: "Grep the whole repo: 'floor' in this sense is defined nowhere. This PR deleted the only two places that explained it, the RoleOptions.MinimumImplicitMember doc comment and the elevation block in OrgMemberPermissions. The UI now uses a term whose definition the same commit removed." Luffy grepped the docs for somewhere to send the reader: "the only hits are the generated API reference (docs/reference/api/*.md), and 'Gateway Account' appears nowhere in docs/."

The consequence is the question the copy fails to answer. Mafuuu: "an org admin about to strip workspace access from every member of an organization is told the outcome in a word that has no referent they can resolve."

P2 over the three P3s: the P2 arguments are the more specific ones, naming all three strings, quoting them, and showing that the definition left the tree in this commit. Note this is not CRF-3 with different words. CRF-3 is the missing prose page; this is the shipped dialog standing in for it, and Zoro is right that even with a doc, "the floor" is the wrong word in a settings page.

Zoro's concrete replacements, for :154: "Roles attached to every member of this organization. With an empty selection, new members can read the organization and manage their own account, but cannot create or use workspaces." And for :169: "No default roles. New members cannot create or use workspaces." Fold in CRF-11's correction about existing members and both findings close together.

🤖

coderd/rbac/roles.go:1133

P2 [CRF-14] The PR deleted the only in-file explanation of where member workspace permissions went, and put nothing in its place. (Leorio P2, Gon P3)

Leorio: "Before this PR, a reader who opened OrgMemberPermissions hit an eleven-line comment naming OrgWorkspaceAccessMemberPerms, organization-workspace-access, and default_org_member_roles. The PR removed it (-roles.go:1199-1211) and put nothing in its place." What remains says only that the permissions vary with workspace sharing settings.

The consequence is a comprehension trap in the most widely held role in the system: "The next person who gets a bug report saying 'members can't create workspaces' reads this function, sees no ResourceWorkspace grant, and has no idea whether that is the design or the bug."

This is the substantive half of the comment findings, distinct from CRF-5 (stale "in the floor" wording) and CRF-29 (comments restating their assertions). Leorio's draft:

// OrgMemberPermissions returns the permissions for the organization-member
// system role, which can vary based on the organization's workspace sharing
// settings.
//
// Workspace permissions are deliberately not included here. They live on the
// organization-workspace-access role (OrgWorkspaceAccessMemberPerms), which
// DefaultOrgMemberRoles attaches to every new organization. An org that clears
// default_org_member_roles leaves its members with this set only.

OrgServiceAccountPermissions has the same hole and needs the same sentence.

🤖

coderd/rbac/roles.go:227

P3 [CRF-18] OrgWorkspaceAccessMemberPerms stays exported although the only production caller left is the role definition in the same package, so the elevation this PR just unbundled can be re-bundled into any other role. (Knov)

Knov: "Before this PR the function had three production callers: the orgWorkspaceAccess role at coderd/rbac/roles.go:720, and the two slices.Concat(elevation, floor) sites in OrgMemberPermissions and OrgServiceAccountPermissions. After the diff, grep -rn 'OrgWorkspaceAccessMemberPerms' coderd enterprise cli --include='*.go' | grep -v _test.go returns only the definition and line 720, both inside package rbac."

The consequence is the misuse the promotion exists to remove: "a future caller writing Member: slices.Concat(rbac.OrgWorkspaceAccessMemberPerms(), somethingElse) restores implicit workspace access without touching organization-member, and nothing fails."

Ordered with CRF-17, because it is one change: fix the test to read the role through RoleByName first, then unexport the helper to orgWorkspaceAccessMemberPerms. The elevation becomes reachable only through the role identifier, and the package boundary states the invariant the PR title only asserts in prose. Kept at P3 rather than treated as dead-code cleanup: an exported perm-set helper is reachable by any package, and the severity is set by what happens when someone uses it, not by there being no caller today.

🤖

codersdk/organizations.go:107

P3 [CRF-21] GA ships no way to create a Gateway Accounts organization atomically: default_org_member_roles is settable only on PATCH, so every new org is born granting workspace access to all members. (Mafuuu)

Mafuuu: "CreateOrganizationRequest (codersdk/organizations.go:107-113) has no default_org_member_roles field, and enterprise/coderd/organizations.go:316 hardcodes DefaultOrgMemberRoles: rbac.DefaultOrgMemberRoles() on insert. An operator who wants an org whose members must never hold workspace permissions has to do create-then-PATCH, and the org exists with the elevation in between."

The scenario: an operator provisions a gateway org from Terraform or a script, POST returns, and before the follow-up PATCH lands an IdP-sync-eligible user logs in and is enrolled. That user can create and exec into workspaces in an org created specifically to deny it. The subsequent PATCH closes the door but does not revoke what was already reachable.

P3 because the window is short and needs a login inside it. It is a finding rather than a note because GA is the moment this API shape stops being provisional: CreateOrganizationRequest gains a *[]string now or the gap is permanent. The fix is the field plus threading it into the existing InsertOrganizationParams, and the validation loop at enterprise/coderd/organizations.go:68-81 is already factored to be reused.

Mafuuu states the limit of the evidence: derived from reading the request shapes, the insert call site and the request-time union at users.sql:625, not from constructing the race.

🤖

site/src/pages/OrganizationSettingsPage/CustomRolesPage/CustomRolesPageView.tsx:161

P3 [CRF-26] Opening "Edit default roles" before the org roles query resolves gives the admin a dialog with a title, a Confirm button, and nothing in between. (Nami)

Nami: "The Edit button is disabled only for isUpdatingDefaultRoles || !defaultRolesEntitled, so it is live while availableOrgRoles is still undefined. DefaultRolesDialog.tsx:39 coerces that to [], and RoleSelector.tsx:67 returns null when selectableRoles is empty, so the dialog body is empty. Confirm still submits [...selected], which equals the current roles, so nothing is destroyed; the admin just gets a headless dialog and no explanation."

Nothing is lost, which is why this is P3 and not higher, but the empty dialog is indistinguishable from Bisky's saturation case in CRF-13, so an admin who hits either reports the same symptom and the two have different causes.

RoleSelector already accepts loading and error, and CustomRolesPage already holds organizationRolesQuery. Either disable the button until availableOrgRoles is defined, or thread the query's loading and error state through to the selector. Threading it also covers the load failure, which currently renders the same empty dialog.

🤖

enterprise/coderd/license/usercount_test.go:32

P3 [CRF-1] The file still declares that subtests toggle global builtin roles and keeps them serial, but after this PR every call is ReloadBuiltinRoles(nil). (Netero)

Netero: "All six sites (:69/:70, :115/:116, :157/:158, :188/:189, :231/:232, :256/:257) now pass nil on both the set and the cleanup, and grep -rn ReloadBuiltinRoles enterprise/coderd/license/ shows no caller in the package that passes options any more (the bench file's call was deleted in this diff). So the reset is a no-op and nothing in the package mutates the globals."

Two consequences: "the header comment at :32-33 tells the next reader that role globals vary per subtest when they do not, and the //nolint:tparallel,paralleltest at :35 permanently serializes six subtests that each stand up a Postgres database."

Fix: delete the six reload/cleanup pairs, the :32-33 paragraph and the nolint, then add t.Parallel() to the parent and subtests. CRF-32 is the seventh pair, in roles_test.go, created by this same diff; treat them as one change. Razor checked the assertions do not go vacuous: every subtest that depends on floor-only members calls emptyDefaultRoles, so the no-op reloads leave nothing hanging.

🤖

coderd/rbac/roles_test.go:218

Nit [CRF-30] Hand-rolled hasResource loop where slices.ContainsFunc does the job, in a file that already uses that pattern. (Ging-Go)

Ging: "The PR rewrote this test body and kept the six-line closure. permissionGranted at coderd/rbac/roles_test.go:57 in the same file is the established pattern":

hasResource := func(perms []rbac.Permission, resource string) bool {
    return slices.ContainsFunc(perms, func(p rbac.Permission) bool {
        return p.ResourceType == resource && !p.Negate
    })
}

slices is already imported here. Keep the !p.Negate filter exactly as is: Chopper and Kite both verified it is load-bearing, because OrgMemberPermissions appends a negated ResourceWorkspace/ActionShare permission when ShareableWorkspaceOwners != Everyone, and without the filter the require.False would flip for any other org setting.

🤖

coderd/rbac/roles.go:1066

P4 [CRF-31] sort.Slice in Permissions, the function this PR now routes both OrgMemberPermissions and OrgServiceAccountPermissions through directly. (Ging-Go)

Ging: "slices.SortFunc (1.21) is the replacement; the sort package docs point at it ('more ergonomic and runs faster', no reflection-based swapper). Same instability semantics, so the sort result is unchanged. Notable only because this PR deleted \"slices\" from this file's imports (line 6 still imports sort), leaving the file on the older API for its one sort."

Outside the diff, so P4. Worth knowing the instability is deliberate downstream: Komugi notes ReconcileSystemRole compares with the set-based rbac.PermissionsEqual, precisely so unstable tie order among a resource's actions cannot make every replica rewrite the system-role row at startup.

🤖

coderd/rbac/rolestore/rolestore.go:71

Note [CRF-34] A stale name in default_org_member_roles degrades quietly rather than failing loudly, and that string is now the only grant path. (Meruem)

Meruem: "Expand silently drops roles that no longer resolve. If a future release renames or removes organization-workspace-access, orgs storing that name lose the grant with no error surfaced anywhere. That is the failure mode a string-keyed cross-version reference buys, and it is now the only mechanism granting workspace access."

Not this PR's to fix. The GA promotion is what makes it permanent, which is why it is on the record.

🤖

coderd/rbac/roles.go:221

Note [CRF-35] DefaultOrgMemberRoles() is applied only at org creation, so the deployment default and the per-org data diverge permanently. (Pariston)

Pariston: "enterprise/coderd/organizations.go:316 passes it on insert and migration 000516 backfilled it once. There is no reconciler that reapplies it. Any future addition to the deployment-wide default will need its own backfill migration to reach existing orgs."

This is the base design that shipped under the experiment, not something this PR introduces, and no change is requested. It is the durable cost of moving the elevation from code into per-org data, and the reason the next change to DefaultOrgMemberRoles() is a migration, not a constant edit.

🤖

🤖 This review was automatically generated with Coder Agents.