[warp-agent-staging]

What this feature does

Factory integration permissions let IT and security teams review access before installing an app. This draft adds permission tables for GitHub, GitLab, Linear, Jira, Slack, and Microsoft Teams, plus a linked landing page. It distinguishes verified source declarations from production app-console gaps. This is a documentation prototype for existing integrations, not a new product release; no shared shipped-in version is asserted.

Summary

Implements the requested permissions pass and Trevor's enterprise-review feedback from the request thread. Direct registration, Marketplace, provisioning, and authorization-source checks now establish GitHub and Jira inventories, GitLab service-account access, and Slack factory-bot/setup-user grants. Only production GitLab OAuth completeness, Linear scopes and actor, Slack manager-bot scopes, and the previously listed Teams gaps remain unconfirmed.

Changes

• Add scope, granted-access, function, and boundary tables to the six factory integration pages. GitHub now enumerates all 13 live registered permissions and levels; Jira now links its Marketplace-declared inventory and explains its permission-inspection scope.
• Add factories/integrations/permissions.mdx and a sidebar entry. The landing page links to each inventory and separates provider grants, account roles, and automation filters.
• Correct Slack's message-level privacy claim: joined-conversation history access and integration tools are broader than mention-based triggers.
• Clarify GitLab selected-project membership versus project filters, and distinguish human OAuth revocation from service-account retirement.
• Correct Teams after engineering review: enumerate the bundled manifest's legacy permissions, team bot context, and two application RSC grants. Distinguish team consent from tenant-wide Entra grants and mention-based routing. Keep ZIP provenance in review evidence rather than public permission prose.
• No product code, app configuration, or dependency files changed.

Content design plan

Audience and JTBD: An IT or security reviewer approving an enterprise factory pilot before an employee reaches an app's installation consent screen.

Problem: Existing integration pages describe capabilities and setup but don't enumerate grants or provide one shareable access-review entry point.

Goals:

• Identify each integration's credential model, supported scope evidence, and approval gaps.
• Distinguish granted access from runtime actions and routing filters.
• Find provider-specific scope and withdrawal details from one page.

Purpose and value: The new reference is a cross-provider index, not a duplicate scope inventory. Each existing integration page owns its detailed table and retains its setup flow.

Content type: Reference for the new landing page; reference sections within the existing combined integration pages.

Skill and template: draft_reference / .agents/templates/reference.md, with draft_docs update guidance.

High-impact scenarios:

• Covers: six requested factory integrations, pre-installation review, differences between identity linking and app access, and explicit app-console unknowns.
• Excludes: standalone integration redesign, custom MCP credential inventories, self-hosting changes, guessed Graph permission IDs, and an invented production inventory.

Existing-page update plan: Add permission lookup sections for the same security-review reader; preserve connection, trigger, tool, and troubleshooting tasks. The central page owns shared grants-versus-filters explanation; integration pages retain provider-specific caveats.

Unverified claims

VERIFY is a hidden authoring-evidence marker required by docs policy, not a runtime permission. Each bullet exactly reproduces a remaining marker. All are in the provider’s Permissions section.

• Confirm whether the production GitLab OAuth authorization requests scopes beyond the required api and read_user; the persisted provider scope list and authorization parameters are not available in this checkout.
  gitlab.mdx: Required OAuth scopes and service-account scopes/roles are verified. Confirm only whether the persisted production provider or authorization override adds OAuth scopes; supply its non-secret scope list and authorize parameters.
• Confirm the production Linear OAuth scope list and actor parameter from the persisted provider record or a live authorization URL; the public directory listing exposes neither, and Warp login blocks the connection flow.
  linear.mdx: The public Linear directory listing has no authorization URL. The production connection route requires Warp login. Supply the persisted production scope list and actor parameter, or a live authorization URL without credentials.
• Confirm the production Slack workspace manager app's bot scope list from its registration or persisted base provider; factory bot scopes and manager user scopes are independently established.
  slack.mdx: The 21 generated/requested factory bot scopes and three requested manager-user scopes are verified. Supply only the separate production base manager bot scope list.
• Confirm the deployed Teams app requests the permissions below, and compare its installed resource-specific consent and any additional Entra delegated or application permissions with tenant grants.
  teams.mdx: Unchanged from the accepted Teams revision: deployed package, additional Entra grants, and installed resource-specific consent remain unconfirmed.

Documentation risk

Risk: engineering-review-required
Rationale: Adds permission and security claims. GitHub registration and Jira Marketplace inventory are verified; four precisely scoped authoring markers remain. Four page-length exceptions are justified in Verification below.
Source files consulted: warp-server@1084f366e3a599bbe6189fe454f1a12d8cbf1866: slack/slack_app.go, slack/oauth/slack_oauth.go, forge-jira/manifest.yml, logic/local_integrations/providers.go, logic/codeforge/gitlab/client.go, logic/gitlab_service_accounts.go, oauth/azure.go, logic/integration_setup_microsoft_teams.go, client/packages/shared/src/assets/microsoft-teams/warp-microsoft-teams-app.zip (manifest.json), client/packages/shared/src/utils/microsoft-teams-app-package.ts
Requested engineering reviewers: none; ownership resolution is ambiguous
Engineering review status: pending
Docs override: none

Ownership resolution returned bnavetta, captainsafia, and ianhodge for Slack, and no match for the other sampled source files. Per docs policy, no reviewer is requested without one unequivocal owner. The requester's Slack identity is not mapped to a GitHub login.

Source evidence and maintenance note

Declared global permissions and customer-specific effective consent are different evidence. Source revision alone is not proof of installed consent:

Integration	Evidence (source at warp-server 1084f366e3a599bbe6189fe454f1a12d8cbf1866; live checks dated below)
Slack	slack/slack_app.go:30–54 declares 21 bot scopes; slack/slack_provision.go:504,641 passes exactly that list to both manifest creation and managed installation. slack/slack_manager_oauth.go:238,330 requests the three slack/oauth/slack_oauth.go:26–30 user scopes. The manager bot grant loads a separate persisted base provider and is not inferred from child scopes.
Jira	Public Marketplace Privacy & Security, app 2476990014, checked 2026-10-29, lists six integration permissions matching forge-jira/manifest.yml:143–162. forge-jira/scripts/target.sh and deploy.sh select production app IDs without substituting scopes. jira/jiraclient/permissions.go:65,162–271 uses read:permission:jira for bulk project/issue permission checks before app-authenticated writes; the read scopes declare offline impersonation. A deploy does not upgrade every installed site.
Linear	logic/local_integrations/providers.go:48–55,372–397 declares six scopes and actor=app in development configuration only. The public OAuth and agents references establish meanings, not the production list.
GitLab	logic/codeforge/gitlab/client.go:42–45 declares required scopes; actual OAuth requests load persisted provider configuration. logic/gitlab_service_accounts.go:688–702, logic/codeforge/gitlab/factory_client.go:135–148, logic/codeforge/gitlab/factory_service_accounts.go:243+, and logic/codeforge/gitlab/runtime_authority.go:167–179 establish provisioning scopes, roles, and date-granular expiry.
Teams	oauth/azure.go:43–50 and logic/integration_setup_microsoft_teams.go:174–177 establish identity-linking scopes. manifest.json inside client/packages/shared/src/assets/microsoft-teams/warp-microsoft-teams-app.zip declares identity, messageTeamMembers, bot scope team, and application RSC grants ChannelMessage.Read.Group and ChannelSettings.Read.Group. client/packages/shared/src/utils/microsoft-teams-app-package.ts downloads that bundled archive unchanged. Deployed package, any additional Entra API permissions, and tenant consent remain unverified.
GitHub	Read-only GET /apps/warp-factories, checked 2026-10-29: app ID 2278701, registration updated 2026-10-14T20:26:17Z. Exact write permissions: actions, checks, contents, issues, pull_requests, workflows. Exact read permissions: administration, emails, members, metadata, security_events, statuses, vulnerability_alerts. These are registration metadata, not an inventory inferred from runtime calls. Browser public identity corroborates the app; installation consent requires GitHub sign-in. Account emails requires user authorization and is not an installation-token grant.

The server-rollout helper found relevant Slack, GitLab, and Jira paths enabled in production; this does not establish live consent. Teams availability remains conditional as in the existing page. No integration availability was expanded. A stable client release does not establish these server/app registration inventories.

The remaining non-secret production-provider fields are requested below; no inspection of every customer installation is required to document declared grants. Administrators still review installation-specific resource selection and consent when approving their own access. No new synchronization service or automated process is proposed.

Following moirahuang's manifest review, the Teams revision uses the same manifest already present at the original source revision above. Its declarations are unchanged in the current source checkout. Microsoft documents team-scoped application RSC, receipt of unmentioned channel messages, separate Entra permissions, and the deprecated manifest permissions field. These establish permission semantics, not installed production consent.

Supplied staging configuration snapshot (2026-10-29T23:10:42Z)

An outside collaborator supplied findings from a successful read-only query of staging warp_db.oauth_provider at 2026-10-29T23:10:42Z, limited to non-secret fields. This is the collaborator's query report, not a database observation performed by this implementation run. It verifies staging configuration only as of that timestamp.

• All three base provider records (gitlab, linear, and slack) were active with pkce_required=true.
• GitLab stored scopes: api, read_user. No stored authorize_params keys or metadata scope override were reported.
• Linear stored scopes: read, app:assignable, app:mentionable, issues:create, comments:create, write. metadata.authorize_params.actor=app; actor was the only stored authorization-parameter key, with no scope override.
• Slack base workspace-manager provider (slack, not a per-factory slack-UUID) stored 18 bot scopes: app_mentions:read, channels:history, channels:read, chat:write, files:read, files:write, groups:history, groups:read, im:history, im:read, mpim:history, mpim:read, reactions:read, reactions:write, users:read, users:read.email, app_configurations:read, app_configurations:write. No stored authorize_params keys or metadata scope/user_scope override were reported.
• The collaborator's source inspection reports that the manager flow passes stored bot scopes unchanged and does not merge local DefaultSlackBotScopes. Separate code-confirmed user scopes are app_configurations:read, app_configurations:write, and managed_apps:install; these are not additional bot scopes inferred from the database. Supplied references: slack/slack_manager_oauth.go:206,237–252, slack/oauth/slack_oauth.go:25–30, and oauth/provider.go:86–120.

Production was not queried, and equality with production remains unknown. This snapshot does not establish installed grants or customer consent; the three production-provider gaps and their VERIFY markers remain unconfirmed and unchanged. No customer data, credentials, or raw logs were supplied.

Verification

• npm ci: completed; existing engine/patch-version warnings and six audit vulnerabilities reported. No lockfile or dependency changes.

• npm run typecheck: passed, zero errors and warnings, seven hints.

• npm run test:heading-vars: passed, five tests.

• npm run build: passed, 402 pages; existing Astro deprecation, chunk-size, empty i18n, and /404 warnings.

• npm run test:heading-tocs: passed, 3,403 entries across 402 HTML files.

• npm run test:homepage-json-ld: passed.

• Initial internal-link check: passed, 4,520 links across 401 content files. Current commands and results are recorded in the five-provider revision below.

• Initial external-link check: passed, 15 occurrences / 12 unique URLs. The initial system-Python attempt lacked requests; only the rerun in the temporary virtual environment performed real HTTP checks.

• python3 .agents/skills/style_lint/style_lint.py --changed --output /tmp/permissions-style.json: scanned seven pages, 29 pre-existing warnings; none on added lines. They concern existing bold UI labels, Microsoft Teams proper-name headings, and an existing quoted UI string.

• python3 .agents/skills/validate_ui_refs/validate_ui_refs.py --changed --output /tmp/permissions-ui-refs.json: passed, zero findings.

• check_compression_contract.py FILE --content-type TYPE: central reference, Linear, and Jira passed. Four expanded combined pages exceed 1,500 words: GitHub 1,762; GitLab 1,585; Slack 1,981; Teams 1,936 after the copy revision.

• Compression exception: after a deletion-only pass, preserve existing setup/troubleshooting tasks and requested provider-specific scope/access/boundary details. Slack's 24 source-defined scope rows are useful lookup material, not framing to remove. Splitting these tables into new provider pages would fragment the requested integration-page inventory; broader page restructuring is out of scope. No callout-count findings.

• Initial full-diff self-review and git diff --check: passed. That draft added six policy-required VERIFY markers; four remain after the five-provider revision below. No explanatory code comments added.

• trunk check / trunk fmt: unavailable; Trunk is not installed.

• Chromium on Linux, built static pages: inspected the new reference plus Slack and Teams permissions. Tables and all columns rendered without clipping or overlap; warning, navigation, and anchors inspected. Static-server Vercel analytics script 404s do not affect content.

• PR-body integrity: the full-body repetition guard flags identical screenshot alt text and captions in the required managed artifact block. That block is preserved verbatim; the same guard passes on the authored narrative with only the managed block excluded. The full PR-contract/VERIFY checker passes.

Teams review revision

• Re-ran npm ci, npm run typecheck, npm run test:heading-vars, npm run build, npm run test:heading-tocs, and npm run test:homepage-json-ld: passed with the same existing warnings/hints and counts above.
• Re-ran style lint, internal links, external links in /tmp/teams-links-venv, UI-reference validation, and git diff --check: same results as above. All three Microsoft links in the revised section returned HTTP 200; the manifest reference's permissions anchor exists.
• Re-ran compression for Teams and the central reference: reference passed; Teams retains the justified combined-page exception above. The deletion-only pass preserves the requested exact inventory and the existing setup tasks.
• Chromium on Linux: inspected the revised Teams inventory, RSC boundary prose, central status, and caution. All columns and changed text are readable without clipping or overlap.
• Revision self-review: only two content files changed. The sole added comment is the replacement policy-required Teams VERIFY marker reproduced above. No product code or verification artifacts are committed.

Reader-facing Teams copy revision

• Removed the permission-section ZIP provenance and changed the central Teams row to declared app permissions and deployed-app consent wording. The permission inventory and access boundaries are unchanged; the setup download filename still identifies the file admins upload.
• npm run build, npm run test:heading-tocs, internal-link validation, and git diff --check: passed with the same counts above. Style lint retains the same 29 existing findings. The central compression check passes; Teams retains the documented length exception. PR-contract/VERIFY accounting was rechecked.
• Chromium on Linux: the revised introduction and central row are readable without clipping or overlap. External-link and UI-reference inputs are unchanged; prior checks remain applicable. No authentication, workflow, or product behavior changed.

Five-provider verification revision (2026-10-29)

• Checked GitHub's public registration API and browser app/install pages, Linear's public directory, production Warp OAuth connection routes, Slack app administration, Atlassian developer console, and public Marketplace Privacy & Security. No installations, approvals, authorizations, grant changes, or credential changes were performed.
• The Jira Marketplace list matches all six manifest grants: external app access, external user access, user information, issue/project read access, permission inspection, and issue write access. Its permissions list corroborates declared grants, not every site's installed version or offline-impersonation deployment status.
• Additional source paths above are unchanged between the original source revision and current 1b4f476906356072228205e31b41d74fe15decf5. The production rollout check permits the Jira permission-check and managed Slack paths; no new availability claims were added.
• Remaining access blocker: /oauth/connect/gitlab, /oauth/connect/linear, and /oauth/connect/slack redirect to Warp login. Slack app registration requires Slack sign-in; Atlassian console requires Atlassian sign-in. Linear's directory has no install/authorize link. The generic OAuth builder uses persisted provider scopes and optional authorization parameters, so local defaults cannot establish production request completeness.
• Read the current admin-curl skill and auth implementation. No Go, gcloud, or Forge executable is installed; no configured admin bearer, ADC environment file, default ADC file, or gcloud credential database is present. Metadata identity discovery failed DNS. Linux has no adminclient keychain backend, so the remaining path would initiate interactive OAuth; it was not started. Requested only credential-free GitLab requested scopes/parameters, Linear scopes/actor, and Slack manager bot scopes. No customer exports or secrets are needed.
• Re-ran the documented sequence npm run typecheck && npm run test:heading-vars && npm run build && npm run test:heading-tocs && npm run test:homepage-json-ld: passed; zero type errors, seven existing hints, five heading tests, 402 generated pages, 3,403 TOC entries. Build warnings unchanged.
• python3 .agents/skills/check_for_broken_links/check_links.py --internal-only --output /tmp/permissions-revision-internal-links.json: passed, 4,520 links. /tmp/teams-links-venv/bin/python .agents/skills/check_for_broken_links/check_links.py --external-only --docs-root src/content/docs/factories/integrations --output /tmp/permissions-revision-external-links.json: passed, 16 occurrences / 13 URLs. An earlier attempt used a no-longer-present virtualenv and did not perform HTTP checks.
• Style lint and UI-reference validation: same 29 existing style findings, no findings on added lines, and zero UI-reference findings. Exact inventory assertions match all 13 GitHub registration keys/levels and all 21 Slack factory bot scope rows. Trunk remains unavailable.
• Compression: reference, Linear, and Jira pass. Current GitHub 1,945 words, GitLab 1,592, Slack 2,011; unchanged Teams 1,936. The existing exception remains: retain required scope lookup detail and existing setup/troubleshooting, rather than split one integration's inventory across pages. Deletion-only review removed blanket warnings and redundant pending-inventory prose.
• Revision self-review and git diff --check: passed across six content files. The only three added comment lines are narrowed policy-required GitLab, Linear, and Slack VERIFY markers; GitHub and Jira markers were removed, and Teams is unchanged. No source, dependencies, verification scripts, logs, or media are committed.
• Chromium on Linux: inspected all six changed permission sections at a desktop viewport. Table columns and long scope tokens fit their cells. Captures show actual rendered content, not a mockup. Browser verification does not establish unobserved production authorization.
• The known external Agent docs review ID-token 401 failure was not retried and no workflow credentials were changed. Push-time CI will run normally.

Visual proof

The current captures show the GitHub repository and account inventories, Jira permission-check purpose, Slack setup-user grants and separate manager-bot caveat, and central status table. Public Marketplace and authentication-boundary captures document the read-only investigation. Earlier blanket-warning screenshots are superseded.

Computer-use screenshots (10)

app.warp.dev/oauth/connect/linear redirects to Warp login (blocker)

app.warp.dev/integrations returns 404 Page not found

developer.atlassian.com/console/myapps redirects to id.atlassian.com login (blocker)

Atlassian Marketplace Warp listing (app 2476990014) Privacy & Security: declared integration permissions list

Atlassian Marketplace Warp listing Installation tab: admin-only manual install steps, 'Get it now' not clicked

GitHub permissions intro and repository table top rows

GitHub outside-repository permissions table

Jira permissions: six scopes including read:permission:jira purpose

Slack managed setup user scopes table and separate manager bot caveat paragraph

Central provider status table on permissions inventory page

Co-Authored-By: Oz oz-agent@warp.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
docs	Ready	Preview	Oct 29, 2026 10:30pm UTC

[warp-agent-staging]

This PR was generated with Warp.

Comment @warp-staging-factory on this PR to send it follow-up work.

  

[moirahuang]

@warp-factories-staging same question here, what does verify mean here why can't you verify yourself?

[warp-agent-staging]

VERIFY is an authoring-evidence marker, not a runtime grant. In 3d2def10, I confirmed the required api/read_user scopes and provisioning code: api tokens, manager Owner role, and factory Developer memberships on selected projects. Only completeness of the production human OAuth request remains unknown: it loads a persisted provider record, and the connection URL requires Warp login. No configured noninteractive admin access is available. Leaving open for the non-secret requested scopes and authorization parameters; no customer membership export is needed.

Responding as Docs Factory (V2): Open session · View in factory

[moirahuang]

@warp-staging-factories same thing here, verify yourself

[warp-agent-staging]

VERIFY marks missing authoring evidence. I checked the public Linear directory and production connection route: the directory exposes no authorization URL, and the route requires Warp login. The actual builder loads persisted scopes and actor parameters; the six local defaults do not prove that production row. 3d2def10 preserves only that precise gap. No configured noninteractive admin access is available; leaving open pending a credential-free scope/actor export or live authorization URL.

Responding as Docs Factory (V2): Open session · View in factory

[moirahuang]

@warp-factories-staging confirm yourself here

[warp-agent-staging]

VERIFY marks missing authoring evidence. 3d2def10 confirms all 21 factory bot scopes in both manifest creation and managed installation, plus the three explicit manager user_scope values. Those no longer need blanket verification. Only the separate manager bot inventory remains: it loads a persisted base provider and cannot be inferred from child scopes. Slack registration and the Warp connection require sign-in; no configured noninteractive admin access is available. Leaving open for that bot scope list only.

Responding as Docs Factory (V2): Open session · View in factory

[moirahuang]

@warp-staging-factories you have multiple places where you say VERIFY, i don't understand why you're not able to verify them yourself via what is provisioned in the code? can you explain clearly with plain english, your previous explanations didn't really make sense to me

[warp-agent-staging]

@moirahuang VERIFY is a drafting note I added meaning “I haven’t confirmed this exact statement.” It is not a product permission or setup step. My earlier blanket warnings were too broad.

Yes, I can verify permissions that the provisioning code explicitly assigns, and I have. That covers GitLab’s bot tokens/roles, Slack’s factory-app and provisioning-user permissions, and the Jira and Teams manifests. GitHub’s permissions were also checked against the live app.

The remaining three lists are different: they live in Warp’s production database, and the code reads them rather than hard-coding them.

• GitLab: the bot’s permissions are confirmed. The separate permission list requested from the person connecting GitLab is read from production settings.
• Linear: the six-permission list in the repo configures local development. Production reads its own saved list, including whether the app or the installer is the actor.
• Slack: each factory app’s permissions are confirmed. The separate manager app’s bot-permission list comes from production settings.

The authorization code effectively says “load the saved permission list, then request it.” Reading that code does not reveal the list currently saved in production, and this run has no access to those records.

Teams is different: its requested permissions are already known from the manifest. The remaining marker concerns what version is installed and any extra Microsoft grants. I do not need to inspect every customer installation to document the manifest’s permissions.

Can you share those three non-secret production settings, or point me to their production definition? No credentials or customer data are needed.

Responding as Docs Factory (V2): Open session