Factory launch (8/18): Automation Platform rename infra + Factories tab scaffold - #513
Open
rachaelrenk wants to merge 32 commits into
Open
Factory launch (8/18): Automation Platform rename infra + Factories tab scaffold#513rachaelrenk wants to merge 32 commits into
rachaelrenk wants to merge 32 commits into
Conversation
- 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>
…etting-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>
…ion 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>
…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>
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>
…-vars-reference' into rrenk/factory-launch-restructure
…-vars-guides-support' into rrenk/factory-launch-restructure
…-vars-platform' into rrenk/factory-launch-restructure
- 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>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Overview
This PR scaffolds the Factories tab, reorganizes the platform docs IA, adds rename variables for the Oz → Automation Platform transition, and updates the CLI/API docs with deprecation and rebrand wording. The broad structure is coherent, but I found three blocking rename-infrastructure/docs-rendering issues that would leave broken links or stale/incorrect product names after the flip. No security findings were found, and no approved spec context was available for spec-drift review.
Concerns
- Several new Markdown links put
{VARS.WEB_APP_URL}directly in the link destination. MDX does not evaluate expressions in Markdown hrefs, so these links render with literal/encoded{VARS.WEB_APP_URL}destinations instead of the Oz web app URL. - Several references variableize the
Oz by Warp GitHub Appproper name withWARP_AUTOMATION_PLATFORM; when that value flips, the docs will refer to a different/nonexistent GitHub App name. - The new sidebar cross-link hardcodes
Oz API & SDK reference, so it will not participate in theAPI_SDK_NAMErename flip that this PR introduces.
Verdict
Found: 1 critical, 2 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
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>
…oute 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>
|
Deployment failed for project docs with the following error: Learn More: https://vercel.link/invalid-route-source-pattern |
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>
rachaelrenk
commented
Aug 12, 2026
rachaelrenk
commented
Aug 12, 2026
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>
rachaelrenk
commented
Aug 13, 2026
| title: Agent Memory (Research Preview) | ||
| description: >- | ||
| Agent Memory gives agents in Oz persistent memory across supported harnesses, | ||
| Agent Memory gives agents in {{WARP_AUTOMATION_PLATFORM}} persistent memory across supported harnesses, |
Contributor
Author
There was a problem hiding this comment.
Currently renders as:
Agent Memory gives agents in Oz persistent memory across supported harnesses,
After the 8/18 launch, it will read:
Agent Memory gives agents in [the] Automation Platform persistent memory across supported harnesses,
Assuming that the platform name ends up being "Automation Platform", this is an awkward update to the description. In an instance like this, it makes more sense to update to "Warp" generally, like:
Agent Memory gives agents in Warp..
seems like the more logical and safe option. In which case, we should just update this now to "Warp" instead of "Oz"? wdyt @hongyi-chen
Collaborator
There was a problem hiding this comment.
yeah let's change to Warp
rachaelrenk
commented
Aug 13, 2026
rachaelrenk
commented
Aug 13, 2026
rachaelrenk
commented
Aug 13, 2026
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>
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>
…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>
This was referenced Aug 13, 2026
…z 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>
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>
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>
…ssues
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>
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>
…oups 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>
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>
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>
rachaelrenk
commented
Aug 14, 2026
rachaelrenk
left a comment
rachaelrenk
left a comment
Contributor
Author
There was a problem hiding this comment.
Open question for 8/18: what does the Slack / Linear mention handle become?
The bug this commit defuses. 18 spots across 9 files wrote the mention handle as @{VARS.WARP_AUTOMATION_PLATFORM}. That renders as @Oz today, so it reads correctly — but the variable flips to the new product name at rename, which would have silently turned every one of them into Tag @Automation Platform in a message. An invalid handle, in copy-paste instructions, with nothing in CI to catch it.
A mention handle is a literal string a user types. It isn't the product name in prose, and it doesn't necessarily change when the product name does. The GitHub handle was already correctly hardcoded as @oz-agent in 31 places — Slack and Linear were the outliers. They're now hardcoded to @Oz, so rendering is unchanged and the rename can't break them.
This is a holding action, not the answer.
What we need from product
On 8/18, does the Slack/Linear handle stay @Oz, or change?
- If it stays — consistent with the
ozCLI binary andoz.warp.dev, both of which survive per Zach's 8/18 note — these lines are already correct and need nothing further. - If it changes, all 18 spots below need the new handle. Worth confirming at the same time whether
@oz-agentfor GitHub changes alongside it, or whether the two intentionally diverge.
All 18 locations
GitHub truncates the patch for most of these files, so only two could take an inline comment. Full list:
| File | Count | Note |
|---|---|---|
platform/integrations/quickstart.mdx |
4 | Most of any page, and the one most likely to be copied literally by a new user |
platform/integrations/linear.mdx |
3 | One of the two surfaces using this handle |
platform/team-access-billing-and-identity.mdx |
2 | Line 70 uses both handles — @Oz for Slack/Linear, @oz-agent for GitHub. If they diverge, this sentence needs both answers |
platform/integrations/azure-devops.mdx |
2 | Slack + Linear, in Next steps |
platform/integrations/bitbucket.mdx |
2 | Slack + Linear, in Next steps |
platform/integrations/gitlab.mdx |
2 | Slack + Linear, in Next steps |
platform/environments.mdx |
1 | Example of triggering a run from Slack |
platform/oz-web-app.mdx |
1 | Inside the integrations table |
reference/cli/integration-setup.mdx |
1 | Only one outside the platform section — easiest to miss in a follow-up sweep |
To re-find them all: grep -rn '@Oz' src/content/docs
| import { VARS } from '@data/vars'; | ||
|
|
||
| Oz integrations let you trigger cloud agents directly from the tools your team already uses. This guide walks you through connecting Oz to Slack. Once set up, anyone on your team can tag @Oz in a message or thread to kick off a cloud agent that runs the task and posts results back to the conversation. | ||
| {VARS.WARP_AUTOMATION_PLATFORM} integrations let you trigger cloud agents directly from the tools your team already uses. This guide walks you through connecting {VARS.WARP_AUTOMATION_PLATFORM} to Slack. Once set up, anyone on your team can tag @Oz in a message or thread to kick off a cloud agent that runs the task and posts results back to the conversation. |
Contributor
Author
There was a problem hiding this comment.
Mention handle — 4 occurrences in this file, the most of any page.
This is the integrations quickstart, so it's the page a new user is most likely to copy literally. If @Oz changes on 8/18, this page matters most.
See the review summary for the full 18-location inventory.
| ### Triggering agents inside Linear | ||
|
|
||
| Tagging @Oz on an issue or in a Linear comment starts an agent run. Oz clones the repositories defined in your environment, sets up your development environment using your Docker image and setup commands, and begins working through the task with full context from your codebase and the Linear issue. Agents post updates as they progress, including a task list, elapsed time, and checkpoints, so you can follow along without leaving Linear. | ||
| Tagging @Oz on an issue or in a Linear comment starts an agent run. {VARS.WARP_AUTOMATION_PLATFORM} clones the repositories defined in your environment, sets up your development environment using your Docker image and setup commands, and begins working through the task with full context from your codebase and the Linear issue. Agents post updates as they progress, including a task list, elapsed time, and checkpoints, so you can follow along without leaving Linear. |
Contributor
Author
There was a problem hiding this comment.
Mention handle — 3 occurrences in this file.
Linear is one of the two surfaces that use this handle. Does @Oz stay after 8/18, or change?
See the review summary for the full 18-location inventory.
Contributor
|
I'm working on changes requested in this PR (responding to a PR review body). You can view the conversation on Warp. Powered by Oz |
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements the docs IA restructure + Oz→Automation Platform rename infrastructure for the 8/18 Warp Factories soft launch. See the plan for full context.
Scope: IA restructure and rename mechanics only. Does not include authoring the actual Factories page content (HYC will workshop) or the
vars.tsvalue flip itself (a separate follow-up PR on/near launch day).What's in this PR
/factories/) with 6 stub pages (Overview, Quickstart, How Factories work, Configure your Factory, Connect your Factory, Infrastructure & security) matching HYC's IA doc. Each stub has real frontmatter and a bracketed content outline for HYC/content to fill in.platform/,reference/,agents/,terminal/,guides/,support-and-community/,enterprise/,changelog/, root).style_lint.py'sRENAME_SENSITIVE_VAR_STRINGSextended to catch bare "Oz", "Oz Platform", and "Oz API & SDK"; newAPI_SDK_NAMEandFACTORY_WEB_APP/FACTORY_WEB_APP_URLvars added.:::cautionbanner added to all 11reference/cli/*pages pointing to the Warp Agent CLI docs; sidebar relabeled "Oz CLI (legacy)". No banner added tooz-web-app.mdxorreference/api-and-sdk/*since there's no live replacement for either yet..agents/references/terminology.mdentries for Automation Platform (flagged pending naming confirmation) and baseline Warp Factories terms./platform/software-factory→/factories/invercel.json; source content kept (not deleted) as material for HYC's Factories-tab migration.style_lint.py's hardcoded-var check now uses word-boundary matching (was a substring check causing false positives) and recognizes JSX-expressionVideoEmbedtitles./apipage). The Scalar-vs-Astro rendering split that originally motivated the separate top-level tab only explains why/apican't have a full Starlight sidebar tree — it doesn't require/apito also have its own nav pill, and the page remains fully reachable from Reference's sidebar and its own topbar nav. Also fixed a staletopic.label === 'Oz'check inWarpTopicNav.astro(dead since the Automation Platform rename) so the custom cloud icon override renders again instead of silently falling back to a generic icon./api. Renamed the "Reference" tab to "API & Reference" and promoted the "API Reference" link from 3 levels deep (Reference > API & SDK > 3rd item) to a new "Technical Reference" group as the very first item in the tab's sidebar, followed by an "Overview" link to the reference landing page. Also updated the matching label in the llms.txtcustomSetslist and the search-result breadcrumb map for consistency./reference/api-and-sdk/that was actively breaking topic-detection for that page (Automation Platform's topbar tab would incorrectly show as active whenever a reader landed on that page, sincestarlight-sidebar-topicsresolves ties by array order).POST /agent/identities, not agents generically). Added a "## Capabilities" section to that landing page bridging identity-level properties (Skills, Secrets) and per-run capabilities (MCP).Validation
npm run build— 370 pages, clean buildstyle_lint.py --all— hardcoded-var issues reduced from ~all-124-files to 67 remaining, all confirmed intentional exceptions (GitHub App proper names like "Oz by Warp", screenshot alt text describing actual visible branding, code fences, CLI command examples)check_links.py --internal-only— 0 broken links after all IA changes, including the Cloud Agents restructuringKnown open items / follow-ups
platform/oz-web-app.mdxintentionally left without a deprecation banner (per direction that the legacy Oz web app stays as-is until 9/15).Co-Authored-By: Warp Agent agent@warp.dev