Refresh browser pool guides and standardize on "browser pools" - #464
Refresh browser pool guides and standardize on "browser pools"#464andrewleesteele wants to merge 27 commits into
Conversation
Add a Browser Pools Quickstart, move the pool guides from Advanced to Basics, and use "browser pools" as the single name for the concept everywhere in the docs (the API, SDKs, CLI, and dashboard already do). Push pools as the production path from the Create page, the home page, and the Scale guide, and lead with the fact that idle pooled browsers aren't billed.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
Note: Hypeship prematurely created this PR...still thinking necessary changes through. |
- Document that reuse: true persists browser state across acquisitions (not isolated) and reuse: false is the clean/per-user path, with a multi-tenant leak warning. - Explain why acquiring is faster than browsers.create(): pre-applied restart-triggering configs and no create-endpoint rate limit. - Point the read-only-profile note at the per-user-profiles pattern instead of a standalone session. - Fold two update-semantics FAQ entries into one pointer to the canonical Update a pool section; align the fill-rate example with the 25% default. - Keep the Browser Pools nav group in Advanced for now. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pools quickstart is being folded into a future unified Kernel quickstart rather than living as a feature-specific guide. Delete the page and its nav entry, and repoint the six inbound links (home, pricing, concepts, create, scale, and the overview callout) to the browser pools overview. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD is0ca62af, which removesbrowsers/pools/quickstart.mdx, drops itsdocs.jsonnav entry, and retargets intro/home links to the overview. That narrows scope; it does not raise risk.Evidence (from full diff vs base)
- 10 files, all Mintlify docs:
.mdxcontent plus adocs.jsonnav label rename (Reserved Browsers→Browser Pools).- Content/terminology updates and example code blocks on pools overview, FAQ, create, scale, pricing, concepts, and related pages.
- No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
- No CODEOWNERS file requiring a separate owner approval.
Why this level
- Documentation-only surface with no production logic or shared runtime impact.
- Blast radius limited to published docs/nav; easy to reason about and revert.
Actions taken
- Risk unchanged at Very Low → did not dismiss prior approval.
- Did not re-approve (approval already present).
- Did not assign or request reviewers.
Sent by Cursor Automation: Assign PR reviewers
Position browser pools as the step you reach when taking a working automation to production, after learning to create and drive a browser — rather than "most production workloads run on them from day one," which pushes them before the fundamentals. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD isad048aa. Since that approval, the branch removed the browser-pools quickstart (already assessed) and made a one-line home-page copy reframe inindex.mdx. That does not raise risk.Evidence (from full diff vs base)
- 10 files, all Mintlify docs:
.mdxcontent plus adocs.jsonnav label rename (Reserved Browsers→Browser Pools).- Terminology, guidance, and example code-block updates across pools overview/FAQ, create, scale, pricing, concepts, and related pages.
- No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
- No CODEOWNERS file requiring a separate owner approval.
Why this level
- Documentation-only surface with no production logic or shared runtime impact.
- Blast radius limited to published docs/nav; easy to reason about and revert.
Actions taken
- Risk unchanged at Very Low → did not dismiss prior approval.
- Did not re-approve (approval already present).
- Did not assign or request reviewers.
Sent by Cursor Automation: Assign PR reviewers
Move the one piece of guidance the overview lacked — pool sizing via available_count — into a Sizing section, and drop the FAQ page. Its other entries duplicated overview sections (update, reuse, timeout, profiles) or belonged elsewhere (target-site rate limiting, debugging). Repoint the auth/profiles link to the per-user-profiles section. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD is8f38449. Since that approval, the branch removed the browser-pools quickstart, reframed home-page copy, folded the FAQ into the overview (deletedbrowsers/pools/faq.mdx), added a short sizing section, and retargeted a profiles link. That does not raise risk.Evidence (from full diff vs base)
- 11 files, all Mintlify docs:
.mdxcontent plusdocs.jsonnav updates (Reserved Browsers→Browser Pools; FAQ page removed from nav).- Terminology, guidance, and example code-block updates across pools overview, create, scale, pricing, concepts, and related pages.
- No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
- No CODEOWNERS file requiring a separate owner approval.
Why this level
- Documentation-only surface with no production logic or shared runtime impact.
- Blast radius limited to published docs/nav; easy to reason about and revert.
Actions taken
- Risk unchanged at Very Low → did not dismiss prior approval.
- Did not re-approve (approval already present).
- Did not assign or request reviewers.
Sent by Cursor Automation: Assign PR reviewers
Apply the naming rule to cross-page references (home, pricing, projects, scale, create, proxies, reference, integrations) and the pools overview intro so the feature is never shortened to "pool" — which collides with connection pools, IP pools, and socket pools elsewhere in the docs. Non-browser-pool uses (curl connection/socket pools, proxy IP/ISP pools) are intentionally left for their own qualifiers. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD isfd9c595. Since that approval, the branch removed the browser-pools quickstart, folded/deleted the FAQ, reframed home-page copy, and (latest) spell-out terminology updates replacing bare "pool" with "browser pool" across docs. That does not raise risk.Evidence (from full diff vs base)
- 16 files, all Mintlify docs:
.mdxcontent plusdocs.jsonnav updates (Reserved Browsers→Browser Pools; FAQ page removed from nav).- Terminology, guidance, and example code-block updates across pools overview, create, scale, pricing, concepts, and related pages; FAQ deleted.
- No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
- No CODEOWNERS file requiring a separate owner approval.
Why this level
- Documentation-only surface with no production logic or shared runtime impact.
- Blast radius limited to published docs/nav; easy to reason about and revert.
Actions taken
- Risk unchanged at Very Low → did not dismiss prior approval.
- Did not re-approve (approval already present).
- Did not assign or request reviewers.
Sent by Cursor Automation: Assign PR reviewers
…s-docs-refresh # Conflicts: # browsers/chrome-policies.mdx # docs.json
With the FAQ folded in and Chrome policies moved out (#469), the section is one page. Move browsers/pools/overview.mdx → browsers/pools.mdx so it serves at /browsers/pools, retitle it "Browser Pools", and collapse the nav group to a single entry. Repoint every /browsers/pools/overview link to /browsers/pools, fix a stale #create-a-pool-of-reserved-browsers anchor, and add a redirect from the old overview path. Changelog's bare /browsers/pools links now resolve to a real page. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Refer to on-demand browsers rather than browsers.create() in prose, and drop the size/fill-rate parameter mismatch: the code sample and API reference own parameter names and defaults, not the prose. - Cut the fill-rate link from five places to one, in Sizing, where you'd act on it. - Give flush its own short section under Update, where it's the remedy for stale configuration, and restore the two links that pointed at it. - Say "browser pool" at each section's first mention, keeping "the pool" only for back-references; rename the Create, Update, and per-user headings to match, updating the links that referenced them. - Remove three more restatements: the Create lead repeated the Steps block, the Update warning re-explained discard_all_idle, and the per-user lead repeated the read-only paragraph above it. - Soften releasing into a best practice rather than an instruction, and trim the Managed Auth mention to a pointer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval remains in effect. Latest HEAD is
f6abf40. Diff vs merge base is still documentation-only: Mintlify.mdxpages plusdocs.jsonnav/redirect updates.Latest delta since the prior assessment (
d75d11b→f6abf40): prose/structure polish inbrowsers/pools.mdx, plus two cross-link/anchor wording tweaks inauth/profiles.mdxandbrowsers/chrome-policies.mdx.Evidence (from diff only)
- 26 files, +408 / −722 — all
.mdxordocs.json- Consolidates browser pools docs (
browsers/pools.mdx), deletes oldbrowsers/pools/overview.mdxandfaq.mdx, updates cross-links and terminology- Adds redirect
/browsers/pools/overview→/browsers/poolsand flattens sidebar entry indocs.json- Expands intro guidance in
introduction/create.mdxandintroduction/scale.mdx(examples and prose only)- No application code, CI, infra, auth, billing logic, or schema changes
- No
CODEOWNERSfile in the repoRisk factors
Factor Assessment Codepaths / production logic None Blast radius Docs site content and navigation only Infrastructure None Security / auth None Action
No approval change. Risk remains Very Low; not re-approving because an automation approval is already present.
Sent by Cursor Automation: Assign PR reviewers
The intro stated the same idea three times — configure once, get pre-configured browsers — and never actually said what a browser pool is. Replace it with three paragraphs doing one job each: what a browser pool is, why acquiring is faster, and what it costs. The Chromium restart becomes part of the start-up point rather than a third parallel clause. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD isa4c7e45. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to/browsers/pools, Scale-page rewrite, pools-page restructuring). Latest delta (f6abf40→a4c7e45) edits a single file (browsers/pools.mdx): rewrites the intro into a clearer definition / latency / cost framing. That does not raise risk.Evidence (from full diff vs base)
- 26 files, all Mintlify docs:
.mdxcontent plusdocs.jsonnav/redirect updates (Reserved Browsers→ singlebrowsers/poolsentry; FAQ removed;/browsers/pools/overview→/browsers/pools).- Terminology, guidance, and example code-block updates across pools, create, scale, pricing, concepts, and related pages; FAQ and old overview deleted in favor of one pools page.
- Latest delta: 1 file, docs prose only (+4 / −2).
- No application code, APIs, auth, infra, schema, deploy config, or model-prompt instruction files.
- No CODEOWNERS file requiring a separate owner approval.
Why this level
- Documentation-only surface with no production logic or shared runtime impact.
- Blast radius limited to published docs/nav; easy to reason about and revert.
Actions taken
- Risk unchanged at Very Low → did not dismiss prior approval.
- Did not re-approve (approval already present).
- Did not assign or request reviewers.
Sent by Cursor Automation: Assign PR reviewers
- Drop the "size is always required on update" note: size is optional on update (required only on create), and following the note risks resizing the pool as a side effect of an unrelated config change. - Fix the Go update sample, which passed a bare int for an optional field. - Rework the sizing section: gloss available_count/acquired_count in prose, and match the page's bold-lead-in bullet pattern. - Fold the one-line flush subsection into the update warning that already referenced it, and add flush to the API reference pointer. - Drop the "pre-" from the page description. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD isd67b61c. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to/browsers/pools, Scale/Create rewrites, pools-page tightening).Latest delta since the prior assessment (
a4c7e45→d67b61c): copy and sample fixes inbrowsers/pools.mdxonly — drop incorrect “size always required on update” guidance, correct the Go update sample (kernel.Int(20)), rework sizing bullets, and fold flush into the existing update warning. That does not raise risk.Evidence (from diff only)
- 26 files, +402 / −722 — all Mintlify
.mdxordocs.json- Consolidates browser pools docs onto
/browsers/pools, adds overview→pools redirect, updates nav- Cross-page link/terminology updates (“browser pool”) and intro/scale/pricing prose
- No application code, infra, auth/billing logic, schemas, or shared libraries
- No
CODEOWNERSrequirement foundDecision
Risk remains Very Low. Prior approval stands; not re-approving.
Sent by Cursor Automation: Assign PR reviewers
A browser pool and browsers.create() are two ways of provisioning the same browser, not two instruments to pick between, so "the right tool" reads oddly here. Use the verb the section below already uses. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD is327ca95. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to/browsers/pools, Scale/Create rewrites, pools-page tightening).Latest delta since the prior assessment (
d67b61c→327ca95): one-line copy edit inintroduction/scale.mdx("when a browser pool is the right tool" → "when to reach for a browser pool"). That does not raise risk.Evidence (from diff only)
- 26 files, +402 / −722 — all Mintlify
.mdxordocs.json- Consolidates browser pools docs onto
/browsers/pools, adds overview→pools redirect, updates nav- Cross-page link/terminology updates and intro/scale/pricing prose
- No application code, infra, auth/billing logic, schemas, or shared libraries
- No
CODEOWNERSrequirement foundDecision
Risk remains Very Low. Prior approval stands; not re-approving.
Sent by Cursor Automation: Assign PR reviewers
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want fixes drafted automatically? Bugbot Autofix can create code changes for findings. A team admin can enable Autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 327ca95. Configure here.
| Browser curl concurrency is constrained by Chromium's internal networking limits: | ||
|
|
||
| - **HTTP/1.x (direct)** — About 6 sockets per host group and up to 256 active sockets per pool. | ||
| - **HTTP/1.x (direct)** — About 6 sockets per host group and up to 256 active sockets per connection pool. |
There was a problem hiding this comment.
is connection pool the same as browser pool?
There was a problem hiding this comment.
"connection pool" refers to chromium's internal socket pool (HTTP/1.x sockets), unrelated to browser pools.
| ## Browser | ||
| A `Browser` is a cloud-based browser managed by Kernel. They accept Chrome DevTools Protocol connections and can be used to run browser automations or web agents. | ||
|
|
||
| ## Browser Pool |
|
since we are removing |
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Pushed @AnnaXWang re: redirects — the
(These are page-level redirects — old per-question FAQ anchors land on the pools page rather than the exact heading.) re: Bugbot "reserved browsers" — fixed both: |
There was a problem hiding this comment.
Stale comment
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation after synchronize
Previous automation approval was on
bf5ab05. Latest HEAD iscd11471. Since that approval, the branch continued documentation-only work (FAQ fold/delete, terminology standardization, page collapse to/browsers/pools, Scale/Create rewrites, pools-page tightening).Latest delta since the prior assessment (
327ca95→cd11471): adds/browsers/pools/faq→/browsers/poolsredirect indocs.json, plus two wording tweaks (reserved→maintainedin pricing; "reserved browsers" → "the browser pool" in scale). That does not raise risk.Evidence (from diff only)
- 26 files, +403 / −722 — all Mintlify
.mdxordocs.json- Consolidates browser pools docs onto
/browsers/pools, adds overview/faq→pools redirects, updates nav- Cross-page link/terminology updates and intro/scale/pricing prose
- No application code, infra, auth/billing logic, schemas, or shared libraries
- No
CODEOWNERSrequirement foundDecision
Risk remains Very Low. Prior approval stands; not re-approving.
Sent by Cursor Automation: Assign PR reviewers
There was a problem hiding this comment.
Risk assessment: Very Low
Verdict: Very Low risk — prior approval retained (risk did not increase).
Re-evaluation
Previous automation approval remains active (bf5ab05). Latest HEAD is cd11471. Full diff vs base is still documentation-only; risk has not increased.
Evidence (from diff only)
- 26 files, +403 / −722 — exclusively Mintlify
.mdxanddocs.json - Consolidates browser pools docs onto
/browsers/pools(deletes overview/FAQ pages), collapses nav (Reserved Browsers→ singlebrowsers/poolsentry), adds redirects for/browsers/pools/overviewand/browsers/pools/faq - Cross-page terminology/link updates plus Create/Scale/pricing prose and example code blocks
- No application/runtime code, APIs, auth/billing logic, infrastructure, schemas, CI/deploy config, or model-prompt instruction files
- No
CODEOWNERSfile requiring separate owner approval
Why this level
- Docs-site content and nav/redirects only; no production logic or shared systems
- Blast radius limited to published documentation IA and copy; easy to reason about and revert
Actions taken
- Risk remains Very Low → did not dismiss prior approval
- Did not re-approve (approval already present)
- Did not assign or request reviewers
Sent by Cursor Automation: Assign PR reviewers
AnnaXWang
left a comment
There was a problem hiding this comment.
thank you! i would love to move "browser pools" out of advanced and into intermediate but that probably opens a whole can of worms because other concepts under advanced also arguably should move as well.



Summary
Browser pools weren't surfaced where a user decides to go to production — the concept was called "Reserved Browsers" in the sidebar, and the Create page never mentioned them. And the pools page itself had grown into a tutorial and an API reference wearing one hat, explaining the same handful of facts three and four times over.
This PR is scoped to browser pools documentation. The end-to-end quickstart is #470 (stacked on this branch), and the broader docs IA rework — replacing Basics/Intermediate/Advanced with lifecycle groups — is tracked separately. (Merged
mainto pick up #469, which moved Chrome policies to a standalone page.)1. One name: "browser pools", and every other "pool" qualified. The API, SDKs, CLI, and dashboard already said "browser pools" — the docs were the outlier. Renamed the sidebar group, dropped "reserved browsers" as a product name, and swept bare "pool" → "browser pool" in prose. "Pool" is overloaded here, so the other senses are disambiguated too: "connection pool" on the curl networking limits, "managed proxy pool" on bot-detection. ("ISP pool" and the unikernels page's "warm pools" were already unambiguous.)
2. Not described as "warm". Per docs-team feedback on this PR, "warm" implies pools run hot and bill for idle time — the opposite of the actual benefit. Now "ready to use" / "pre-provisioned", and the pricing line leads with the benefit: "an idle browser pool costs nothing between tasks."
3. One page at
/browsers/pools. The section was three pages (overview + FAQ + Chrome policies); it's now one, served at/browsers/poolsrather than/browsers/pools/overview. The FAQ folded in, Chrome policies left via #469, the nav group collapsed to a single entry, and a redirect covers the old path. The changelog's bare/browsers/poolslinks — previously 404s — now resolve, because that's where the page actually lives.4. Deduped. The intro explained "config is pre-applied so acquisition is faster" four times; read-only profiles appeared three times; update/stale-config semantics three times, including a paragraph duplicated verbatim two paragraphs later;
refresh_on_profile_updatethree times. Merged the three profile sections into one "Profiles with browser pools", moved the stale-config warning to "Update a pool" where it belongs, replaced "Pool configuration options" with a short Configuration pointer, and moved Sizing next to the acquire/release lifecycle.5. Pitched where users move to production, workload-driven. An "On demand or from a browser pool" section on
introduction/create(build withbrowsers.create(), move to a pool once you're repeating the same task), plus pointers from the home page and Scale. Fundamentals first, then pools — not a day-one default, not an afterthought.6. Scale page rewritten. It was written pre-launch and framed pools around three co-equal factors with a blunt "<50 concurrency → don't bother" gate. Now: benefit (low-latency acquisition, reserved capacity, higher creation throughput; the concurrency-limit tradeoff) → when to use vs on-demand (workload signals, not thresholds) → sizing (links to the pools page), keeping the three architecture patterns and dropping their numeric gates.
7. Content gaps closed.
reuse: true(default) returns the same browser with cookies/storage/sessions intact, so it's fast but not isolated;reuse: falseis clean at the cost of a rebuild. Multi-tenant leak warning added.available_count, target 10–20% available; a small pool still pays off when acquisition latency matters, with no concurrency-number gate.start_urlthe only per-acquire override), read-only profiles, reserved capacity holds concurrency slots whether or not acquired, Start-Up/Enterprise only.fill_rate_per_minuteexample aligned with the documented 25% default (was 10, which read as a competing default).Verification
origin/main; resolveddocs.jsonand took main's canonicalbrowsers/chrome-policies.mdx.docs.jsonvalid; every nav page resolves to a file; the pools entry is a singlebrowsers/poolspage; no staleoverview/faq/policy-jsonnav refs./browsers/pools/overviewlinks repointed; a stale#create-a-pool-of-reserved-browsersanchor fixed; every in-page anchor resolves; externally-linked anchors preserved (#how-browser-pools-work,#create-a-pool,#update-a-pool,#sizing-a-browser-pool,#per-user-profiles-with-pools)./browsers/pools/overview→/browsers/pools(new),/browsers/pools/policy-json→/browsers/chrome-policies(from Move Chrome Policies to Advanced and clarify it applies to individual browsers #469).sizeis required onupdate; it isn't.sizeis required on create only, and optional on update (param.Opt[int64], "If provided, replaces the number of browsers to maintain in the pool"). The note asserting otherwise has been removed, along with the Go update sample that passed a bareintfor that optional field. "Acquire isn't rate-limited" verified against the API's rate-limiter: onlyPOST /browsersis rate-limited.mint devnot booted in this environment, so the pages aren't visually confirmed. Worth a preview pass before merge.Related
🤖 Generated with Claude Code
Note
Low Risk
Documentation-only changes with redirects and link updates; no runtime code paths affected. Residual risk is broken anchors or stale external changelog links not updated in this PR.
Overview
Consolidates browser pools documentation into a single page at
/browsers/pools, removingbrowsers/pools/overview.mdxandbrowsers/pools/faq.mdx. The nav drops the "Reserved Browsers" subgroup for one entry;docs.jsonadds redirects from the old paths and repoints internal links from/browsers/pools/overview(and old anchors) to the new page.The new guide deduplicates repeated lifecycle, profile, and update semantics, adds limitations, reuse behavior (including multi-tenant warnings), sizing via
available_count, and clearer why acquire is faster (pre-applied restart configs, nobrowsers.createrate limit). Wording shifts from "warm/pre-warmed" to ready/pre-provisioned and clarifies idle pool billing.Production positioning updates:
introduction/creategets an "On demand or from a pool" section with acquire examples;introduction/scaleis rewritten around benefits, workload-based pool vs on-demand choice, and sizing (without hard concurrency gates). Smaller sweeps across pricing, concepts, profiles, CLI/MCP copy, and misc pages qualify bare "pool" where needed (e.g. curl connection pool).No product or API behavior changes in this diff—documentation and IA only.
Reviewed by Cursor Bugbot for commit cd11471. Bugbot is set up for automated code reviews on this repo. Configure here.