Repository navigation
docs: add workspace admin permissions and role changes to the Workspaces page - #414
Open
rachaelrenk wants to merge 10 commits into
Open
rachaelrenk wants to merge 10 commits into
rachaelrenk wants to merge 10 commits into
Conversation
Auto-drafted from warp-server spec workspace-admin-roles (PRODUCT.md only). Co-Authored-By: Oz <oz-agent@warp.dev>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
rachaelrenk
added a commit
that referenced
this pull request
Aug 25, 2026
… footguns (#619) * docs: request reviewers for real and lead ambient PRs with a feature summary Two fixes to the ambient new-feature docs pipeline (GROW-6093). 1. Actually request reviewers. The drafted PR only named reviewers in prose, which puts nothing in GitHub's review queue: docs #414, #415, #416 and #417 all named reviewers in the body and received zero reviews, three with an empty requested-reviewers list. Wire a required `gh pr edit --add-reviewer` step into missing_docs drift-watch step 7 and into the create_pr skill, with the `dannyneira` fallback that release-docs-update.yml already uses, plus a verification read-back so a silently skipped assignment is caught. The prose /cc mention stays. suggest_reviewers.py gains `--reviewers-only` so the step can consume the resolved set without scraping the human-readable table. 2. Lead the PR body with a feature summary. Drafting PRs must open with `## What this feature does`: plain language, what the feature does for the user, ending with the shipped-in version and date read from check_new_release.py --json. Budget 75 words. check_pr_body.py gains `--require-lead-section`, asserting the heading is present once, is the first heading, is non-empty, and is within budget. Co-Authored-By: Warp <agent@warp.dev> * docs: address review — per-reviewer requests, first-content check, CI wiring Blocking fix. The reviewer verification was emptiness-only, so the owning engineer could be dropped silently — the exact bug this PR exists to fix. `gh pr edit --add-reviewer a,b,c` is one atomic mutation, so a single unassignable entry rejected the whole list and the `||` then replaced every resolved owner with the fallback; a non-empty readback still passed. This is live: `warpdotdev/oss-maintainers` is the root-rule owner in the warp client repo and appears in most resolutions, but `/repos/warpdotdev/docs/teams` is empty, so it cannot be requested here. Now each reviewer is requested in its own call and the readback is compared against the resolved set, with partial results reported. Also fixed the readback jq: the old `[.reviewRequests[].login // .reviewRequests[].name]` silently drops teams from a mixed list (verified). Also: - check_lead_section now asserts the summary is the first *content*, not just the first heading. A body opening with unheaded spec/workflow/run-ID preamble previously exited 0, which is the shape the check exists to stop. - _iter_non_code_lines skips HTML comments, so a `##` inside a multi-line comment no longer displaces the lead section — same class already handled for code fences. - Wired test_check_new_release.py into CI. The earlier deferral was wrong: #586 does not touch ci.yml and this PR already edits it, while missing_docs/SKILL.md advertises the test as covered. - suggest_reviewers.py routes resolution diagnostics to stderr under --reviewers-only, so a fallback leaves a trace without polluting stdout. - Removed the duplicated reviewer snippet from missing_docs; create_pr holds the canonical copy. The copies had already diverged, and the missing_docs one used `[[ -z ... ]] && ...`, which returns 1 and would abort a `set -e` scheduled run. - Backticked the date in the worked example; marked the drafting-only lines in the copy-paste heredoc. - Tests locking in first-content, HTML-comment banners, multi-line comments, CRLF bodies, and the stderr diagnostics. Co-Authored-By: Warp <agent@warp.dev> * create_pr: stop the fallback reviewer from masking a dropped owner Review catch on #619. Step 4 appended FALLBACK_REVIEWER to GOT, but GOT answers "which resolved owners did I actually request". Counting the fallback there let the verification pass on a run where every real owner was rejected -- the exact silent failure the section exists to prevent, two paragraphs after it says "verify against the resolved set, not against emptiness". Traced against the documented snippet with a stubbed gh. Resolved owners alice and bob, both rejected, fallback accepted: before: warning: requested 1/2 resolved reviewers Requested reviewers: dannyneira exit 0 after: ERROR: none of the 2 resolved owners could be requested (wanted: alice bob); only the fallback is assigned. exit 1 The fallback now stays out of GOT, and the outcomes are reported as four distinct states rather than one count: all owners requested, a partial result naming who is missing, owners resolved but none requested (an error, because the PR has the wrong reviewer), and nothing resolved at all (a note, because the fallback is the intended pall there). Not even the fallback landing remains a hard failure. Verified by extracting the snippet from SKILL.md and executing it against a stubbed gh across all five cases, so the documented text is what was tested rather than a paraphrase of it. Co-Authored-By: Warp <agent@warp.dev> * create_pr: trust the read-back, and fix comment/fence ordering Two review catches on #619. 1. Reviewer verification trusted gh's exit status The section warns that `gh pr edit` can exit 0 while quietly skipping a reviewer, then verified against GOT -- which is built from those exit statuses. A silently skipped owner passed. Verification now compares the read-back against WANT. Step 4's fallback also keys off the read-back rather than GOT, because when gh exits 0 for every owner and requests none of them, a GOT-based check skips the fallback entirely and leaves the PR with no reviewer at all. Match on the last path segment, lowercased: a team resolves as org/team but reads back as its bare slug, so a naive compare reported every team as missing. Verified by extracting the snippet from SKILL.md and running it against a stubbed gh across nine cases, including a stub that exits 0 without recording the reviewer: bob silently skipped -> warning names bob (previously silent) all silently skipped -> fall all silently skipped -> fall all silently skipped -> fall es its bare slug, no false "missing" 2. Fence detection ran before comment stripping A ``` line inside an HTML comment opened a phantom code block that ate the closing --> and every line after it, including the lead heading. A valid body failed with "missing required lead section", which reads as an authoring mistake rather than a parser bug. Precisely: only an *odd* number of fence lines inside a comment breaks it. A balanced pair opens and closes a phantom block that happens to end before the -->, so it passed by luck. The tests say which case is the real regression rather than implying all of them were. The fix honors fence state first, then strips comments, then looks for a fence in the visible text. Simply reordering the two would break the mirror case:mirror case:mirror case:mirror case:mirror case:mirror case:mirror cs a comment would swallow tmirror case:mirror case:mirror cver both directions plus a guard tmirror case:mirror case:mirror case:mirror case:mirror case:mirror case:mirror cs a comment would swallow tmirror caseent@warp.dev> * create_pr: verify the fallback reviewer by name, not by read-back emptiness Review catch on #619 (QUALITY-1875 rework). When owner resolution came back empty and the PR already carried an unrelated reviewer, the prior "is $REQUESTED non-empty" check treated that unrelated reviewer as proof the dannyneira fallback had landed, so it skipped verifying/re-requesting the fallback by name -- and the script still printed "fallback requested" and exited 0 even when dannyneira was never assigned. Added a has_reviewer helper that checks the read-back for a specific reviewer, used it to gate the fallback request/verification when resolution was empty, and split the final error check so a fallback that truly can't be assigned is reported as a failure instead of masked by an unrelated reviewer already on the PR. Added test_request_reviewers.py, which extracts the documented snippet from SKILL.md and runs it against a stubbed gh/suggest_reviewers.py across the normal-resolution, empty-resolution, and pre-existing-unrelated-reviewer cases. test_unrelated_reviewer_does_not_mask_fallback_failure fails against the pre-fix snippet and passes after the fix. Wired into ci.yml. Co-Authored-By: Warp <agent@warp.dev> * missing_docs: fix the three sandbox footguns validation run #2 hit The second drift-watch validation run surfaced three ways the skill misleads an unattended agent. All three are documentation gaps in the skill, not code bugs. 1. Working directory. Every path in the skill is relative to the docs repo root, but the skill never says so, and a sandbox commonly starts one level up. The failure mode is the problem: python3 exits 2 with "can't open file", which is the same exit code audit_docs.py uses to fail loud on a broken environment. An agent that reads the code and not the message concludes a sanity guard tripped and stops. State the cwd requirement up front, name the collision, and repeat it at the release-gate step and in the scheduled-agent prompt -- the prompt is the only one of the three a cron run is guaranteed to read. 2. npm install. `npm run build` is the only validation this repo has and it needs node_modules, which a fresh sandbox does not have. Add `npm ci` as a stated precondition in Requirements and at both build sites. 3. Surface-map key edits. A rename sweep run across feature_surface_map.md corrupted an corrupted an corrupted an corrupted an corrupted an corrupted aon corrupted an corrupted an corrupted an corrupted an corrupted an map entry is a literal code identifier that only matches because it matches ex because it matches ex because it matches ex beCo-Authored-By: Warp <agent@warp.dev> --------- Co-authored-by: Warp <agent@warp.dev> Co-authored-by: warp-agent-staging[bot] <240773466+warp-agent-staging[bot]@users.noreply.github.com>
rachaelrenk
marked this pull request as ready for review
October 8, 2026 14:10
Contributor
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
![warp-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR adds a new workspace admin roles documentation page and sidebar entry. The draft is not ready to publish because it still contains reviewer TODOs, unverified availability claims, deprecated platform terminology, and a security-sensitive run-visibility claim that is not tracked through the docs verification contract.
Concerns
- Public docs content and
src/sidebar.tscontain unresolved TODO placeholders that need to be resolved or removed before merge. - The page presents follow-up or unverified functionality as part of the current workspace admin capability set.
- The new page uses deprecated Oz-run terminology instead of the current cloud agent run terminology and variable system.
- The PR body is missing the expected
## Documentation riskand## Unverified claimssections for an agent-authored feature-doc PR, even though the draft contains verification-sensitive claims.
Verdict
Found: 0 critical, 5 important, 0 suggestions
Request changes
Comment /warp-agent-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
Replace the standalone workspace-admin-roles page with verified content on the existing Workspaces page, which already covers workspace roles, teams, invitations, and spend limits. - Add Workspace admin permissions, Changing workspace roles, and Cloud agent run visibility sections to workspaces.mdx - Remove the standalone page and its sidebar entry - Drop claims that could not be verified against warp-server Co-Authored-By: Warp <agent@warp.dev>
rachaelrenk
changed the title
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Review summary
The independent agent completed its review for this commit.
Findings
src/content/docs/enterprise/team-management/workspaces.mdx:81— [IMPORTANT] The sentences "Runs owned by an individual user rather than a team stay private to that user. Neither team admins nor workspace admins can see them." and (line 79) "They can see what a member of the owning team sees, such as the prompt, logs, and artifacts" state security and privacy guarantees as fact, but the PR body says the user-owned exclusion is inferred and needs source-owner sign-off, and the prompt/logs/artifacts scope is not listed in Unverified claims. Requested change: wrap these sentences in VERIFY markers and list them in the PR body's Unverified claims section, or obtain source-owner sign-off and record it in the PR body before merge.src/content/docs/enterprise/team-management/workspaces.mdx:48— [SUGGESTION] "The previous owner becomes an Admin on plans that support multiple admins, and a Member on other plans" never names the plans, so the reader cannot tell which outcome applies. Requested change: name the plans or link to the page that lists them; if neither is possible, remove the plan split.src/content/docs/enterprise/team-management/workspaces.mdx:39— [SUGGESTION] "Manage teams - Create teams and manage the membership and settings of any team" repeats line 59 ("Workspace admins can also manage every team's membership and settings") and line 26. Requested change: keep the statement in one place, for example remove line 59 or point this bullet to the "Teams inside a workspace" section.src/content/docs/enterprise/team-management/workspaces.mdx:37— [SUGGESTION] "Removing a member also removes them from every team in the workspace" (and line 33's "Team admins who aren't workspace admins keep admin permissions only on their own team") are technical claims with no source tie-in in Unverified claims. Requested change: confirm them against workspace_membership.go and authz/engine.go, or add them to the Unverified claims list for the engineering reviewer.
Verdict
Request changes
- Point the "Manage teams" bullet at Teams inside a workspace instead of repeating the team-management statement - Drop the unnamed plan split for ownership transfer; the previous owner becomes an Admin on every workspace this page covers - Describe run visibility as the same access as a team member, removing the unverified list of what a run exposes Co-Authored-By: Warp <agent@warp.dev>
Contributor
There was a problem hiding this comment.
Review summary
The independent agent completed its review for this commit.
Findings
src/content/docs/enterprise/team-management/workspaces.mdx:47— [IMPORTANT] The claims that role changes never alter team roles, that a demoted admin loses access immediately, that admins can't remove the owner or change the owner's role, and that only the owner transfers ownership appear in neither## Verified from sourcenor## Unverified claims, and the only cited file for this section (memberActions.ts) is client code. Requested change: cite the server-side authorization code for each claim, or add a{/* VERIFY: ... */}marker and list it under## Unverified claims.src/content/docs/enterprise/team-management/workspaces.mdx:48— [SUGGESTION] "The previous owner becomes an Admin" is inferred from tier configuration, not the transfer logic, andteams.mdxdescribes team ownership transfer differently. Requested change: cite the workspace ownership-transfer handler or mark the claim with a VERIFY marker.src/content/docs/enterprise/team-management/workspaces.mdx:33— [SUGGESTION] The new admin-permissions paragraph and the Admin and Owner role bullets above restate each other and the "Only the owner transfers ownership" bullet. Requested change: say each fact once by trimming the role bullets or the overlap here.src/content/docs/enterprise/team-management/workspaces.mdx:81— [SUGGESTION] "Stay private to that user" and "Neither team admins nor workspace admins can see them" are absolute privacy claims that conflict with the session-sharing links documented inviewing-cloud-agent-runs.mdx. Requested change: qualify with "unless the owner shares the session", or confirm with engineering and add a VERIFY marker.
Verdict
Request changes
Contributor
There was a problem hiding this comment.
Review summary
The independent agent completed its review for this commit.
Findings
src/content/docs/enterprise/team-management/workspaces.mdx:41— [SUGGESTION] The "Workspace admin permissions" list (lines 35-41) mostly restates line 26 (Admin role) and line 59 (admins manage every team), and the bullets at lines 39-41 are link-only pointers. Requested change: fold the one new fact (line 33) into the Admin bullet at line 26, keep only bullets that add information (members and invitations), and drop the link-only bullets.src/content/docs/enterprise/team-management/workspaces.mdx:41— [SUGGESTION] "cloud agent runs" is a literal here, while line 79 uses{VARS.PLATFORM_RUN}. Requested change: use{VARS.PLATFORM_RUN}sat line 41, or remove the variable and the import at line 9 if the bullet is removed.src/content/docs/enterprise/team-management/workspaces.mdx:50— [SUGGESTION] The PR body's "Unverified claims" lists the Members page and three-dots menu (line 45) and "Members of Enterprise workspaces can't remove themselves" (this line) as unconfirmed, but neither has a VERIFY marker, so both ship as fact. Requested change: add a VERIFY marker for each (the body already lists them) or resolve with engineering before merge, and say "leave a workspace" explicitly so it doesn't read as contradicting enterprise/team-management/teams.mdx line 61 (members can leave a team).src/content/docs/enterprise/team-management/workspaces.mdx:49— [SUGGESTION] Several claims are in neither "Verified from source" nor "Unverified claims": admins can promote, demote, and remove other admins (line 37), invite link and approved-domain controls (line 38), a demoted admin keeps team admin roles (line 47), and admins can't remove the owner or change the owner's role (this line). I could not open warp-server from this run. Requested change: add a per-claim source mapping to the PR body so the engineering reviewer can confirm each claim.src/content/docs/enterprise/team-management/workspaces.mdx:45— [SUGGESTION] "Changing workspace roles" is a procedure placed between the conceptual role sections and the other conceptual sections, against the conceptual-then-reference-then-procedures ordering in AGENTS.md, and the Admin Panel is not oriented on its first mention. Requested change: move the section after "Cloud agent run visibility" and before "Workspace settings and team settings", and name where the Admin Panel lives (the Warp app) at first mention.src/content/docs/enterprise/team-management/workspaces.mdx:81— [SUGGESTION] The first two sentences at line 79 repeat each other, and line 81 makes a strong privacy claim ("Neither team admins nor workspace admins can see them") that the cited integration test does not cover (it covers an admin seeing a team run and a non-member not seeing it). Requested change: merge the two sentences at line 79, and either cite coverage for the user-owned and team-admin cases in the PR body or add a VERIFY marker until engineering confirms.
Verdict
Approve
warp-agent-staging
Bot
added
the
factory:docs-factory
Contributor
|
This PR was generated with Warp. Comment    Test changesNo affected Factories to test. |
Contributor
There was a problem hiding this comment.
Review summary
The independent agent completed its review for this commit.
Findings
src/content/docs/enterprise/team-management/workspaces.mdx:45— [SUGGESTION] The Members page path and "three-dots menu" label are listed as unverified in the PR body (derived fromwarp-serverclient source, not the live app), andadmin-panel.mdxdoesn't mention a Members page. Requested change: confirm the labels in the live Admin Panel, or add a{/* VERIFY: ... */}marker here and list it under## Unverified claims.src/content/docs/enterprise/team-management/workspaces.mdx:49— [SUGGESTION] "Members of Enterprise workspaces can't remove themselves. An admin removes them." is stated as fact, but the PR body says it is inferred fromauthorizeWorkspaceRemovaland needs engineering confirmation, including a possible admin-forced exception. Requested change: confirm it with engineering before merge, or add a{/* VERIFY: ... */}marker on this line and list it under## Unverified claims.
Verdict
Approve with nits
Co-Authored-By: Oz <oz-agent@warp.dev>
Contributor
There was a problem hiding this comment.
Review summary
The independent agent completed its review for this commit.
Findings
src/content/docs/enterprise/team-management/workspaces.mdx:26— [SUGGESTION] The new Admin bullet says the same thing twice ("every team, including teams they don't belong to" and "admin-level permissions on every team"). Requested change: cut the repeated clause and keep only the contrast, e.g. "Team admins who aren't workspace admins have admin permissions only on their own teams."src/content/docs/enterprise/team-management/workspaces.mdx:33— [SUGGESTION] "Workspace admins can:" reads as a complete list but covers only members and invitations, and cross-team access is already stated in the Admin role bullet and at line 45 ("Workspace admins can also manage every team's membership and settings"). Requested change: retitle the section (e.g. "Managing members and invitations") or fold the two bullets into Workspace roles, and drop the duplicated sentence.src/content/docs/enterprise/team-management/workspaces.mdx:67— [SUGGESTION] "Other members can access their own runs and runs owned by their teams" is unclear because "other members" overlaps with the owner sentence before it. Requested change: rewrite as "Members can access runs they own and runs owned by their teams." and keep the sharing caveat as a separate sentence.src/content/docs/enterprise/team-management/workspaces.mdx:71— [SUGGESTION] The "Changing workspace roles" section opens with one sentence covering four actions (promote, demote, remove, transfer), has no steps or expected outcome, and its bullets are rules rather than steps. Requested change: either use numbered steps for one role change with the expected result, or retitle the section for the rules (e.g. "Role change behavior") and keep one orienting sentence for the Admin Panel path.src/content/docs/enterprise/team-management/workspaces.mdx:73— [SUGGESTION] "Roles are additive" misdescribes the behavior, since workspace and team roles are independent rather than cumulative. Requested change: use "Workspace and team roles are independent - Changing a workspace role never changes a member's team roles...".
Verdict
Approve
Contributor
There was a problem hiding this comment.
Review summary
The independent agent completed its review for this commit.
Findings
src/content/docs/enterprise/team-management/workspaces.mdx:67— [IMPORTANT] The required independent check of the added authorization/privacy claims could not be completed: the cited warp-server revision b3041e6fb3b8330ab9a3e3ff200da8a4232f3da1 was inaccessible (API 404; Git authentication unavailable). Requested resolution: provide source access or review-accessible revision-pinned excerpts of aiTaskPolicies, TeamAdmins.Includes, run-visibility tests, membership handlers, and Members UI, then rerun the source review. This is a verification gap, not a demonstrated factual error or a pending-human-approval violation.src/content/docs/enterprise/team-management/workspaces.mdx:26— [SUGGESTION] The Admin bullet repeats its scope in "every team, including teams they don't belong to" and "admin-level permissions on every team." Requested resolution: combine those clauses and preserve the contrast with team admins.src/content/docs/enterprise/team-management/workspaces.mdx:71— [SUGGESTION] "Changing workspace roles" gives a generic menu instruction for four actions without a selected action or confirmation outcome. Requested resolution: add a short numbered promotion/demotion procedure with exact action labels and the resulting role; retain the role consequences and owner constraints below it.
Verdict
Request changes
tylerlam-warp
approved these changes
Oct 18, 2026
Contributor
|
@tylerlam-warp, your Warp account is not a member of any team with access to this repository. |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this feature does
Workspace admins can manage members, invitations, teams, billing, and cloud agent runs across every team in an Enterprise workspace, while only the owner transfers ownership. Role changes never alter team roles. Available in the current stable release,
v0.2026.09.30.08.29.stable_01(2026-09-30).Summary
This PR started as an auto-drafted standalone page for the
workspace-admin-rolesspec. Since it opened,enterprise/team-management/workspaces.mdxmerged (#723) and already covers workspace roles, teams, invitations, settings enforcement, and spend limits, so a second page would have duplicated it and used different role labels.The final diff adds only the content that page was missing, checked against
warp-serverdevelop.warpdotdev/warp-server→specs/workspace-admin-roles/PRODUCT.mdChanges
src/content/docs/enterprise/team-management/workspaces.mdx{VARS.PLATFORM_RUN}.Dropped from the original draft
warp-serverorwarp-internal.Content design plan
Audience and JTBD: An Enterprise workspace owner or admin deciding which colleagues to make admins, who needs to know what an admin can do, what stays with the owner, and what a role change affects.
Problem:
workspaces.mdxlists the three roles but doesn't say what admin permissions cover, how role changes interact with team roles, what only the owner can do, or who can see cloud agent runs.Goals:
Purpose and value: Admins currently have to infer these rules from the product or ask support. The content belongs on the existing Workspaces page, so the PR updates it instead of adding a page.
Content type: Feature documentation (combined) — conceptual permissions content plus a short role-change procedure on an existing page.
Skill and template:
draft_feature_doc/.agents/templates/feature-doc.mdHigh-impact scenarios:
Unverified claims
Workspace spend limits
This is a pre-existing VERIFY marker from docs: document Warp's native workspaces model #723. This PR does not change it.
Verified from source
These claims were checked against
warp-serverdevelopatb3041e6fb3b8330ab9a3e3ff200da8a4232f3da1, including the review's security-sensitive run-visibility claims.TeamAdmins.Includesinauthz/types/subject_set.go.workspacePolicies,getWorkspaceMemberActions,removeUserFromWorkspaceTeamMemberships,logic/workspace_invites.go, andlogic/workspace_invite_links.go.workspace_memberships, so team roles remain unchanged. The owner role cannot be changed through the role mutation, and only the owner passesauthorizeWorkspaceOwnershipTransfer. SeeapplyWorkspaceMemberRole,validateTargetWorkspaceMember, andauthorizeWorkspaceOwnershipTransferinlogic/workspace_membership.go, plusset_workspace_member_role_test.goandtransfer_workspace_ownership_test.go.WorkspaceMembersSettings.tsxandmemberActions.ts.authorizeWorkspaceRemovalblocks self-removal for Enterprise workspaces while allowing an authorized admin to remove another member. Seelogic/workspace_memberships.go.aiTaskPoliciesinauthz/engine.go,authz/ai_task_workspace_admin_test.go, andtest/integration/workspace_admin_run_visibility_test.go.applyWorkspaceMemberRoledemotes the previous owner according toMultiAdminPolicy; paid and Enterprise tiers enable multi-admin through_base_self_serve_plan.yaml.transfer_workspace_ownership_test.gocovers the previous owner becoming Admin when multi-admin is enabled.Documentation risk
Risk: engineering-review-required
Rationale: Describes workspace admin permissions, role-change rules, Enterprise-only behavior, and cloud agent run visibility (a security and privacy claim).
Source revision:
warpdotdev/warp-server@b3041e6fb3Source files consulted:
authz/engine.go,authz/types/subject_set.go,authz/agent_platform_policies.go,logic/workspace_membership.go,logic/workspace_memberships.go,logic/workspace_invites.go,logic/workspace_invite_links.go,billing/config/tiers/_base_self_serve_plan.yaml,billing/config/tiers/_base_enterprise.yaml,config/prod.yaml,test/integration/set_workspace_member_role_test.go,test/integration/transfer_workspace_ownership_test.go,test/integration/workspace_admin_run_visibility_test.go,authz/ai_task_workspace_admin_test.go,client/src/components/admin/memberActions.ts, andclient/src/components/admin/workspace/WorkspaceMembersSettings.tsx.Engineering review status: pending
Docs override: none
Validation
style_lint.py --changedcompleted with two pre-existing glossary suggestions for Membership and Teams; it reported no warnings on lines added by this PR.check_links.py --internal-onlypassed: 0 broken links across 4,378 internal links.git diff --checkchecks passed.npm run typecheck,npm run test:heading-vars,npm run build,npm run test:heading-tocs, andnpm run test:homepage-json-ldpassed. Typecheck reported 0 errors and 0 warnings; the generated TOC check validated 3,368 entries.trunk checkwas unavailable because the Trunk CLI is not installed in this environment.Originally auto-drafted by Oz. Conversation: https://app.warp.dev/conversation/7abbf494-93ec-4cf3-b692-738012aea1f5
Co-Authored-By: Warp agent@warp.dev