docs(ci-cd-pipeline): point at a living workflow instead of a fossil snippet

.changeset/6308-living-workflow-example.md

@@ -0,0 +1,26 @@
+---
+---
+
+Docs change; no published surface.
+
+`content/docs/guide/ci-cd-pipeline.md`'s "Adding a New Workflow" section told a
+contributor to "follow the existing pattern for pnpm + Turbo setup" and then gave a copied
+YAML block in which every line had drifted: `actions/setup-node@v4` where every workflow
+in this repository now uses `@v7`, a hardcoded `node-version: 20` where every workflow
+declares `'22.x'` (and 20 sits below the floor the root `package.json`'s `engines` field
+now declares), and `pnpm/action-setup@v4`, which no workflow here has ever used — pnpm
+comes from `corepack enable` plus the root `packageManager` field instead. Re-measured on
+this change's own HEAD: `actions/setup-node@v7` — 28 occurrences, no other version;
+`node-version:` — 27 `'22.x'` and 1 `'22'`; `pnpm/action-setup` — 0.
+
+A copied block is a fossil by construction, so the section now points at
+`readme-exports.yml` as a living example instead of repeating one: it is short, runs on
+every pull request, and its setup is the complete pattern most new build/test/lint
+workflows need (checkout, `corepack enable`, `actions/setup-node` with pnpm's cache,
+`pnpm install --frozen-lockfile`, then a `turbo run build` step). Only the two steps that
+hold regardless of which Node or pnpm version the repository is on — the checkout step and
+`corepack enable` — stay quoted on the page; the reader copies the version-specific steps
+from the workflow itself. No new version literal was introduced, so no
+`doc-version-claims.test.ts` `KNOWN_CLAIMS` entry was needed.
+
+objectui#6308.

content/docs/guide/ci-cd-pipeline.md

@@ -1734,17 +1734,28 @@ takes part in it.
 > because nothing checked, and one of them is a PR gate.
 
 1. Create a new `.yml` file in `.github/workflows/`.
-2. Follow the existing pattern for pnpm + Turbo setup:
-
-```yaml
-- uses: actions/checkout@v4
-- uses: pnpm/action-setup@v4
-- uses: actions/setup-node@v4
-  with:
-    node-version: 20
-    cache: 'pnpm'
-- run: pnpm install --frozen-lockfile
-```
+2. Copy the pnpm + Turbo setup from a workflow that runs today, not from a snippet on this
+   page. A copied YAML block is a fossil the moment it is pasted — this page used to keep
+   one here, and every line of it had drifted: `actions/setup-node@v4` where every workflow
+   now uses `@v7`, a hardcoded `node-version: 20` where every workflow declares `'22.x'`
+   (and 20 sat below the floor the root `package.json`'s `engines` field now declares), and
+   `pnpm/action-setup@v4`, which no workflow in this repository has ever used — pnpm comes
+   from `corepack enable` plus the root `packageManager` field instead.
+
+   `readme-exports.yml` (see the **README Exports** section above) is a good one to read: it
+   is short, runs on every pull request, and its setup is the complete pattern most new
+   build/test/lint workflows need — checkout, enable Corepack, `actions/setup-node` with
+   pnpm's own cache, `pnpm install --frozen-lockfile`, then a `turbo run build` step for
+   whatever it needs built. Two of its steps hold for any workflow no matter which Node or
+   pnpm version the repository is on when you read this:
+
+   ```yaml
+   - uses: actions/checkout@v7
+   - run: corepack enable
+   ```
+
+   Copy everything else — the Node version, the cache key, the install command — from the
+   workflow itself, not from this page.
 
 3. Use Turbo for any build/test/lint steps to leverage caching: