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
+133-1Lines changed: 133 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -20,7 +20,139 @@ reviews:
20
20
- develop
21
21
- main
22
22
path_filters:
23
-
- '!**/docs/docs/**'
23
+
- "!**/docs/docs/**"
24
24
- "!*.html"
25
25
- "!*.md"
26
26
- "!*.svg"
27
+
path_instructions:
28
+
- path: "**/*"
29
+
instructions: |
30
+
Full review
31
+
32
+
Perform a comprehensive analysis and reevaluate all resolved items with the following criteria:
33
+
34
+
1. **Test Coverage Analysis:**
35
+
1. For each modified or new test file, verify:
36
+
1. Tests follow the mercuriusClient integration test pattern (preferred over vi.mock unit tests) with proper GraphQL document nodes
37
+
2. All edge cases and use cases are covered (success paths, error paths, boundary conditions, authentication/authorization checks)
38
+
3. Test assertions are correct and meaningful
39
+
4. 100% code coverage is achieved for the associated implementation files
40
+
5. No redundant or duplicate test cases exist
41
+
6. Test files are in the correct location (e.g., test/graphql/types/Mutation/ not test/routes/graphql/Mutation/)
42
+
43
+
2. For each modified or new source file, identify:
44
+
- Specific lines of code lacking test coverage (list exact line numbers)
45
+
- Functions, branches, or conditions that need additional test cases
46
+
- Mock/stub requirements that may be missing
47
+
- Error scenarios that are not covered (invalid arguments, resource not found, permission denied, etc.)
48
+
49
+
2. **Documentation & Code Comments:**
50
+
1. Verify auto-generated documentation is updated (as enforced by Check-AutoDocs job)
51
+
2. Check for adequate JSDoc comments on public functions and complex logic
52
+
3. Ensure README.md or related docs are updated if new features are added
53
+
4. Validate that Table of Contents is updated (as required by pre-commit hooks)
54
+
55
+
3. **Identify Issues:**
56
+
1. Lines of code that are missing tests (list specific line numbers)
57
+
2. Any unnecessary files that have been submitted (build artifacts, node_modules, .env files, IDE configs)
58
+
3. Unused imports or dead code (as checked by knip)
59
+
4. Console.log statements or debug code left in production files
60
+
5. Files that should be excluded from the PR scope
61
+
62
+
4. **PR Requirements Validation:**
63
+
1. Verify the PR meets the requirements of the linked issue:
64
+
1. All acceptance criteria are addressed
65
+
2. No out-of-scope changes are included
66
+
2. Validate compliance with all previously suggested improvements and comments:
67
+
1. All review comments have been addressed
68
+
2. Requested changes have been implemented correctly
69
+
3. Check PR metadata:
70
+
1. Proper title and description
71
+
2. Linked to appropriate issue(s)
72
+
3. Target branch is correct (typically `develop`)
73
+
4. Verify no sensitive information is exposed (as checked by Check-Sensitive-Files job)
74
+
75
+
5. **CI/CD Pipeline Compatibility:**
76
+
1. Validate that code changes won't break any of the 17+ CI jobs
77
+
2. Ensure pre-commit hook requirements are met:
78
+
1. Code formatting (Prettier)
79
+
2. Linting (ESLint)
80
+
3. Type checking (TypeScript)
81
+
3. Check that changes don't introduce performance regressions for the 12-shard test execution
82
+
4. Note: codecov/project may fail when adding comprehensive tests due to meta-coverage (test code branches not covered by meta-tests) - this is expected if codecov/patch passes
83
+
84
+
6. **Security & Best Practices:**
85
+
1. No security vulnerabilities introduced
86
+
2. No exposed API keys, tokens, or credentials
87
+
3. Proper input validation and sanitization
88
+
4. No SQL injection or XSS vulnerabilities in any data handling
89
+
5. Proper error handling without leaking sensitive information
1. For the specific implementation file(s) being tested:
99
+
1. Verify the implementation logic is correct and free of bugs
100
+
1. Validate that queries target the correct database tables/entities (e.g., ensure tagsTable vs tagFoldersTable is correct)
101
+
1. Check that foreign key relationships are correctly enforced
102
+
1. Confirm business logic constraints are properly implemented
103
+
1. Verify proper error handling and status codes
104
+
1. **CRITICAL:** Any bugs, logic errors, or incorrect implementations discovered in the file(s) under test MUST be fixed in this PR before approval
105
+
106
+
9. **Requirement Validation:**
107
+
1. Verify the PR fully addresses the linked issue:
108
+
1. All acceptance criteria from the issue are met
109
+
1. Implementation matches the described solution approach
110
+
1. No scope creep or unrelated changes are included
111
+
112
+
10. **Compliance:**
113
+
1. Confirm compliance with all previous review feedback:
114
+
1. All resolved comments have been properly addressed
115
+
1. No regressions of previously suggested improvements
116
+
1. Coding standards and conventions are followed consistently
117
+
118
+
11. **Review Decision Criteria:**
119
+
1. **Request Changes** when ANY of the following apply:
120
+
- Missing test coverage or invalid/insufficient tests
121
+
- Code quality issues, security concerns, or bugs
122
+
- Incomplete implementation of issue requirements
123
+
- Bugs or logic errors in the implementation file(s) under test
124
+
- Non-compliance with previous feedback
125
+
- Presence of unnecessary files
126
+
- Failing CI checks that need code changes
127
+
128
+
2. **Approve** ONLY when ALL of these are satisfied:
129
+
- Complete test coverage (≥95% for new/modified code, ≥80% overall)
130
+
- All tests follow proper patterns (mercuriusClient integration tests with proper structure)
131
+
- No code quality issues, security concerns, or bugs
132
+
- Full implementation of issue requirements
133
+
- Implementation file(s) under test are correct and bug-free
134
+
- Compliance with all previous feedback
135
+
- No unnecessary files
136
+
- All CI checks passing or failures are unrelated to this PR
137
+
138
+
12. **Approval Process:**
139
+
1. Only append the [approve] tag when you are approving, specifically when:
140
+
1. All criteria in section 11.2 above are fully satisfied
141
+
1. The implementation file(s) under test are correct and bug-free
142
+
1. Zero changes are required (not even trivial ones)
143
+
1. You are confident the PR is ready to merge
144
+
145
+
13. **Focus Areas:**
146
+
1. Prioritize substantive issues over minor stylistic suggestions
147
+
1. Focus on issues that would cause CI pipeline failures or production bugs
148
+
1. Highlight any deviations from established codebase patterns (e.g., incorrect test file locations, wrong testing patterns)
149
+
1. Consider the scope: test-focused PRs should maintain clear boundaries, but implementation bugs in files being tested must be fixed
150
+
151
+
**Important Notes:**
152
+
1. Test-focused PRs should maintain clear scope boundaries. However, this does NOT exempt bugs in the specific file(s) being tested - those must be fixed in the same PR to ensure testing achieves its goal: validate AND fix implementation correctness. Only bugs in unrelated files may be deferred to separate issues.
153
+
1. If codecov/project fails but codecov/patch passes, note that this is often due to meta-coverage issues (test code branches not covered by meta-tests) and may be acceptable.
154
+
1. When suggesting test improvements, prefer mercuriusClient integration tests with proper GraphQL document nodes over vi.mock unit tests, following the repository's testing philosophy.
This directory contains custom [GritQL](https://docs.grit.io/) plugins for [Biome](https://biomejs.dev/).
4
+
5
+
For detailed documentation on the active plugins and their impact on testing, please refer to the [Testing & Validation documentation](../docs/docs/docs/developer-resources/testing/testing-validation.md#biome-plugins).
// GritQL plugin to detect Pothos string resolvers that might need escapeHTML()
2
+
//
3
+
// IMPORTANT: GritQL comments are stripped from AST - cannot use disable comments.
4
+
// To exclude files, use Biome's linter.rules configuration in biome.jsonc.
5
+
//
6
+
// This is a diagnostic-only rule. It warns but cannot auto-fix.
7
+
//
8
+
// Examples:
9
+
//
10
+
// Triggers warning:
11
+
// t.string({
12
+
// resolve: (parent) => parent.bio // No escapeHTML
13
+
// })
14
+
//
15
+
// Does NOT trigger warning:
16
+
// t.string({
17
+
// resolve: (parent) => escapeHTML(parent.bio)
18
+
// })
19
+
20
+
// Match t.string with resolve function, flag if no escapeHTML call inside
21
+
`t.string({ $props })` where {
22
+
$props <: contains `resolve: $resolver`,
23
+
not $resolver <: contains `escapeHTML($arg)`,
24
+
register_diagnostic(span=$props, message="String resolver may need escapeHTML() for XSS prevention. Import from '~/src/utilities/sanitizer'.", severity="warn")
0 commit comments