docs(factories): use root-absolute links on merged factory pages

src/content/docs/factories/factory-agents.mdx

@@ -24,7 +24,7 @@ When you set up a factory, Warp offers five default roles. Every factory gets a
 
 These roles describe responsibilities, not a fixed pipeline. A small, well-understood change can skip the spec stage entirely, and review can send work back to implementation for another pass. By default, work that goes through the spec stage needs a human to approve the spec before implementation starts.
 
-For the complete lifecycle, see [how Warp Factories work](./how-factories-work).
+For the complete lifecycle, see [how Warp Factories work](/factories/how-factories-work/).
 
 ## Foreman
 
@@ -44,27 +44,27 @@ Spec turns an ambiguous request into a concrete plan. It interviews the requeste
 
 ### Implement
 
-Implement makes the change. When a spec exists, it continues the spec's branch and draft pull request rather than starting over. It writes the code, adds tests, runs the repository's validation, reviews its own diff, and, when [computer use](../agents/capabilities/computer-use) is available, captures visual evidence of user-facing changes. If review finds problems, implement revises the change. It never merges.
+Implement makes the change. When a spec exists, it continues the spec's branch and draft pull request rather than starting over. It writes the code, adds tests, runs the repository's validation, reviews its own diff, and, when [computer use](/agents/capabilities/computer-use/) is available, captures visual evidence of user-facing changes. If review finds problems, implement revises the change. It never merges.
 
 ### Review
 
 Review checks the finished change with fresh eyes, deliberately hunting for problems: unmet requirements, broken conventions, missing or failing tests, security issues, and evidence that doesn't hold up. It separates clear defects from judgment calls, then gives the foreman one of three recommendations: accept the change, send it back for revision, or ask a human to decide. The recommendation is advice for the foreman; it doesn't approve or merge the pull request.
 
 ## Where verification happens
 
-There's no separate verification agent, and the default team doesn't need one. Implement proves its own change works: it runs the tests and repository checks, and, when [computer use](../agents/capabilities/computer-use) is available, uses it to capture visual evidence of user-facing changes, such as screenshots and recordings of the running app. Review then checks that proof, reruns or extends validation when necessary, and confirms the results meet the criteria. You can add custom agents for extra quality coverage, but implement and review keep these responsibilities either way.
+There's no separate verification agent, and the default team doesn't need one. Implement proves its own change works: it runs the tests and repository checks, and, when [computer use](/agents/capabilities/computer-use/) is available, uses it to capture visual evidence of user-facing changes, such as screenshots and recordings of the running app. Review then checks that proof, reruns or extends validation when necessary, and confirms the results meet the criteria. You can add custom agents for extra quality coverage, but implement and review keep these responsibilities either way.
 
 ## Built-in skills and memory
 
 Every default agent comes with GitHub skills, and the foreman also comes with a Slack skill. The issue tracker you choose during setup adds to that baseline: choosing Linear or Jira gives the agents that tracker's skill and instructions for working with it. If you don't choose a tracker, the agents get only the baseline.
 
-Each default agent also has its own [Auto-memory store](../agents/agent-memory). Over time, Warp consolidates the agent's conversations into memory, and that accumulated memory shapes how the agent behaves. Keep this in mind when comparing two agents: identical settings don't guarantee identical behavior, because each agent remembers different things.
+Each default agent also has its own [Auto-memory store](/agents/agent-memory/). Over time, Warp consolidates the agent's conversations into memory, and that accumulated memory shapes how the agent behaves. Keep this in mind when comparing two agents: identical settings don't guarantee identical behavior, because each agent remembers different things.
 
 ## Configure agent behavior
 
 Use the agent editor in the control room to change an agent's description, model, runner, host, MCP servers, secrets, and instructions.
 
-You can also manage the whole factory as version-controlled code, with [factory definition files](./factory-as-code) in a Git repository, where changes get the same review, history, and rollback as any other code. A few agent settings can only be set in the files: harness, environment, and credential strategy. Where the repository lives determines how the two editing paths work together:
+You can also manage the whole factory as version-controlled code, with [factory definition files](/factories/factory-as-code/) in a Git repository, where changes get the same review, history, and rollback as any other code. A few agent settings can only be set in the files: harness, environment, and credential strategy. Where the repository lives determines how the two editing paths work together:
 
 * **Warp-managed repository** - Edit agents in the agent editor, or edit the definition files directly in the control room's **Code** tab, whichever fits the change. Both write to the same files, so the editor and the code always agree.
 * **A GitHub repository your team owns** - The files are the only way to change the factory. Edits go through pull requests, and the file-owned settings in the control room are read-only.
@@ -89,13 +89,13 @@ Default model IDs change over time, so choose based on what each role has to do
 | Implement | Coding strength, with a harness that fits your repositories and toolchain |
 | Review | A different model or harness from implement, so the two don't share blind spots |
 
-See [model choice for agents](../agents/inference/model-choice) and [harnesses for cloud agents](../platform/harnesses) for available options. Define reusable procedures with [skills](../agents/capabilities/skills), and scope each role's external access through [MCP servers](../platform/mcp) and [cloud agent secrets](../platform/secrets).
+See [model choice for agents](/agents/inference/model-choice/) and [harnesses for cloud agents](/platform/harnesses/) for available options. Define reusable procedures with [skills](/agents/capabilities/skills/), and scope each role's external access through [MCP servers](/platform/mcp/) and [cloud agent secrets](/platform/secrets/).
 
 ## Add custom agents and automations
 
 Add custom agents for jobs the default roles don't handle, such as documentation, security analysis, migrations, or release checks. A custom agent doesn't have to be a required step for every work item.
 
-Automations start a chosen agent on a schedule or when an event fires. They're one more way for work to enter your factory; the foreman still coordinates whatever they start. For all the ways to route work into a factory, see [connect your factory](./connect-your-factory).
+Automations start a chosen agent on a schedule or when an event fires. They're one more way for work to enter your factory; the foreman still coordinates whatever they start. For all the ways to route work into a factory, see [connect your factory](/factories/connect-your-factory/).
 
 ## Human decision points and permissions
 
@@ -109,4 +109,4 @@ A few capabilities sit outside an agent's configuration: built-in harness tools,
 
 Treat the approval steps as workflow conventions, not access control. Warp Factories has no special approver role, and nothing written in an agent's instructions grants it access beyond what it's configured with. Real enforcement lives in your repository permissions and platform configuration.
 
-Next, capture these choices in [factory definitions as code](./factory-as-code).
+Next, capture these choices in [factory definitions as code](/factories/factory-as-code/).

src/content/docs/factories/factory-mcp.mdx

@@ -16,10 +16,10 @@ The factory keeps a single record of each task throughout. Whether a change happ
 
 * **Send work in** - Turn anything from your local session into a factory task: a bug you found, review feedback, or a half-finished change.
 * **Continue a task locally** - Pull a task's context into your own checkout, work with your own tools, and return the result to the same task.
-* **Stay in sync** - List and search tasks, read a task's conversation, and message its [foreman](./factory-agents), the agent that orchestrates each task inside the factory.
+* **Stay in sync** - List and search tasks, read a task's conversation, and message its [foreman](/factories/factory-agents/), the agent that orchestrates each task inside the factory.
 * **Create a factory** - Set up a new factory when you know the team, repositories, and source-control details.
 
-Factory MCP is one of several ways work enters a factory, alongside Slack, Linear, Jira, and GitHub. See [connect your factory](./connect-your-factory) for all intake paths and [how Warp Factories work](./how-factories-work) for how tasks move through a factory.
+Factory MCP is one of several ways work enters a factory, alongside Slack, Linear, Jira, and GitHub. See [connect your factory](/factories/connect-your-factory/) for all intake paths and [how Warp Factories work](/factories/how-factories-work/) for how tasks move through a factory.
 
 ## Connect and authenticate
 
@@ -51,7 +51,7 @@ In clients that use the `mcpServers` JSON format, such as Cursor:
 
 For Codex and other clients, follow the [client's own remote-server instructions](https://developers.openai.com/codex/mcp/#connect-codex-to-an-mcp-server) with the same URL.
 
-For unattended automation, skip the browser flow and authenticate with a [Warp API key](../reference/cli/api-keys/) instead. Create the key for a least-privilege cloud agent rather than your personal account, and pass it as a bearer token:
+For unattended automation, skip the browser flow and authenticate with a [Warp API key](/reference/cli/api-keys/) instead. Create the key for a least-privilege cloud agent rather than your personal account, and pass it as a bearer token:
 
 ```json
 {
@@ -89,7 +89,7 @@ If the new task builds on local changes, push the branch or open a pull request
 ## Pick up a task and work on it locally
 
 1. **Find the task.** Your agent locates it with `list_tasks` or `search_task`, or resolves a reference you give it with `get_task`: a task or run URL, a GitHub pull request, a Slack permalink, a Linear or Jira issue, or a branch name.
-2. **Pull down the context.** Calling `get_task` with `start_working=true` returns the task's status, run history, and suggested Git commands for setting up an isolated [worktree](../code/git-worktrees/) in a local clone. Factory MCP never modifies your files; your agent runs the setup itself.
+2. **Pull down the context.** Calling `get_task` with `start_working=true` returns the task's status, run history, and suggested Git commands for setting up an isolated [worktree](/code/git-worktrees/) in a local clone. Factory MCP never modifies your files; your agent runs the setup itself.
 3. **Coordinate while you work.** `message_foreman` sends progress, questions, and blockers to the task's foreman, and `get_conversation` reads the replies. Messaging keeps the factory informed but doesn't move the task or hand anything back.
 4. **Commit and push.** Validate the change, then push the branch. The factory can't see uncommitted or unpushed work.
 5. **Hand the task back.** Your agent calls `send_task` with the task's ID, the pushed branch or pull request URL, and a note covering what changed, what was validated, and what remains. The work returns to the same task, and the foreman decides the next step.
@@ -106,7 +106,7 @@ Sending work to a factory means you're no longer watching it. To be notified whe
 
 ## Tool reference
 
-Factory MCP exposes these ten tools. Your MCP client fetches the full input schemas from the server, and tool results include links that open the corresponding task or run in the factory's [control room](./control-room).
+Factory MCP exposes these ten tools. Your MCP client fetches the full input schemas from the server, and tool results include links that open the corresponding task or run in the factory's [control room](/factories/control-room/).
 
 | Tool | What it does |
 | --- | --- |
@@ -123,9 +123,9 @@ Factory MCP exposes these ten tools. Your MCP client fetches the full input sche
 
 ## Related pages
 
-* [Connect your factory](./connect-your-factory) - Every way work can enter a factory, including the Slack, Linear, Jira, and GitHub integrations.
-* [Factory agents](./factory-agents) - The foreman and the other agents that carry out a factory's tasks.
-* [How Warp Factories work](./how-factories-work) - The task lifecycle and the agents that move work through it.
-* [Warp Factories quickstart](./quickstart) - Create a factory and send it its first work item.
-* [Model Context Protocol in Warp](../agents/capabilities/mcp/) - How MCP servers work in the Warp app, with a catalog of popular MCP servers you can add to Warp directly.
-* [Handoff between local and cloud agents](../platform/handoff/) - Move workspaces and conversations between local and cloud outside a factory.
+* [Connect your factory](/factories/connect-your-factory/) - Every way work can enter a factory, including the Slack, Linear, Jira, and GitHub integrations.
+* [Factory agents](/factories/factory-agents/) - The foreman and the other agents that carry out a factory's tasks.
+* [How Warp Factories work](/factories/how-factories-work/) - The task lifecycle and the agents that move work through it.
+* [Warp Factories quickstart](/factories/quickstart/) - Create a factory and send it its first work item.
+* [Model Context Protocol in Warp](/agents/capabilities/mcp/) - How MCP servers work in the Warp app, with a catalog of popular MCP servers you can add to Warp directly.
+* [Handoff between local and cloud agents](/platform/handoff/) - Move workspaces and conversations between local and cloud outside a factory.

src/content/docs/factories/integrations/jira.mdx

@@ -15,7 +15,7 @@ Connect Jira Cloud to your factory so your team can start factory work without l
 
 * **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 factory** - You need a factory in the connected workspace and permission to edit its [definition](../factory-as-code).
+* **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
@@ -49,7 +49,7 @@ Connect Jira Cloud to your factory so your team can start factory work without l
    Handle the Jira assignment and return a concise result.
    ```
 
-   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](../factory-as-code) for the full syntax.
+   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.
 
 5. Save the automation, or commit and push the definition if you used definitions as code. Then 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.
 
@@ -88,4 +88,4 @@ When the run finishes, the result appears in the agent session. The agent doesn'
 * **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.
 
-For the other ways to route work into a factory, see [connecting your factory](../connect-your-factory).
+For the other ways to route work into a factory, see [connecting your factory](/factories/connect-your-factory/).

src/content/docs/factories/integrations/slack.mdx

@@ -14,7 +14,7 @@ Connect a factory to Slack so your team can send it work without leaving their c
 
 You need permission to update the factory and install apps in the target Slack workspace. Workspace policy can require administrator approval.
 
-Installing the app grants the Slack permissions shown on the authorization screen. Filters on automations only control which events start work; they don't limit what the app can access. For workspace-level installation and removal behavior, see the [Slack platform integration](../../platform/integrations/slack).
+Installing the app grants the Slack permissions shown on the authorization screen. Filters on automations only control which events start work; they don't limit what the app can access. For workspace-level installation and removal behavior, see the [Slack platform integration](/platform/integrations/slack/).
 
 ## Connect the factory
 
@@ -83,4 +83,4 @@ A factory can create issues, branches, and pull requests, but your repository's
 - **Installation is pending** - Ask a Slack workspace administrator to approve the app, then finish the installation.
 - **Two runs start for one mention** - Remove or narrow overlapping app-mention and channel-message triggers.
 
-Removing the app from your Slack workspace stops new requests from Slack for that factory; to reconnect it, return to factory setup and click **Add to Slack** again. Deleting the factory also removes its Slack connection. To route work into the factory from other tools, see [Connect your factory](../connect-your-factory).
+Removing the app from your Slack workspace stops new requests from Slack for that factory; to reconnect it, return to factory setup and click **Add to Slack** again. Deleting the factory also removes its Slack connection. To route work into the factory from other tools, see [Connect your factory](/factories/connect-your-factory/).

src/content/docs/factories/measure-and-improve.mdx

@@ -77,7 +77,7 @@ Every benchmark also runs **Correctness**, a built-in scorer that marks each tri
 
 ## Configure and review Self-improvement
 
-Turn on **Self-improvement** for each Scorer whose failures you want investigated automatically. Self-improvement groups related failures and files follow-up tasks as ordinary agent runs. A follow-up run can propose changes to application code. It can also improve the factory itself: when you manage your factory as [definitions as code](./factory-as-code), its prompts, skills, and configuration are version-controlled files, so a follow-up run can open a pull request against the factory definition the same way it would against application code. Nothing is adopted without your review.
+Turn on **Self-improvement** for each Scorer whose failures you want investigated automatically. Self-improvement groups related failures and files follow-up tasks as ordinary agent runs. A follow-up run can propose changes to application code. It can also improve the factory itself: when you manage your factory as [definitions as code](/factories/factory-as-code/), its prompts, skills, and configuration are version-controlled files, so a follow-up run can open a pull request against the factory definition the same way it would against application code. Nothing is adopted without your review.
 
 Each Self-improvement pull request includes a **Regressions addressed** section that links the failing runs and Scorer results behind it, so you can trace the change back to its evidence.
 
@@ -106,4 +106,4 @@ flowchart LR
 
 ## Next step
 
-Record an adopted change in [factory definitions as code](./factory-as-code) so your team can review the factory configuration.
+Record an adopted change in [factory definitions as code](/factories/factory-as-code/) so your team can review the factory configuration.