docs: publish the 2.0.0 release, lifecycle, and platform compatibility

[chideat]

Publishes the 2.0.0 release facts for Alauda Cache Service E2, which ships today on 2026-09-08 with a two-year lifecycle and support on Alauda Container Platform v4.2, v4.3, and v4.4.

Release facts published

Version	Release Date	End of Full Support	End of Maintenance
v2.0.x	2026-09-08	2027-09-30	2028-09-30

Lifecycle dates follow the Alauda Cache Service E1 convention: release date plus one and two years, rounded to the end of that month. lifecycle_policy.mdx now carries the same four sections as E1 — version lifecycle timeline, release policy, support phases (Full Support in year one, Maintenance in year two), and maintenance policy — while keeping the Valkey-specific version dimensions and supported-version rule.

Every "not yet published" and "next major release" placeholder is resolved:

Page	Was	Now
lifecycle_policy.mdx	whole "Not yet published" table	published lifecycle timeline and support phases
release_notes.mdx	"release date … have not been established"	compatibility and support matrix + ## 2.0.0 with the release date
intro.mdx	"The next major product release is 2.0.0"	current release, release date, supported platform versions
installation.mdx	"the documentation baseline does not define the supported Alauda Container Platform versions"	v4.2/v4.3/v4.4 in the prerequisites
upgrade.mdx	no platform boundary	platform compatibility section and the v4.1 exclusion
limitations.mdx	"the 2.0.0 documentation baseline"	"Alauda Cache Service E2 version 2.0.0"

2.0.0 has no predecessor product version, so upgrade.mdx states that the procedure applies from the next 2.0.x release onward and points new environments at installation.mdx. No 1.x rows, no 1.x-to-2.0.x upgrade path, and no fixed-issue / known-issue / security-fix sections.

Correction: the 9.1 "packaging defect" warning

Five pages warned that the Helm Chart custom resource definition copy is stale and that a release package must install the canonical schema before 9.1 can be admitted. Verified at tag v2.0.0:

• config/crd/bases/rds.valkey.buf.red_valkeys.yaml enumerates 7.2/8.0/8.1/9.0/9.1;
• charts/valkey-operator/crds/rds.valkey.buf.red_valkeys.yaml enumerates only 7.2/8.0/8.1 — genuinely stale;
• but that chart is an upstream directory untouched since d430d34, referenced by neither the Makefile nor .build/build.yaml. .artifact/metadata.yaml declares packageType: OperatorBundle, and make bundle generates the bundle from config/manifests, which pulls config/crd/bases.

So the warning pointed at a file customers never install. The narrative is removed; the installed-schema verification step stays, and the 8.0/9.0 wording now matches the API comment at the shipped tag — admissible, no image shipped, usable only with a self-supplied image, neither supported nor tested. The stale chart copy is left alone here; it belongs in valkey-operator.

Evidence ledger

Per the CONTENT_AUDIT.md review rule, every new compatibility claim carries an evidence row:

• SOURCE_POLICY.md — the release facts recorded as evidence class 1 (product-owner requirements with no source-code evidence), the lifecycle date convention, the 2.x-only scope, and the corrected image baseline cf797832 (which is 7cb5874 plus one Alpine bump, still building 7.2.14 / 8.1.9 / 9.1.1);
• CONTENT_AUDIT.md — updated P claim class, the rewritten 9.1 and 8.0/9.0 conflict rows, and rows for the five changed pages;
• ARCHITECTURE_FACTS.md — current-release wording, image baseline, and the chart CRD entry;
• TERMINOLOGY.md — Full Support, Maintenance, end of full support, end of maintenance, and Alauda Container Platform registered as canonical terms.

The release candidate pinned in the artifacts registry, 33812cb4, is an ancestor of v2.0.0 and differs from it only in the redis-exporter image tag, so the schema and server-image claims hold for either commit.

llms.txt

Regenerated for the 15 files whose sha256 no longer matched the index: the 6 pages in this change get new descriptions, the other 9 changed only by terminology edits after the index was last generated and keep theirs. exclude_patterns in the state file still said docs/agent/** and is now aligned with llmstxt-config.yaml.

Verification

yarn lint and yarn build both clean.

Follow-ups, not in this change

• master needs the same change as a separate branch.
• installation.mdx still says "chart" twice, and its audit row cites Helm values and templates as evidence, for a page that ships as an OLM bundle. Re-deriving that page against the bundle is a separate task.
• The tested Valkey server source-to-target upgrade matrix in how_to/30-upgrade.mdx is still unknown — an implementation gap, deliberately kept.
• valkey-operator/charts/valkey-operator/crds/ should be regenerated or removed upstream.

🤖 Generated with Claude Code