chore(deps): Astro 7.1 + dependency refresh (#39)

[maehr]

Moves the site onto the Astro 7.1 line and refreshes the remaining dependencies. Targets staging so it ships inside the v0.1.0 release (#4) rather than trailing it.

Note on the version number: the release is Astro 7.1, not 7.10 — astro-710 in the blog URL is the 7.1.0 slug. npm latest is astro@7.1.3.

Dependencies

package	from	to
astro	7.0.6	7.1.3
@astrojs/starlight	0.41.3	0.41.4
starlight-blog	0.27.0	0.28.0
@astrojs/markdown-satteri	0.3.3	0.3.4
@commitlint/cli	21.0.1	21.2.1
lint-staged	17.0.5	17.2.0
prettier	3.8.3	3.9.6
tsx	4.19.2	4.23.1

npm outdated is now empty apart from the deliberate hold below.

TypeScript stays at ^6.0.3. @astrojs/check@0.9.9 declares typescript ^5.0.0 || ^6.0.0, so 7.0.2 would break the peer range. Worth a follow-up issue once @astrojs/check ships a TS 7 range.

Checklist item 1 — plugin compatibility confirmed

All Starlight plugins already declare Astro 7 support; none needed a bump to accept 7.1.

plugin	version	peer range
starlight-llms-txt	0.11.0	astro ^7.0.0, @astrojs/starlight >=0.41.0
starlight-openapi	0.26.0	astro >=7.0.2, @astrojs/starlight >=0.41.0
starlight-links-validator	0.25.2	astro >=7.0.2, @astrojs/starlight >=0.41.0
starlight-blog	0.28.0	@astrojs/starlight >=0.41.0
astro-mermaid	2.1.0	astro >=4

starlight-llms-txt — the #20 blocker — is fine at its current floor; no version change was needed. starlight-blog@0.28.0 is purely additive (multi-instance blogs, structured data, RFC 5005 feed archives, linked cover images, a <Preview> component); its Astro 7 breaking change was 0.27.0, already absorbed in #29.

One source change was required

Not from Astro — from Starlight 0.41.4. withastro/starlight#3936 replaced the intersection inside docsSchema() with .extend() so that z.enum fields can be modified. As a consequence the extend option must now return a ZodObject; BaseSchema is typed z.ZodObject<T>. Our src/content.config.ts returned blogSchema(context).and(z.object({…})), a ZodIntersection, which astro check now rejects with ts(2322).

Fixed by composing with .extend() instead — blogSchema() returns blogEntrySchema(context).partial(), a ZodObject, so this is a direct swap:

-			extend: (context) =>
-				blogSchema(context).and(
-					z.object({
-						maturity: Maturity.optional(),
-						banner: z.object({ content: z.string() }).default(UNSTABLE_BANNER),
-					}),
-				),
+			extend: (context) =>
+				blogSchema(context).extend({
+					maturity: Maturity.optional(),
+					banner: z.object({ content: z.string() }).default(UNSTABLE_BANNER),
+				}),

Behaviour is preserved: Starlight's deepMergeSchemas walks the user shape, and for banner it merges our ZodDefault over Starlight's optional banner field, keeping the UNSTABLE_BANNER default. Verified in the build output — the pre-1.0 banner still renders (see below).

Checklist items 2–3 — verification

• npm run verify — exit 0. prettier --check clean, astro check 0 errors, 0 warnings (2 pre-existing ts(80005) hints on scripts/compile.ts require() calls), full build of 78,940 pages in 1m 9s, starlight-links-validator reports all internal links valid.
• npm run validate:data — 39250/39250 records valid (works=12, systems=10, refs=39204, mappings=24).
• Link check — ran the CI equivalent (.github/workflows/links.yml extracts URLs from data/ and src/content/docs/ rather than crawling dist/, since the built site expands to ~200k resolver URLs): 417 checked, 287 OK, 65 errors, 26 excluded. All 65 are pre-existing external-host noise — 63 × ctext.org 403 (bot-blocking), 1 × iso.org 403, and 1 × 404 on decisions/ADR-0002-…md on main, which resolves once Release v0.1.0: ADR-0001/0002/0003, all data draft, spec fixes #6–#15, Astro 7 (#20) #4 merges. That job is report-only (fail: false) and never gates a PR. This PR touches zero files under data/ or src/content/docs/, so the external-link surface is identical to staging by construction. Internal links are validated at build time by starlight-links-validator, which passed.
• npm run format produced no changes under prettier 3.9.6, so the diff stays on the manifests, the changelog, and the one schema fix.

Checklist item 4 — built-site sanity checks

Verified against dist/:

• llms.txt (843 B) and llms-full.txt (194 KB) generated — starlight-llms-txt ✅
• /api/ OpenAPI pages render (49 KB index plus operations/) — starlight-openapi ✅
• mermaid markup present on /standard/ — astro-mermaid ✅
• /blog/ index and rss.xml build, feed parses as valid XML — starlight-blog ✅
• pre-1.0 banner renders on the home page — confirms the schema fix above ✅
• /id/work/…/index.html plus its .json sibling, with <link rel="alternate"> intact ✅
• /id/ref/… pages at 3,234 B — the feat(site)!: minimal static templates for reference pages #30 slimming holds, no regression ✅, and noindex is still emitted on draft records (feat(site): draft records flagged + noindexed (ADR-0003 follow-up) #26) ✅
• /reg/ index and /cite/ redirect pages build ✅

Checklist item 5 — deferRender / collectionStorage are not applicable here

Investigated and deliberately not adopted. Neither feature touches the registry:

• deferRender is an option on the glob() loader, not on defineCollection. The only content collection in this project is docs, loaded by Starlight's docsLoader() — the option is not reachable without forking that loader.
• Registry data never enters the content layer at all. src/lib/registry.ts calls compileRegistry() from scripts/compile.ts directly and memoises the result in a module-level variable, so the .astro/data-store.json ceiling that experimental.collectionStorage: 'chunked' raises only ever holds the docs markdown — a few hundred KB, nowhere near 10 MB.

So the ROADMAP "millions of references" scaling concern is unaffected by both features; the relevant pressure is in scripts/compile.ts and the 39k static route pages, not the content layer. No config change made. Worth revisiting only if registry records ever move into a content collection.

Unrelated pre-existing issue spotted

/api/openapi.yaml — advertised in the starlight-llms-txt description and in /api/ prose — 404s on production today and is absent from dist/. api/openapi.yaml is a build-time input to starlightOpenAPI({ schema }) and was never copied into public/, so it is not published. This is not a regression from this PR (it 404s on the current live 7.0.6 build too); flagging it for a separate fix.

Closes #39.

🤖 Generated with Claude Code