chore: promote src/nimbus to src

[mvvmm]

Summary

Promotes src/nimbus → src, the structural follow-up flagged in #32229. Nimbus has been the only build target since #32181/#32203, but the app still lived at src/nimbus with srcDir pointed at it, while content/assets/util/some components stayed "shared in place" at the repo-root src/. That split required a ~120-line custom Vite alias-resolver plugin to bridge the two trees. With one tree, that plugin is gone entirely.

Structural changes

• git mv every src/nimbus/* subtree into src/ (components, layouts, pages, schemas, plugins, scripts, styles, lib, content.config.ts, mdx-components.ts, components.ts, astro-config.ts) — no name collisions with what already lived at src/
• astro.config.ts: drop the srcDir/cacheDir override (back to Astro defaults for srcDir)
• src/astro-config.ts: delete the aliasResolver + resolveId fallback Vite plugin — with a single tree, ~ and @ resolve to src/* via the standard tsconfig paths, no override needed
• Single tsconfig.json (~/* and @/* → src/*); removed the separate src/nimbus/tsconfig.json and the root config's exclude: ["src/nimbus"]
• Fixed 6 relative imports whose depth changed with the move, and 5 hardcoded ../components/AiSearch* paths in the components.ts barrel that needed to become ./components/AiSearch*

Type-check fallout (the interesting part)

Removing the src/nimbus exclude meant pnpm run check type-checked the real app for the first time since the migration — previously it was silently scanning ~40 leftover top-level files, not the ~400 under src/nimbus. That surfaced 82 pre-existing errors, all fixed here:

• Real Astro 7 / @cloudflare/nimbus-docs 0.2.2→0.6.1 breakage from chore: bump to astro 7 #32240 that nobody could see break: incrementalBuilds and partialResolver were removed from NimbusIntegrationOptions (partialResolver was already dead code — Render.astro resolves partials itself via getEntry); shiki's CodeLanguage narrowed (lang="curl" → lang="bash", a real highlighting improvement, not just a type cast); GetRSSItemsOptions dropped an already-inert markdown flag; [...slug].astro read two frontmatter fields (canonical, styleGuide) that were never declared in content.config.ts's schemaFields.
• ~50 pre-existing null-safety gaps on the permissive directory collection schema (data.entry/data.name are .optional()) — mostly !/?. at access sites that were already safe in practice, plus one real TS narrowing gap in mobile-sidebar.client.ts (hoisted function declarations can't see an outer early-return guard's narrowing; fixed with a re-bound const).

Two independent bugs found and fixed along the way

Both SkillsList.astro and McpServerList.astro called getCollection(...) with a name that was never declared anywhere. getCollection warns + returns [] for unknown collections rather than throwing, so both have been silently rendering empty on all 6 live agent-setup pages.

• McpServerList.astro called getCollection("cloudflare-mcps-manifest"). Added a mcp-servers collection (src/content/collections/mcp-servers.ts) using the existing middlecacheLoader pattern (same as product-availability/granular-control-applications) against the real middlecache key v1/cloudflare-mcps/mcps-manifest.json, and pointed the component at it.
• SkillsList.astro called getCollection("cloudflare-skills-manifest"). My first attempt at this repointed it at the existing skills collection instead — wrong fix, caught in review: skills is populated by astro-skills's loader reading the full SKILL.md bundle tarball, which exists for the /.well-known/skills/ discovery routes, a different purpose with a heavier loading mechanism. bin/fetch-skills.ts already downloads a lightweight, purpose-built manifest for exactly this display case (v1/cloudflare-skills/skills-manifest.json) to .tmp/middlecache/, but nothing read it afterward — same bug class as the MCP one. Added a dedicated skills-manifest collection mirroring mcp-servers.ts, fetching that manifest directly instead.

Verification

• pnpm run check / lint / format:check / test all clean
• Full pnpm run build succeeds locally (8707 pages)
• pnpm run test:postbuild passes
• Rendered dist/agent-setup/claude-code/index.html confirms both the MCP server list (15 servers) and skills list (all 11 skills) now show real content

Documentation checklist

• The change adheres to the documentation style guide.

[github-actions]

This pull request requires reviews from CODEOWNERS as it changes files that match the following patterns:

Pattern	Owners
*	@cloudflare/product-owners
*.ts	@cloudflare/content-engineering, @kodster28
*.astro	@cloudflare/content-engineering, @kodster28
/src/components/	@cloudflare/content-engineering, @kodster28
/src/components/agent-setup	@cloudflare/product-owners, @cloudflare/ai-agents, @cloudflare/dev-plat-leads
/src/components/realtimekit/	@cloudflare/realtime, @cloudflare/RealtimeKit, @roerohan, @ravindra-cloudflare, @cloudflare/product-owners
/src/util/api.ts	@cloudflare/content-engineering, @kodster28

[github-actions]

Preview URL: https://edbd082b.preview.developers.cloudflare.com
Preview Branch URL: https://chore-promote-nimbus-to-src.preview.developers.cloudflare.com

[cloudflare-docs-bot]

Review

⚠️ 8 warnings found in commit edbd082.

👉 Fix in your agent 👈

Fix the following review findings in PR #32249 (https://github.com/cloudflare/cloudflare-docs/pull/32249).

Before making changes, review each finding and present a brief summary table:
- For each finding, state whether you agree, disagree, or need clarification
- If you disagree (e.g. the fix requires disproportionate effort for minimal benefit,
  or the finding is factually incorrect), explain why
- If you need clarification before deciding, ask those questions
- Then share your plan for which issues to tackle and in what order

After triaging, follow this order:
1. Post a comment on this PR for any findings you are skipping, with the finding ID and your reasoning.
2. Then commit the fixes for the legitimate findings.

The comment must come before the commit — the bot reads PR comments when a new
push triggers a review, so skip comments posted after the push will be missed.

---

## Code Review

### Warnings (8)

#### CR-7ba85bcce2bf · Unchecked external input
- **File:** `src/content/collections/mcp-servers.ts` line 17
- **Issue:** The parser type-asserts `JSON.parse(fileContent) as { servers: McpServer[] }` and then iterates `data.servers` and calls `slug(server.name)` without verifying the manifest shape or that each entry has a usable `name`. A malformed middlecache response will produce a cryptic TypeError instead of a clear validation failure.
- **Fix:** Validate the parsed JSON before using it: check that `data.servers` is an array and that each server has a string `name`, or run the data through the Zod schema inside the parser so failures have actionable messages.

#### CR-47f44786835b · Unchecked external input
- **File:** `src/content/collections/skills-manifest.ts` line 18
- **Issue:** The parser casts middlecache JSON to `{ skills: SkillManifestEntry[] }` without validating that `skills` exists, so a malformed response or missing key throws a generic `TypeError: data.skills is not iterable`.
- **Fix:** Validate the parsed JSON shape (e.g. with Zod) or check `Array.isArray(data.skills)` before iterating.

#### CR-64aae7ca96b1 · Duplicate IDs silently overwritten
- **File:** `src/content/collections/skills-manifest.ts` line 25
- **Issue:** Building the lookup as `lookup[skill.name]` overwrites any earlier entry with the same skill name, silently dropping data if the manifest ever contains duplicates.
- **Fix:** Detect duplicate skill names and throw a descriptive error, similar to the duplicate-slug guard in `mcp-servers.ts`.

#### CR-6b335f745e5e · Unsafe type assertion on unknown field
- **File:** `src/components/cf/ResourcesBySelector.astro` line 69
- **Issue:** data.pcx_content_type is typed as unknown (passthrough), but it is cast directly to string | undefined. If the value is null or a non-string, the filter behaves incorrectly: null yields type null instead of falling back to collection, and non-strings silently fail types.includes.
- **Fix:** Narrow the value with typeof data.pcx_content_type === "string" before using it, and fall back to collection for null or non-string values.

#### CR-e44bfb83d9ee · Missing null guard before object access
- **File:** `src/components/cf/ResourcesBySelector.astro` line 76
- **Issue:** typeof v === "object" is true for null, so a null product item causes v.id to throw Cannot read properties of null (reading 'id').
- **Fix:** Check v !== null before treating v as an object, e.g., typeof v === "object" && v !== null ? v.id : v.

#### CR-59097b881c30 · Sort order mismatches displayed label
- **File:** `src/components/changelog/Header.astro` line 43
- **Issue:** The product sort on line 43 falls back to `""` when `entry.title` is missing, but line 119 displays `product.id` as the fallback. A product with no title would sort at the top of the list while displaying its ID, so the list order would no longer match the alphabetical order of the visible labels.
- **Fix:** Sort by the same displayed value, e.g. `(a.data.entry?.title ?? a.id).localeCompare(b.data.entry?.title ?? b.id)`, so the combobox order matches the rendered labels.

#### CR-447208b47e3d · In-place mutation of collection data
- **File:** `src/pages/pages/platform/language-support-and-tools.json.ts` line 9
- **Issue:** The code assigns `x.data.enable_date = new Date(...)` directly on the object returned by `getCollection`, mutating the collection entry in place. Depending on Astro's collection caching, this side effect can leak transformed data across requests or callers.
- **Fix:** Build a new object instead of mutating `x.data`, for example `return { ...x.data, enable_date: new Date(...).toISOString(), status: x.data.status ?? null };`.

#### CR-c60a5d4cbca7 · Unsafe cast of unknown value
- **File:** `src/pages/pages/platform/language-support-and-tools.json.ts` line 10
- **Issue:** `x.data.enable_date` is typed as `unknown` and cast to `string | number | Date` without runtime validation. If the YAML value is missing, null, a malformed string, or another type, `new Date(...).toISOString()` will throw a `RangeError` at runtime.
- **Fix:** Validate the runtime value before constructing the Date, handle missing/invalid dates explicitly, or narrow the type with a type guard.

Code Review

This code review is in beta and may not always be helpful — use your judgment.

Warnings (8)

File	Issue
collections/mcp-servers.ts line 17	Unchecked external input — The parser type-asserts JSON.parse(fileContent) as { servers: McpServer[] } and then iterates data.servers and calls slug(server.name) without verifying the manifest shape or that each entry has a usable name. A malformed middlecache response will produce a cryptic TypeError instead of a clear validation failure. Fix: Validate the parsed JSON before using it: check that data.servers is an array and that each server has a string name, or run the data through the Zod schema inside the parser so failures have actionable messages.
collections/skills-manifest.ts line 18	Unchecked external input — The parser casts middlecache JSON to { skills: SkillManifestEntry[] } without validating that skills exists, so a malformed response or missing key throws a generic TypeError: data.skills is not iterable. Fix: Validate the parsed JSON shape (e.g. with Zod) or check Array.isArray(data.skills) before iterating.
collections/skills-manifest.ts line 25	Duplicate IDs silently overwritten — Building the lookup as lookup[skill.name] overwrites any earlier entry with the same skill name, silently dropping data if the manifest ever contains duplicates. Fix: Detect duplicate skill names and throw a descriptive error, similar to the duplicate-slug guard in mcp-servers.ts.
src/components/cf/ResourcesBySelector.astro line 69	Unsafe type assertion on unknown field — data.pcx_content_type is typed as unknown (passthrough), but it is cast directly to string | undefined. If the value is null or a non-string, the filter behaves incorrectly: null yields type null instead of falling back to collection, and non-strings silently fail types.includes. Fix: Narrow the value with typeof data.pcx_content_type === "string" before using it, and fall back to collection for null or non-string values.
src/components/cf/ResourcesBySelector.astro line 76	Missing null guard before object access — typeof v === "object" is true for null, so a null product item causes v.id to throw Cannot read properties of null (reading 'id'). Fix: Check v !== null before treating v as an object, e.g., typeof v === "object" && v !== null ? v.id : v.
src/components/changelog/Header.astro line 43	Sort order mismatches displayed label — The product sort on line 43 falls back to "" when entry.title is missing, but line 119 displays product.id as the fallback. A product with no title would sort at the top of the list while displaying its ID, so the list order would no longer match the alphabetical order of the visible labels. Fix: Sort by the same displayed value, e.g. (a.data.entry?.title ?? a.id).localeCompare(b.data.entry?.title ?? b.id), so the combobox order matches the rendered labels.
src/pages/pages/platform/language-support-and-tools.json.ts line 9	In-place mutation of collection data — The code assigns x.data.enable_date = new Date(...) directly on the object returned by getCollection, mutating the collection entry in place. Depending on Astro's collection caching, this side effect can leak transformed data across requests or callers. Fix: Build a new object instead of mutating x.data, for example return { ...x.data, enable_date: new Date(...).toISOString(), status: x.data.status ?? null };.
src/pages/pages/platform/language-support-and-tools.json.ts line 10	Unsafe cast of unknown value — x.data.enable_date is typed as unknown and cast to string | number | Date without runtime validation. If the YAML value is missing, null, a malformed string, or another type, new Date(...).toISOString() will throw a RangeError at runtime. Fix: Validate the runtime value before constructing the Date, handle missing/invalid dates explicitly, or narrow the type with a type guard.

Conventions

_{No convention issues found.}

Style Guide Review

_{No style-guide issues found.}

Commands

Only codeowners can run commands. Post a comment with the command to trigger it.

Command	Description
/review	Runs a review now. Incremental if a prior review exists, full if not.
/full-review	Re-reviews the entire PR diff from scratch, ignoring incremental history. Useful after a rebase, when you want a fresh review, or if the bot gets out of sync and reports issues that no longer exist.
/ignore-review-limit	Permanently lifts the 2-review automatic limit for this PR. Future pushes will trigger reviews as normal.
/disable-auto-review	Stops automatic reviews from triggering on future pushes to this PR. Codeowners can still run /review or /full-review manually.
/rebase	Rebases the PR branch against production. On conflict, attempts to resolve automatically using AI. Stops with an explanation if confidence is not high enough.