Add Spring AI: its generated component descriptor carries only version and prerelease

[amondnet]

Part of #73.

Spring AI has the smallest generated component of any candidate measured, and the audience that benefits most from version-pinned docs.

What upstream generates

spring-ai-docs/src/main/antora/resources/antora-resources/antora.yml, in full:

version: ${antora-component.version}
prerelease: ${antora-component.prerelease}

That is the entire template. The committed spring-ai-docs/src/main/antora/antora.yml declares name, version, title, nav and the collector — and no asciidoc.attributes block at all. Synthesis reduces to writing a descriptor with the version in it.

Attribute references in the pages

23 distinct {...} references across the corpus, of which exactly one — {spring-ai-version}, used once — is a build attribute. The rest ({format}, {subject}, {context}, {voice}, ...) are prompt-template placeholders inside code samples, not AsciiDoc attributes.

Macro load at v1.0.0: configprop: 0, include-code:: 0, include:: 1, javadoc: 1. 109 pages, a single ROOT module.

Why it is worth doing despite being small

This is the case the product exists for. Spring AI's API moves fast enough that a model's training data is reliably stale, and product.md names LLM tooling as the primary consumer. 109 pages of correct, version-pinned API surface is worth more per byte here than anywhere else in the ecosystem.

Open question to settle first

Tags run v1.0.0 through v2.0.1. The layout was probed at v1.0.0 only — whether 2.x moved the component, changed the collector, or altered the module structure is unverified. Probe spring-ai-docs/src/main/antora/antora.yml at v2.0.0 before choosing minimumVersion; a difference means two eras, as Boot has.

Work

• probe the 2.x layout and decide the era structure
• add the ai entry to PROJECTS
• extend tests/unit/upstream-sources.test.ts
• convert one version end to end under --strict
• add Spring AI to NOTICE — it is not currently listed, unlike Framework/Security/Data/Cloud
• update the README support table

Depends on the synthesized-assembly refactor in the Framework issue: Spring AI has no BOM script, no static attributes file and no metadata jars either, so it needs the same relaxed SynthesisSources.

[amondnet]

Probe results: overlay, one era, floor at 1.0.0

Two things in the issue body are now settled, and one of them is a correction.

The "Depends on" line is stale — no dependency remains

Depends on the synthesized-assembly refactor in the Framework issue

That was written before the overlay assembly descriptor existed. Spring Framework landed as overlay, not synthesized (#83, #140), and Spring Security as overlay plus derivedAttributes (#140). Spring AI fits overlay exactly and needs no relaxed SynthesisSources — in fact it needs less than Framework does:

# spring-ai-docs/src/main/antora/resources/antora-resources/antora.yml — in full
version: ${antora-component.version}
prerelease: ${antora-component.prerelease}

Neither line is an asciidoc attribute. version is the descriptor field overlayDescriptor already writes from the catalog version, and prerelease is never true because only GA versions are built. So generatedAttributesFor returns {} and the overlay is pure passthrough — the degenerate case of the era. Nothing is downloaded and nothing is reconstructed.

The issue's claim that {spring-ai-version} is a build attribute does not hold either. Its single occurrence is a Maven property inside an XML listing on the Hana page — <version>${spring-ai-version}</version> — not an AsciiDoc attribute reference. The corpus references zero build attributes; all 23 {…} occurrences are prompt-template placeholders in code samples.

Open question: 2.x is the same era

spring-ai-docs/src/main/antora/antora.yml is byte-identical at v0.8.0, v1.0.0, v1.1.0, v2.0.0 and v2.0.1 — same component path, same mvnw process-resources collector, single ROOT module throughout, and no symlink anywhere under spring-ai-docs (so internalSymlinks is empty). One era, no ceiling. Unlike Boot, 2.x is not a second era.

The floor is a publication fact, not a layout one

The layout reaches back further than the issue assumed — v0.8.0 and v0.8.1 exist and share it. The floor is 1.0.0 anyway, for the same kind of reason Boot's archive era starts at 4.0.8: org/springframework/ai/spring-ai-bom on Maven Central begins at 1.0.0-M5, and 0.8.0/0.8.1 are absent entirely (404). Those releases went to Spring's milestone repository only, so no consumer can pin a dependency to what those 50 pages describe.

Conversion

Both ends of the range convert clean under --strict, zero converter warnings:

Version	Pages	configprop:	include-code::	Unresolved attributes
1.0.0	109	0	0	0
2.0.1	121	0	0	0

One converter gap the corpus surfaced

--strict reported zero warnings while quietly mangling 16 inline stem:[…] expressions on api/vectordbs/understand-vectordbs.adoc. Asciidoctor substitutes the stem macro before the converter's walker runs, so the expression arrives as plain text in MathJax delimiters and the walker never sees a construct to warn about. Escaped as prose, \$\vec{a}\$ reached the reader as \\$\\vec{a}\\$. escapeText in inline-html.ts now carries those through as $…$; the pattern matches nothing across the 449 MB of already-converted corpora, so no published output changes.