Skip to content

chore: gate factory launch - #508

Draft
hongyi-chen wants to merge 3 commits into
mainfrom
hyc/factory-launch
Draft

chore: gate factory launch#508
hongyi-chen wants to merge 3 commits into
mainfrom
hyc/factory-launch

Conversation

@hongyi-chen

Copy link
Copy Markdown
Collaborator

Gates the factory launch. Implementation to follow.

Conversation: https://staging.warp.dev/conversation/7451da22-6397-4ae3-a494-9f167301b6ef
Run: https://oz.staging.warp.dev/runs/019ff6fe-37b6-7588-b397-a62d8c9e2a5a

This PR was generated with Oz.

Placeholder commit to open a draft PR that will gate the factory launch.

Co-Authored-By: Warp Agent <agent@warp.dev>
@cla-bot cla-bot Bot added the cla-signed label Aug 12, 2026
@vercel

vercel Bot commented Aug 12, 2026

Copy link
Copy Markdown

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

Project Deployment Actions Updated (UTC)
docs Ready Ready Preview Aug 14, 2026 10:06pm

Request Review

…ab scaffold (#513)

* feat: scaffold Factories tab and Automation Platform rename infra

- Add new top-level Factories sidebar topic with 6 stub pages
  (Overview, Quickstart, How Factories work, Configure your Factory,
  Connect your Factory, Infrastructure & security) per HYC's IA doc
- Relabel the Oz tab to Automation Platform and reorganize its 10
  subsections into 6 groups (Cloud Agents, Environments, Integrations,
  Orchestration, Self-hosting, API/SDK); all page slugs unchanged
- Add vars.ts entries: API_SDK_NAME (rename-sensitive) and
  FACTORY_WEB_APP/FACTORY_WEB_APP_URL (net-new, for platform.warp.dev)
- Extend style_lint.py RENAME_SENSITIVE_VAR_STRINGS to catch bare "Oz"
  and "Oz Platform", with longest-match dedup so specific matches
  (Oz CLI, Oz Platform, etc.) aren't double-flagged by the general
  bare "Oz" entry
- Add Automation Platform + Warp Factories terminology.md entries
- Migrate platform/index.mdx prose to the vars system
- Add redirect for /platform/software-factory -> /factories/ (content
  migration to the new tab flagged for HYC, not deleted)

Co-Authored-By: Warp Agent <agent@warp.dev>

* docs: migrate hardcoded Oz product names to vars in agents/terminal/getting-started

Replace hardcoded rename-sensitive Oz-branded strings (Oz, Oz CLI, Oz web
app, Oz API, Oz API & SDK, Oz Platform, Oz run) with {VARS.*} references
in body prose (and {{TOKEN}} in frontmatter) across:
- src/content/docs/agents/**
- src/content/docs/terminal/comparisons and terminal/input/classic-input
- src/content/docs/getting-started/migrate-to-warp-from-claude-code
- src/content/docs/index.mdx and quickstart.mdx

Left unmigrated (intentional, per scope): image alt/figcaption text that
transcribes actual on-screen branding of existing screenshots/graphics,
and Oz mentions inside fenced code blocks (example prompts).

Co-Authored-By: Warp Agent <agent@warp.dev>

* docs: migrate reference/ Oz-branded strings to vars, add CLI deprecation banner

Migrate hardcoded Oz product-name strings (Oz CLI, Oz web app, oz.warp.dev, Oz dashboard, Oz run, Oz API & SDK, Oz Platform, bare Oz) to the vars system across src/content/docs/reference/cli/** and src/content/docs/reference/api-and-sdk/**, using {VARS.KEY} in MDX body prose and {{TOKEN}} in frontmatter. Add a shared deprecation callout to the top of every reference/cli/* page pointing to the Warp Agent CLI as the replacement for the Oz CLI. Relabel the Reference tab's CLI sidebar entry to 'Oz CLI (legacy)' in src/sidebar.ts.

Co-Authored-By: Warp Agent <agent@warp.dev>

* docs: migrate hardcoded Oz strings to vars system in guides, support-and-community, enterprise, changelog

Replace hardcoded rename-sensitive Oz-branded strings (Oz CLI, Oz web app,
oz.warp.dev, Oz dashboard, Oz run, Oz API & SDK, Oz Platform, bare Oz) with
src/data/vars.ts references ({VARS.KEY} in body prose, {{TOKEN}} in
frontmatter) across all guides/, support-and-community/, enterprise/, and
changelog/ files containing product-name mentions.

Left unmigrated (intentional, per style_lint OZ_TERMS_TO_AVOID / screenshot
alt-text exceptions):
- changelog/2026.mdx:501 'Oz agents' (wording issue, not vars issue)
- changelog/2026.mdx:629 'Oz cloud agent' (wording issue)
- changelog/2026.mdx:787 'the Oz agent' (wording issue)
- changelog/2026.mdx:1362 image alt text describing the 2026.02.10 launch screenshot

Co-Authored-By: Warp Agent <agent@warp.dev>

* docs: migrate Oz platform strings to vars in platform/ directory

Replace hardcoded rename-sensitive strings (Oz, Oz Platform, Oz CLI,
Oz web app, Oz dashboard, Oz run, Oz API & SDK) with {VARS.*} in body
prose and {{TOKEN}} in frontmatter across src/content/docs/platform/,
excluding index.mdx and software-factory.mdx which are handled
separately.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: resolve topic-resolution build failures and lint false positives

- Add back platform/oz-web-app to the Automation Platform sidebar
  (accidentally dropped during the reorg, broke the build)
- Give the Automation Platform topic an explicit id and associate the
  orphaned platform/software-factory page with it via topic frontmatter,
  since it's no longer listed in any sidebar but still needs a topic to
  resolve (content stays as source material for HYC's Factories migration)
- Fix style_lint.py's check_hardcoded_vars to match on word boundaries
  instead of plain substring search, so short literals like bare "Oz"
  don't false-positive inside unrelated tokens (e.g. a YouTube share
  link's si=OzvuInMl8DoNR97R query param)
- Fix style_lint.py's video-title check to recognize JSX expression
  titles, not just quoted string literals

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: convert broken VARS markdown links to JSX anchors

MDX doesn't evaluate {} expressions inside plain markdown link
destination syntax [text](url) -- only inside JSX. 12 links across 8
reference/ pages used [label]({VARS.WEB_APP_URL}/path) syntax, which
the internal link checker correctly flagged as broken (the literal
string "{VARS.WEB_APP_URL}/path" isn't a real path).

Converted all 12 to the <a href={...}>label</a> JSX pattern already
used elsewhere in the codebase, using a template literal when a path
suffix is appended to the base URL.

Verified with:
- python3 .agents/skills/check_for_broken_links/check_links.py --internal-only (0 broken links, was 12)
- npm run build (370 pages, clean)

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: merge software-factory redirect entries to stay under Vercel's route limit

Vercel deployment was failing with errorCode "too_many_routes":
"Maximum number of routes (rewrites, redirects, etc) exceeded. Max is
2048, received 2049." The repo's vercel.json is already right at that
ceiling (~2047 processed routes on the base branch), and my two
separate redirect entries for /platform/software-factory (trailing
and non-trailing slash) each counted as a route, pushing the total
over by one.

Merged the two entries into a single rule using an optional trailing
slash pattern ("/platform/software-factory/?"), matching both URL
forms with one redirect instead of two.

Verified with npm run build (370 pages, clean).

Note for follow-up: the docs repo is now sitting almost exactly at
Vercel's 2048-route hard limit. Any future redirect addition (by
anyone) risks tripping this same failure. Worth a separate pass to
audit and consolidate redundant slash-variant redirect pairs across
vercel.json to create headroom.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: use valid Vercel redirect syntax for software-factory redirect

The previous fix used /platform/software-factory/? as the source
pattern to match both trailing-slash variants in one entry, but
Vercel rejected it with errorCode invalid-route-source-pattern (? is
not valid syntax in this position for Vercel redirect sources).

Reverted to a single plain entry using only the trailing-slash
canonical form (matching the simple, proven syntax used by the
adjacent /agent-platform/ entry), still keeping the net route count
at +1 instead of +2 to stay under the 2048 route cap.

Verified with npm run build (370 pages, clean) and a JSON validity
check on vercel.json.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: address PR review feedback

Automated (oz-for-oss) review comments:
- Revert incorrect variableization of the "Oz by Warp GitHub App"
  proper noun in reference/cli/integration-setup.mdx,
  reference/cli/api-keys.mdx, and enterprise/team-management/
  admin-panel.mdx. This is a literal, external GitHub App display
  name, not a docs-rename-sensitive string -- flipping
  WARP_AUTOMATION_PLATFORM would otherwise make these pages document
  a GitHub App name that doesn't actually exist.
- Fix sidebar.ts's hardcoded "Oz API & SDK reference" cross-link
  label to use {VARS.API_SDK_NAME} via a template literal, so it
  participates in the rename. Also imported VARS in sidebar.ts and
  applied the same fix to the "Oz CLI (legacy)" label I introduced
  earlier in this PR.
- (The flagged broken-markdown-link issue in reference/cli/api-keys.mdx
  was already fixed in a prior commit on this branch.)

Human review feedback (rachaelrenk):
- Fixed several places where "{VARS.WARP_AUTOMATION_PLATFORM} platform"
  would read as a duplicated word once the var's value changes to
  something like "Automation Platform" (e.g. "Automation Platform
  platform"). Removed the redundant literal "platform" suffix in 5
  MDX body occurrences and 2 frontmatter occurrences, since the var's
  value already conveys "platform" on its own.
- Wrapped the 6 Factories stub pages in an explicit sidebar group
  (matching how every other topic in sidebar.ts organizes its items)
  instead of leaving them as bare top-level entries, which is what
  was likely causing them to render as headings instead of pages
  under one collapsible "Factories" section.

Verified with npm run build (370 pages, clean), the internal link
checker (0 broken links), and style_lint.py --all (confirmed the
"Oz by Warp" reversions and "platform platform" fixes landed as
expected, no regressions).

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: remove {VARS.X} expressions from heading text (breaks TOC/anchors)

Starlight's "On this page" TOC and heading-anchor-id generation extract
heading text from the raw MDX AST before JSX expressions are evaluated,
so a heading like `### {VARS.WARP_AGENT_CLI}` doesn't render "Oz CLI"
in the TOC/anchor -- it renders the literal, unevaluated expression
source ("VARS.WARP_AGENT_CLI"), producing anchor ids like
"#varswarp_agent_cli" and a "On this page" entry reading
"VARS.WARP_AGENT_CLI" verbatim. The heading text in the page body
renders correctly (full MDX/JSX evaluation), so this only surfaces in
the TOC sidebar and in the URL fragment for that heading.

Found and fixed 40 occurrences across 21 files. In each case, reworded
the heading to avoid embedding a {VARS.X} expression, while keeping
{VARS.X} usable in the body prose beneath it (unaffected by this bug):
- Headings that were only "{VARS.X}" (e.g. "### {VARS.WEB_APP}") became
  static, descriptive text ("### Web app", "### CLI", "### API", etc.)
- Headings mixing static text + a var were reworded to drop the var
  while preserving meaning (e.g. "## How runners fit into the
  {VARS.WARP_AUTOMATION_PLATFORM}" -> "## How runners fit into cloud
  agent runs")
- The one historical changelog heading ("Introducing Oz: orchestration
  for cloud agents") was set to literal "Oz" text instead of the var,
  since it's a dated historical announcement and shouldn't silently
  reword itself when the var flips

Also fixed a related, unrelated heading collision on
agents/capabilities/computer-use/index.mdx: its own "## Overview"
heading collided with Starlight's synthetic top-of-page "Overview" TOC
entry (auto-generated for intro content before the first heading),
producing two adjacent "Overview" rows in the TOC. Renamed to
"## Capabilities" to match its actual content.

Per review feedback, also normalized the Computer Use API section to
consistently use {VARS.API_SDK_NAME} (matching the page's own later,
correct usage) instead of "{VARS.WARP_AUTOMATION_PLATFORM} API", since
both phrases link to the same /reference/api-and-sdk/ page and the
future name for that page is "Warp API & SDK", not "Automation
Platform API".

Verified with:
- npm run build (370 pages, clean)
- Inspected the built HTML for agents/capabilities/computer-use/index.html:
  TOC and anchor ids now read "Capabilities", "CLI", "API", "Web app"
  instead of "VARS.WARP_AGENT_CLI" / duplicate "Overview" / broken ids
- python3 .agents/skills/check_for_broken_links/check_links.py --internal-only (0 broken links)
- style_lint.py --all (no new hardcoded-var regressions)

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: use plain Warp instead of the automation-platform var on Agent Memory page

Per review feedback: "Agent Memory gives agents in Automation Platform
persistent memory..." reads awkwardly once the WARP_AUTOMATION_PLATFORM
var flips. Since "Warp" is already a locked, stable product name (not
rename-sensitive), it's the safer and more natural choice here.

Applied the same reasoning consistently across the rest of the page,
not just the flagged frontmatter line, since the same "lives on
Automation Platform" / "runs on Automation Platform" pattern recurs in
several other sentences and would have reintroduced the same
awkwardness once the var value changes:
- Frontmatter description
- "lives on Warp" / "part of Warp" / "run on Warp"
- "Warp extracts/saves/searches/creates..." (subject of a sentence)

Left one occurrence alone ("self-hosted {VARS.WARP_AUTOMATION_PLATFORM}")
since that specifically references the self-hostable orchestration
platform as a technical concept, not a generic "in Warp" phrasing.

Also normalized the "Programmatic API access" bullet to use
{VARS.API_SDK_NAME} instead of "{VARS.WARP_AUTOMATION_PLATFORM} API",
consistent with the same fix applied elsewhere in this PR (both link
to /reference/api-and-sdk/, and the correct future name is "Warp API
& SDK", not "Automation Platform API").

Verified with npm run build (370 pages, clean).

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: correct WARP_AUTOMATION_PLATFORM -> API_SDK_NAME mismatches (post-flip audit, round 1)

Following up on the "Automation Platform API" bug caught in review: audited
every {VARS.WARP_AUTOMATION_PLATFORM} usage across the docs for the same
class of issue and found it recurring in 14 more files (~25 occurrences).

Root cause: whenever prose names the actual API/SDK product surface (usually
as "the [X] API" linking to /reference/api-and-sdk/, or an "[X] API and SDK"
phrase), it must use {VARS.API_SDK_NAME} (future value "Warp API & SDK"),
not {VARS.WARP_AUTOMATION_PLATFORM} + a literal " API"/" SDK" suffix (which
would render the invented, non-canonical name "Warp Automation Platform
API" once the platform var flips). This is a wrong-var bug, not just a
grammar/redundancy issue -- the two vars name different things.

Fixed across: platform/overview.mdx, platform/quickstart.mdx,
reference/api-and-sdk/{index,quickstart,demo-sentry-monitoring-with-sdk}.mdx,
reference/api-and-sdk/troubleshooting/{index,errors/index}.mdx,
reference/cli/{index,artifacts}.mdx, reference/index.mdx,
platform/team-access-billing-and-identity.mdx,
support-and-community/plans-and-billing/{credits,platform-credits}.mdx,
guides/agent-workflows/how-to-run-multiple-ai-coding-agents.mdx.

Where a sentence names the API/SDK as a generic noun without further
qualification (not the proper name of the product), simplified to plain
"API"/"the API" instead of introducing an unnecessary var, e.g. "calls the
API (directly or via an SDK)" and "The Python SDK ... calls the API from
Python services".

Also applied the same generic-scaffolding-to-plain-"Warp" simplification
established on the Agent Memory page fix earlier in this PR, for sentences
like "another agent CLI outside of {var}" and "uploads to {var} --
screenshots...", since "Warp" is the stable, locked product name and reads
correctly regardless of how WARP_AUTOMATION_PLATFORM resolves.

One grammar fix: "An {VARS.WARP_AUTOMATION_PLATFORM} cloud environment"
(reference/api-and-sdk/quickstart.mdx) used "An" for agreement with "Oz"
today, but "Warp Automation Platform" needs "A" -- reworded to "A cloud
environment" to avoid the var/article dependency entirely.

Broader audit scope covered in this pass (per user direction, judging
DASHBOARD/PLATFORM_RUN under the same-shape assumption where their future
value is still TBD): swept the whole docs tree for the API_SDK_NAME
mismatch class, redundant trailing-word duplication (e.g. "platform
platform"), and "an {VAR}" article-agreement breaks across all six
rename-sensitive vars (WARP_AUTOMATION_PLATFORM, WARP_AGENT_CLI, WEB_APP,
DASHBOARD, PLATFORM_RUN, API_SDK_NAME). No further redundant-word or
article-agreement issues were found beyond what's fixed here.

Not yet exhaustively reviewed: the full ~300-occurrence long tail of plain
{VARS.WARP_AUTOMATION_PLATFORM} usages for subtler phrasing/tone issues
(the kind fixed on the Agent Memory page) -- flagging as a follow-up since
that requires reading full sentence context per occurrence rather than
pattern-matching, and is lower risk than the two bug classes fixed here.

Verified with:
- npm run build (370 pages, clean)
- check_for_broken_links.py --internal-only (0 broken links, 3495 checked)

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: round 2 of post-rename vars audit across the site

Continues the systematic sweep of {VARS.X} usages for issues that would
only surface after the Oz -> Warp Automation Platform rename ships.

Fixes applied:
- "platform...platform" duplicate wording (7 more instances across
  agents/index.mdx, enterprise/index.mdx, enterprise/getting-started/*,
  and root index.mdx), matching the earlier computer-use/index.mdx fix.
- Leftover un-migrated literal "Oz agents" / "@oz" mentions in
  reference/cli/integration-setup.mdx (missed in the original migration).
- Leftover un-migrated VideoEmbed title in platform/oz-web-app.mdx.
- Reworded platform/team-access-billing-and-identity.mdx:160, which
  incorrectly described personal-token auth as "authenticating as
  {platform}" instead of authenticating as the triggering user.

Policy decision (confirmed with user): changelog/2026.mdx entries are
dated historical records of what shipped under the Oz brand at the time.
Reverted all ~58 rename-sensitive var usages in that file
(WARP_AUTOMATION_PLATFORM, WARP_AGENT_CLI, PLATFORM_RUN, DASHBOARD,
WEB_APP, WEB_APP_URL) back to their current literal Oz-branded text, so
historical entries don't get silently rewritten when the rename ships.
This is consistent with the earlier "Introducing Oz" launch-heading fix
in the same file. Removed the now-unused VARS import from that file.

Verified: clean build (370 pages), 0 broken internal links, and no new
hardcoded-var lint regressions (all 71 remaining findings are pre-existing
exceptions in files untouched by this round).

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: swap Factories tab icon from server to setting (gear)

Starlight's built-in icon set has no literal factory glyph, so a true
factory-with-smokestack icon would need an icon-library plugin (e.g.
Phosphor or Material Symbols via starlight-plugin-icons) plus a Sidebar
component override -- out of scope for now. Using 'setting' (gear) as a
placeholder since it's the closest built-in match to automated machinery,
and it's visually distinct from the icons on the Terminal (laptop) and
Automation Platform (cloud-download) tabs.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: remove redundant top-level API tab, fix stale Oz icon check

The horizontal "API" tab duplicated a link already present in the
Reference tab's sidebar (API & SDK > API Reference > /api). Both pointed
to the same standalone Scalar-rendered page.

The original reason for splitting /api into its own top-level topic was
that Scalar is a different rendering framework than the rest of the
Astro/Starlight site, so /api can't have a normal per-topic sidebar tree
(hence it was a link-only topic with no `items`). That constraint only
explains why /api itself can't be a full Starlight topic -- it doesn't
require /api to also have its own top-level nav pill. The destination
remains fully reachable:
- From the Reference tab's existing "API Reference" sidebar link
- From WarpTopbar.astro's own breadcrumb/nav on the /api page itself,
  which already links back to "API & SDK" and "Quickstart"

Removing the topic entry needed no other changes: WarpTopicNav.astro just
renders whatever topics exist, and the search breadcrumb label map in
CustomSidebar.astro is keyed off URL segments, not the topic list.

Also fixed a related stale reference in WarpTopicNav.astro: the custom
cloud-icon override still checked `topic.label === 'Oz'`, left over from
before the Automation Platform rename. Updated to `'Automation Platform'`
so the custom SVG actually renders again instead of silently falling
back to Starlight's generic cloud-download icon. Removed the now-dead
`</>`-bracket icon branch for the deleted API topic.

Verified: clean build (370 pages, /api page itself untouched) and 0
broken internal links.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: rename Reference tab to "API & Reference", surface API Reference link

Per HYC/Rachael's Slack discussion following the top-level API tab
removal: HYC flagged that dropping the tab could make the standalone
Scalar-rendered /api page harder to discover. Two changes address that
without re-adding the redundant top-level tab:

1. Renamed the "Reference" tab to "API & Reference" so the tab label
   itself signals that API docs live there.
2. Promoted the "API Reference" link from 3 levels deep (Reference >
   API & SDK > 3rd item) to a new "Technical Reference" group at the very
   top of the tab's sidebar, as the first item -- immediately visible
   without expanding anything. The group's second item is a renamed
   self-link ("Overview") to the former bare "Technical reference" page
   link, following the same self-link-as-first-child pattern already used
   by other groups in this file (e.g. Self-hosting > Overview).

Also updated two lower-priority, non-interactive spots that mirrored the
old "Reference" label for consistency: the llms.txt generator's
customSets list (astro.config.mjs) and the search-result breadcrumb label
map (CustomSidebar.astro).

Verified: clean build (370 pages) and 0 broken internal links.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: put Overview before API Reference under Technical Reference

Order flip only, per feedback on the previous commit.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: restructure Cloud Agents group per HYC feedback

Addresses HYC's follow-up feedback on the Automation Platform tab:

1. Renamed the bare "Agents" sidebar item to "Cloud agent accounts",
   matching the page's own H1 exactly. The generic "Agents" label was
   confusing sitting inside a "Cloud Agents" group, and easily conflated
   with the different "agents" meaning used under Harnesses (Warp Agent,
   Claude Code, Codex).

2. Converted it into a small group and nested Skills as agents, MCP
   servers, and Secrets beneath it, replacing the removed "API / SDK"
   group entirely (which is now empty since its 4th item, a duplicate
   cross-link to /reference/api-and-sdk/, was already identified as
   actively breaking topic-detection for that page and removed).
   Skills and Secrets are literal properties of a cloud agent identity
   (POST /agent/identities accepts `skills` and `secrets` directly); MCP
   is per-run rather than identity-scoped, so added a bridging
   "## Capabilities" section to agents.mdx explicitly covering both
   identity-level and run-level capabilities.

3. Reordered the Cloud Agents group per HYC's note that individual cloud
   agents should be introduced before the tooling for monitoring them:
   Quickstart -> Oz platform -> Cloud agent accounts (+ capabilities) ->
   Viewing cloud agent runs -> Managing cloud agents -> Oz web app ->
   Handoff -> Harnesses -> Access/billing/identity -> FAQs.
   ("Managing cloud agents" was previously positioned above the page
   that actually defines what a cloud agent is.)

Verified: clean build (370 pages) and 0 broken internal links.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: rename subgroup to Warp Cloud Agents, relabel Overview to Cloud agent accounts

The subgroup label 'Cloud agent accounts' was too narrow for its actual
contents -- Skills as agents, MCP servers, and Secrets are cloud-agent
capabilities generally (per HYC/Rachael Slack discussion), not
account/identity-specific. Renamed the subgroup to 'Warp Cloud Agents'
(broader, factually accurate: all 4 pages are genuinely about cloud
agents) and moved the more specific 'Cloud agent accounts' label down to
just the Overview item (platform/agents.mdx), where it's fully accurate.

Accepted a slight nesting redundancy with the parent 'Cloud Agents'
group per explicit direction.

Verified: clean build (370 pages) and 0 broken internal links.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: lead Warp Cloud Agents with the Warp Agent page, move it above Oz platform

HYC review feedback on the restructured Cloud Agents group.

- Move the Warp Agent harness page into the Warp Cloud Agents subgroup as
  its Overview, and drop it from the Harnesses subgroup.
- Move the Warp Cloud Agents subgroup above the Oz platform entry.
- Point the Warp Agent page at its new siblings, splitting Related pages
  into the agents in this section and the harness comparison.

The page keeps its /platform/harnesses/warp-agent slug, so all six
inbound links stay valid and no redirects are needed. The Harnesses
overview still links to it, so it remains reachable from that group.

Cloud agent accounts stays its own page: it carries the
/agent/identities endpoint table, plan limits, service accounts, and
pull request authorship rules, none of which the harness page covers.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix: land the Automation Platform tab on the platform overview

The tab pointed at /platform/, so clicking "Automation Platform" opened a
page titled "Cloud agents overview". The platform overview it should have
opened already exists at /platform/overview.

Retarget the tab to /platform/overview/ and move /platform/ into the
Cloud Agents group as that group's Overview.

Did not swap the two page bodies, which was the other option considered.
The URLs are already aligned with their content, and each carries 16
legacy redirects that match:

  /platform/overview  <- /agent-platform/warp-platform,
                         /cloud-agents-platform, /agent-platform/platform
  /platform/          <- /agent-platform/ambient-agents,
                         /cloud-agents-overview

Swapping the bodies would have sent all 32 legacy URLs to the opposite of
what they ask for, inverted 17 internal links across 10 files that read
"the Automation Platform" and point at /platform/overview/, and broken an
#execution-hosts anchor link from platform/environments.mdx.

Precedent for a non-root tab target: the Changelog tab links to
/changelog/2026/.

Also on the platform overview:

- Add a Warp Factories section, framed as composing the primitives the
  page describes. The page previously mentioned Factories zero times,
  which is a gap now that Factor  which is a gap now that Factor  which is  th  which is a gap now that Factor  which is a gap now that Factor  whicexp  which is a gap now that Factor  which is a gap now that Factor  duplicated "Using cloud agents with or without the Warp
  app" section with a "Where to g  app" section with a "Where to g  app" section with a "Where to g  appch   app" section with a "Where to g  app" section with aunt stays at 2037.

Co-Authored-By: Warp Agent <agent@warp.dev>

* refactor(sidebar): split agent runtime from agent configuration

Per HYC's review on 8/14, which chose Option 1 from the three proposed.
This supersedes 763abea, which made the Warp Agent harness page the
Overview of a "Warp Cloud Agents" group. That group mixed one
Warp-Agent-specific page with four cross-harness ones, so a Codex user
looking for Secrets had to find it under a Warp-branded heading.

Cloud Agents now reads:

  Overview / Quickstart
  Harnesses           Overview, Warp Agent (Default), Claude Code,
                      Codex, Authentication
  Agent configuration Cloud agent accounts, Skills as agents,
                      MCP servers, Secrets
  Operations          Session sharing, Managing cloud agents, Oz web app
  Handoff
  Access, billing, and identity / Cloud agent FAQs

HYC asked to confirm everything in Agent configuration is cross-harness,
and flagged Cloud agent accounts as a likely exception. Audited all four:

- platform/agents        zero references to any harness, Warp Agent,
                         Claude, or Codex
- skills-as-agents       - skills-as-agents       - skills-as-agents       - skills-as-agent   uses OPENAI_API_KEY as its example; both
                         third                         third                         thirdharness constraint

So nothing needed calling out. Recorded in a sidebar comment so the
group does not silently reacquire Warp-specific pages.

Operations groups the three surfaces HYC lisOperations groups the three surfaces HYC lisOperations groups theg Operations groups the three surfaces HYC lup. The name mirrors the "Management and observability"
section of the platform overview, which covers thessection of the platform overview, which covers thessection of the platrom "Viewing cloud agent
  runs" to "Session sharing". The page is titled "Cloud agent session
  sharing", so the old label sent readers somewhere they did not expect.
- Revert the Related pages split on warp-agent.mdx from 763abea. The
  "agents in this section" framing only held while that page was a
  section overview.
- Delete the old collapsed Harnesses group, which would otherwise have
  listed the same four pages twice.

No slugs change: no redirects, no broken links, route count still 2037.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix(platform): correct group label, heading levels, and two content issues

From a top-to-bottom review of the Automation Platform tab.

Sidebar

- Rename the 'Self-hosting' group to 'Deployment and hosting'. The group
  holds a comparison page, a Warp-HOSTED page, and the self-hosting set,
  so the old label filed 'Warp-hosted agents' under its own opposite.
- Qualify two labels inside that group. With the group renamed, a bare
  'Overview' and 'Quickstart' read as the group's rather than
  self-hosting's. Both now match their page titles.

deployment-patterns.mdx

- Promote every heading one level. The page had no H2 at all: it opened
  with an H4, used H3 for its three patterns, and H4 beneath. Starlight
  builds the on-page table of contents from H2s, so the page had none.

integrations/bitbucket.mdx

- 'Step 4: Test your environment' was an H2 while Steps 1-3 were H3s
  under the two H2 deployment variants, so Step 4 rendered as a sibling
  of the variants rather than continuing either sequence. It is a   of the variants rather than continuing either sequence. It is a   ofso.

integrations/index.mdx

- Drop the second of two consecutive :::note ca- Drop the second of two coegration setup, which the Get started list alr- Drop the second of two consecutive :::note ca- Drop the second of he {WARP_AGENT_CLI}'. Integrations
  run on the platform; the CLI is one trigger among six, which the
  Triggers page states plainly. The replacem  Triggers page states plainly. The replacem  Triggers page slugs change: no redirects, no broken links, route count still 2037.

Co-Authored-By: Warp Agent <agent@warp.dev>

* refactor(sidebar): split Triggers and Integrations into sibling groups

Triggers was nested inside Integrations, which inverted the concept.
platform/triggers lists integrations as one of six trigger types,
alongside schedules, the CLI, the API, GitHub, and GitHub Actions. So
the content said Triggers contains Integrations while the nav said the
reverse. The sidebar comment showed the nesting was inherited from an
earlier prototype rather than chosen.

They are now siblings:

  Triggers        Triggers overview, Scheduled agents quickstart,
                  Scheduled agents
  Integrations    Integrations overview, Integrations quickstart, Slack,
                  Linear, Jira, GitHub, GitHub Actions, Azure DevOps,
                  Bitbucket, GitLab, cloud providers

Siblings rather than nesting Integrations under Triggers, which would
have pushed 11 pages four levels deep for a relationship the overview
pages can state in prose.

Also add the return cross-link. Triggers already pointed at Integrations
three times; Integrations did not point back. Its intro now names
Triggers as the full set of ways to start a run.

Grouping is independent of slugs, so no files move, no redirects, and no
links change. 52 pages links change. 52 pages links change. 52 pages links change. 52 pt@warp.dev>

* refactor(sidebar): merge Triggers & integrations, collapse level-2 groups

Supersedes 248e603, which split Triggers and Integrations into sibling
groups. Siblings implied the two are peers, which they are not:
platform/triggers lists integrations as one of six trigger types. But
nesting either inside the other is also wrong -- Triggers under
Integrations inverts the concept, and Integrations under Triggers buries
11 pages four levels deep. A single group named for both sidesteps the
question, and the overview pages carry the actual relationship in prose.

The return cross-link added in 248e603 stays. Triggers overview is still
a distinct page, and the Integrations intro still needs to name it as the
full set of ways to start a run.

Separately, collapse the three level-2 groups added in 42b8422:
Harnesses, Agent configuration, and Operations. Every other level-2 group
on the site already sets collapsed: true -- Blocks, Capabilities,
Interacting with agents, Handoff, GitHub Actions -- so these three were
the only ones expanding on load, which made the tab open long and
inconsistent with the rest of the docs.

Also normalize the indentation of the ClouAlso normalize the indentation of the ClouAlso han its siblings. No rendering change.

52 pages in the tab, none listed twice. No slugs change.

Co-Authored-By: Warp Agent <agent@warp.dev>

* refactor(sidebar): nest Scheduled agents and Integrations subgroups

Shortens the Triggers & integrations group from 14 visible rows to 3.

  Overview                  platform/triggers
  Scheduled agents          collapsed: Overview, Quickstart
  Integrations              collapsed: Overview, Quickstart, Slack, Linear,
                            Jira, GitHub, GitHub Actions, Azure DevOps,
                            Bitbucket, GitLab, cloud providers

Both new subgroups follow the Overview-then-Quickstart shape the GitHub
Actions subgroup already uses. Nesting GitHub Actions one level deeper
matches existing precedent: the Agents tab nests Computer Use inside
Capabilities inside Warp Agents.

platform/triggers becomes the group overview, so its intro now names
integrations explicitly instead of only 'schedules, webhooks, or other
automation patterns'.

Kept both overview pages rather than merging them into one. Merging
would mean deleting a page, and the two are not comparable:
platform/integrations has 20 inbound links and 19 legacy redirect
sources, against 4 and 0 for platform/triggers. Deleting the more
established of the two to save a single sidebar row is a bad trade, and
with Integrations now a subgroup it needs its own overview regardless.

52 pages in the tab, none listed twice. No slugs change.

Co-Authored-By: Warp Agent <agent@warp.dev>

* fix(platform): hardcode @oz mention handle instead of variabilizing it

18 places across 9 files wrote the Slack and Linear mention handle as
@{VARS.WARP_AUTOMATION_PLATFORM}. That renders as "@oz" today, so it
looks correct, but the variable flips to the new product name at rename.
Every one of these would have silently become "Tag @automation Platform
in a message" -- an invalid handle -- with nothing failing in CI to catch
it.

A mention handle is a literal string a user types. It is not the product
name appearing in prose, and it does not necessarily change when the
product name changes. The GitHub handle was already correctly hardcoded
as @oz-agent in 31 places; this brings Slack and Linear in line.

Rendering is unchanged: WARP_AUTOMATION_PLATFORM is currently "Oz", so
these already displayed as "@oz".

Also teaches the style linter the same distinction. The hardcoded-var
rule matched "Oz" inside "@oz" via its word boundary, so hardcoding
raised the repo total from 1148 to 1167. The rule now skips an
"@"-prefixed occurrence. The exemption is per-occurrence, not per-line:
a line containing both "@oz" and "Oz web app" still flags the latter.
Repo total is back to 1148.

The correct post-rename handle is still an open product question. It is
flagged inline on the changed lines for review.

Co-Authored-By: Warp Agent <agent@warp.dev>

* Add a hairline separator above the page footer CTA

HYC's review asked for a visual break between page content and the
"See something wrong? Edit this page or open an issue" CTA, which
previously ran on directly after the last line of prose and read like a
trailing sentence of the article.

Adds a border-top to the page footer in FeedbackFooter.astro, using the
same treatment already applied to the "On this page" panel footer in
CustomPageSidebar.astro (1px, --sl-color-hairline-light). The rule sits
inside .sl-container, so it spans the content column rather than
full-bleed like Starlight's ContentPanel divider.

Also drops a dead `margin-top: 2rem` from the same rule. The footer is a
sibling of .sl-markdown-content inside Starlight's ContentPanel, whose
`.sl-container > * + *` rule (0,1,1) outranks a bare `footer` selector
(0,0,1), so the gap above the footer has always been 1.5rem. Space below
the rule is now set with padding-top, which nothing else targets, so the
1.5rem above and below is symmetric and under our control.

The /api reference is unaffected: it renders DocsFeedbackLinks in its own
fixed-position card, not through this footer.

Verified: build clean at 370 pages; the separator renders on standard and
splash (404) pages; /api emits no page footer.

Co-Authored-By: Warp <agent@warp.dev>

* refactor(sidebar): shorten the Support tab and relabel two platform groups

Addresses HYC's final round of structural feedback on the tab bar and the
Automation Platform tab.

- 'Support & Community' -> 'Support'. The horizontal tab bar was wrapping
  to a second line early; this was the longest label after 'Automation
  Platform'. Total tab-label length drops from 102 to 89 characters across
  the 9 tabs, a 13% trim, and 'Automation Platform' (19) and
  'API & Reference' (15) are now the longest remaining.
- Community group moved to the bottom of the Support tab. Readers enter
  this tab for help far more often than for community links, so
  troubleshooting, plans and billing, and privacy now come first.
- 'Deployment and hosting' -> 'Deployment & hosting'.
- 'Operations' -> 'Management & Observability', matching the section name
  already used on the platform overview.

Labels only. No slugs, redirects, or page content change.

Verified in built output: the Support tab renders with group order
Troubleshooting -> Plans -> Privacy -> Community; 'Operations' and
'Deployment and hosting' no longer appear anywhere; build clean at 370
pages.

Co-Authored-By: Warp <agent@warp.dev>

* refactor(sidebar): label follow-ups on the Support and platform tabs

Two consistency fixes on top of the previous commit.

- Support tab's bare first item: 'Support and Community' -> 'Overview'.
  The tab is now 'Support', so repeating the old two-part name in the
  first item was stale. 'Overview' also matches the bare first item on the
  Automation Platform, API & Reference, and Enterprise tabs. The page's own
  'Support & Community' H1 and title are intentionally left alone, so the
  page keeps its search and SEO surface.
- 'Management & Observability' -> 'Management & observability', matching
  the sentence case used by its sibling labels ('Triggers & integrations',
  'Infrastructure & security') and by the platform overview section of the
  same name.

Verified in built output: no 'Support and Community' left in the sidebar,
the page title still renders, and no capital-O variant survives.

Co-Authored-By: Warp <agent@warp.dev>

---------

Co-authored-by: Warp Agent <agent@warp.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants