[fas89]

The post-release pass for forge-cli 0.23.0: the pin, the regeneration it unblocks, and the four pages that said "the next release after 0.22.0". Three commits, one per concern.

1. The pin

supportedCliVersion and supportedCliInstallSpec move to 0.23.0. Nothing else in cli-version.json moves, and that was checked rather than assumed, since you asked:

Key	Checked how	Result
supportedFluidContractVersion 0.7.5	FluidSchemaManager.PREVIEW_VERSIONS on 0.23.0 is ['0.7.6']	0.7.6 is still a preview, so 0.7.5 is still the latest stable — unchanged
quickstartScaffoldVersion 0.7.5	the gate's own scaffold check	fluid init --quickstart on 0.23.0 emits 0.7.5 — unchanged
supportedSdkVersion 0.10.0	pypi.org JSON for data-product-forge-sdk	latest is 0.10.0 — unchanged
supportedCustomScaffoldVersion 0.4.1	pypi.org JSON for data-product-forge-custom-scaffold	latest is 0.4.1 — unchanged

BUNDLED_VERSIONS on 0.23.0 is 0.7.1 … 0.7.6, same set as 0.18.1, so the contract-pins check passes untouched.

The version sweep named 21 lines, and they are not all the same thing

Fourteen are claims about what a reader should run today, or sample output. They move to 0.23.0, and each is substantiated by a check in the same run: fluid --version on 0.23.0 prints FLUID Forge CLI v0.23.0 (which is what cli/version.md now shows), the coverage check passes 69 subcommands, and the flag oracle passes 1335 fenced invocations.

Seven are a different claim: they record which release a page's own content was verified or recorded against — the Docs Baseline banners on providers/{aws,gcp,local,snowflake}.md and walkthrough/{export-orchestration,universal-pipeline}.md, plus cli/README.md's note that its examples use a particular release. I did not re-verify or re-record any of those pages. Moving the number would have claimed work nobody did, so they keep the release that produced them and gain <!-- cli-version: historical --> — a line whose version is deliberately not the pin, which is exactly what that marker is documented for.

Say if you would rather they moved to 0.23.0 anyway; it is a one-line change per page, but it is a claim I cannot stand behind from here.

The 424 the sweep does not see

There are about 445 0.18.1 mentions across roughly 145 files outside RELEASE_NOTES_*. The sweep matches 21 of them, because it only matches baseline phrasings on purpose. The rest are "as of 0.18.1 …", recorded transcripts, sample fluid_version fields and the like — many historically true, some genuinely stale now that 0.19 through 0.23 have shipped.

Re-baselining those is the "track 0.23.0" pass this repo has done once per release before (docs: track 0.18.1 — every page says what 0.18.1 does, #141). It is a PR of its own, not a rider on the pin bump. Flagged as a follow-up with the count so it is a decision rather than an oversight.

scripts/forge-cli-releases.json is refreshed from the forge-cli checkout, so reviewedThroughRelease is 0.23.0 and the release-marker sweep's freshness half stays armed for the next release.

2. The regeneration — and one thing it refused to do first

reference/contract-0.7.6-preview.md has been rendered from the 0.7.6 schema bundled in 0.18.1 ever since the pin stopped moving, which is why it listed neither engine: flink nor trigger.type: continuous nor sink.catalogAuth. The delta now goes from 48 added rows to 93, and from 12 changed to 17.

The first run failed, and it was right to:

ERROR: fluid-schema-0.7.6.json $.$defs.column.properties.quality.items:
keyword 'minProperties' is not one the reference generator renders.
Teach scripts/gen_contract_reference.py about it before regenerating.

That is the walker's fail-closed design doing its job — it refuses an unknown keyword rather than dropping the constraint silently. minProperties: 1 is new in this release: absent from 0.22.0's bundled 0.7.6 and from main before #753, present on the #753 branch. It sits on a column's quality rule, where every key is optional and an empty {} would otherwise validate as a rule that says nothing. The walker now renders it as the object counterpart of minItems, so the row reads each item: min properties 1 in the same idiom as the rest of that column. That is the only change to the generator.

The hard-fail is the right behaviour, and it has a standing cost. Rendering a constraint the
walker does not understand, or quietly dropping it, would publish a field reference that
understates what fluid validate enforces — which is worse than a failed job. The cost is that
the generator lives in this repo while the schema lives in forge-cli, so any forge-cli release
that introduces a schema keyword blocks its own docs regeneration until someone adds support
here. That is a follow-up below, not a thing to fix in passing.

contract-0.7.5.md moved by four lines too: its provenance line now names 0.23.0 with the new schema sha, and two Lake Formation descriptions gained text in this release.

Confirmed in the output, not assumed

• fluid odcs validate carried through. The regenerated page contains it once and contains fluid generate odcs zero times, so the schema-text fix you made in e1b62a53 renders verbatim as predicted. I also diffed the #753 branch schema against the released 0.23.0 one: that one description is the only difference between them, which is the tidiest possible confirmation.
• min properties 1 renders on exposes[].contract.schema[].quality.
• metadata.team.members[].email renders with format email and an empty description, because the schema gives it none — which is precisely why the fluidEmail caveat earns its own subsection rather than a table cell.

3. The four slots, and what else the pin unlocked

upgrading.md × 2 (the exported-artifact warning, the DuckDB drift-defect tip), project-dotenv-trust.md × 1, preview-fields.md × 1 — all now naming 0.23.0, each also losing the sentence that explained the number was unsettled.

preview-fields.md needed more than a number swap, because its shape was built around the stale pin:

• The seven 0.23.0 fields join the page's own index table with First in CLI 0.23.0, each path spelled the way the generated delta spells it (so exposes[].contract.schema[].quality, not "quality on a column"). Their detail section drops its now-duplicate table and keeps the four subsections that hold what a row cannot.
• sink.catalogAuth, builds[].engine: flink and trigger.type: continuous were prose paragraphs because the delta could not list them. It can now, so they are rows. The sink.catalogAuth paragraph also asserted it had no row in the delta, which stopped being true the moment the pin moved — gone with the paragraph.
• The delta pointer named only the consumes and exposes sections; the seven land under metadata, description and builds as well, so it names the grouping instead of two of five groups.

The overlay-by-identity paragraph stays prose: it is a behaviour, not a field.

Premise notes

The root description text did not change, and did not need to. You said it changed and that "the old sentence about an ODCS export publishing purpose alone is gone". Diffed byte for byte: that description is identical between the #753 branch and released 0.23.0. It is also already correct, because the sentence is written as history — "While this was a string, an export of a valid contract could only ever carry description.purpose" — and is followed by the sentence saying the object now survives a FLUID → ODPS → FLUID cycle and reaches both exports. Nothing to fix; the only schema-text change between the branch and the release is the fluid odcs validate one.

0.23.0 is on PyPI, and my first install said it was not. pip install data-product-forge==0.23.0 failed with a version list stopping at 0.22.0. That was a stale cached index page, not reality: pypi.org's JSON API reports info.version 0.23.0, the /0.23.0/json endpoint is 200, and the simple index lists both the wheel and the sdist. --no-cache-dir installed it. Noting it because your "verified against the pypi.org index rather than local pip" is exactly the distinction that mattered, and because a CI runner with a warm index could hit the same thing — the workflow's pip install has no --no-cache-dir, though a fresh runner has no cache to be stale.

Verified locally

Reproduced from the workflow files, on python3.12 with data-product-forge[local]==0.23.0:

Command	From	Result
check_cli_docs.py --version-only	cli-consistency.yml	OK (0.23.0)
check_cli_docs.py (all 7 checks)	cli-consistency.yml	OK — 69 subcommands, 0.7.5 scaffold, contract pins, 1335 invocations, every version claim, 237 pages swept
check_providers.py	cli-consistency.yml	OK (4 execution providers)
gen_contract_reference.py --check	cli-consistency.yml	OK — 2 pages match the schemas bundled in 0.23.0
npm run docs:build	docs-pr-check.yml	exit 0, 243 pages
node scripts/check-dist-links.mjs	docs-pr-check.yml	Clean — 138,930 absolute references
base-prefix-check	link-check.yml	OK, self-test passed
lychee-source	link-check.yml	0 errors over 913 unique links; canaries 0 / 2

The release-marker sweep now reports forge-cli newest release 0.23.0, reviewed through 0.23.0.

Heading anchors are still the one link class no gate here covers, so I read them out of the built HTML again. The retitled section's anchor is four-of-the-0-23-0-fields-need-more-than-a-table-row; nothing linked to the old one. The four subsection anchors are unchanged, and the four cross-page anchors the new rows use all resolve: authenticate-a-sink-to-a-rest-catalog, flink-jobs-engine-flink, continuous-builds-trigger-type-continuous, read-this-first-if-you-consume-the-exported-artifacts.

Follow-ups

Four, none of them acted on here.

1. Re-verify the seven Docs Baseline pages against 0.23.0, then move the banner. This is
   the other half of the decision above. A banner frozen at 0.18.1 behind a historical marker
   is honest today and misinforming eventually, and the only thing that resolves it is actually
   re-running those four provider pages and two walkthroughs — plus cli/README.md's examples —
   against 0.23.0 and re-recording what changed. Real work, deliberately not smuggled in here.

2. Add schema-keyword support to gen_contract_reference.py as part of each release. As
   above: the walker refuses an unknown keyword by design, the generator is in this repo, and the
   schema is in forge-cli — so a release that tightens the schema stops its own docs. 0.23.0's
   minProperties is the first instance and took one line plus a comment, but the pattern will
   repeat, and the failure lands on whoever next bumps the pin rather than on the release. Worth
   either a line in forge-cli's release checklist pointing at this file, or a periodic pass over
   the keywords the bundled schemas use versus KNOWN_KEYWORDS.

3. The "track 0.23.0" pass over the roughly 424 remaining 0.18.1 mentions the sweep does
   not match — "as of 0.18.1 …", recorded transcripts, sample fluid_version fields. The
   precedent is docs: track 0.18.1 — every page says what 0.18.1 does, with release notes and an upgrade guide for 0.15.1–0.18.1 #141, docs: track 0.18.1 — every page says what 0.18.1 does, with release notes and an upgrade guide, which is the same pass done once before, as its own PR. Overlaps
   follow-up 1 and could absorb it.

4. docs/cli/ reference edits for --env on fluid odcs export and
   fluid odps-bitol export, which 0.23.0 added. These are safe in fenced blocks now that the
   pin is 0.23.0; the flag oracle would have rejected them against 0.18.1, which is why docs: the seven new 0.7.6 preview fields, and the exported ODCS/ODPS artifact changes (forge-cli #753) #167 left
   them in prose.