Conversation
Reviewer's GuideThis PR introduces an end-of-review banner that is printed after all pull request review threads, and updates the README and design documentation to mention and describe this new completion notice. Sequence diagram for printing the end-of-review banner after PR threadssequenceDiagram
participant CLI as vk CLI
participant GH as GitHub API
participant Print as print_thread
participant Banner as print_end_banner
CLI->>GH: Fetch PR review threads
loop For each thread
CLI->>Print: print_thread(thread)
Print-->>CLI: Thread output
end
CLI->>Banner: print_end_banner()
Banner-->>CLI: Prints 'end of code review' banner
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Rate limit exceeded@leynos has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 9 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (1)
Summary by CodeRabbit
WalkthroughUpdate the documentation and README to clarify the new feature: a final "end of code review" banner is printed after all review threads. Add the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI (vk)
participant GitHub API
User->>CLI (vk): Run pr subcommand
CLI (vk)->>GitHub API: Fetch unresolved review threads
GitHub API-->>CLI (vk): Return review threads
CLI (vk)->>CLI (vk): Print review threads
CLI (vk)->>CLI (vk): Print "========== end of code review =========="
CLI (vk)-->>User: Output complete review with end banner
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Possibly related PRs
Poem
✨ Finishing Touches🧪 Generate unit tests
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @leynos - I've reviewed your changes and found some issues that need to be addressed.
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `src/main.rs:639` </location>
<code_context>
}
+/// Print a closing banner once all review threads have been displayed.
+fn print_end_banner() {
+ println!("========== end of code review ==========");
+}
</code_context>
<issue_to_address>
The module does not begin with a `//!` comment as required by the review instructions.
Please add a `//!` module-level comment at the very top of this file to describe its purpose, as per the project guidelines.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
AGENTS.md(4 hunks)docs/GITHUB_TOKEN.md(1 hunks)src/main.rs(3 hunks)
🧰 Additional context used
📓 Path-based instructions (3)
docs/**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
docs/**/*.md: Reference: Use the markdown files within the docs/ directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Update: When new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve, proactively update the relevant file(s) in the docs/ directory to reflect the latest state.
Files:
docs/GITHUB_TOKEN.md
**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.md: Validate Markdown files using markdownlint.
Validate Markdown Mermaid diagrams using the nixie CLI.
Files:
docs/GITHUB_TOKEN.mdAGENTS.md
⚙️ CodeRabbit Configuration File
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -our) spelling and grammar
- Paragraphs and bullets must be wrapped to 80 columns, except where a long URL would prevent this (in which case, silence MD013 for that line)
- Code blocks should be wrapped to 120 columns.
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
docs/GITHUB_TOKEN.mdAGENTS.md
**/*.rs
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.rs: Run cargo fmt, cargo clippy -- -D warnings, and RUSTFLAGS="-D warnings" cargo test before committing.
Clippy warnings MUST be disallowed.
Fix any warnings emitted during tests in the code itself rather than silencing them.
Where a function is too long, extract meaningfully named helper functions adhering to separation of concerns and CQRS.
Where a function has too many parameters, group related parameters in meaningfully named structs.
Where a function is returning a large error consider using Arc to reduce the amount of data returned.
Write unit and behavioural tests for new functionality. Run both before and after making any change.
Document public APIs using Rustdoc comments (///) so documentation can be generated with cargo doc.
Prefer immutable data and avoid unnecessary mut bindings.
Handle errors with the Result type instead of panicking where feasible.
Avoid unsafe code unless absolutely necessary and document any usage clearly.
Files:
src/main.rs
⚙️ CodeRabbit Configuration File
**/*.rs: * Seek to keep the cyclomatic complexity of functions no more than 12.
Adhere to single responsibility and CQRS
Place function attributes after doc comments.
Do not use
returnin single-line functions.Move conditionals with >2 branches into a predicate function.
Avoid
unsafeunless absolutely necessary.Every module must begin with a
//!doc comment that explains the module's purpose and utility.Comments and docs must follow en-GB-oxendict (-ize / -our) spelling and grammar
Lints must not be silenced except as a last resort.
#[allow]is forbidden.- Only narrowly scoped
#[expect(lint, reason = "...")]is allowed.- No lint groups, no blanket or file-wide suppression.
- Include
FIXME:with link if a fix is expected.Use
rstestfixtures for shared setup and to avoid repetition between tests.Replace duplicated tests with
#[rstest(...)]parameterised cases.Prefer
mockallfor mocks/stubs.Prefer
.expect()over.unwrap()Ensure that any API or behavioural changes are reflected in the documentation in
docs/Ensure that any completed roadmap steps are recorded in the appropriate roadmap in
docs/Files must not exceed 400 lines in length
- Large modules must be decomposed
- Long match statements or dispatch tables should be decomposed by domain and collocated with targets
- Large blocks of inline data (e.g., test fixtures, constants or templates) must be moved to external files and inlined at compile-time or loaded at run-time.
Files:
src/main.rs
🧠 Learnings (1)
AGENTS.md (1)
Learnt from: CR
PR: leynos/wireframe#0
File: AGENTS.md:0-0
Timestamp: 2025-07-21T13:10:04.795Z
Learning: Applies to docs/**/*.md : Documentation must use en-GB-oxendict spelling and grammar (with the exception of 'license' which is to be left unchanged for community consistency).
🪛 LanguageTool
AGENTS.md
[locale-violation] ~47-~47: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...grammar. (EXCEPTION: the naming of the "LICENSE" file, which is to be left unchanged ...
(LICENCE_LICENSE_NOUN_SINGULAR)
[uncategorized] ~161-~161: Possible missing comma found.
Context: ...(>=) version requirements is strictly forbidden as they introduce unacceptable risk a...
(AI_HYDRA_LEO_MISSING_COMMA)
🔇 Additional comments (9)
docs/GITHUB_TOKEN.md (1)
7-7: LGTM: Proper line consolidation.The line consolidation improves readability whilst maintaining the 80-column wrapping guideline.
AGENTS.md (5)
12-13: LGTM: Improved readability through line consolidation.The reformatting enhances flow whilst maintaining the 80-column guideline.
28-32: LGTM: Clear documentation formatting.The line breaks improve readability of the file size requirements.
34-35: LGTM: Consistent formatting maintained.The line consolidation aligns with the project's documentation standards.
47-48: Ignore the static analysis hint about LICENSE spelling.The static analysis tool suggests changing "LICENSE" to "LICENCE" for British English, but the coding guidelines explicitly state this is an exception for community consistency. The current usage is correct.
169-170: LGTM: Proper line wrapping maintained.The formatting preserves readability within the column constraints.
src/main.rs (3)
1-7: LGTM: Clear documentation of the new feature.The crate-level documentation properly describes the end-of-review banner functionality and addresses the previous requirement for module-level comments.
640-643: LGTM: Simple and effective banner implementation.The function follows Rust best practices with a clear purpose, proper documentation, and no unnecessary return statement.
698-698: LGTM: Appropriate placement of the banner call.The banner is correctly positioned after all review threads have been processed, providing clear completion indication.
There was a problem hiding this comment.
Actionable comments posted: 2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
AGENTS.md(4 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.md: Validate Markdown files using markdownlint.
Validate Markdown Mermaid diagrams using the nixie CLI.
Files:
AGENTS.md
⚙️ CodeRabbit Configuration File
**/*.md: * Avoid 2nd person or 1st person pronouns ("I", "you", "we")
- Use en-GB-oxendict (-ize / -our) spelling and grammar
- Paragraphs and bullets must be wrapped to 80 columns, except where a long URL would prevent this (in which case, silence MD013 for that line)
- Code blocks should be wrapped to 120 columns.
- Headings must not be wrapped.
- Documents must start with a level 1 heading
- Headings must correctly increase or decrease by no more than one level at a time
- Use GitHub-flavoured Markdown style for footnotes and endnotes.
- Numbered footnotes must be numbered by order of appearance in the document.
Files:
AGENTS.md
🧠 Learnings (1)
AGENTS.md (3)
Learnt from: CR
PR: leynos/wireframe#0
File: AGENTS.md:0-0
Timestamp: 2025-07-21T13:10:04.795Z
Learning: Applies to docs/**/*.md : Documentation must use en-GB-oxendict spelling and grammar (with the exception of 'license' which is to be left unchanged for community consistency).
Learnt from: CR
PR: leynos/ddlint#0
File: AGENTS.md:0-0
Timestamp: 2025-07-18T18:35:14.639Z
Learning: Applies to docs/**/*.md : Documentation must use en-GB-oxendict spelling and grammar (with the exception of "license" which is to be left unchanged for community consistency).
Learnt from: CR
PR: leynos/lille#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T12:00:26.489Z
Learning: Applies to **/*.md : Documentation must use en-GB-oxendict spelling and grammar (with the exception of "license" which is to be left unchanged for community consistency).
🪛 LanguageTool
AGENTS.md
[locale-violation] ~46-~46: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...grammar. (EXCEPTION: the naming of the "LICENSE" file, which is to be left unchanged ...
(LICENCE_LICENSE_NOUN_SINGULAR)
1 participant
Summary
Testing
make lintmake testmake markdownlintmake nixie(fails: too many arguments)https://chatgpt.com/codex/tasks/task_e_6884fbe49d848322ad47a6ca1d22b533
Summary by Sourcery
Add a final completion banner to the CLI’s PR review output and update documentation to describe it
New Features:
Enhancements:
Documentation: