human documenation - #574
Conversation
Expanded the README to include a detailed explanation of the 'no-mistakes' tool, its advantages, and trade-offs related to AST-parsing.
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
Reviewer's guide (collapsed on small PRs)Reviewer's GuideREADME documentation is expanded with a rationale section explaining the purpose of File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. 📝 WalkthroughSummary by CodeRabbit
WalkthroughREADME.md adds a Slop Warning, expands the AST-parsing explanation and trade-offs, adds contribution and support guidance, and removes the Link Lint instructions. ChangesREADME documentation
Estimated code review effort: 1 (Trivial) | ~2 minutes Suggested labels: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
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.
Hey - I've found 1 issue, and left some high level feedback:
- There’s a typo in the new README section (“understnad” should be “understand”), and it’s worth quickly scanning the added text for similar small errors to keep the messaging polished.
- Consider briefly clarifying what “high recall and low precision” means in practical terms for users (e.g., a short example of a likely false positive) to make the trade-off more immediately understandable.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- There’s a typo in the new README section (“understnad” should be “understand”), and it’s worth quickly scanning the added text for similar small errors to keep the messaging polished.
- Consider briefly clarifying what “high recall and low precision” means in practical terms for users (e.g., a short example of a likely false positive) to make the trade-off more immediately understandable.
## Individual Comments
### Comment 1
<location path="README.md" line_range="31" />
<code_context>
+
+There are a few trade-offs with this approach:
+
+1. Some code is difficult to understnad through AST-parsing, so `no-mistakes` includes rules that enforce AST-parsing-friendly coding. For example, Playwright test selectors should be simple strings - dynamically generated strings will not match well.
+2. `no-mistakes` is best effort, with high recall and low precision, meaning it may return wrong information/relationships, but should never miss a relationship. An agent should verify if a relationship returned is true.
+3. High CPU usage - parsing your repository on-demand may cause high-CPU usage, but may be significantly faster than other methods (e.g. `vitest related` takes 2 minutes on a sample repository, but takes 1 second with `no-mistakes` via `no-mistakes test plan` and supports Playwright). This may become a bottleneck when working on multiple worktrees at once, but `no-mistakes` includes a locking mechanism to not run concurrently.
</code_context>
<issue_to_address>
**issue (typo):** Correct the typo "understnad" to "understand."
```suggestion
1. Some code is difficult to understand through AST-parsing, so `no-mistakes` includes rules that enforce AST-parsing-friendly coding. For example, Playwright test selectors should be simple strings - dynamically generated strings will not match well.
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
|
|
||
| There are a few trade-offs with this approach: | ||
|
|
||
| 1. Some code is difficult to understnad through AST-parsing, so `no-mistakes` includes rules that enforce AST-parsing-friendly coding. For example, Playwright test selectors should be simple strings - dynamically generated strings will not match well. |
There was a problem hiding this comment.
issue (typo): Correct the typo "understnad" to "understand."
| 1. Some code is difficult to understnad through AST-parsing, so `no-mistakes` includes rules that enforce AST-parsing-friendly coding. For example, Playwright test selectors should be simple strings - dynamically generated strings will not match well. | |
| 1. Some code is difficult to understand through AST-parsing, so `no-mistakes` includes rules that enforce AST-parsing-friendly coding. For example, Playwright test selectors should be simple strings - dynamically generated strings will not match well. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 `@README.md`:
- Line 32: Update the no-mistakes description to avoid guaranteeing that
relationships are never missed: present high recall as an aspiration or advise
agents to verify important relationships, while preserving the existing warning
about potentially incorrect relationships.
- Line 31: Correct the misspelled word “understnad” to “understand” in the
README sentence describing AST parsing, leaving the rest of the text unchanged.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
|
|
||
| There are a few trade-offs with this approach: | ||
|
|
||
| 1. Some code is difficult to understnad through AST-parsing, so `no-mistakes` includes rules that enforce AST-parsing-friendly coding. For example, Playwright test selectors should be simple strings - dynamically generated strings will not match well. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix the spelling error.
Change understnad to understand.
🧰 Tools
🪛 LanguageTool
[grammar] ~31-~31: Ensure spelling is correct
Context: ...approach: 1. Some code is difficult to understnad through AST-parsing, so no-mistakes i...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 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 `@README.md` at line 31, Correct the misspelled word “understnad” to
“understand” in the README sentence describing AST parsing, leaving the rest of
the text unchanged.
Source: Linters/SAST tools
Updated README to improve clarity and fix typos.
Added support status for various languages and tools.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
README.md (1)
143-144: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winKeep a local link-check path for contributors.
CI still runs Lychee over
README.mdand documentation files in.github/workflows/ci.yml; removing the only README instructions leaves contributors without a documented way to reproduce that check locally. Retain a short command or link to the CI check.🤖 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 `@README.md` around lines 143 - 144, Restore a concise README section documenting how contributors can run the same Lychee link check locally, or link to the corresponding workflow in `.github/workflows/ci.yml`; keep the instructions aligned with the CI check covering README.md and documentation files.
🤖 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 `@README.md`:
- Line 21: Update the README sentence beginning “The primary use-cases of
`no-mistakes`” to use “are” instead of “is,” preserving the rest of the wording.
- Line 33: In the README text, correct the misspelled word “determinstically” to
“deterministically” while leaving the surrounding statement unchanged.
- Around line 21-25: Add a concrete diff-input command to the README’s primary
use-cases or test-selection documentation, alongside the existing --changed-file
examples. Use the tool’s supported diff argument and show a representative diff
source so users can see how to select tests from changes.
---
Nitpick comments:
In `@README.md`:
- Around line 143-144: Restore a concise README section documenting how
contributors can run the same Lychee link check locally, or link to the
corresponding workflow in `.github/workflows/ci.yml`; keep the instructions
aligned with the CI check covering README.md and documentation files.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| The primary use-cases of `no-mistakes` is: | ||
|
|
||
| 1. Discovering impacted files and tests during planning | ||
| 2. Running selected tests in PR CI to minimize CI costs | ||
| 3. AST-based guardrails for your coding agents to minimize entropy and power the above use-cases |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Add the promised diff-based test-selection example.
The PR objective calls for documenting a diff input, but this README only describes test selection and shows --changed-file examples. Add a concrete command demonstrating how to pass a diff.
🤖 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 `@README.md` around lines 21 - 25, Add a concrete diff-input command to the
README’s primary use-cases or test-selection documentation, alongside the
existing --changed-file examples. Use the tool’s supported diff argument and
show a representative diff source so users can see how to select tests from
changes.
|
|
||
| During planning, `no-mistakes` will provide the full dependency chain to the agent in a single, fast, CLI command. | ||
| During CI testing, a `getPost()` change will select the relevant Playwright tests to run. | ||
| No embeddings, all determinstically. |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix the spelling error.
Change determinstically to deterministically.
🧰 Tools
🪛 LanguageTool
[grammar] ~33-~33: Ensure spelling is correct
Context: ...wright tests to run. No embeddings, all determinstically. ## Why? Most codebase intelligence tools c...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 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 `@README.md` at line 33, In the README text, correct the misspelled word
“determinstically” to “deterministically” while leaving the surrounding
statement unchanged.
Source: Linters/SAST tools
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #574 +/- ##
==========================================
- Coverage 99.46% 99.22% -0.25%
==========================================
Files 1043 1239 +196
Lines 81869 96925 +15056
==========================================
+ Hits 81432 96171 +14739
- Misses 437 754 +317
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
difffor test selection