Use Astro docs to generate API documentation for all platforms

[onlyexeption]

No description provided.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of files (300). Try reducing the number of changed files and requesting a review from Copilot again.

[onlyexeption]

@copilot can you skip the docs folder which contains all the removed files and review all remaining ones that actually have meaningful changes? That is the src, scripts and spec folders as well as the package.json

[Copilot]

@copilot can you skip the docs folder which contains all the removed files and review all remaining ones that actually have meaningful changes? That is the src, scripts and spec folders as well as t...

Here's a review of the meaningful changes (src/, scripts/, spec/, package.json):

---

package.json
New build:docs:*-api scripts look good. One observation: build:docs:all runs all 4 in sequence, each doing npm install --silent inside the same submodule. Running npm run build:docs:all will install 4 times unnecessarily — worth noting in docs, though it's not functionally wrong.

---

scripts/export-*.ts (4 new files)
All scripts follow the same pattern: validate submodule → install → (optional pre-build) → Astro build → copy llms-full.txt. The structure is clear. No functional issues. The duplication across the 4 files could eventually be extracted into a shared utility, but it's readable as-is.

---

src/config/platforms.ts
Collapsing ApiSourceConfig from two variants (markdown-index, typedoc-json) into a single llms-full-txt is the right simplification. Blazor config added correctly.

---

src/lib/api-doc-loader.ts
The new parseLlmsFullTxt is clean. Two observations:

1. readFileSync is not in a try/catch: if a file exists but fails to read (e.g. permissions), the error propagates past loadPlatform's ApiDocsInitializationError-only catch, crashing the loader. Wrapping the read+parse block in a try/catch that rethrows as ApiDocsInitializationError would be more resilient.
2. inferComponentType — Blazor/WC patterns test chunk with /m flag rather than just the heading line. In practice body lines won't start with ### [, but using heading directly (already extracted) would be simpler and safer.

---

src/tools/constants.ts / schemas.ts / handlers.ts
All correctly updated to include Blazor and remove the formatStructuredComponent path. No issues.

---

spec/unit/mcp-runtime-spec.ts and src/__tests__/**
Tests are correctly updated to match the new llms-full-txt-based loader. ReactJsonParser spec and fixture teardown are properly removed. The acceptance test fixtures use realistic ### [Component](url) format that exercises the actual parser logic.

---

Overall the changes are well-structured. The two items in api-doc-loader.ts (error resilience for readFileSync and simplifying inferComponentType) are the only things worth addressing before merge.

[onlyexeption]

@copilot I applied your suggested fixes, can you review all the files you previously reviewed again?

[Copilot]

@copilot I applied your suggested fixes, can you review all the files you previously reviewed again?

Both suggested fixes are correctly applied in api-doc-loader.ts:

1. readFileSync is now wrapped in a try/catch that rethrows as ApiDocsInitializationError ✅
2. All inferComponentType patterns now test heading directly instead of chunk with the /m flag ✅

All other previously reviewed files (config/platforms.ts, tools/handlers.ts, tools/schemas.ts, scripts/export-*.ts, package.json, and the test files) remain correct with no regressions.

One minor stale reference I noticed: in src/tools/constants.ts inside the USAGE_GUIDE string (line 143), the description for search_api still reads "supports angular, react, webcomponents" — it should include blazor now that all four platforms are supported. This is a cosmetic issue in the agent's usage guide, not blocking.