You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .coderabbit.yaml
+28Lines changed: 28 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -45,6 +45,29 @@ reviews:
45
45
# Post review details on each review. Additionally, post a review status when a review is skipped in certain cases.
46
46
# Default: true
47
47
review_status: false # current: true
48
+
path_instructions:
49
+
- path: "fern/docs.yml"
50
+
instructions: |
51
+
Redirect destinations for documentation pages must use the rendered Fern route from docs/index.yml, not the source file path.
52
+
In docs/index.yml, the rendered URL comes from the section/page `slug` hierarchy; the `path` field only points to the source MDX file.
53
+
For example, the source path docs/configure-rails/colang/colang-2/language-reference/introduction.mdx renders under /configure-guardrails/colang/colang-2/language-reference/introduction because the top-level Configure Guardrails section has slug `configure-guardrails`.
54
+
Do not suggest replacing valid rendered routes such as /configure-guardrails/... with source-path-derived routes such as /configure-rails/....
55
+
Before flagging a redirect destination as wrong, verify the route by tracing the relevant entries in docs/index.yml.
56
+
- path: "docs/**/*.mdx"
57
+
instructions: |
58
+
Internal absolute documentation links in Fern MDX pages must use the rendered Fern route, not the source file path.
59
+
Derive routes from the slug hierarchy in docs/index.yml. For example:
60
+
- docs/configure-rails/index.mdx renders at /configure-guardrails/configure-rails, not /configure-rails.
61
+
- docs/configure-rails/colang/index.mdx renders at /configure-guardrails/colang, not /configure-rails/colang.
62
+
- docs/run-rails/index.mdx renders at /run-guardrailed-inference/run-rails, not /run-rails.
63
+
- docs/getting-started/installation-guide.mdx renders at /get-started/installation-guide, not /getting-started/installation-guide.
64
+
Before flagging or suggesting fixes for internal docs links, verify them with docs/index.yml.
65
+
Do not suggest changing valid Fern routes back to source-path-style links.
66
+
- path: "docs/**/*.ipynb"
67
+
instructions: |
68
+
Markdown links in documentation notebooks should match the rendered Fern routes when they point to docs pages.
69
+
Use docs/index.yml slug hierarchy as the source of truth for internal documentation routes.
70
+
Do not suggest changing valid Fern routes such as /configure-guardrails/... to source file paths such as /configure-rails/....
48
71
# Configuration for pre merge checks
49
72
# Default: {}
50
73
pre_merge_checks:
@@ -67,4 +90,9 @@ reviews:
67
90
# Review draft PRs/MRs.
68
91
# Default: false
69
92
drafts: false
93
+
# Only auto-review PRs labeled `status: triaged` (auto-applied for maintainers
94
+
# / NVIDIA-NeMo org members; a maintainer adds it after triage for external
95
+
# contributors). Gates review noise on agent/external PRs.
96
+
labels:
97
+
- "status: triaged"
70
98
# Base branches (other than the default branch) to review. Accepts regex patterns. Use '.*' to match all branches.
description: Propose a maintainer-led refactor for discussion
3
+
title: "refactor: "
4
+
labels: ["refactoring", "status: needs triage"]
5
+
body:
6
+
- type: markdown
7
+
attributes:
8
+
value: |
9
+
Refactors are maintainer-led and are not accepted as unsolicited pull requests.
10
+
11
+
Use this form to explain the problem and proposed direction. Maintainers decide whether the refactor should happen, what plan is acceptable, and who, if anyone, should be assigned to implement it.
12
+
- type: checkboxes
13
+
attributes:
14
+
label: Required checks
15
+
description: Confirm before submitting this proposal.
16
+
options:
17
+
- label: I searched existing issues and pull requests for related refactor proposals.
18
+
required: true
19
+
- label: I understand that opening this issue does not mean a refactor PR will be accepted.
20
+
required: true
21
+
- label: I understand that a refactor PR should not be opened unless a maintainer approves the plan and assigns the work.
22
+
required: true
23
+
- type: textarea
24
+
attributes:
25
+
label: Problem
26
+
description: What is hard to maintain, unsafe, confusing, or blocking today?
27
+
placeholder: Describe the current design problem and why it matters.
28
+
validations:
29
+
required: true
30
+
- type: textarea
31
+
attributes:
32
+
label: Proposed direction
33
+
description: What structural direction do you think maintainers should consider?
34
+
placeholder: Keep this high level unless maintainers have asked for detailed design.
35
+
validations:
36
+
required: true
37
+
- type: textarea
38
+
attributes:
39
+
label: Migration and compatibility notes
40
+
description: What public APIs, config formats, docs, or user workflows could be affected?
41
+
validations:
42
+
required: true
43
+
- type: textarea
44
+
attributes:
45
+
label: Validation plan
46
+
description: What tests, docs checks, or compatibility checks would be needed?
47
+
validations:
48
+
required: true
49
+
- type: textarea
50
+
attributes:
51
+
label: Risks
52
+
description: List known risks, open questions, and possible alternatives.
53
+
validations:
54
+
required: true
55
+
- type: textarea
56
+
attributes:
57
+
label: Relevant branch or files
58
+
description: Optional. Share a WIP branch, affected files, or investigation notes if useful.
59
+
validations:
60
+
required: false
61
+
- type: dropdown
62
+
attributes:
63
+
label: Are you interested in helping after maintainer approval?
64
+
description: This does not assign you to the work. Maintainers decide ownership after triage.
65
+
options:
66
+
- I am only proposing this for maintainer consideration.
67
+
- I can help with investigation if maintainers ask.
68
+
- I can help implement after maintainers approve a plan and assign the work.
0 commit comments