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
Before anything else, read and follow AGENTS.md for this repository and module.
35
-
Review this pull request:
36
-
- Check for code quality issues
37
-
- Look for potential bugs
38
-
- Suggest improvements
39
-
- If you make any code edits, run 'cd Client && just test' to verify they compile and pass tests before committing.
35
+
Before doing anything else, read and follow AGENTS.md for this repository and for any affected module.
36
+
37
+
You are reviewing this pull request only. Do not edit files, do not commit changes, and do not attempt to rewrite the PR.
38
+
39
+
Review only the changes introduced by this pull request, using surrounding repository context only when needed to understand correctness.
40
+
41
+
Focus on:
42
+
- Correctness bugs
43
+
- Regressions
44
+
- Unsafe assumptions
45
+
- Error handling problems
46
+
- API misuse
47
+
- Race conditions, lifetime issues, ownership issues, or resource leaks
48
+
- Test coverage gaps where the changed behaviour is not adequately covered
49
+
- Maintainability issues that would realistically matter in this codebase
50
+
51
+
Do not comment on:
52
+
- Pure style preferences unless AGENTS.md or existing repository conventions clearly require them
53
+
- Hypothetical rewrites
54
+
- Broad architecture advice unrelated to this PR
55
+
- Trivial naming or formatting issues unless they obscure correctness
56
+
- Missing tests for code that has no meaningful behavioural change
57
+
58
+
Output requirements:
59
+
- Start with review findings, not process narration
60
+
- Do not describe which files you read or how you investigated
61
+
- Every comment must be either a concrete finding or an explicit no-issues verdict
62
+
- If you found no blocking or important issues, say exactly that and stop
63
+
64
+
For every finding:
65
+
- Cite the specific file and changed line/range when possible
66
+
- Explain why it is a real issue
67
+
- Explain the likely impact
68
+
- Suggest the smallest reasonable fix
69
+
- State confidence as High, Medium, or Low
70
+
71
+
Use this severity scale:
72
+
- Blocking: correctness, data loss, security, build failure, test failure, serious regression
73
+
- Important: likely bug, maintainability risk, missing validation, meaningful test gap, or unproven cross-layer behaviour
74
+
- Minor: small cleanup with clear value
75
+
76
+
Prefer fewer, higher-confidence comments over many speculative comments.
77
+
78
+
Pay special attention to semantic mismatches:
79
+
- Comments that do not match the code behaviour
80
+
- Variable names that imply different behaviour than the implementation
81
+
- Function names that imply different behaviour than the implementation
82
+
- Frontend/backend/plugin contract mismatches
83
+
- Changed values passed across process, IPC, API, or plugin boundaries
84
+
- Sentinel values such as 0, -1, null, undefined, empty strings, and empty arrays
85
+
- Type-safe code that may still be behaviourally wrong
86
+
87
+
When reviewing sentinel values:
88
+
- Do not assume 0 means "unlimited", "default", "disabled", or "empty" unless the implementation explicitly proves it
89
+
- Do not assume null, undefined, empty strings, or empty arrays preserve existing/default behaviour unless the implementation explicitly proves it
90
+
- Trace the changed value through every visible layer before deciding it is safe
91
+
- If a changed value crosses frontend/backend/plugin boundaries and its final meaning is not explicitly proven, flag it as an Important finding
92
+
- If behaviour depends on a downstream plugin, backend, external command, or runtime convention that is not visible in the PR, flag the assumption instead of treating it as safe
93
+
- Treat contradictions between comments and runtime behaviour as review-worthy
94
+
95
+
Treat contradictory intent as a real bug:
96
+
- If a comment, variable name, function name, or PR intent says the code should do one thing, but the implementation appears to do another, flag it as an Important finding
97
+
- Do not rationalise contradictions as intentional unless the implementation explicitly proves that interpretation
98
+
- Do not describe contradictory behaviour as correct
99
+
- Example: if code claims to load "full history" but passes `limit: 0`, and the visible backend preserves `0` as `0`, you must flag that as a potential bug unless another visible layer explicitly maps `0` to unlimited
100
+
101
+
Before concluding that there are no substantive issues:
102
+
- Re-check any finding where the code behaviour appears to contradict a comment, variable name, function name, or stated intent
103
+
- Re-check every changed sentinel value that crosses a frontend/backend/plugin boundary
104
+
- Do not treat "the code compiles" as evidence that behaviour is correct
105
+
- Do not infer intended behaviour from comments alone
106
+
- If you are relying on an assumption about downstream behaviour, say so explicitly and treat it as a review concern
107
+
108
+
If there are no substantive issues, say that no blocking or important issues were found. Do not invent issues to appear useful. Do not mention the review process, file reads, or search steps in the final output.
Before anything else, read and follow AGENTS.md for this repository and module.
53
-
Review this pull request:
54
-
- Check for code quality issues
55
-
- Look for potential bugs
56
-
- Suggest improvements
57
-
- If you make any code edits, run 'cd Client && just test' to verify they compile and pass tests before committing.
122
+
Before doing anything else, read and follow AGENTS.md for this repository and for any affected module.
123
+
124
+
You are reviewing this pull request only. Do not edit files, do not commit changes, and do not attempt to rewrite the PR.
125
+
126
+
Review only the changes introduced by this pull request, using surrounding repository context only when needed to understand correctness.
127
+
128
+
Focus on:
129
+
- Correctness bugs
130
+
- Regressions
131
+
- Unsafe assumptions
132
+
- Error handling problems
133
+
- API misuse
134
+
- Race conditions, lifetime issues, ownership issues, or resource leaks
135
+
- Test coverage gaps where the changed behaviour is not adequately covered
136
+
- Maintainability issues that would realistically matter in this codebase
137
+
138
+
Do not comment on:
139
+
- Pure style preferences unless AGENTS.md or existing repository conventions clearly require them
140
+
- Hypothetical rewrites
141
+
- Broad architecture advice unrelated to this PR
142
+
- Trivial naming or formatting issues unless they obscure correctness
143
+
- Missing tests for code that has no meaningful behavioural change
144
+
145
+
Output requirements:
146
+
- Start with review findings, not process narration
147
+
- Do not describe which files you read or how you investigated
148
+
- Every comment must be either a concrete finding or an explicit no-issues verdict
149
+
- If you found no blocking or important issues, say exactly that and stop
150
+
151
+
For every finding:
152
+
- Cite the specific file and changed line/range when possible
153
+
- Explain why it is a real issue
154
+
- Explain the likely impact
155
+
- Suggest the smallest reasonable fix
156
+
- State confidence as High, Medium, or Low
157
+
158
+
Use this severity scale:
159
+
- Blocking: correctness, data loss, security, build failure, test failure, serious regression
160
+
- Important: likely bug, maintainability risk, missing validation, meaningful test gap, or unproven cross-layer behaviour
161
+
- Minor: small cleanup with clear value
162
+
163
+
Prefer fewer, higher-confidence comments over many speculative comments.
164
+
165
+
Pay special attention to semantic mismatches:
166
+
- Comments that do not match the code behaviour
167
+
- Variable names that imply different behaviour than the implementation
168
+
- Function names that imply different behaviour than the implementation
169
+
- Frontend/backend/plugin contract mismatches
170
+
- Changed values passed across process, IPC, API, or plugin boundaries
171
+
- Sentinel values such as 0, -1, null, undefined, empty strings, and empty arrays
172
+
- Type-safe code that may still be behaviourally wrong
173
+
174
+
When reviewing sentinel values:
175
+
- Do not assume 0 means "unlimited", "default", "disabled", or "empty" unless the implementation explicitly proves it
176
+
- Do not assume null, undefined, empty strings, or empty arrays preserve existing/default behaviour unless the implementation explicitly proves it
177
+
- Trace the changed value through every visible layer before deciding it is safe
178
+
- If a changed value crosses frontend/backend/plugin boundaries and its final meaning is not explicitly proven, flag it as an Important finding
179
+
- If behaviour depends on a downstream plugin, backend, external command, or runtime convention that is not visible in the PR, flag the assumption instead of treating it as safe
180
+
- Treat contradictions between comments and runtime behaviour as review-worthy
181
+
182
+
Treat contradictory intent as a real bug:
183
+
- If a comment, variable name, function name, or PR intent says the code should do one thing, but the implementation appears to do another, flag it as an Important finding
184
+
- Do not rationalise contradictions as intentional unless the implementation explicitly proves that interpretation
185
+
- Do not describe contradictory behaviour as correct
186
+
- Example: if code claims to load "full history" but passes `limit: 0`, and the visible backend preserves `0` as `0`, you must flag that as a potential bug unless another visible layer explicitly maps `0` to unlimited
187
+
188
+
Before concluding that there are no substantive issues:
189
+
- Re-check any finding where the code behaviour appears to contradict a comment, variable name, function name, or stated intent
190
+
- Re-check every changed sentinel value that crosses a frontend/backend/plugin boundary
191
+
- Do not treat "the code compiles" as evidence that behaviour is correct
192
+
- Do not infer intended behaviour from comments alone
193
+
- If you are relying on an assumption about downstream behaviour, say so explicitly and treat it as a review concern
194
+
195
+
If there are no substantive issues, say that no blocking or important issues were found. Do not invent issues to appear useful. Do not mention the review process, file reads, or search steps in the final output.
0 commit comments