docs: publish recipes with devnotes

[andreatnvidia]

📋 Summary

Publish the complete Recipes section from main alongside rolling Dev Notes. This prevents published Dev Notes from linking to unreleased recipe pages without making the rest of the documentation rolling.

🔗 Related Issue

N/A

🔄 Changes

• Copy the complete fern/versions/latest/pages/recipes tree into the published latest docs.
• Replace the top-level Recipes navigation block while preserving release-pinned sections and archived versions.
• Republish when any recipe page changes.
• Cover replacement, deletion, idempotency, and preservation of the release-pinned Concepts section.

🧪 Testing

• .venv/bin/pytest -q packages/data-designer/tests/docs - 15 passed
• .venv/bin/ruff check --fix .
• .venv/bin/ruff format .
• Dry run against the current docs-website snapshot - 29 recipe pages and navigation references moved to latest; Concepts remained pinned to v0.6.1.
• Unit tests added/updated
• E2E tests: N/A; the publisher test and docs-website dry run cover the changed path.

✅ Checklist

• Follows commit message conventions
• Commits are signed off (DCO)
• Architecture docs updated (N/A; no architecture changes)

[github-actions]

Fern preview: https://nvidia-preview-pr-794.docs.buildwithfern.com/nemo/datadesigner

Fern previews include the docs-website version archive with PR changes synced into latest. Notebook tutorials are rendered without execution outputs in previews.

[greptile-apps]

Greptile Summary

This PR publishes recipe docs alongside rolling Dev Notes. The main changes are:

• Adds recipe page edits to the Dev Notes publish workflow trigger.
• Copies the latest recipe pages into the published branch.
• Replaces the published Recipes navigation block from latest.yml.
• Extends tests for replacement, stale page removal, idempotency, and pinned section preservation.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
.github/workflows/publish-fern-devnotes.yml	Adds recipe page changes to the workflow path filter; recipe navigation and assets were already covered by existing paths.
fern/scripts/fern-published-branch.py	Copies the latest recipe page tree and replaces the top-level Recipes navigation section during Dev Notes publishing.
packages/data-designer/tests/docs/test_fern_published_branch.py	Adds coverage for recipe navigation replacement, stale recipe deletion, repeated patching, and preservation of pinned Concepts content.

_{Reviews (1): Last reviewed commit: "docs: publish recipes with devnotes" | Re-trigger Greptile}

[github-actions]

Thanks for putting this together, @andreatgretel — this is a tidy, well-tested change.

Summary

This PR makes the Recipes navigation section roll forward with Dev Notes when the patch-devnotes publish step runs, so published Dev Notes never link to unreleased recipe pages. It does this by copying the full fern/versions/latest/pages/recipes tree into the published branch, replacing the published Recipes nav block with the source one, and adding a workflow trigger on recipe page changes. The implementation matches the stated intent, and the test additions (replacement, deletion, idempotency, and preservation of the release-pinned Concepts section) cover the new path well.

Findings

Suggestions — Take it or leave it

fern/scripts/fern-published-branch.py:415 — Recipes nav paths aren't validated the way Dev Notes are

• What: Dev Notes go through rewrite_devnotes_block, which copies each referenced page individually and raises PublishedBranchError if a page named in the nav is missing. Recipes instead rely on the wholesale copy_path of the pages/recipes tree (via FERN_DEVNOTE_SUPPORT_PATHS), with no per-page existence check — a nav entry pointing at a non-existent recipe page would publish a broken link rather than fail the run.
• Why: It's a mild robustness asymmetry between the two sections. In practice the risk is small: a dangling nav entry is a pre-existing error in the source latest.yml, and Fern's own build would surface it. So this is genuinely optional.
• Suggestion: Either leave as-is (the bulk copy is simpler and the paths already resolve to ./latest/pages/recipes/..., so no rewrite is needed), or add a lightweight assertion that each pages/recipes path in the extracted block exists under the copied tree. Worth a one-line comment noting the intentional difference from Dev Notes so the next reader doesn't wonder why recipes skip the rewrite step.

fern/scripts/fern-published-branch.py:55 — FERN_DEVNOTE_SUPPORT_PATHS now carries a non-devnote path

• What: fern/versions/latest/pages/recipes was added to a list whose name and preceding comment are framed entirely around dev-note kit components and CSS.
• Why: Purely a readability nit — the constant name now slightly under-describes its contents.
• Suggestion: Optionally rename to something like FERN_PATCH_SUPPORT_PATHS, or extend the comment above the list to mention that recipe pages are copied here too. Not blocking.

What Looks Good

• Reuse over duplication — leaning on the existing generic extract_navigation_section / replace_navigation_section helpers (rather than cloning the devnotes-specific block logic) keeps the new code to a couple of lines and reads cleanly.
• The idempotency test is the right instinct — invoking patch_devnotes twice and asserting section: Recipes appears exactly once directly guards the failure mode this kind of block-replacement code is prone to (accumulating duplicate sections). Combined with the pinned-Concepts assertion, the test convincingly proves that Recipes rolls while release-pinned sections stay put.
• Trigger + code + test move together — adding pages/recipes/** to the workflow's path filter in the same PR means the republish actually fires when a recipe changes; it's good to see the automation and the logic land as one unit.

Structural Impact (graphify, 2.4s)

Risk: LOW (localized change)

• 2 Python files, 0 AST entities, 0/77 clusters

Verdict

Ship it (with nits) — Only optional suggestions, nothing blocking. The extraction boundaries line up with the real fern/versions/latest.yml (the nested Image Generation / Code Generation sub-sections sit at deeper indent and are correctly kept inside the block, and the next top-level Plugins section terminates it). Note: I couldn't re-run ruff or pytest in this CI environment (the project venv wasn't on PATH), so I'm relying on the PR's reported 15 passed and the linter checkboxes for the mechanical checks.

---

This review was generated by an AI assistant.