diff --git a/src/components/WarpTopicNav.astro b/src/components/WarpTopicNav.astro index d3bc29508..97b6fdea1 100644 --- a/src/components/WarpTopicNav.astro +++ b/src/components/WarpTopicNav.astro @@ -25,11 +25,10 @@ // underline share `--sl-color-text-accent`, which auto-adapts to dark // and light themes. // - No surrounding chip / box / bg — just type + icon -// - Topic badge (e.g. Factories "Early Access"): rendered as a plain span -// styled as a compact brand pill (Inter, 11px/600, accent tint, fully -// rounded) instead of Starlight's ``, whose monospace bordered -// box clashed with the nav type and was wide enough to wrap the nav -// onto a second row at common laptop widths. +// - Topic badges render as compact brand pills (Inter, 11px/600, accent +// tint, fully rounded) instead of Starlight's ``, whose bordered +// monospace box clashed with the nav type and was wide enough to wrap the +// nav onto a second row at common laptop widths. import { Icon } from '@astrojs/starlight/components'; const { topics } = Astro.locals.starlightSidebarTopics; diff --git a/src/content/docs/factories/benchmarks.mdx b/src/content/docs/factories/benchmarks.mdx index 7f21eddcb..a4a38980b 100644 --- a/src/content/docs/factories/benchmarks.mdx +++ b/src/content/docs/factories/benchmarks.mdx @@ -9,11 +9,7 @@ sidebar: import { VARS } from '@data/vars'; import VideoEmbed from '@components/VideoEmbed.astro'; -:::note -Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. -::: - -Warp Factories benchmarks compare model and runner configurations for one factory agent on the same fixed tasks. Use a benchmark to test a change on representative work before you apply it to your factory. +Warp Factories benchmarks compare model, harness, and runner configurations for one factory agent on the same fixed tasks. Use a benchmark to test a change on representative work before you apply it to your factory. This video shows how to compare benchmark results for quality and cost before changing a coding agent's configuration. @@ -67,7 +63,7 @@ This video shows how to turn your team's coding tasks into a reusable benchmark ![The task editor with fields for a title, prompt, correctness criteria, and pinned repositories.](../../../assets/factories/benchmark-task-editor.png)
The task editor for a benchmark suite.
-6. Click **Run**. In the launch dialog, choose the model or an authorized custom factory router and the runner for each configuration. Third-party harness comparisons are not available yet. +6. Click **Run**. In the launch dialog, choose the harness and model, or an authorized custom factory router, and the runner for each configuration. 7. Add configurations, select Scorers, and set "Repetitions." The dialog shows the number of trials created. More trials and Scorers increase the run's cost. 8. Click **Run benchmark**. The benchmark page shows its status and scored trials. You can cancel a running or scoring benchmark. diff --git a/src/content/docs/factories/connect-your-factory.mdx b/src/content/docs/factories/connect-your-factory.mdx index 29a56f447..b34ef6cd4 100644 --- a/src/content/docs/factories/connect-your-factory.mdx +++ b/src/content/docs/factories/connect-your-factory.mdx @@ -15,7 +15,7 @@ GitHub, GitLab.com, and Azure DevOps Services connect both repositories and prov ## Choose a source -Pick the sources that match where work starts for your team. You can connect multiple sources, but not both Linear and Jira at the same time. The setup wizard currently offers Linear; to use Jira, connect it after setup or in your [factory definition](/factories/factory-as-code/). +Pick the sources that match where work starts for your team. You can connect multiple sources, but not both Linear and Jira at the same time. Choose either issue tracker during setup, or connect one later from the factory's settings or [definition](/factories/factory-as-code/). Once a source is connected, here's the concrete action that hands it work — each links to that integration's full instructions rather than repeating them. diff --git a/src/content/docs/factories/factory-agents.mdx b/src/content/docs/factories/factory-agents.mdx index d6c71f9f5..ad7510bec 100644 --- a/src/content/docs/factories/factory-agents.mdx +++ b/src/content/docs/factories/factory-agents.mdx @@ -7,10 +7,6 @@ sidebar: label: "Factory agents" --- -:::note -Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. -::: - Every factory has a **foreman**, the agent you talk to from the tool that sends the request, such as Slack or Linear. Four other default agents each cover one part of the software development lifecycle: triage scopes the request, spec writes the plan, implement writes the code, and review checks it. Together they take a work item from the moment it reaches your factory to a pull request ready for review. ## The default agents diff --git a/src/content/docs/factories/factory-api.mdx b/src/content/docs/factories/factory-api.mdx index f2a051fa9..8e044192a 100644 --- a/src/content/docs/factories/factory-api.mdx +++ b/src/content/docs/factories/factory-api.mdx @@ -10,10 +10,6 @@ import { VARS } from '@data/vars'; The factory endpoints are part of the {VARS.WARP_PLATFORM_API}. Use them to find a factory and start work from a custom integration without managing agent details. Build them into a chat bot, script, or service for any tool Warp doesn't connect to directly. -:::note -Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. -::: - ## How it works * `GET /factory` - list factories your account can access. Add `search` to filter by name or alias, case-insensitive. diff --git a/src/content/docs/factories/factory-skills.mdx b/src/content/docs/factories/factory-skills.mdx index 5135d59ff..e279b6fb7 100644 --- a/src/content/docs/factories/factory-skills.mdx +++ b/src/content/docs/factories/factory-skills.mdx @@ -7,10 +7,6 @@ sidebar: label: "Factory skills" --- -:::note -Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. -::: - A skill tells an agent what to check, how to classify results, what to produce, and when to escalate. In a factory, skills are how you extend or override [default agents](/factories/factory-agents/), without editing their prompts directly. ## Skill sources in a factory diff --git a/src/content/docs/factories/how-factories-work.mdx b/src/content/docs/factories/how-factories-work.mdx index 435685dcb..eb87c381c 100644 --- a/src/content/docs/factories/how-factories-work.mdx +++ b/src/content/docs/factories/how-factories-work.mdx @@ -7,10 +7,6 @@ sidebar: label: "How factories work" --- -:::note -Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. -::: - A factory is a fleet of agents wired to your software development lifecycle. It connects your repositories and tools to move requests through triage, specification, implementation, review, and verification, while people stay in control of key decisions. You talk to one agent, the **foreman**, from the tool that sends the request, such as Slack or Linear. The foreman dispatches the factory's other agents, and each one owns a part of the software development lifecycle. Deciding which repositories belong in this factory is a separate question. See [sizing a factory](/factories/#sizing-a-factory) for that guidance. diff --git a/src/content/docs/factories/index.mdx b/src/content/docs/factories/index.mdx index d36427bf6..d0945518f 100644 --- a/src/content/docs/factories/index.mdx +++ b/src/content/docs/factories/index.mdx @@ -7,14 +7,24 @@ sidebar: label: "Overview" --- import { VARS } from '@data/vars'; +import { CardGrid, LinkCard } from '@astrojs/starlight/components'; import VideoEmbed from '@components/VideoEmbed.astro'; -:::note -Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. If your team already has access, sign in to the {VARS.FACTORY_WEB_APP}. -::: - A factory is a group of agents that shares repositories and delivery policy. Its foreman accepts work from connected tools, dispatches the right agents, and returns the result to the source. + + + + + ## What is a software factory? diff --git a/src/content/docs/factories/infrastructure-and-security.mdx b/src/content/docs/factories/infrastructure-and-security.mdx index 64660a837..c4a4af401 100644 --- a/src/content/docs/factories/infrastructure-and-security.mdx +++ b/src/content/docs/factories/infrastructure-and-security.mdx @@ -7,11 +7,11 @@ sidebar: label: "Infrastructure & security" --- -Warp Factories runs on the infrastructure your team chooses. You decide where a factory runs code, which model providers serve its inference requests, and which credentials each agent receives. Warp coordinates the work and stores run data such as transcripts and artifacts. +Warp Factories separates execution, inference, and credential boundaries. You choose where code runs, which providers serve inference, and which credentials each agent receives. Warp coordinates the work and stores transcripts and artifacts. ## Control plane and execution plane -Every factory splits responsibilities across two planes: +Each factory uses two planes: * **Control plane** - Warp coordinates runs, identity and configuration, observability, integrations, storage, and inference routing. * **Execution plane** - A Warp-hosted sandbox or a managed self-hosted worker checks out code, runs setup, invokes tools, builds the project, and executes commands. @@ -27,17 +27,13 @@ flowchart LR C --> D["Warp-managed storage"] ``` -Self-hosting moves only the execution plane: with a managed self-hosted worker, repository checkouts, command execution, and the sandbox filesystem stay on machines you control, but content that enters prompts, results, transcripts, attachments, artifacts, or telemetry still flows through Warp and the providers you configure. See [deployment patterns](/factories/deployment-patterns/) and [execution security](/platform/execution-security/) for the broader data model. - -The diagram below maps those boundaries for self-hosted execution; factory runs follow the same data model. See the [data security and boundaries](/platform/architecture/#data-security-and-boundaries) reference for a description of each data class. +With managed self-hosting, repository checkouts, commands, and sandbox files stay on machines you control. Prompts, results, transcripts, attachments, artifacts, and telemetry still flow through Warp and configured providers. See [deployment patterns](/factories/deployment-patterns/), [execution security](/platform/execution-security/), and the [data security and boundaries](/platform/architecture/#data-security-and-boundaries) reference for details. ![Self-hosted data security and boundaries diagram showing what stays in customer infrastructure, what Warp retains, and what transits Warp to model providers](../../../assets/agent-platform/data-security-boundaries.png) ## Runners -A runner defines the compute a factory's agents work on: the operating system and architecture, the sandbox image, and the instance shape (vCPUs and memory). The workspace itself — repositories, setup commands, and secrets — comes from the factory's [definition](/factories/factory-as-code/). See the [runner reference](/factories/runners/) for the available compute options. - -Declare runners as `runners/*.yaml` files. Every agent inherits `agentDefaults.runner`, and an agent or automation can override it. The execution host determines how the runner's compute settings are used: +A runner selects the operating system, architecture, sandbox image, and vCPU and memory shape. The factory's [definition](/factories/factory-as-code/) supplies repositories, setup commands, and secrets. Define runners in `runners/*.yaml`; `agentDefaults.runner` sets the default, and agents and automations can override it. The execution host determines how each setting is used: | Setting | Warp-hosted | Direct | Kubernetes | Docker | | --- | --- | --- | --- | --- | @@ -46,9 +42,7 @@ Declare runners as `runners/*.yaml` files. Every agent inherits `agentDefaults.r | `platform.linux.registryCredentialSecretName` | Warp-managed private-registry credential | Ignored | Ignored; use `imagePullSecrets` | Ignored; configure registry credentials on the worker, such as in its Docker config | | `instanceShape` | Sandbox size, subject to plan limits; omitted uses the workspace default | Ignored; the task uses host resources | Task-container requests and limits; overrides matching `pod_template` resources; omitted keeps template or cluster defaults | Task-container limits; omitted adds no limits | -Self-hosted runner settings do not provision worker capacity. Worker configuration controls host resources, registry authentication, volumes, node placement, and other backend policy. - -See [cloud agent runner compute options](/factories/runners/) and [factory runner syntax](/factories/factory-as-code/#runnersnameyaml). +Self-hosted runner settings don't provision capacity. Worker configuration controls resources, registry authentication, volumes, placement, and backend policy. See [runner compute options](/factories/runners/) for available configurations. ## Choose an execution host @@ -74,7 +68,7 @@ Unmanaged self-hosted agents and other CLI agents can't serve as a factory's exe ### Managed self-hosting structures -Factories use managed self-hosting, so Warp still orchestrates their runs. The worker backend sets isolation and scheduling on your infrastructure: +The worker backend sets isolation and scheduling on your infrastructure: | Structure | How factory runs execute | What your team operates | Use it when | | --- | --- | --- | --- | @@ -113,27 +107,38 @@ A factory handles four kinds of credentials, each with its own boundary: Scope each credential to the resources and actions its agent needs. Warp redacts known secret values at output boundaries, but redaction is a backstop, not a substitute for narrow external permissions and rotation. See [cloud agent secrets](/platform/secrets/), [harness authentication](/platform/harnesses/authentication/), [secret redaction](/support-and-community/privacy-and-security/secret-redaction/), and [team identity](/platform/team-access-billing-and-identity/) for the underlying controls. -## Governance and metering +## Factory roles and permissions + +Factory creation uses the team-level Warp Factories role. Team and workspace admins and team-level Editors can create factories. + +Three roles govern an existing factory: + +* **User** - View and run the factory, and propose definition changes. +* **Editor** - Edit the factory definition, configure its agents, repositories, and automations, attach existing integrations, secrets, and MCP servers, and select existing runners. +* **Admin** - Manage members, delete the factory, and force-merge a blocked definition change. + +Team and workspace admins and owners always have the Admin role. Admins for a factory manage its roles; team and workspace admins manage the team-level role. + +Managing shared runners and connecting team-wide integrations and providers require team or workspace permission. Factory roles don't control specification or pull request review. Treat factory definition changes as operational code, and protect merges through repository settings. -Factories use your existing [team roles](/enterprise/team-management/roles-and-permissions/): Team Owners and Admins control factory definitions, runners, secrets, and provider configuration. Warp Factories doesn't add a factory-specific approval role, so who reviews specifications and who approves merges stays a workflow and repository policy decision. Treat factory-definition changes as operational code: review them like any other change, and keep merge access with the people responsible for shipping. +## Metering -Warp meters hosted compute, Warp-provided inference, and platform services. Managed self-hosted execution moves compute costs to your own infrastructure, and customer-supplied inference bills model usage through your provider account. Platform services consume credits regardless of these choices. See [platform credits](/support-and-community/plans-and-billing/platform-credits/) for details. +Warp meters hosted compute, Warp-provided inference, and platform services. Self-hosting moves compute costs to your infrastructure; customer-supplied inference bills your provider account. Platform services still consume credits. See [platform credits](/support-and-community/plans-and-billing/platform-credits/) for details. ## Deployment checklist -1. **Classify the workload** - Identify the repositories, data, internal services, and regulated systems the factory can reach. -2. **Choose execution** - Decide where checkout, commands, and the sandbox filesystem must run. -3. **Configure the factory and its runners** - Set the repositories, setup commands, secrets, and compatible runners in the factory's definition. -4. **Choose inference** - Select provider routing. -5. **Scope credentials** - Set each agent's secret allowlist, harness authentication, and repository identity. -6. **Set review gates** - Decide where humans review specifications and pull requests, and enforce those gates in workflow and repository policy. -7. **Validate operations** - Test network egress, isolation, rotation, redaction, capacity, observability, and metering before increasing volume. +1. **Classify access** - Inventory repositories, data, and services. +2. **Set boundaries** - Choose execution and inference hosts. +3. **Scope credentials** - Configure allowlists, harness authentication, and repository identity. +4. **Enforce review** - Protect factory-definition and pull request merges. +5. **Validate operations** - Test egress, isolation, rotation, capacity, observability, and metering. ## Related pages -* [**Deployment patterns**](/factories/deployment-patterns/) - Compare Warp-hosted, managed self-hosted, and CLI-only execution. -* [**Managed self-hosting**](/factories/self-hosting/) - Choose a worker backend and follow its setup guide. -* [**Execution security**](/platform/execution-security/) - Review data boundaries, network egress, and backend-specific controls. -* [**Bring Your Own LLM**](/enterprise/enterprise-features/bring-your-own-llm/) - Compare customer-owned inference options and provider support. -* [**Enterprise security overview**](/enterprise/security-and-compliance/security-overview/) - Review data handling, ZDR, compliance, and access controls across Warp. -* [Team-managed model keys and endpoints](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) - Configure customer-supplied inference credentials. +* [**Deployment patterns**](/factories/deployment-patterns/) - Compare execution and inference boundaries. +* [**Runners**](/factories/runners/) - Configure compute and worker compatibility. +* [**Managed self-hosting**](/factories/self-hosting/) - Deploy and operate a worker backend. +* [**Execution security**](/platform/execution-security/) - Review data boundaries, egress, and backend controls. +* [**Team-managed model keys and endpoints**](/enterprise/enterprise-features/team-managed-keys-and-endpoints/) - Configure inference credentials. +* [**Roles and permissions**](/enterprise/team-management/roles-and-permissions/) - Govern team and workspace resources. +* [**Platform credits**](/support-and-community/plans-and-billing/platform-credits/) - Understand factory metering. diff --git a/src/content/docs/factories/integrations/azure-devops.mdx b/src/content/docs/factories/integrations/azure-devops.mdx index a61bb40c3..650839284 100644 --- a/src/content/docs/factories/integrations/azure-devops.mdx +++ b/src/content/docs/factories/integrations/azure-devops.mdx @@ -10,10 +10,6 @@ import { VARS } from '@data/vars'; Connect Azure DevOps Services to a factory so agents can work in selected repositories, open pull requests, and start runs from work item and pull request events. Warp creates a dedicated Microsoft Entra identity for each factory's Git and pull request operations. -:::note -Warp Factories is in Early Access and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. -::: - The first-class integration supports hosted Azure DevOps Services at `dev.azure.com`. It doesn't support Azure DevOps Server. To use a self-hosted Azure DevOps Server repository, [configure it as another code forge](/factories/code-forges/other-code-forges/). For standalone cloud agent environments, use the [Azure DevOps access token setup](/platform/integrations/azure-devops/). ## How identities and access work @@ -30,7 +26,7 @@ Each factory identity consists of a separate Microsoft Entra application and ser ## Requirements -* **A Warp team with Warp Factories access** - A factory belongs to a [Warp team](/knowledge-and-collaboration/teams/). +* **A Warp team** - A factory belongs to a [Warp team](/knowledge-and-collaboration/teams/). * **An Azure DevOps Services organization** - Use an organization hosted at `dev.azure.com`, with the project and repositories the factory needs. * **A connected Azure DevOps user** - Connect a user who can read the organization, project, and repositories you want to select. * **An active connection for each automation creator** - The user who creates an Azure DevOps automation must keep their own Azure DevOps OAuth connection active with the required scopes. diff --git a/src/content/docs/factories/integrations/jira.mdx b/src/content/docs/factories/integrations/jira.mdx index 01e848f2f..1c06677da 100644 --- a/src/content/docs/factories/integrations/jira.mdx +++ b/src/content/docs/factories/integrations/jira.mdx @@ -13,42 +13,47 @@ Connect Jira Cloud to your factory so your team can start factory work without l ## Prerequisites * **Jira Cloud** - The integration supports Jira Cloud only, not Jira Server or Data Center. -* **A Jira site admin** - Installing the Warp app on a Jira site and connecting it to a Warp workspace requires site admin permissions. +* **A Jira site admin** - A site admin must install the Warp app and connect the Jira site to your Warp workspace. * **A factory** - You need a factory in the connected workspace and permission to edit its [definition](/factories/factory-as-code/). * **The Warp agent in Jira** - The **Warp** agent must be available on your Jira site so people can assign or mention it on work items. Jira lists it among Atlassian's Rovo agents. ## Connect Jira and add an automation -1. **Install the Warp app on your Jira site and connect it to your Warp workspace.** The [Jira integration setup](/platform/integrations/jira/#setup) walks through both. Once connected, every factory in the workspace can use it. (That page's `warp-agent` label flow starts standalone cloud agent runs; factories skip the label and use an automation instead.) +1. **Open Jira setup.** Choose **Jira** while creating a factory. To connect it later, open the top-level **Integrations** page in the {VARS.FACTORY_WEB_APP}, find **Jira**, and click **Connect**. +2. **Install Warp for Jira and connect the site.** A Jira site admin installs the app on the Jira Cloud site. In Jira, open **Apps** > **Manage apps** > **Warp** > **Configure**, then click **Connect to Warp**. Once connected, Jira is available to every factory in the workspace. See the [Jira installation steps](/platform/integrations/jira/#setup) for the full app flow. -2. **Connect Jira to this factory.** A workspace connection makes Jira available to your factories, but each one opts in separately: in the factory's **Settings**, connect **Jira** and select the projects that should trigger it. +If you aren't a Jira site admin, choose **Someone else** during setup and email the request or copy the approval link to a site admin. The link expires after seven days, and you can resend or revoke it while the request is pending. -3. **Point an automation at Jira.** In the factory's dashboard, open **Automations** and add a trigger for **Jira** > **Agent session created**. Use **Projects** and, optionally, **Keywords** to scope which sessions start a run, and choose the agent that handles them. +3. **Connect Jira to the factory.** In the factory dashboard, open **Settings** > **Integrations**, connect **Jira**, select the projects this factory works with, then click **Enable**. If you connected Jira while creating the factory, select the projects before finishing setup. Each factory opts in separately even though the Jira site is connected to the workspace. - If you picked Jira projects when you created the factory, that automation already exists. Edit it rather than adding a second one. +4. **Configure the Jira automation.** In the factory dashboard, open **Automations**. If you selected Jira projects during factory creation, edit the existing Jira automation. Otherwise, add a trigger for **Jira** > **Agent session created**. Choose the agent that handles the work, select the projects, and optionally add keywords to narrow which sessions start runs. - To set this up in code instead, declare the `jira` integration in the factory's `factory.yaml` (`integrations: [{type: jira}]`), then add a file under `automations/`, such as `automations/jira-assignment/automation.md`, with an `agent_session_created` trigger: +5. **Test the connection.** Assign or mention **Warp** on a work item and include an instruction. Jira starts an agent session, and the run appears under the matching automation in your factory. - ```markdown title="automations/jira-assignment/automation.md" - --- - enabled: true - agent: foreman - triggers: - - provider: jira - event: agent_session_created - filter: - project_keys: [ENG] - keywords: [investigate, fix] - --- + {/* VISUAL: A Jira work item assigned to Warp, showing the resulting agent session. */} - Handle the Jira assignment and return a concise result. - ``` +The standalone Jira integration uses the `warp-agent` label to start cloud agent runs. Factories use an automation instead. - With this automation, the agent named `foreman` handles sessions for work items in the `ENG` project whose assignment text contains `investigate` or `fix`. Commit and push the files to apply them; see [definitions as code](/factories/factory-as-code/) for the full syntax. +### Configure the automation as code -4. **Test it.** Assign or mention **Warp** on a work item and include an instruction. Jira starts an agent session, and the run appears under the matching automation in your factory. +Declare the `jira` integration in `factory.yaml` (`integrations: [{type: jira}]`), then add a file under `automations/`, such as `automations/jira-assignment/automation.md`, with an `agent_session_created` trigger: - {/* VISUAL: A Jira work item assigned to Warp, showing the resulting agent session. */} +```markdown title="automations/jira-assignment/automation.md" +--- +enabled: true +agent: foreman +triggers: + - provider: jira + event: agent_session_created + filter: + project_keys: [ENG] + keywords: [investigate, fix] +--- + +Handle the Jira assignment and return a concise result. +``` + +This automation sends Jira sessions from the `ENG` project to the agent named `foreman` when their assignment text contains `investigate` or `fix`. Commit and push the files to apply them. See [definitions as code](/factories/factory-as-code/) for the full syntax. ## Filter which sessions start runs @@ -84,7 +89,7 @@ Warp's built-in Jira tools read Jira as the person who created the run; that per ## Troubleshooting -* **Warp is unavailable in Jira** - Confirm the Warp app is installed on the Jira Cloud site. On the app's **Configure** page, click **Connect to Warp** if the installation isn't connected to a workspace. +* **Warp is unavailable in Jira** - Confirm the Warp app is installed on the Jira Cloud site. On the app's **Configure** page, click **Connect to Warp** if the installation isn't connected to a workspace. If someone else is completing setup, confirm that their setup link is still active. * **No run starts** - Confirm an enabled `agent_session_created` automation exists, its agent is available, and its project and keyword filters match the assignment. * **The session shows no result** - Open the matching automation's run to see whether the agent is still working, waiting for input, or failed. * **A Jira update fails** - Confirm the app can access the work item's project and that the requested action or workflow transition is valid. diff --git a/src/content/docs/factories/integrations/teams.mdx b/src/content/docs/factories/integrations/teams.mdx index 7939e87aa..139205348 100644 --- a/src/content/docs/factories/integrations/teams.mdx +++ b/src/content/docs/factories/integrations/teams.mdx @@ -8,14 +8,13 @@ sidebar: --- import { VARS } from '@data/vars'; -Connect a factory to Microsoft Teams so your team can send work from channel conversations. Mention the Warp app in a configured standard or shared channel, and the factory replies in the same thread. +Connect a factory to Microsoft Teams so mentions in standard and shared channels start work and receive replies in the same thread. -## Who does each step +## Who completes each part -* **Warp workspace admin** - Makes Microsoft Teams available and connects installed teams to the Warp workspace. -* **Microsoft Teams admin** - Uploads and approves the Warp custom app in the Teams admin center. -* **Factory editor** - Selects the connected teams and channels for a factory and manages its automations. -* **End user** - Mentions **@Warp** to start work. +* **Warp workspace admin** - Starts the connection and connects the installed team to the workspace. +* **Teams admin or team owner** - Downloads and adds the Warp app. A Teams admin uploads and approves it. +* **Factory editor** - Selects the connected teams and channels for the factory. :::caution The integration supports standard and shared channels. Private channels and direct messages are not supported. @@ -23,12 +22,13 @@ The integration supports standard and shared channels. Private channels and dire ## Set up Microsoft Teams -1. **Enable Microsoft Teams for the Warp workspace.** A workspace admin opens the top-level **Integrations** page in the {VARS.FACTORY_WEB_APP}. If **Microsoft Teams** doesn't appear, contact sales. -2. **Download the Warp Teams app.** On the **Microsoft Teams** integration, click **Connect**, sign in with Microsoft when prompted, then click **Download Warp app package**. The `warp-microsoft-teams-app.zip` file contains the app manifest and icons, with no executable files. -3. **Upload and approve the app.** A Microsoft Teams admin opens the [Teams admin center](https://admin.teams.microsoft.com), goes to **Teams apps** > **Manage apps**, and clicks **Upload new app**, uploads the ZIP, and approves it. Warp then appears under **Apps** > **Built for your org** in Teams. -4. **Add Warp to each team.** In Microsoft Teams, open **Apps** > **Built for your org** > **Warp**, then click **Add** for every team the factory should use. -5. **Connect the installed teams to the Warp workspace.** Back on the top-level **Integrations** page in the {VARS.FACTORY_WEB_APP}, the workspace admin selects the new teams and clicks **Enable**. If a workspace admin selects a pending team while configuring a factory, Warp performs this connection automatically. -6. **Select teams and channels for the factory.** While creating the factory, or from the factory's **Settings**, choose **Microsoft Teams**, select the connected teams, and select at least one standard channel in each team. Click **Enable** or finish factory setup. +1. **Enable Microsoft Teams for the Warp workspace.** A workspace admin opens **Integrations** in the {VARS.FACTORY_WEB_APP}. If **Microsoft Teams** is unavailable, contact sales. +2. **Choose who completes setup.** A workspace admin opens **Microsoft Teams** and clicks **Connect**. If they also administer Teams, continue. Otherwise, choose **Someone else** and email the setup request or copy its approval link for a Teams admin or team owner. Links expire after seven days. +3. **Download the Warp app package.** Sign in with Microsoft and download `warp-microsoft-teams-app.zip`. It contains the app manifest and icons, with no executable files. A delegated recipient uses the approval link without your Warp session. +4. **Upload and approve the app.** In the [Teams admin center](https://admin.teams.microsoft.com), go to **Teams apps** > **Manage apps**, click **Upload new app**, then upload and approve the package. +5. **Add Warp to each team.** In Microsoft Teams, open **Apps** > **Built for your org** > **Warp**, then add Warp to each team the factory should use. +6. **Connect the installed team to the Warp workspace.** Back in setup, select and connect the team. A delegated recipient uses the approval link; direct setup requires a workspace admin to select the team under **Integrations** and click **Enable**. +7. **Select teams and channels for the factory.** During factory creation or in the factory's **Settings**, an editor chooses **Microsoft Teams**, selects the connected teams and at least one standard channel in each, then clicks **Enable**. Warp creates an enabled **teams-app-mentions** automation for the teams and channels selected in the last step. @@ -42,8 +42,8 @@ Warp creates an enabled **teams-app-mentions** automation for the teams and chan * **Start work** - Mention **@Warp** in a configured channel or thread. The factory includes supported attachments and replies in the same thread. Unsupported attachments don't block the request text. * **Continue work** - Reply in a thread that already has a factory work item. When responses to thread replies are enabled, eligible replies continue that work without another mention. -* **Use shared channels** - New root messages in shared channels still require an explicit **@Warp** mention. See the [shared-channel rules](#use-shared-channels). -* **Review results** - Follow progress and the final response in Teams. For code-change work, the factory can also open a pull request. Other workflows can return results directly in the thread. +* **Use shared channels** - Root messages require **@Warp**. See the [shared-channel rules](#use-shared-channels). +* **Review results** - Follow progress and results in Teams. Code changes can also open a pull request. Automation-started work runs as the factory agent selected in that automation. To manage your account link, mention **@Warp** with `sign in`, `sign out`, or `help` in a channel where the app is installed. For `sign in`, follow the private link, then send your request again. `sign out` unlinks your account from every factory in that Microsoft organization. @@ -122,7 +122,7 @@ See the [factory definition syntax](/factories/factory-as-code/#integrations) fo ## Troubleshooting * **Microsoft Teams is missing in Warp** - Ask a workspace admin to confirm the integration is enabled. If it isn't available, contact sales. -* **An installed team is missing in Warp** - Confirm the app is approved, then click **Add** for that team from **Apps** > **Built for your org** in Teams. A Warp workspace admin must then select the team on the top-level **Integrations** page to connect it to the workspace. +* **An installed team is missing in Warp** - Confirm the app is approved, then click **Add** for that team from **Apps** > **Built for your org** in Teams. A Warp workspace admin must then select the team on the top-level **Integrations** page to connect it to the workspace. For delegated setup, confirm that the admin or team owner's setup link is still active. * **Warp says, "This Microsoft Teams channel isn't connected to a Warp Factory. Connect this team to a Factory, then mention this bot again."** - Ask a Warp workspace admin to connect the team on the top-level **Integrations** page, then mention **@Warp** again. * **Warp doesn't acknowledge a mention** - Confirm the team and channel are selected, mention **@Warp**, and follow any private account-linking prompt. For a shared channel, check the [shared-channel rules](#use-shared-channels). * **A channel is missing from the picker** - The picker lists standard channels only. Add a shared channel through the [factory definition](#configure-microsoft-teams-as-code). diff --git a/src/content/docs/factories/measure-and-improve/self-improvement.mdx b/src/content/docs/factories/measure-and-improve/self-improvement.mdx index 8cf6b2f18..532f84a13 100644 --- a/src/content/docs/factories/measure-and-improve/self-improvement.mdx +++ b/src/content/docs/factories/measure-and-improve/self-improvement.mdx @@ -9,7 +9,9 @@ sidebar: {/* VISUAL: The Self-improvement pull request list, or a Benchmarks suite run -- this section is text-only today. */} -Turn on **Self-improvement** for each Scorer whose failures you want investigated automatically. A failure is a score below the Scorer's pass threshold. The scheduled check starts a Self-improvement run after an agent has 25 unreviewed failures, or when its oldest unreviewed failure is seven days old. It groups the failures for each agent into a follow-up run that proposes a fix. +Turn on **Self-improvement** for each Scorer whose failures you want investigated automatically. A failure is a score below the Scorer's pass threshold. By default, the scheduled check starts a Self-improvement run after an agent has 25 distinct unreviewed failures, or when its oldest unreviewed failure is seven days old. It groups the failures for each agent into a follow-up run that proposes a fix. + +For a GitHub-backed factory, set `selfImprovement.failedRunThreshold` in `factory.yaml` to change the scheduled threshold to any value from 1 through 50. The `reviewerType` values are `admins` (the default, team admins and owners), `team` (any team member), `none`, and `custom` (members listed in `reviewerEmails`). Warp randomly requests one eligible reviewer unless you use `none`. See [`selfImprovement` in the factory definition reference](/factories/factory-as-code/#selfimprovement). To run the check without waiting for the scheduled threshold, click **Run now** on the factory dashboard's **Self-improvement** page. An ad hoc run can include an agent with one unreviewed failure. You cannot choose which agents or failures it processes. diff --git a/src/content/docs/factories/quickstart.mdx b/src/content/docs/factories/quickstart.mdx index a26486473..5bca3ec50 100644 --- a/src/content/docs/factories/quickstart.mdx +++ b/src/content/docs/factories/quickstart.mdx @@ -8,17 +8,13 @@ sidebar: --- import { VARS } from '@data/vars'; -:::note -Warp Factories is in **Early Access** and available to a limited set of teams. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. -::: - -Create a factory and take one small work item from prompt to pull request in about 10 minutes. This quickstart is for teams that already have Warp Factories access and know which repositories they want the factory to use. - +Create a factory and take one small work item from prompt to pull request in about 10 minutes. ## Prerequisites -* **Warp Factories access** - [Request Early Access](https://www.warp.dev/factories/request-access) for your team. -* **A Warp team with credits** - The team's [credits](/support-and-community/plans-and-billing/platform-credits/) are consumed by factory agents. +* **A Warp account and team** - Get started with Warp, then join or create the team that will own the factory. +* **Permission to create factories** - You need a team or workspace admin role, or the team-level Warp Factories Editor role. See [factory roles and permissions](/factories/infrastructure-and-security/#factory-roles-and-permissions). +* **Available team usage** - The factory's agents consume the team's [credits](/support-and-community/plans-and-billing/platform-credits/). * **Repository access** - Authorize GitHub, GitLab, or Azure DevOps during setup. Restricted organizations need owner approval. Azure DevOps also requires [one-time administrator approval](/factories/integrations/azure-devops/#requirements). ## Set up your factory @@ -29,7 +25,6 @@ _About 5 minutes_ For GitHub and GitLab repositories, an agent connected to [Factory MCP](/factories/factory-mcp/#set-up-with-your-coding-agent) can run this whole setup. Use the web setup wizard for Azure DevOps. If the wizard is still open when the agent finishes, refresh the page to see the new factory. ::: - 1. Sign in to the {VARS.FACTORY_WEB_APP}. Next to **Factories**, click **+**.
@@ -85,7 +80,6 @@ Send work from Slack or an issue tracker. If you skipped integrations, start a r repo's lint check, and open a pull request. ``` - 2. The foreman dispatches the agents needed for the request and posts progress where it started. Follow the foreman and child runs on the factory's [Runs page](/factories/factory-dashboard/#inspect-runs). Requests for input also appear in your [inbox](/factories/factory-inbox/). If you connected Slack, you can follow along there instead: diff --git a/src/content/docs/factories/troubleshooting.mdx b/src/content/docs/factories/troubleshooting.mdx index a021a649c..d32d4e782 100644 --- a/src/content/docs/factories/troubleshooting.mdx +++ b/src/content/docs/factories/troubleshooting.mdx @@ -12,11 +12,11 @@ Fix the problems teams hit most often when setting up a factory and running thei ## Setting up a factory -### You don't have access to Warp Factories +### You can't create or configure a factory -**Cause:** Warp Factories is in Early Access and enabled per team. +**Cause:** Creating a factory requires a team or workspace admin role, or the team-level Warp Factories Editor role. Configuring an existing factory requires its Editor or Admin role. -**Fix:** [Request access](https://www.warp.dev/factories/request-access) for your team. If a teammate already has it, ask a team admin to confirm you're on that team. +**Fix:** Ask a team or workspace admin to set your team-level Warp Factories role to Editor. To configure an existing factory, ask an Admin for that factory to set your role to Editor. See [factory roles and permissions](/factories/infrastructure-and-security/#factory-roles-and-permissions). ### A repository doesn't appear in the picker diff --git a/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx b/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx index 3b6b9128b..eeb7e8f4b 100644 --- a/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx +++ b/src/content/docs/guides/agent-workflows/build-a-self-improving-agent.mdx @@ -24,7 +24,7 @@ The outer loop proposes improvements; it doesn't apply them silently. Every chan ## Prerequisites * A working inner loop with at least one agent running ([set up your software factory](/guides/agent-workflows/set-up-a-software-factory)) -* A Warp account ([sign up at warp.dev](https://www.warp.dev)) +* A Warp account (get started with Warp) * A cloud environment with access to your repository ([create one](/platform/environments)) ## Why principles beat rules diff --git a/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx b/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx index af83db49c..50dab8478 100644 --- a/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx +++ b/src/content/docs/guides/agent-workflows/build-a-triage-agent.mdx @@ -15,7 +15,7 @@ Learn how to use the {VARS.WARP_AUTOMATION_PLATFORM} to build a triage agent tha ## Prerequisites -* A Warp account ([sign up at warp.dev](https://www.warp.dev)) +* A Warp account (get started with Warp) * A GitHub repository with Issues enabled * A cloud environment with access to your repository ([create one](/platform/environments/configuring-environments/#create-an-environment-with-guided-setup)) * A Warp API key added to your CI secrets as `WARP_API_KEY` ([create one](/agents/cli/oz-cli/api-keys/#from-the-web-app-recommended)) diff --git a/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx b/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx index 511fe9544..7df2d43e2 100644 --- a/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx +++ b/src/content/docs/guides/agent-workflows/run-a-software-factory-in-the-cloud.mdx @@ -13,12 +13,12 @@ tags: --- import { VARS } from '@data/vars'; -The GitHub Actions approach in [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) gets the four-agent loop working. This guide covers the {VARS.WARP_AUTOMATION_PLATFORM}-native production setup for teams running the factory at scale: cloud environments, secrets and permissions, triggers, and observability. To run the same loop as a managed product instead, see [Warp Factories](/factories/). +The GitHub Actions approach in [Set up your software factory](/guides/agent-workflows/set-up-a-software-factory) gets the four-agent loop working. Use the {VARS.WARP_AUTOMATION_PLATFORM}-native production setup to add cloud environments, permissions, triggers, and observability. To run the same loop as a managed product instead, see [Warp Factories](/factories/). ## Prerequisites * A working software factory loop ([set one up](/guides/agent-workflows/set-up-a-software-factory)) -* A Warp account ([sign up at warp.dev](https://www.warp.dev)) +* A Warp account (get started with Warp) ## Why cloud agents, not cloud computers diff --git a/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx b/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx index f0983809b..8575b2edd 100644 --- a/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx +++ b/src/content/docs/guides/agent-workflows/write-product-and-tech-specs-with-agents.mdx @@ -18,7 +18,7 @@ Specs give implementation agents the context they need to make good decisions, a ## Prerequisites -* A Warp account ([sign up at warp.dev](https://www.warp.dev)) +* A Warp account (get started with Warp) * A triaged issue labeled `ready-to-spec` or equivalent ([set up triaging](/guides/agent-workflows/build-a-triage-agent)) * `common-skills` installed globally from [`warpdotdev/common-skills`](https://github.com/warpdotdev/common-skills): diff --git a/src/content/docs/index.mdx b/src/content/docs/index.mdx index 5ce13adc8..e3695b83f 100644 --- a/src/content/docs/index.mdx +++ b/src/content/docs/index.mdx @@ -31,7 +31,7 @@ The {VARS.WARP_AUTOMATION_PLATFORM} runs cloud agents from triggers, schedules, ## Warp Factories -Warp Factories is available in Early Access. A factory turns incoming engineering work into a repeatable, multi-stage workflow with specialized agents, review points, and measurable outcomes. +A factory turns incoming engineering work into a repeatable, multi-stage workflow with specialized agents, review points, and measurable outcomes. * [Warp Factories overview](/factories/) - Learn how a factory receives, routes, and tracks work. * [Factory quickstart](/factories/quickstart/) - Create a factory and send it its first work item. diff --git a/src/content/docs/platform/overview.mdx b/src/content/docs/platform/overview.mdx index b3a590356..75a83bb2d 100644 --- a/src/content/docs/platform/overview.mdx +++ b/src/content/docs/platform/overview.mdx @@ -66,7 +66,7 @@ Runs pick up your team's shared setup no matter what triggered them: [MCP server ## Warp Factories -[Warp Factories](/factories/) builds on these pieces to run persistent, multi-agent development workflows: specialized cloud agents move each work item through triage, specification, implementation, and review. It's in Early Access. [Request access](https://www.warp.dev/factories/request-access) to use it with your team. +[Warp Factories](/factories/) builds on these pieces to run persistent, multi-agent development workflows: specialized cloud agents move each work item through triage, specification, implementation, and review. ## Where to go next diff --git a/src/data/vars.ts b/src/data/vars.ts index 1fbc605e3..bb21274c5 100644 --- a/src/data/vars.ts +++ b/src/data/vars.ts @@ -67,5 +67,6 @@ export const VARS = { ADD_ON_CREDITS: "Add-on Credits", // URLs + GET_STARTED_URL: "https://www.warp.dev/get-started", CONTACT_SALES_URL: "https://www.warp.dev/contact-sales", } as const; diff --git a/src/sidebar.ts b/src/sidebar.ts index 6bdb317fd..5ac2af3a5 100644 --- a/src/sidebar.ts +++ b/src/sidebar.ts @@ -382,7 +382,6 @@ export const sidebarTopics: StarlightSidebarTopicsUserConfig = [ ], }, { - // Warp Factories documentation for Early Access. // Starlight has no built-in factory glyph, so use its settings icon. id: 'factories', label: 'Factories',