docs(agents): define where a new document belongs - #3777
Conversation
The `docs/` tree had accumulated component guides that belong on the website: standalone OIDC, GPU/vGPU and VM-networking documents written as part of a feature PR and never routed anywhere. Nothing said where documentation should go, and in particular nothing mentioned that the website appends a whole package README onto a published page, so a contributor with package-scoped prose had no reason to use that route. Replace the four-line "Documentation is organized as follows" list with a destination table and the test that separates `docs/` from the website: whether a non-documentation file has to link to the document by path. Also state that a merged document records current behaviour and its limitations, not the development process around it — the "What is NOT in Phase N" and "this PR" residue that motivated this. Drop one such residue while here: backup-classes.md described a pin as one "this PR removes". Assisted-By: Claude <noreply@anthropic.com> Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com>
📝 WalkthroughWalkthroughThe documentation updates add rules for selecting documentation destinations and clarify the cause of historical CloudNativePG image and CRD version skew. ChangesDocumentation placement guidance
CloudNativePG upgrade note
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/agents/overview.md`:
- Line 139: Update the documentation guidance in the README publishing sentence
to clarify that the website pull request is automated, replacing “without a
second PR” with wording such as “without a second manual PR by the author.”
Preserve the existing explanation of the website update targets and package
README workflow.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 74d71a77-500b-4e7c-8d89-8bca4d2e0740
📒 Files selected for processing (2)
docs/agents/overview.mddocs/operations/backup-classes.md
|
|
||
| | Destination | What belongs there | | ||
| | --- | --- | | ||
| | `packages/<group>/<name>/README.md` | Anything scoped to a single package. Prose goes **above** `## Parameters`; that section is `cozyvalues-gen` output and is never hand-edited. The website's `make update-apps` / `update-vms` / `update-networking` / `update-k8s` / `update-services` targets append the whole README onto a published page, so this route reaches users without a second PR. Prefer it whenever the content fits one package. | |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Clarify the second pull request requirement.
docs/release.md states that the website-docs job opens a separate cozystack/website documentation pull request. Replace “without a second PR” with “without a second manual PR by the author,” or state that the website PR is automated.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/agents/overview.md` at line 139, Update the documentation guidance in
the README publishing sentence to clarify that the website pull request is
automated, replacing “without a second PR” with wording such as “without a
second manual PR by the author.” Preserve the existing explanation of the
website update targets and package README workflow.
What this PR does
docs/had collected component guides that belong on the website, standalone oidc, gpu and vm networking documents written inside the feature PRs that added the code and never routed anywhere a user looks. Nothing said where documentation should go, and in particular nothing mentioned that the website appends a whole package README onto a published page, so a contributor with package scoped prose had no reason to use that route.This replaces the four line "Documentation is organized as follows" list in
docs/agents/overview.mdwith a destination table and the test that separatesdocs/from the website: whether a non-documentation file has to link to the document by path. It also says that a merged document records current behaviour and its limitations, not the development process around it, which is the "What is NOT in Phase N" and "this PR" residue that motivated the whole thing.One such residue dropped while here,
docs/operations/backup-classes.mddescribed a pin as one "this PR removes".Moving the documents themselves is a separate PR.
Downstream repositories
Walked the trigger map against the diff: this touches
docs/agents/overview.mdanddocs/operations/backup-classes.mdonly. No package added, renamed or removed, novalues.yamlorvalues.schema.jsonfield, nopackages/core/platform/values.yamlkey, no bundle or variant, no release asset name, noApplicationDefinitionsemantics, no Talos pin, and no change tocozyvalues-gen,cozypkgor a package Makefile.Release note
Summary by CodeRabbit