Conversation
Reviewer's GuidePR enhances manifest version handling by deserializing File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary by CodeRabbit
WalkthroughUpdate documentation and example YAML files to standardise Changes
Sequence Diagram(s)sequenceDiagram
participant TestRunner
participant ManifestParser
participant ErrorHandler
TestRunner->>ManifestParser: Parse manifest with netsuke_version: "1.0"
ManifestParser-->>ErrorHandler: Detect invalid version string
ErrorHandler-->>TestRunner: Return error message containing "version"
TestRunner->>TestRunner: Assert parsing failed and error message contains "version"
Estimated code review effort2 (~12 minutes) Possibly related PRs
Suggested reviewers
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 (
|
![codescene-delta-analysis[bot]](https://avatars.githubusercontent.com/in/53921?s=60&v=4){kind=small}
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
![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 (12)
docs/behavioural-testing-in-rust-with-cucumber.md(1 hunks)docs/netsuke-design.md(4 hunks)docs/roadmap.md(1 hunks)examples/basic_c.yml(1 hunks)examples/photo_edit.yml(1 hunks)examples/visual_design.yml(1 hunks)examples/website.yml(1 hunks)examples/writing.yml(1 hunks)tests/ast_tests.rs(1 hunks)tests/data/invalid_version.yml(1 hunks)tests/features/manifest.feature(1 hunks)tests/steps/manifest_steps.rs(1 hunks)
📓 Path-based instructions (4)
docs/**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
docs/**/*.md: Use the markdown files within the docs/ directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update the relevant file(s) in the docs/ directory to reflect the latest state when new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve.
Documentation must use en-GB-oxendict spelling and grammar (with the exception of 'license' which is to be left unchanged for community consistency).
Files:
docs/roadmap.mddocs/behavioural-testing-in-rust-with-cucumber.mddocs/netsuke-design.md
**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.md: Validate Markdown files using make markdownlint.
Run make fmt after any documentation changes to format all Markdown files and fix table markup.
Validate Mermaid diagrams in Markdown files by running make nixie.
Markdown paragraphs and bullet points must be wrapped at 80 columns.
Code blocks in Markdown must be wrapped at 120 columns.
Tables and headings in Markdown must not be wrapped.
Use dashes (-) for list bullets in Markdown.
Use GitHub-flavoured Markdown footnotes ([^1]) for references.
Files:
docs/roadmap.mddocs/behavioural-testing-in-rust-with-cucumber.mddocs/netsuke-design.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/roadmap.mddocs/behavioural-testing-in-rust-with-cucumber.mddocs/netsuke-design.md
**/*.rs
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.rs: 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.
Document public APIs using Rustdoc comments (///) so documentation can be generated with cargo doc.
Every module must begin with a module level (//!) comment explaining the module's purpose and utility.
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.
Place function attributes after doc comments.
Do not use return in single-line functions.
Use predicate functions for conditional criteria with more than two branches.
Lints must not be silenced except as a last resort.
Lint rule suppressions must be tightly scoped and include a clear reason.
Prefer expect over allow.
Prefer .expect() over .unwrap().
Files:
tests/ast_tests.rstests/steps/manifest_steps.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:
tests/ast_tests.rstests/steps/manifest_steps.rs
**/*{_test,tests}.rs
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*{_test,tests}.rs: Write unit and behavioural tests for new functionality. Run both before and after making any change.
Use rstest fixtures for shared setup.
Replace duplicated tests with #[rstest(...)] parameterised cases.
Prefer mockall for mocks/stubs.
Files:
tests/ast_tests.rs
🧰 Additional context used
📓 Path-based instructions (4)
docs/**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
docs/**/*.md: Use the markdown files within the docs/ directory as a knowledge base and source of truth for project requirements, dependency choices, and architectural decisions.
Proactively update the relevant file(s) in the docs/ directory to reflect the latest state when new decisions are made, requirements change, libraries are added/removed, or architectural patterns evolve.
Documentation must use en-GB-oxendict spelling and grammar (with the exception of 'license' which is to be left unchanged for community consistency).
Files:
docs/roadmap.mddocs/behavioural-testing-in-rust-with-cucumber.mddocs/netsuke-design.md
**/*.md
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.md: Validate Markdown files using make markdownlint.
Run make fmt after any documentation changes to format all Markdown files and fix table markup.
Validate Mermaid diagrams in Markdown files by running make nixie.
Markdown paragraphs and bullet points must be wrapped at 80 columns.
Code blocks in Markdown must be wrapped at 120 columns.
Tables and headings in Markdown must not be wrapped.
Use dashes (-) for list bullets in Markdown.
Use GitHub-flavoured Markdown footnotes ([^1]) for references.
Files:
docs/roadmap.mddocs/behavioural-testing-in-rust-with-cucumber.mddocs/netsuke-design.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/roadmap.mddocs/behavioural-testing-in-rust-with-cucumber.mddocs/netsuke-design.md
**/*.rs
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*.rs: 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.
Document public APIs using Rustdoc comments (///) so documentation can be generated with cargo doc.
Every module must begin with a module level (//!) comment explaining the module's purpose and utility.
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.
Place function attributes after doc comments.
Do not use return in single-line functions.
Use predicate functions for conditional criteria with more than two branches.
Lints must not be silenced except as a last resort.
Lint rule suppressions must be tightly scoped and include a clear reason.
Prefer expect over allow.
Prefer .expect() over .unwrap().
Files:
tests/ast_tests.rstests/steps/manifest_steps.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:
tests/ast_tests.rstests/steps/manifest_steps.rs
**/*{_test,tests}.rs
📄 CodeRabbit Inference Engine (AGENTS.md)
**/*{_test,tests}.rs: Write unit and behavioural tests for new functionality. Run both before and after making any change.
Use rstest fixtures for shared setup.
Replace duplicated tests with #[rstest(...)] parameterised cases.
Prefer mockall for mocks/stubs.
Files:
tests/ast_tests.rs
🔇 Additional comments (16)
examples/basic_c.yml (1)
1-1: Maintain semver-compliant manifest version; change is correct.
"1.0.0"satisfies semantic-version parsing while remaining quoted to avoid YAML numeric coercion. No further action required.examples/website.yml (1)
1-1: Keep version string in full semver form.The update to
"1.0.0"aligns the sample manifest with the new validation logic. Good work.examples/writing.yml (1)
1-1: Version field updated to valid semver.Change is correct and consistent with other examples.
tests/data/invalid_version.yml (1)
1-6: Test fixture correctly captures invalid version.The manifest intentionally uses
"1.0"to trigger validation failure in tests. File structure is minimal yet sufficient.examples/visual_design.yml (1)
1-1: Semantic versioning compliance correctly implemented.The update from "1.0" to "1.0.0" aligns with the semver crate validation requirements and maintains consistency across example manifests.
examples/photo_edit.yml (1)
1-1: Consistent semantic versioning update applied.The version string correctly updated to "1.0.0" to comply with semver validation requirements.
docs/roadmap.md (1)
27-28: Roadmap accurately updated to reflect completed implementation.The checklist item correctly marked as complete with proper formatting and annotation style consistent with other completed items.
tests/ast_tests.rs (1)
217-221: Well-implemented unit test for version validation.The test correctly validates that invalid semantic version strings cause deserialization to fail. The test name is descriptive and the implementation is concise and focused.
tests/features/manifest.feature (1)
8-11: Comprehensive integration test scenario for version validation.The Cucumber scenario properly tests both the failure condition and error message content, providing valuable integration-level coverage that complements the unit tests. The Gherkin syntax is correct and the scenario is well-structured.
docs/netsuke-design.md (5)
406-410: LGTM! Code block delimiter corrected.The change from quadruple to triple backticks properly formats the Rust code block for correct syntax highlighting and rendering.
490-491: LGTM! Consistent code block formatting maintained.The correction ensures proper markdown syntax for the Rust code example.
553-554: LGTM! YAML code block delimiter corrected.The formatting fix ensures proper syntax highlighting for the YAML example.
590-594: Excellent clarification of semver parsing implementation.The addition clearly explains how
netsuke_versionvalidation works using thesemver::Versionlibrary'sDeserializeimplementation. This provides users with a clear understanding of the strict semantic versioning requirement and failure behaviour.
1004-1012: LGTM! Ninja code block formatting corrected.The fixes ensure proper markdown syntax for the Ninja build file examples, maintaining consistent formatting throughout the documentation.
tests/steps/manifest_steps.rs (2)
58-62: Well-implemented failure validation step.The function properly validates both aspects of parsing failure: the absence of a successfully parsed manifest and the presence of an error message. The assertion messages are clear and helpful for debugging test failures.
64-72: Excellent error message validation step.The function properly implements error message content checking with appropriate Clippy suppression, clear expectations, and a helpful assertion message that shows both actual and expected content. The implementation follows established testing patterns in the codebase.
| July 2025 — | ||
| <https://docs.rs/cucumber/latest/cucumber/struct.Cucumber.html> | ||
| <https://docs.rs/cucumber/latest/cucumber/struct.Cucumber.html> |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Fix inconsistent footnote indentation.
Keep footnote URLs indented uniformly at four spaces to match the rest of the document and avoid visual drift.
- <https://docs.rs/cucumber/latest/cucumber/struct.Cucumber.html>
+ <https://docs.rs/cucumber/latest/cucumber/struct.Cucumber.html>📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| July 2025 — | |
| <https://docs.rs/cucumber/latest/cucumber/struct.Cucumber.html> | |
| <https://docs.rs/cucumber/latest/cucumber/struct.Cucumber.html> | |
| July 2025 — | |
| <https://docs.rs/cucumber/latest/cucumber/struct.Cucumber.html> |
🤖 Prompt for AI Agents
In docs/behavioural-testing-in-rust-with-cucumber.md around lines 1168 to 1169,
the footnote URL indentation is inconsistent. Adjust the indentation of the
footnote URL line to be uniformly four spaces, matching the rest of the
document's footnote style to maintain visual consistency.
1 participant
Summary
netsuke_versionusingsemver::Version1.0.0Testing
make fmtmake lintmake testhttps://chatgpt.com/codex/tasks/task_e_68800bd49a508322af89553d36827559
Summary by Sourcery
Enforce semantic versioning on the manifest’s version field, update related documentation and examples, and expand tests for invalid version handling
New Features:
Enhancements:
Documentation:
Tests: