Conversation
Reviewer's GuideThis PR refines markdown documentation by standardizing footnote syntax to markdown footnotes, normalizing ordered list numbering, converting embedded HTML tables into markdown tables, and reflowing paragraphs for consistent line wrapping across multiple docs. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Summary by CodeRabbit
WalkthroughApply formatting and whitespace adjustments across multiple documentation files. Rewrap lines, adjust paragraph breaks, align tables, and refine indentation for improved readability and markdown consistency. Do not alter any technical content, logic, code examples, or API descriptions. No changes are made to exported or public entities. Changes
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}
There was a problem hiding this comment.
Hey @leynos - I've reviewed your changes - here's some feedback:
- Given the scale of these formatting-only changes, consider splitting the PR into smaller, focused commits (e.g., one for list numbering, one for footnotes, one for tables) to make reviews more manageable and reduce the risk of unintended content drift.
- A markdown linter or formatter (e.g., markdownlint or Prettier) could automate wrapping, list indentation, and footnote style enforcement to keep these docs consistent in the future.
- Please double‐check the rendered output (especially the converted tables and renumbered footnotes) in your markdown viewer to ensure all elements still display as intended across different platforms.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Given the scale of these formatting-only changes, consider splitting the PR into smaller, focused commits (e.g., one for list numbering, one for footnotes, one for tables) to make reviews more manageable and reduce the risk of unintended content drift.
- A markdown linter or formatter (e.g., markdownlint or Prettier) could automate wrapping, list indentation, and footnote style enforcement to keep these docs consistent in the future.
- Please double‐check the rendered output (especially the converted tables and renumbered footnotes) in your markdown viewer to ensure all elements still display as intended across different platforms.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}
| Use doc comments to document public APIs. Keep them consistent with the | ||
| contents of the manual. | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Wrap to 80 columns
This paragraph runs past the 80-column limit. Rewrap accordingly to satisfy the Markdown rules section of the same document.
🤖 Prompt for AI Agents
In docs/documentation-style-guide.md around lines 61 to 63, the paragraph
exceeds the 80-column width limit. Reformat the text by inserting line breaks so
that no line exceeds 80 characters, ensuring it complies with the Markdown rules
section of the document.
| **multi-packet streaming responses**, and **transparent message | ||
| fragmentation**. More than just a list of features, this is a statement of | ||
| capability maturity. It details a cohesive strategy for hardening the library | ||
| with production-grade resilience, first-class observability, and a rigorous | ||
| quality assurance process. The result will be a framework that is not only | ||
| powerful and flexible but also exceptionally robust, debuggable, and a pleasure | ||
| to use. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Wrap long sentence to ≤ 80 columns
The two-line sentence runs beyond the mandated 80-character limit, violating the project’s markdown wrapping rule.
- powerful and flexible but also exceptionally robust, debuggable, and a pleasure
- to use.
+ powerful and flexible but also exceptionally robust,
+ debuggable, and a pleasure to use.📝 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.
| **multi-packet streaming responses**, and **transparent message | |
| fragmentation**. More than just a list of features, this is a statement of | |
| capability maturity. It details a cohesive strategy for hardening the library | |
| with production-grade resilience, first-class observability, and a rigorous | |
| quality assurance process. The result will be a framework that is not only | |
| powerful and flexible but also exceptionally robust, debuggable, and a pleasure | |
| to use. | |
| **multi-packet streaming responses**, and **transparent message | |
| fragmentation**. More than just a list of features, this is a statement of | |
| capability maturity. It details a cohesive strategy for hardening the library | |
| with production-grade resilience, first-class observability, and a rigorous | |
| quality assurance process. The result will be a framework that is not only | |
| powerful and flexible but also exceptionally robust, | |
| debuggable, and a pleasure to use. |
🤖 Prompt for AI Agents
In
docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md
around lines 19 to 25, the long sentence exceeds the 80-character line length
limit. Break the sentence into multiple lines so that each line is at most 80
characters long, ensuring readability and compliance with the project's markdown
formatting rules.
There was a problem hiding this comment.
Actionable comments posted: 22
🔭 Outside diff range comments (3)
docs/hardening-wireframe-a-guide-to-production-resilience.md (1)
82-85: Ensure measurable-objective block fits width limit.Lines 82-85 breach the width limit. Apply hard wraps or silence MD013 once per
paragraph.docs/mocking-network-outages-in-rust.md (1)
502-567: Standardise spelling and pronoun usage; resolve variant clash (parameterized/parametrised)
Maintain en-GB spelling and remove personal pronouns.-As the above examples show, many scenarios follow a similar pattern of setup -and assertion. We can use the `rstest` crate to avoid repetitive code by -parameterizing the scenarios. The `#[rstest]` attribute allows us to define -multiple cases for a single test function. +The previous examples expose a repeating pattern of setup and assertion. Using +the `rstest` crate avoids repetitive code by parametrising the scenarios. The +`#[rstest]` attribute defines multiple cases for a single test function.docs/rust-testing-with-rstest-fixtures.md (1)
620-622: Fix invalid Rust lines hidden with#.Lines beginning with
#inside code blocks are interpreted by rustdoc as hidden code, but# name: &str,(and the similar# user_fixture: User) is not valid Rust and will break doctests if the file is ever promoted to one. Replace the hash prefix with a proper argument line or remove the hash completely.- # name: &str, + name: &str,-fn test_custom_name_user(# user_fixture: User) { +fn test_custom_name_user(user_fixture: User) {Also applies to: 646-647
| header bytes. Only the minimal header portion should be read, returning the | ||
| full frame and the number of bytes consumed from the input. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Wrap paragraph to ≤ 80 columns.
The two lines run past the mandated 80-column limit for prose in *.md files. Re-wrap to comply with the style guide.
-header bytes. Only the minimal header portion should be read, returning the
-full frame and the number of bytes consumed from the input.
+header bytes. Only the minimal header portion should be read, returning the
+full frame and the number of bytes consumed from the input.Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In docs/frame-metadata.md around lines 8 to 9, the paragraph exceeds the
80-column limit for markdown files. Reformat the text by inserting line breaks
so that no line exceeds 80 characters, ensuring compliance with the style guide
for readability.
| A library is functionally correct when it performs its specified tasks | ||
| according to its API. A library is *mature* when it anticipates the realities | ||
| of its operational environment. For a low-level networking framework like | ||
| `wireframe`, this means acknowledging that production systems are complex, | ||
| failures are inevitable, and visibility into runtime behaviour is | ||
| non-negotiable. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Wrap prose to 80 columns.
Lines 5-10 overrun the column limit. Hard-wrap after “framework like” or add an
MD013 suppression comment for the paragraph.
🤖 Prompt for AI Agents
In docs/observability-operability-and-maturity.md around lines 5 to 10, the
paragraph exceeds the 80-column limit. Fix this by hard-wrapping the text after
"framework like" or another suitable point to ensure no line exceeds 80
characters, maintaining readability and compliance with markdown style
guidelines.
| to perform the conversion explicitly within a fixture or at the beginning of | ||
| the test to handle errors more gracefully or provide more specific diagnostic | ||
| messages. | ||
|
|
||
| ## VI. Asynchronous Testing with `rstest` |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Terminate paragraph with punctuation.
Add a full stop at the end of the paragraph to satisfy grammar tooling.
- messages
+ messages.📝 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.
| to perform the conversion explicitly within a fixture or at the beginning of | |
| the test to handle errors more gracefully or provide more specific diagnostic | |
| messages. | |
| ## VI. Asynchronous Testing with `rstest` | |
| to perform the conversion explicitly within a fixture or at the beginning of | |
| the test to handle errors more gracefully or provide more specific diagnostic | |
| messages. | |
| ## VI. Asynchronous Testing with `rstest` |
🧰 Tools
🪛 LanguageTool
[grammar] ~692-~692: Please add a punctuation mark at the end of paragraph.
Context: ... messages. ## VI. Asynchronous Testing with rstest rstest provides robust supp...
(PUNCTUATION_PARAGRAPH_END)
🤖 Prompt for AI Agents
In docs/rust-testing-with-rstest-fixtures.md around lines 688 to 692, the
paragraph before the "## VI. Asynchronous Testing with `rstest`" heading is
missing a full stop at the end. Add a period at the end of the last sentence in
that paragraph to properly terminate it and satisfy grammar tooling.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 9
🔭 Outside diff range comments (4)
docs/observability-operability-and-maturity.md (2)
25-27: Remove first-person pronoun.Rewrite the clause beginning with “we provide users” to an impersonal construction to comply with the documentation style guide that forbids first- or second-person pronouns.
31-34: Eliminate first-person pronoun “we” in technical narrative.Replace “we must have structured, context-aware diagnostics” with a neutral phrasing such as “structured, context-aware diagnostics are required”.
docs/rust-testing-with-rstest-fixtures.md (2)
646-648: Repair invalid Rust snippet – remove stray#in function signature.The
#inside the parameter list breaks the example and may confuse readers.-fn test_custom_name_user(# user_fixture: User) { +fn test_custom_name_user(user_fixture: User) {
407-408: Eliminate second-person pronoun in prose-style comment.The phrase “you'd” breaches the style guide (“Avoid 2nd person”). Rephrase to remain impersonal.
-// In a real test, you'd have more specific assertions based on expected_next_state +// In a real test, more specific assertions based on expected_next_state should be provided
♻️ Duplicate comments (5)
docs/wireframe-1-0-detailed-development-roadmap.md (1)
27-27: Use the ellipsis character, add the hyphen, and apply the Oxford comma.Replace the ASCII triple-dot with “…”, hyphenate the compound adjective, and insert the serial comma for clarity.
-| 1.3 | Connection Actor Write Loop | Convert per-request workers into stateful connection actors. Implement a `select!(biased; ...)` loop that polls for shutdown signals, high/low priority pushes and the handler response stream in that strict order. | Large | #1.2 | +| 1.3 | Connection Actor Write Loop | Convert per-request workers into stateful connection actors. Implement a `select!(biased; …)` loop that polls for shutdown signals, high/low-priority pushes, and the handler response stream in that strict order. | Large | #1.2 |docs/rust-doctest-dry-guide.md (4)
7-8: Replace American “behavior” with British “behaviour”.- operates. Its behavior, particularly its testing mechanism, is not an arbitrary + operates. Its behaviour, particularly its testing mechanism, is not an arbitrary
273-276: Remove second-person pronouns and keep en-GB spelling.- For an example that demonstrates how to download a file from the internet, you want to ensure the example code is syntactically correct and uses the API properly, but you do not want your CI server to actually perform a network request every time tests are run. + For an example that demonstrates how to download a file from the internet, it is essential to confirm that the example code is syntactically correct and uses the API properly, while ensuring the CI server does not perform a network request during every test run.
608-610: Switch to British “behaviour”.- integration test compiled in a separate crate. This mental model explains - nearly all of its behavior. + integration test compiled in a separate crate. This mental model explains + nearly all of its behaviour.
244-251: Standardise register, spelling, and capitalisation inside the attribute table.-| ignore | Skips both compilation and execution. | ignored | Use Case: For pseudo-code, examples known to be broken, or to temporarily disable a test. Caveat: Provides no guarantee that the code is even syntactically correct. Generally discouraged in favor of more specific attributes.[^3] | -| should_panic | Compiles and runs the code. The test passes if the code panics. | ok on panic, failed if it does not panic. | Use Case: Demonstrating functions that are designed to panic on invalid input (e.g., indexing out of bounds). | -| compile_fail | Attempts to compile the code. The test passes if compilation fails. | ok on compilation failure, failed if it compiles successfully. | Use Case: Illustrating language rules, such as the borrow checker or type system constraints. Caveat: Highly brittle. A future Rust version might make the code valid, causing the test to unexpectedly fail.[^4] | -| no_run | Compiles the code but does not execute it. | ok if compilation succeeds. | Use Case: Essential for examples with undesirable side effects in a test environment, such as network requests, filesystem I/O, or launching a GUI. Guarantees the example is valid Rust code without running it.[^5] | -| edition2021 | Compiles the code using the specified Rust edition's rules. | ok on success. | Use Case: Demonstrating syntax or idioms that are specific to a particular Rust edition (e.g., edition2018, edition2021).[^4] | +| ignore | Skips both compilation and execution. | ignored | Use Case: For pseudocode, examples known to be broken, or to temporarily disable a test. Warning: Provides no guarantee that the code is even syntactically correct. Generally discouraged in favour of more specific attributes.[^3] | +| should_panic | Compiles and runs the code. The test passes if the code panics. | OK on panic, failed if it does not panic. | Use Case: Demonstrating functions that are designed to panic on invalid input (e.g., indexing out of bounds). | +| compile_fail | Attempts to compile the code. The test passes if compilation fails. | OK on compilation failure, failed if it compiles successfully. | Use Case: Illustrating language rules, such as the borrow checker or type system constraints. Warning: Highly brittle. A future Rust version might make the code valid, causing the test to unexpectedly fail.[^4] | +| no_run | Compiles the code but does not execute it. | OK if compilation succeeds. | Use Case: Essential for examples with undesirable side effects in a test environment, such as network requests, file-system I/O, or launching a GUI. Guarantees the example is valid Rust code without running it.[^5] | +| edition2021 | Compiles the code using the specified Rust edition's rules. | OK on success. | Use Case: Demonstrating syntax or idioms that are specific to a particular Rust edition (e.g., edition2018, edition2021).[^4] |
There was a problem hiding this comment.
Actionable comments posted: 14
🔭 Outside diff range comments (5)
docs/wireframe-1-0-detailed-development-roadmap.md (1)
101-103: Use Oxford “-ize” spellingAdhere to the en-GB-oxendict guideline by switching to “prioritized”.
-... will be explicitly prioritised using +... will be explicitly prioritized usingdocs/rust-testing-with-rstest-fixtures.md (3)
107-108: Remove second-person pronoun in install instructionsThe documentation style forbids second-person language. Rephrase the sentence to an impersonal construction.
-Add the following lines to your `Cargo.toml` under the `[dev-dependencies]` section: +Add the following lines to the project’s `Cargo.toml` under the `[dev-dependencies]` section:
134-134: Remove second-person pronoun from headingHeadings must avoid “your”. Shorten accordingly.
-### B. Your First Fixture: Defining with `#[fixture]` +### B. First Fixture: Defining with `#[fixture]`
1028-1028: Eliminate second-person pronoun in example descriptionRewrite the sentence to comply with the style guide.
-Assume you have files in `tests/test_data/` like `file1.txt`, `file2.json` +Assume the directory `tests/test_data/` contains files such as `file1.txt` and `file2.json`docs/rust-binary-router-library-design.md (1)
23-28: Wrap paragraph to ≤ 80 columns.Lines exceed the mandated width, violating
MD013.
Insert hard breaks; keep the back-tick fences intact.
♻️ Duplicate comments (1)
docs/rust-doctest-dry-guide.md (1)
316-318: Replace second-person pronoun “your”.The sentence still breaches the style guide’s ban on second-person wording despite a previous review pointing this out.
- The typical implementation pattern is to create a private helper module within your library: + The typical implementation pattern is to create a private helper module within the library:
docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 6
🔭 Outside diff range comments (1)
docs/rust-binary-router-library-design.md (1)
90-98: Replace bare numerals with GitHub-style footnotesInline citations
.8,.10,.11violate the style-guide rule “Use footnotes referenced with[^label]”. Convert each trailing numeral to a properly-formatted footnote reference and add matching definitions at the bottom of the file.- integrates well with Serde.8 It offers high performance and configurable - options for endianness and integer encoding.10 `bincode` 2.0 makes Serde an - optional dependency and provides its own `Encode`/`Decode` traits that can be - derived.11 + integrates well with Serde.[^serde] It offers high performance and + configurable options for endianness and integer encoding.[^bincode-config] + `bincode` 2.0 makes Serde optional and provides its own `Encode`/`Decode` + derive macros.[^bincode-v2]Add near the existing footnote block:
[^serde]: Serde – <https://serde.rs> [^bincode-config]: Bincode configuration options – <https://docs.rs/bincode/latest/bincode/config/index.html> [^bincode-v2]: Bincode 2.0 release notes – <https://github.com/bincode-org/bincode/releases/tag/v2.0.0>
♻️ Duplicate comments (9)
docs/wireframe-testing-crate.md (2)
68-72: Line wrapping improved but still check against duplicate.The reflowing properly addresses the 80-column requirement, though this appears to address the same concern raised in past reviews about line length violations.
110-112: Path correction and flow improvement completed.The changes successfully remove the erroneous space in the file path and improve sentence structure whilst maintaining the 80-column limit.
docs/mocking-network-outages-in-rust.md (7)
12-17: First-person language eliminated successfully.The changes properly convert first-person narrative to neutral, objective descriptions whilst maintaining the technical accuracy and improving readability.
101-103: Neutral voice successfully implemented.The conversion from first-person language to objective description improves the documentation's professional tone whilst maintaining clarity.
148-152: Impersonal construction properly applied.The elimination of first-person pronouns creates more professional technical documentation whilst preserving the explanation's clarity and accuracy.
237-241: Neutral narrative voice established.The conversion from first-person to objective description successfully eliminates style guide violations whilst maintaining the technical explanation's clarity.
438-440: Objective voice properly maintained.The removal of first-person language creates more professional documentation whilst preserving the technical guidance about error assertion.
499-502: Neutral documentation voice established.The conversion to objective language successfully eliminates first-person references whilst maintaining the technical accuracy about test parameterisation.
559-564: Impersonal construction implemented.The elimination of first-person pronouns creates professional technical documentation whilst preserving the explanation's clarity about test structure.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (7)
docs/hardening-wireframe-a-guide-to-production-resilience.md(3 hunks)docs/mocking-network-outages-in-rust.md(13 hunks)docs/rust-binary-router-library-design.md(45 hunks)docs/rust-doctest-dry-guide.md(8 hunks)docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md(11 hunks)docs/wireframe-1-0-detailed-development-roadmap.md(1 hunks)docs/wireframe-testing-crate.md(4 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.md
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
🧠 Learnings (4)
docs/mocking-network-outages-in-rust.md (8)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/mocking-network-outages-in-rust.md:0-0
Timestamp: 2025-06-30T23:05:35.781Z
Learning: Applies to docs/**/*_test.rs : Parameterize repetitive test scenarios using the `rstest` crate to avoid code duplication and improve test clarity.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use `rstest` for tests with complex setup, parameterization, or where improved readability and DRY principles are desired; use standard `#[test]` for simple, isolated unit tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Use `rstest` for tests requiring complex setup, parameterization, or improved readability, but consider standard `#[test]` for simple, non-parameterized unit tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Prefer `rstest` for tests requiring complex setup, parameterization, or improved readability, and use standard `#[test]` for simple unit tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T03:26:36.990Z
Learning: Applies to **/*_test.rs : Replace duplicated tests with `#[rstest(...)]` parameterised cases.
Learnt from: CR
PR: leynos/wireframe#0
File: AGENTS.md:0-0
Timestamp: 2025-06-30T23:02:18.018Z
Learning: Applies to **/*_test.rs : Replace duplicated tests with `#[rstest(...)]` parameterised cases.
Learnt from: CR
PR: leynos/netsuke#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T02:48:05.151Z
Learning: Applies to **/*{_test,tests}.rs : Replace duplicated tests with #[rstest(...)] parameterised cases.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures and parameterized arguments (#[case], #[values]) can be combined in the same rstest test function, allowing for expressive and flexible test scenarios.
docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md (6)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/wireframe-1-0-detailed-development-roadmap.md:0-0
Timestamp: 2025-06-29T18:04:58.493Z
Learning: The FragmentStrategy trait should define core methods such as decode_header and encode_header, and be extensible to support context-aware fragmentation rules.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Applies to docs/src/**/*.rs : The `FragmentStrategy` trait must provide methods for determining max fragment payload, decoding headers, and encoding headers, supporting multiplexing and concurrent re-assembly.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/wireframe-1-0-detailed-development-roadmap.md:0-0
Timestamp: 2025-06-29T18:04:58.493Z
Learning: Multiplexed re-assembly should be supported by using msg_id from FragmentMeta as a key into a dashmap::DashMap of partial messages, enabling concurrent re-assembly of multiple messages.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/generic-message-fragmentation-and-re-assembly-design.md:0-0
Timestamp: 2025-06-30T23:04:39.802Z
Learning: Applies to docs/**/fragment_adapter.rs : The FragmentAdapter must use a concurrently accessible map (such as dashmap::DashMap) for in-flight message re-assembly to support multiplexing.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Applies to docs/src/**/*.rs : Use a concurrent hash map (e.g., `dashmap::DashMap`) keyed by `msg_id` for re-assembling multiple logical messages concurrently in the `FragmentAdapter`.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/wireframe-1-0-detailed-development-roadmap.md:0-0
Timestamp: 2025-06-29T18:04:58.493Z
Learning: Advanced testing should include concurrency verification using loom for select! loops and PushHandle, and property-based testing with proptest for complex protocol interactions.
docs/rust-doctest-dry-guide.md (2)
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : To conditionally execute doctests based on features, use #[cfg(feature = "...")] inside the code block or cfg_attr to conditionally add the ignore flag to the doctest header.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : Use #[doc(cfg(...))] to visually indicate feature-gated items in generated documentation, requiring #![feature(doc_cfg)] at the crate root.
docs/rust-binary-router-library-design.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Prioritize protocol-agnosticism, developer experience, and Rust's safety and performance guarantees in all design and implementation decisions.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/roadmap.md:0-0
Timestamp: 2025-06-30T23:07:15.902Z
Learning: Applies to docs/src/{app,server}.rs : Build the Actix-inspired API around `WireframeApp` and `WireframeServer` as described, including method signatures (`new`, `route`, `service`, `wrap`), consistent `Result<Self>` error strategy, and ergonomic chaining
🪛 LanguageTool
docs/hardening-wireframe-a-guide-to-production-resilience.md
[uncategorized] ~39-~39: Loose punctuation mark.
Context: ...ible to all clones. - TaskTracker: The server uses a TaskTracker to `s...
(UNLIKELY_OPENING_PUNCTUATION)
docs/wireframe-1-0-detailed-development-roadmap.md
[uncategorized] ~29-~29: Possible missing comma found.
Context: ...for a single, non-multiplexed stream of fragments and the outbound logic for splitting a ...
(AI_HYDRA_LEO_MISSING_COMMA)
docs/mocking-network-outages-in-rust.md
[style] ~15-~15: Would you like to use the Oxford spelling “parameterized”? The spelling ‘parameterised’ is also correct.
Context: ... I/O streams. rstest is leveraged for parameterised tests and mockall is used for mocking...
(OXFORD_SPELLING_Z_NOT_S)
[uncategorized] ~15-~15: Possible missing comma found.
Context: ...rstest is leveraged for parameterised tests and mockall is used for mocking where...
(AI_HYDRA_LEO_MISSING_COMMA)
[locale-violation] ~316-~316: Lower-case ‘Ok’ is American English. For British English use “OK”.
Context: ...n error reply with code=1 and returning Ok(()). Our test_writer expects exactly...
(OK)
[style] ~500-~500: Would you like to use the Oxford spelling “parameterizing”? The spelling ‘parameterising’ is also correct.
Context: ...rstestcrate avoids repetitive code by parameterising the scenarios. The#[rstest]` attribut...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~559-~559: Consider using the typographical ellipsis character here instead.
Context: ... } } ``` In the snippet above, each case(...) macro provides a different `Scenario`...
(ELLIPSIS)
[style] ~562-~562: Would you like to use the Oxford spelling “parametrized”? The spelling ‘parametrised’ is also correct.
Context: ...serts the expected outcome. This single parametrised test replaces multiple individual tests...
(OXFORD_SPELLING_Z_NOT_S)
docs/rust-doctest-dry-guide.md
[uncategorized] ~20-~20: Loose punctuation mark.
Context: ...a developer executes cargo test --doc, rustdoc initiates a multi-stage proce...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~61-~61: Possible missing comma found.
Context: ...te)`). This is not a bug or an oversight but a fundamental aspect of the design, enf...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~80-~80: Please add a punctuation mark at the end of paragraph.
Context: ...private functions must either be marked as ignore, forgoing the test guarantee,...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~82-~82: Loose punctuation mark.
Context: ...tions must either be marked as ignore, forgoing the test guarantee, or be dupl...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~103-~103: This phrase is redundant. Consider using “inside”.
Context: ...): These document the item they are inside of (e.g., a module or the crate itself). T...
(OUTSIDE_OF)
[grammar] ~121-~121: Please add a punctuation mark at the end of paragraph.
Context: ...tem's purpose. For instance, an example for String::clone() should not just show...
(PUNCTUATION_PARAGRAPH_END)
[misspelling] ~140-~140: This word is normally spelled as one.
Context: ...rongly discouraged. It is considered an anti-pattern because users often copy example code v...
(EN_COMPOUNDS_ANTI_PATTERN)
[style] ~207-~207: Consider using the typographical ellipsis character here instead.
Context: ... error-handling examples, the entire fn main() -> Result<...> {... } and Ok(()) scaffolding ca...
(ELLIPSIS)
[locale-violation] ~207-~207: Lower-case ‘Ok’ is American English. For British English use “OK”.
Context: ...e fn main() -> Result<...> {... } and Ok(()) scaffolding can be hidden, pres...
(OK)
[style] ~217-~217: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...s can sometimes be hidden to de-clutter very simple examples. The existence of features...
(EN_WEAK_ADJECTIVE)
[style] ~223-~223: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...ver, the ideal documentation example is often just a small, illustrative snippet that...
(EN_REPEATEDWORDS_OFTEN)
[uncategorized] ~249-~249: Possible missing comma found.
Context: ... execute it. | OK if compilation succeeds. ...
(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~254-~254: Loose punctuation mark.
Context: ...Detailed Attribute Breakdown - ignore: This is the bluntest instrument in the ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~260-~260: Loose punctuation mark.
Context: ...lustrative pseudocode. - should_panic: This attribute inverts the normal test ...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~263-~263: Consider using a more formal/concise alternative here.
Context: ...s successfully or panics for a reason other than the one expected (if a specific panic m...
(OTHER_THAN)
[uncategorized] ~265-~265: Loose punctuation mark.
Context: ...sage is asserted).[^3] - compile_fail: This is a powerful tool for creating ed...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~272-~272: Loose punctuation mark.
Context: ...ch would break the test.[^4] - no_run: This attribute strikes a crucial balanc...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~279-~279: Loose punctuation mark.
Context: ...thout executing it.[^5] - edition20xx: This attribute allows an example to be ...
(UNLIKELY_OPENING_PUNCTUATION)
[formatting] ~305-~305: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ed by #[cfg(test)]. This will not work, because rustdoc does not enable the test co...
(COMMA_BEFORE_BECAUSE)
[grammar] ~424-~424: Please add a punctuation mark at the end of paragraph.
Context: ...mpiler.[^15] The compiler only sees the host cfg (e.g., target_os = "windows"),...
(PUNCTUATION_PARAGRAPH_END)
[locale-violation] ~460-~460: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... runs, does nothing, and is reported as ok. While simple to write, this can be mi...
(OK)
[style] ~491-~491: Consider using the typographical ellipsis character here instead.
Context: ...ocumentation. This is achieved with the #[doc(cfg(...))] attribute, which requires enabling ...
(ELLIPSIS)
[style] ~520-~520: Since ownership is already implied, this phrasing may be redundant.
Context: ...hree distinct types of tests, each with its own purpose: - Doctests: These are ide...
(PRP_OWN)
[style] ~531-~531: Consider using the typographical ellipsis character here instead.
Context: ...odules within the source files (often mod tests {... }) and are compiled only with `#[cfg...
(ELLIPSIS)
[style] ~577-~577: Consider using the typographical ellipsis character here instead.
Context: ...(http://crates.io), where hidden lines (#...) look like ugly, commented-out code....
(ELLIPSIS)
[grammar] ~592-~592: Please add a punctuation mark at the end of paragraph.
Context: ... first write and debug the example as a standard #[test] function in a temporary fi...
(PUNCTUATION_PARAGRAPH_END)
[style] ~617-~617: Consider using the typographical ellipsis character here instead.
Context: ...f fallible functions, always use the fn main() -> Result<...> pattern, hiding the boilerplate. Avoi...
(ELLIPSIS)
[style] ~624-~624: Consider using the typographical ellipsis character here instead.
Context: ...ity* in the final documentation. Use #[cfg(feature = "...")] or other cfg flags inside th...
(ELLIPSIS)
[style] ~632-~632: You have already used ‘right’ in nearby sentences. Consider using an alternative word to let your writing stand out and sound more polished.
Context: ...a square peg into a round hole. Use the right tool for the job. ### Works cited ...
(REP_RIGHT)
[typographical] ~636-~636: To join two clauses or introduce examples, consider using an em dash.
Context: ...he job. ### Works cited [^1]: rust - How can I write documentation tests for ...
(DASH_RULE)
[typographical] ~639-~639: To join two clauses or introduce examples, consider using an em dash.
Context: ...ules> [^2]: Rustdoc doctests need fixing - Swatinem, accessed on July 15, 2025, <ht...
(DASH_RULE)
[typographical] ~641-~641: To join two clauses or introduce examples, consider using an em dash.
Context: .../fix-rustdoc/> [^3]: Documentation tests - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~641-~641: To join two clauses or introduce examples, consider using an em dash.
Context: ...: Documentation tests - The rustdoc boOK - Rust Documentation, accessed on July 15,...
(DASH_RULE)
[typographical] ~647-~647: To join two clauses or introduce examples, consider using an em dash.
Context: ...l> [^6]: How to organize your Rust tests - LogRocket Blog, accessed on July 15, 202...
(DASH_RULE)
[typographical] ~650-~650: To join two clauses or introduce examples, consider using an em dash.
Context: ..._rust/> [^8]: Writing Rust Documentation - DEV Community, accessed on July 15, 2025...
(DASH_RULE)
[typographical] ~654-~654: To join two clauses or introduce examples, consider using an em dash.
Context: ...at-is-rustdoc.html> [^10]: Documentation - Rust API Guidelines, accessed on July 15...
(DASH_RULE)
[typographical] ~656-~656: To join two clauses or introduce examples, consider using an em dash.
Context: ...1]: Best practice for doc testing README - help - The Rust Programming Langu...
(DASH_RULE)
[typographical] ~656-~656: To join two clauses or introduce examples, consider using an em dash.
Context: ...t practice for doc testing README - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...mpile_fail doc test ignored in cfg(test) - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...ail doc test ignored in cfg(test) - help - The Rust Programming Language Forum, acc...
(DASH_RULE)
[typographical] ~664-~664: To join two clauses or introduce examples, consider using an em dash.
Context: ...for-doctests/50426> [^14]: quote_doctest - Rust - Docs.rs, access...
(DASH_RULE)
[typographical] ~664-~664: To join two clauses or introduce examples, consider using an em dash.
Context: ...tests/50426> [^14]: quote_doctest - Rust - Docs.rs, accessed on J...
(DASH_RULE)
[typographical] ~666-~666: To join two clauses or introduce examples, consider using an em dash.
Context: .../quote-doctest> [^15]: Advanced features - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~666-~666: To join two clauses or introduce examples, consider using an em dash.
Context: ...5]: Advanced features - The rustdoc boOK - Rust Documentation, accessed on J...
(DASH_RULE)
[typographical] ~668-~668: To join two clauses or introduce examples, consider using an em dash.
Context: ...tdoc/advanced-features.html> [^16]: rust - How can I conditionally execute a module...
(DASH_RULE)
[uncategorized] ~673-~673: Loose punctuation mark.
Context: ...[^18]: How do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~673-~673: To join two clauses or introduce examples, consider using an em dash.
Context: ...ow do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2025, <http...
(DASH_RULE)
docs/rust-binary-router-library-design.md
[uncategorized] ~75-~75: Loose punctuation mark.
Context: ...h distinct characteristics. - wire-rs: The user query specifically suggests co...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~269-~269: Since ownership is already implied, this phrasing may be redundant.
Context: ...cture. Users should be able to define their own framing logic and message types. - **Pe...
(PRP_OWN)
[uncategorized] ~332-~332: Although a hyphen is possible, it is not necessary in a compound modifier in which the first word is an adverb that ends in ‘ly’.
Context: ... byte payload of incoming frames into strongly-typed Rust data structures (messages) and s...
(HYPHENATED_LY_ADVERB_ADJECTIVE)
[style] ~519-~519: Since ownership is already implied, this phrasing may be redundant.
Context: ...os, "wireframe" might need to provide its own wrapper traits and derive macros that i...
(PRP_OWN)
[uncategorized] ~530-~530: Loose punctuation mark.
Context: ...ation will be considered: - bincode: Offers high performance, configurabilit...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~533-~533: Loose punctuation mark.
Context: ...ose binary serialization. - postcard: Ideal for scenarios where serialized si...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~614-~614: To reduce wordiness, try specifying a number or using “many” or “numerous” instead.
Context: ... high-throughput systems that process a large number of messages per second. - Dynamic Routing...
(LARGE_NUMBER_OF)
[style] ~635-~635: This phrasing can be wordy. Try something more concise.
Context: ...lear, declarative API for this routing, as opposed to manual match statements over message ...
(OPPOSED_TO)
🔇 Additional comments (23)
docs/hardening-wireframe-a-guide-to-production-resilience.md (6)
7-10: Lines wrap and wording comply with style guide
Sentences are under 80 columns, free of disallowed pronouns, and use en-GB-oxendict spelling.
14-17: Clear, rule-compliant prose
Paragraph follows the required wrapping, avoids first-/second-person pronouns, and keeps technical tone intact.
21-23: No issues detected in shutdown intro
Content meets length, spelling, and pronoun constraints.
35-37: Line-length fix addressed correctly
Sentence now hard-wrapped; no MD013 violations remain in this fragment.
46-48: Cancellation-aware loop paragraph looks good
Wording is concise, wrapped, and pronoun-free; nothing further to adjust.
311-312: Consistent -ize spelling retained
“Serialise” uses the required -ize form (“serialize”); line length also within limit.docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md (1)
17-25: Formatting matches guidelines
The wrapped paragraph stays within the 80-column rule, uses Oxford “-ize” spelling, and avoids first/second-person pronouns.docs/wireframe-testing-crate.md (4)
10-12: Formatting meets requirements.The changes successfully standardise hyphenation and improve line flow whilst maintaining the 80-column limit. The technical content remains intact.
74-77: Standardised hyphenation improves consistency.The replacement of non-breaking hyphens with ASCII hyphens prevents rendering and search issues whilst maintaining readability.
81-83: Clean sentence structure enhancement.The rewording improves flow by eliminating unnecessary line breaks between related clauses whilst preserving the technical meaning.
152-152: Term consistency maintained.The replacement of "wireframe_testing" with the properly formatted crate name maintains consistency with the surrounding documentation style.
docs/mocking-network-outages-in-rust.md (11)
47-48: Sentence flow improved.The merger of related clauses creates better paragraph flow whilst preserving the technical explanation of the transaction handling process.
52-54: Technical precision maintained.The adjustments to punctuation and clause structure improve readability without altering the technical meaning of the transaction processing description.
56-56: Grammatical correction applied.The numbering correction from "1." to "2." ensures proper sequential order in the enumerated list.
220-223: Code explanation refined.The adjustments improve sentence structure and maintain technical accuracy whilst enhancing the flow of the explanation about the refactoring approach.
275-279: Technical explanation enhanced.The sentence restructuring improves clarity about the test behaviour and expected outcomes whilst maintaining accuracy about the timeout mechanism.
444-446: Technical explanation streamlined.The sentence restructuring improves flow whilst maintaining the accuracy of the explanation about write failure scenarios.
569-570: Technical explanation refined.The sentence adjustment improves flow whilst maintaining accuracy about the mockall crate's utility in testing scenarios.
576-577: Clarity enhancement applied.The sentence restructuring improves readability whilst preserving the technical guidance about mocking complexity and alternatives.
595-599: Technical precision maintained.The adjustments to sentence structure improve flow whilst preserving the accuracy of the explanation about business logic isolation in testing.
658-659: Documentation consistency improved.The formatting adjustments enhance readability whilst maintaining the technical accuracy of the conclusion about testing behaviour expectations.
316-320: British English spelling inconsistency remains.The text still contains "Ok" instead of the British English "OK" as flagged by static analysis. Apply the correction to maintain consistency with the style guide.
-and returning `Ok(())`. Our `test_writer` expects exactly those 8 bytes. We +and returning `OK(())`. Our `test_writer` expects exactly those 8 bytes. WeLikely an incorrect or invalid review comment.
docs/rust-doctest-dry-guide.md (1)
5-12: Introduction reads cleanly and obeys house style
No second-person pronouns, en-GB spelling is correct, and the heading hierarchy increments by one level.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 7
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (5)
docs/hardening-wireframe-a-guide-to-production-resilience.md(3 hunks)docs/roadmap.md(2 hunks)docs/rust-binary-router-library-design.md(45 hunks)docs/rust-doctest-dry-guide.md(8 hunks)docs/wireframe-1-0-detailed-development-roadmap.md(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.md
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
🧠 Learnings (2)
docs/rust-doctest-dry-guide.md (2)
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : To conditionally execute doctests based on features, use #[cfg(feature = "...")] inside the code block or cfg_attr to conditionally add the ignore flag to the doctest header.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : Use #[doc(cfg(...))] to visually indicate feature-gated items in generated documentation, requiring #![feature(doc_cfg)] at the crate root.
docs/rust-binary-router-library-design.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Prioritize protocol-agnosticism, developer experience, and Rust's safety and performance guarantees in all design and implementation decisions.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/roadmap.md:0-0
Timestamp: 2025-06-30T23:07:15.902Z
Learning: Applies to docs/src/{app,server}.rs : Build the Actix-inspired API around `WireframeApp` and `WireframeServer` as described, including method signatures (`new`, `route`, `service`, `wrap`), consistent `Result<Self>` error strategy, and ergonomic chaining
🪛 LanguageTool
docs/hardening-wireframe-a-guide-to-production-resilience.md
[uncategorized] ~32-~32: Loose punctuation mark.
Context: ... synchronisation. - CancellationToken: A single root token is created at serve...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~38-~38: Loose punctuation mark.
Context: ... visible to all clones. - TaskTracker: The server uses a TaskTracker to `spa...
(UNLIKELY_OPENING_PUNCTUATION)
docs/roadmap.md
[uncategorized] ~12-~12: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...sy to use. - Performance: Maintain high performance and low overhead. - Extensibility:...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~131-~131: Would you like to use the Oxford spelling “initialization”? The spelling ‘initialisation’ is also correct.
Context: ...d on_disconnect hooks for session initialisation and cleanup (src/hooks.rs). - [x] ...
(OXFORD_SPELLING_Z_NOT_S)
[style] ~291-~291: Consider using a more concise synonym.
Context: .... - [x] **Examples:** - [x] Create a variety of examples demonstrating core features (...
(A_VARIETY_OF)
docs/rust-doctest-dry-guide.md
[uncategorized] ~20-~20: Loose punctuation mark.
Context: ...a developer executes cargo test --doc, rustdoc initiates a multi-stage proce...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~61-~61: Possible missing comma found.
Context: ...te)`). This is not a bug or an oversight but a fundamental aspect of the design, enf...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~80-~80: Please add a punctuation mark at the end of paragraph.
Context: ...private functions must either be marked as ignore, forgoing the test guarantee,...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~82-~82: Loose punctuation mark.
Context: ...tions must either be marked as ignore, forgoing the test guarantee, or be dupl...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~103-~103: This phrase is redundant. Consider using “inside”.
Context: ...): These document the item they are inside of (e.g., a module or the crate itself). T...
(OUTSIDE_OF)
[grammar] ~121-~121: Please add a punctuation mark at the end of paragraph.
Context: ...tem's purpose. For instance, an example for String::clone() should not just show...
(PUNCTUATION_PARAGRAPH_END)
[misspelling] ~140-~140: This word is normally spelled as one.
Context: ...rongly discouraged. It is considered an anti-pattern because users often copy example code v...
(EN_COMPOUNDS_ANTI_PATTERN)
[style] ~207-~207: Consider using the typographical ellipsis character here instead.
Context: ... error-handling examples, the entire fn main() -> Result<...> {... } and Ok(()) scaffolding ca...
(ELLIPSIS)
[locale-violation] ~207-~207: Lower-case ‘Ok’ is American English. For British English use “OK”.
Context: ...e fn main() -> Result<...> {... } and Ok(()) scaffolding can be hidden, pres...
(OK)
[style] ~223-~223: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...ver, the ideal documentation example is often just a small, illustrative snippet that...
(EN_REPEATEDWORDS_OFTEN)
[uncategorized] ~249-~249: Possible missing comma found.
Context: ... execute it. | OK if compilation succeeds. ...
(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~254-~254: Loose punctuation mark.
Context: ...Detailed Attribute Breakdown - ignore: This is the bluntest instrument in the ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~260-~260: Loose punctuation mark.
Context: ...lustrative pseudocode. - should_panic: This attribute inverts the normal test ...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~263-~263: Consider using a more formal/concise alternative here.
Context: ...s successfully or panics for a reason other than the one expected (if a specific panic m...
(OTHER_THAN)
[uncategorized] ~265-~265: Loose punctuation mark.
Context: ...sage is asserted).[^3] - compile_fail: This is a powerful tool for creating ed...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~272-~272: Loose punctuation mark.
Context: ...ch would break the test.[^4] - no_run: This attribute strikes a crucial balanc...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~279-~279: Loose punctuation mark.
Context: ...thout executing it.[^5] - edition20xx: This attribute allows an example to be ...
(UNLIKELY_OPENING_PUNCTUATION)
[formatting] ~305-~305: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ed by #[cfg(test)]. This will not work, because rustdoc does not enable the test co...
(COMMA_BEFORE_BECAUSE)
[grammar] ~424-~424: Please add a punctuation mark at the end of paragraph.
Context: ...mpiler.[^15] The compiler only sees the host cfg (e.g., target_os = "windows"),...
(PUNCTUATION_PARAGRAPH_END)
[locale-violation] ~460-~460: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... runs, does nothing, and is reported as ok. While simple to write, this can be mi...
(OK)
[style] ~491-~491: Consider using the typographical ellipsis character here instead.
Context: ...ocumentation. This is achieved with the #[doc(cfg(...))] attribute, which requires enabling ...
(ELLIPSIS)
[style] ~520-~520: Since ownership is already implied, this phrasing may be redundant.
Context: ...hree distinct types of tests, each with its own purpose: - Doctests: These are ide...
(PRP_OWN)
[style] ~531-~531: Consider using the typographical ellipsis character here instead.
Context: ...odules within the source files (often mod tests {... }) and are compiled only with `#[cfg...
(ELLIPSIS)
[style] ~577-~577: Consider using the typographical ellipsis character here instead.
Context: ...(http://crates.io), where hidden lines (#...) look like ugly, commented-out code....
(ELLIPSIS)
[grammar] ~592-~592: Please add a punctuation mark at the end of paragraph.
Context: ... first write and debug the example as a standard #[test] function in a temporary fi...
(PUNCTUATION_PARAGRAPH_END)
[style] ~617-~617: Consider using the typographical ellipsis character here instead.
Context: ...f fallible functions, always use the fn main() -> Result<...> pattern, hiding the boilerplate. Avoi...
(ELLIPSIS)
[style] ~624-~624: Consider using the typographical ellipsis character here instead.
Context: ...ity* in the final documentation. Use #[cfg(feature = "...")] or other cfg flags inside th...
(ELLIPSIS)
[style] ~632-~632: You have already used ‘right’ in nearby sentences. Consider using an alternative word to let your writing stand out and sound more polished.
Context: ...a square peg into a round hole. Use the right tool for the job. ### Works cited ...
(REP_RIGHT)
[typographical] ~636-~636: To join two clauses or introduce examples, consider using an em dash.
Context: ...he job. ### Works cited [^1]: rust - How can I write documentation tests for ...
(DASH_RULE)
[typographical] ~639-~639: To join two clauses or introduce examples, consider using an em dash.
Context: ...ules> [^2]: Rustdoc doctests need fixing - Swatinem, accessed on July 15, 2025, <ht...
(DASH_RULE)
[typographical] ~641-~641: To join two clauses or introduce examples, consider using an em dash.
Context: .../fix-rustdoc/> [^3]: Documentation tests - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~641-~641: To join two clauses or introduce examples, consider using an em dash.
Context: ...: Documentation tests - The rustdoc boOK - Rust Documentation, accessed on July 15,...
(DASH_RULE)
[typographical] ~647-~647: To join two clauses or introduce examples, consider using an em dash.
Context: ...l> [^6]: How to organize your Rust tests - LogRocket Blog, accessed on July 15, 202...
(DASH_RULE)
[typographical] ~650-~650: To join two clauses or introduce examples, consider using an em dash.
Context: ..._rust/> [^8]: Writing Rust Documentation - DEV Community, accessed on July 15, 2025...
(DASH_RULE)
[typographical] ~654-~654: To join two clauses or introduce examples, consider using an em dash.
Context: ...at-is-rustdoc.html> [^10]: Documentation - Rust API Guidelines, accessed on July 15...
(DASH_RULE)
[typographical] ~656-~656: To join two clauses or introduce examples, consider using an em dash.
Context: ...1]: Best practice for doc testing README - help - The Rust Programming Langu...
(DASH_RULE)
[typographical] ~656-~656: To join two clauses or introduce examples, consider using an em dash.
Context: ...t practice for doc testing README - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...mpile_fail doc test ignored in cfg(test) - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...ail doc test ignored in cfg(test) - help - The Rust Programming Language Forum, acc...
(DASH_RULE)
[typographical] ~664-~664: To join two clauses or introduce examples, consider using an em dash.
Context: ...for-doctests/50426> [^14]: quote_doctest - Rust - Docs.rs, access...
(DASH_RULE)
[typographical] ~664-~664: To join two clauses or introduce examples, consider using an em dash.
Context: ...tests/50426> [^14]: quote_doctest - Rust - Docs.rs, accessed on J...
(DASH_RULE)
[typographical] ~666-~666: To join two clauses or introduce examples, consider using an em dash.
Context: .../quote-doctest> [^15]: Advanced features - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~666-~666: To join two clauses or introduce examples, consider using an em dash.
Context: ...5]: Advanced features - The rustdoc boOK - Rust Documentation, accessed on J...
(DASH_RULE)
[typographical] ~668-~668: To join two clauses or introduce examples, consider using an em dash.
Context: ...tdoc/advanced-features.html> [^16]: rust - How can I conditionally execute a module...
(DASH_RULE)
[uncategorized] ~673-~673: Loose punctuation mark.
Context: ...[^18]: How do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~673-~673: To join two clauses or introduce examples, consider using an em dash.
Context: ...ow do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2025, <http...
(DASH_RULE)
docs/rust-binary-router-library-design.md
[uncategorized] ~75-~75: Loose punctuation mark.
Context: ...h distinct characteristics. - wire-rs: The user query specifically suggests co...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~269-~269: Since ownership is already implied, this phrasing may be redundant.
Context: ...cture. Users should be able to define their own framing logic and message types. - **Pe...
(PRP_OWN)
[style] ~519-~519: Since ownership is already implied, this phrasing may be redundant.
Context: ...os, "wireframe" might need to provide its own wrapper traits and derive macros that i...
(PRP_OWN)
[uncategorized] ~530-~530: Loose punctuation mark.
Context: ...ation will be considered: - bincode: Offers high performance, configurabilit...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~533-~533: Loose punctuation mark.
Context: ...ose binary serialization. - postcard: Ideal for scenarios where serialized si...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~614-~614: To reduce wordiness, try specifying a number or using “many” or “numerous” instead.
Context: ... high-throughput systems that process a large number of messages per second. - Dynamic Routing...
(LARGE_NUMBER_OF)
[style] ~635-~635: This phrasing can be wordy. Try something more concise.
Context: ...lear, declarative API for this routing, as opposed to manual match statements over message ...
(OPPOSED_TO)
🔇 Additional comments (3)
docs/roadmap.md (1)
10-16: Hyphenate the compound adjectives.Join the pre-modifying adjective strings with hyphens for clarity and to satisfy the compound-adjective guideline.
- - **Performance:** Maintain high performance and low overhead. + - **Performance:** Maintain high-performance and low-overhead.Likely an incorrect or invalid review comment.
docs/wireframe-1-0-detailed-development-roadmap.md (1)
19-22: Formatting looks sound.The focus block is re-wrapped neatly, respects the 80-column limit, and adheres to the style rules. No action required.
docs/rust-doctest-dry-guide.md (1)
211-214: Switch to en-GB spellingChange American “initializing” to British “initialising”.
- initializing a server—this logic can be hidden to keep the example focused + initialising a server—this logic can be hidden to keep the example focusedLikely an incorrect or invalid review comment.
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 4
♻️ Duplicate comments (1)
docs/rust-doctest-dry-guide.md (1)
246-251: Align table attribute with narrativeThe table lists
edition2021, yet §3.2 and preceding reviews use the genericedition20xx. Harmonise the naming to avoid reader confusion.-| edition2021 | Compiles the code using the specified Rust edition's rules. | OK on success. | Use Case: Demonstrating syntax or idioms that are specific to a particular Rust edition (e.g., edition2018, edition2021).[^4] | +| edition20xx | Compiles the code using the specified Rust edition's rules. | OK on success. | Use Case: Demonstrating syntax or idioms that are specific to a particular Rust edition (e.g., edition2018, edition2021).[^4] |
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (2)
docs/roadmap.md(2 hunks)docs/rust-doctest-dry-guide.md(8 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.md
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
🧠 Learnings (1)
docs/rust-doctest-dry-guide.md (2)
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : To conditionally execute doctests based on features, use #[cfg(feature = "...")] inside the code block or cfg_attr to conditionally add the ignore flag to the doctest header.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : Use #[doc(cfg(...))] to visually indicate feature-gated items in generated documentation, requiring #![feature(doc_cfg)] at the crate root.
🪛 LanguageTool
docs/roadmap.md
[uncategorized] ~12-~12: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...sy to use. - Performance: Maintain high performance and low overhead. - Extensibility:...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[style] ~291-~291: Consider using a more concise synonym.
Context: .... - [x] **Examples:** - [x] Create a variety of examples demonstrating core features (...
(A_VARIETY_OF)
docs/rust-doctest-dry-guide.md
[uncategorized] ~20-~20: Loose punctuation mark.
Context: ...a developer executes cargo test --doc, rustdoc initiates a multi-stage proce...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~61-~61: Possible missing comma found.
Context: ...te)`). This is not a bug or an oversight but a fundamental aspect of the design, enf...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~80-~80: Please add a punctuation mark at the end of paragraph.
Context: ...private functions must either be marked as ignore, forgoing the test guarantee,...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~82-~82: Loose punctuation mark.
Context: ...tions must either be marked as ignore, forgoing the test guarantee, or be dupl...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~98-~98: Would you like to use the Oxford spelling “recognizes”? The spelling ‘recognises’ is also correct.
Context: ...ide within documentation comments. Rust recognises two types: - **Outer doc comments (`//...
(OXFORD_SPELLING_Z_NOT_S)
[grammar] ~121-~121: Please add a punctuation mark at the end of paragraph.
Context: ...tem's purpose. For instance, an example for String::clone() should not just show...
(PUNCTUATION_PARAGRAPH_END)
[misspelling] ~140-~140: This word is normally spelled as one.
Context: ...rongly discouraged. It is considered an anti-pattern because users often copy example code v...
(EN_COMPOUNDS_ANTI_PATTERN)
[uncategorized] ~192-~192: Do not mix variants of the same word (‘recognize’ and ‘recognise’) within a single text.
Context: ...echanism is purely textual and will not recognize ( () ).[^3] ### 2.4 The Power of Hid...
(EN_WORD_COHERENCY)
[style] ~207-~207: Consider using the typographical ellipsis character here instead.
Context: ... error-handling examples, the entire fn main() -> Result<...> {... } and Ok(()) scaffolding ca...
(ELLIPSIS)
[locale-violation] ~207-~207: Lower-case ‘Ok’ is American English. For British English use “OK”.
Context: ...e fn main() -> Result<...> {... } and Ok(()) scaffolding can be hidden, pres...
(OK)
[style] ~223-~223: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...ver, the ideal documentation example is often just a small, illustrative snippet that...
(EN_REPEATEDWORDS_OFTEN)
[uncategorized] ~249-~249: Possible missing comma found.
Context: ... execute it. | OK if compilation succeeds. ...
(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~254-~254: Loose punctuation mark.
Context: ...Detailed Attribute Breakdown - ignore: This is the bluntest instrument in the ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~260-~260: Loose punctuation mark.
Context: ...lustrative pseudocode. - should_panic: This attribute inverts the normal test ...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~263-~263: Consider using a more formal/concise alternative here.
Context: ...s successfully or panics for a reason other than the one expected (if a specific panic m...
(OTHER_THAN)
[uncategorized] ~265-~265: Loose punctuation mark.
Context: ...sage is asserted).[^3] - compile_fail: This is a powerful tool for creating ed...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~272-~272: Loose punctuation mark.
Context: ...ch would break the test.[^4] - no_run: This attribute strikes a crucial balanc...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~279-~279: Loose punctuation mark.
Context: ...thout executing it.[^5] - edition20xx: This attribute allows an example to be ...
(UNLIKELY_OPENING_PUNCTUATION)
[formatting] ~305-~305: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ed by #[cfg(test)]. This will not work, because rustdoc does not enable the test co...
(COMMA_BEFORE_BECAUSE)
[grammar] ~424-~424: Please add a punctuation mark at the end of paragraph.
Context: ...mpiler.[^13] The compiler only sees the host cfg (e.g., target_os = "windows"),...
(PUNCTUATION_PARAGRAPH_END)
[locale-violation] ~460-~460: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... runs, does nothing, and is reported as ok. While simple to write, this can be mi...
(OK)
[style] ~491-~491: Consider using the typographical ellipsis character here instead.
Context: ...ocumentation. This is achieved with the #[doc(cfg(...))] attribute, which requires enabling ...
(ELLIPSIS)
[style] ~520-~520: Since ownership is already implied, this phrasing may be redundant.
Context: ...hree distinct types of tests, each with its own purpose: - Doctests: These are ide...
(PRP_OWN)
[style] ~531-~531: Consider using the typographical ellipsis character here instead.
Context: ...odules within the source files (often mod tests {... }) and are compiled only with `#[cfg...
(ELLIPSIS)
[style] ~577-~577: Consider using the typographical ellipsis character here instead.
Context: ...(http://crates.io), where hidden lines (#...) look like ugly, commented-out code....
(ELLIPSIS)
[grammar] ~592-~592: Please add a punctuation mark at the end of paragraph.
Context: ... first write and debug the example as a standard #[test] function in a temporary fi...
(PUNCTUATION_PARAGRAPH_END)
[style] ~617-~617: Consider using the typographical ellipsis character here instead.
Context: ...f fallible functions, always use the fn main() -> Result<...> pattern, hiding the boilerplate. Avoi...
(ELLIPSIS)
[style] ~624-~624: Consider using the typographical ellipsis character here instead.
Context: ...ity* in the final documentation. Use #[cfg(feature = "...")] or other cfg flags inside th...
(ELLIPSIS)
[style] ~632-~632: You have already used ‘right’ in nearby sentences. Consider using an alternative word to let your writing stand out and sound more polished.
Context: ...a square peg into a round hole. Use the right tool for the job. ### Works cited ...
(REP_RIGHT)
[typographical] ~636-~636: To join two clauses or introduce examples, consider using an em dash.
Context: ...he job. ### Works cited [^1]: rust - How can I write documentation tests for ...
(DASH_RULE)
[typographical] ~639-~639: To join two clauses or introduce examples, consider using an em dash.
Context: ...ules> [^2]: Rustdoc doctests need fixing - Swatinem, accessed on July 15, 2025, <ht...
(DASH_RULE)
[typographical] ~641-~641: To join two clauses or introduce examples, consider using an em dash.
Context: .../fix-rustdoc/> [^3]: Documentation tests - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~641-~641: To join two clauses or introduce examples, consider using an em dash.
Context: ...: Documentation tests - The rustdoc boOK - Rust Documentation, accessed on July 15,...
(DASH_RULE)
[typographical] ~647-~647: To join two clauses or introduce examples, consider using an em dash.
Context: ...l> [^6]: How to organize your Rust tests - LogRocket Blog, accessed on July 15, 202...
(DASH_RULE)
[typographical] ~650-~650: To join two clauses or introduce examples, consider using an em dash.
Context: ..._rust/> [^7]: Writing Rust Documentation - DEV Community, accessed on July 15, 2025...
(DASH_RULE)
[typographical] ~654-~654: To join two clauses or introduce examples, consider using an em dash.
Context: ...hat-is-rustdoc.html> [^9]: Documentation - Rust API Guidelines, accessed on July 15...
(DASH_RULE)
[typographical] ~656-~656: To join two clauses or introduce examples, consider using an em dash.
Context: ...0]: Best practice for doc testing README - help - The Rust Programming Langu...
(DASH_RULE)
[typographical] ~656-~656: To join two clauses or introduce examples, consider using an em dash.
Context: ...t practice for doc testing README - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...mpile_fail doc test ignored in cfg(test) - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...ail doc test ignored in cfg(test) - help - The Rust Programming Language Forum, acc...
(DASH_RULE)
[typographical] ~664-~664: To join two clauses or introduce examples, consider using an em dash.
Context: ...for-doctests/50426> [^12]: quote_doctest - Rust - Docs.rs, access...
(DASH_RULE)
[typographical] ~664-~664: To join two clauses or introduce examples, consider using an em dash.
Context: ...tests/50426> [^12]: quote_doctest - Rust - Docs.rs, accessed on J...
(DASH_RULE)
[typographical] ~666-~666: To join two clauses or introduce examples, consider using an em dash.
Context: .../quote-doctest> [^13]: Advanced features - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~666-~666: To join two clauses or introduce examples, consider using an em dash.
Context: ...3]: Advanced features - The rustdoc boOK - Rust Documentation, accessed on J...
(DASH_RULE)
[typographical] ~668-~668: To join two clauses or introduce examples, consider using an em dash.
Context: ...tdoc/advanced-features.html> [^14]: rust - How can I conditionally execute a module...
(DASH_RULE)
[uncategorized] ~673-~673: Loose punctuation mark.
Context: ...[^15]: How do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~673-~673: To join two clauses or introduce examples, consider using an em dash.
Context: ...ow do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2025, <http...
(DASH_RULE)
🔇 Additional comments (2)
docs/roadmap.md (2)
147-149: ✅ Line-length issue resolvedThe long list item is now wrapped below 80 columns, meeting the Markdown style requirement.
10-12: Hyphenate compound adjectives for precisionHyphenate the compound adjectives that precede nouns to align with en-GB style guidance.
- - **Ergonomics:** The library should be intuitive and easy to use. - - **Performance:** Maintain high performance and low overhead. + - **Ergonomics:** The library should be intuitive and easy-to-use. + - **Performance:** Maintain high-performance and low-overhead.Likely an incorrect or invalid review comment.
| - [x] Create a variety of examples demonstrating core features (`ping_pong`, | ||
| `echo`, `metadata_routing`, `async_stream`). |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Remove verbosity in checklist item
Replace the vague phrase “a variety of” with a concise quantifier.
- - [x] Create a variety of examples demonstrating core features (`ping_pong`,
+ - [x] Create multiple examples demonstrating core features (`ping_pong`,📝 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.
| - [x] Create a variety of examples demonstrating core features (`ping_pong`, | |
| `echo`, `metadata_routing`, `async_stream`). | |
| - [x] Create multiple examples demonstrating core features (`ping_pong`, | |
| `echo`, `metadata_routing`, `async_stream`). |
🧰 Tools
🪛 LanguageTool
[style] ~291-~291: Consider using a more concise synonym.
Context: .... - [x] **Examples:** - [x] Create a variety of examples demonstrating core features (...
(A_VARIETY_OF)
🤖 Prompt for AI Agents
In docs/roadmap.md around lines 291 to 292, the checklist item uses the vague
phrase "a variety of" which is verbose. Replace "a variety of" with a concise
quantifier such as "several" or a specific number to make the item clearer and
more direct.
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (2)
docs/rust-testing-with-rstest-fixtures.md (2)
134-136: Remove second-person pronoun in heading
“Your First Fixture”breaches the no-second-person rule. Rephrase the heading, e.g.“First Fixture: Defining with #[fixture]”.
1044-1049: Remove second-person pronounThe phrase “Assume you have files…” violates the pronoun guideline. Replace with an impersonal construction such as “Assume files exist in
tests/test_data/likefile1.txt”.
♻️ Duplicate comments (2)
docs/rust-doctest-dry-guide.md (2)
98-98: Standardise oxendict ‑ize spellingReplace “recognises” with “recognizes” to align with en-GB-oxendict conventions.
-Doctests reside within documentation comments. Rust recognises two types: +Doctests reside within documentation comments. Rust recognizes two types:
246-246: Align attribute name with narrativeRename the table entry from the concrete
edition2021to the genericedition20xxso it matches §3.2 and avoids confusion.-| edition2021 | Compiles the code using the specified Rust edition's rules. | OK on success. | Use Case: Demonstrating syntax or idioms that are specific to a particular Rust edition (e.g., edition2018, edition2021).[^4] | +| edition20xx | Compiles the code using the specified Rust edition's rules. | OK on success. | Use Case: Demonstrating syntax or idioms that are specific to a particular Rust edition (e.g., edition2018, edition2021).[^4] |
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
docs/rust-doctest-dry-guide.md(7 hunks)docs/rust-testing-with-rstest-fixtures.md(32 hunks)docs/wireframe-client-design.md(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.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/wireframe-client-design.mddocs/rust-testing-with-rstest-fixtures.mddocs/rust-doctest-dry-guide.md
🧠 Learnings (2)
docs/rust-testing-with-rstest-fixtures.md (1)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Be aware that rstest test cases generated by #[case], #[values], or #[files] are discovered at compile time and cannot be dynamically generated at runtime.
docs/rust-doctest-dry-guide.md (2)
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : To conditionally execute doctests based on features, use #[cfg(feature = "...")] inside the code block or cfg_attr to conditionally add the ignore flag to the doctest header.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : Use #[doc(cfg(...))] to visually indicate feature-gated items in generated documentation, requiring #![feature(doc_cfg)] at the crate root.
🪛 LanguageTool
docs/rust-testing-with-rstest-fixtures.md
[grammar] ~580-~580: Please add a punctuation mark at the end of paragraph.
Context: ...useful when destructuring the result of a ```fixture. use rstest::*; #[fixture]...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~607-~607: Use ‘wants’ only when referring to the third person singular such as “he wants”.
Context: ...the test only cares about some parts or wants to use more idiomatic names for destruc...
(CONFUSION_BETWEEN_NNS_OR_WANTS_TO)
[grammar] ~708-~708: Please add a punctuation mark at the end of paragraph.
Context: ... messages. ## VI. Asynchronous Testing with rstest rstest provides robust supp...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~1031-~1031: The preposition ‘as’ seems more likely in this position.
Context: ...` attribute. This attribute can be used on a test function argument to inject file...
(AI_HYDRA_LEO_REPLACE_ON_AS)
docs/rust-doctest-dry-guide.md
[uncategorized] ~20-~20: Loose punctuation mark.
Context: ...a developer executes cargo test --doc, rustdoc initiates a multi-stage proce...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~61-~61: Possible missing comma found.
Context: ...te)`). This is not a bug or an oversight but a fundamental aspect of the design, enf...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~80-~80: Please add a punctuation mark at the end of paragraph.
Context: ...private functions must either be marked as ignore, forgoing the test guarantee,...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~82-~82: Loose punctuation mark.
Context: ...tions must either be marked as ignore, forgoing the test guarantee, or be dupl...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~98-~98: Would you like to use the Oxford spelling “recognizes”? The spelling ‘recognises’ is also correct.
Context: ...ide within documentation comments. Rust recognises two types: - **Outer doc comments (`//...
(OXFORD_SPELLING_Z_NOT_S)
[grammar] ~121-~121: Please add a punctuation mark at the end of paragraph.
Context: ...tem's purpose. For instance, an example for String::clone() should not just show...
(PUNCTUATION_PARAGRAPH_END)
[misspelling] ~140-~140: This word is normally spelled as one.
Context: ...rongly discouraged. It is considered an anti-pattern because users often copy example code v...
(EN_COMPOUNDS_ANTI_PATTERN)
[uncategorized] ~188-~188: Do not mix variants of the same word (‘recognize’ and ‘recognise’) within a single text.
Context: ...echanism is purely textual and will not recognize ( () ).[^3] ### 2.4 The Power of Hid...
(EN_WORD_COHERENCY)
[style] ~203-~203: Consider using the typographical ellipsis character here instead.
Context: ... error-handling examples, the entire fn main() -> Result<...> {... } and Ok(()) scaffolding ca...
(ELLIPSIS)
[locale-violation] ~203-~203: Lower-case ‘Ok’ is American English. For British English use “OK”.
Context: ...e fn main() -> Result<...> {... } and Ok(()) scaffolding can be hidden, pres...
(OK)
[style] ~219-~219: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...ver, the ideal documentation example is often just a small, illustrative snippet that...
(EN_REPEATEDWORDS_OFTEN)
[uncategorized] ~245-~245: Possible missing comma found.
Context: ... execute it. | OK if compilation succeeds. ...
(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~250-~250: Loose punctuation mark.
Context: ...Detailed Attribute Breakdown - ignore: This is the bluntest instrument in the ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~256-~256: Loose punctuation mark.
Context: ...lustrative pseudocode. - should_panic: This attribute inverts the normal test ...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~259-~259: Consider using a more formal/concise alternative here.
Context: ...s successfully or panics for a reason other than the one expected (if a specific panic m...
(OTHER_THAN)
[uncategorized] ~261-~261: Loose punctuation mark.
Context: ...sage is asserted).[^3] - compile_fail: This is a powerful tool for creating ed...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~268-~268: Loose punctuation mark.
Context: ...ch would break the test.[^4] - no_run: This attribute strikes a crucial balanc...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~275-~275: Loose punctuation mark.
Context: ...thout executing it.[^5] - edition20xx: This attribute allows an example to be ...
(UNLIKELY_OPENING_PUNCTUATION)
[formatting] ~301-~301: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ed by #[cfg(test)]. This will not work, because rustdoc does not enable the test co...
(COMMA_BEFORE_BECAUSE)
[grammar] ~416-~416: Please add a punctuation mark at the end of paragraph.
Context: ...mpiler.[^13] The compiler only sees the host cfg (e.g., target_os = "windows"),...
(PUNCTUATION_PARAGRAPH_END)
[locale-violation] ~450-~450: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... runs, does nothing, and is reported as ok. While simple to write, this can be mi...
(OK)
[style] ~479-~479: Consider using the typographical ellipsis character here instead.
Context: ...ocumentation. This is achieved with the #[doc(cfg(...))] attribute, which requires enabling ...
(ELLIPSIS)
[style] ~506-~506: Since ownership is already implied, this phrasing may be redundant.
Context: ...hree distinct types of tests, each with its own purpose: - Doctests: These are ide...
(PRP_OWN)
[style] ~517-~517: Consider using the typographical ellipsis character here instead.
Context: ...odules within the source files (often mod tests {... }) and are compiled only with `#[cfg...
(ELLIPSIS)
[style] ~563-~563: Consider using the typographical ellipsis character here instead.
Context: ...(http://crates.io), where hidden lines (#...) look like ugly, commented-out code....
(ELLIPSIS)
[grammar] ~578-~578: Please add a punctuation mark at the end of paragraph.
Context: ... first write and debug the example as a standard #[test] function in a temporary fi...
(PUNCTUATION_PARAGRAPH_END)
[style] ~603-~603: Consider using the typographical ellipsis character here instead.
Context: ...f fallible functions, always use the fn main() -> Result<...> pattern, hiding the boilerplate. Avoi...
(ELLIPSIS)
[style] ~610-~610: Consider using the typographical ellipsis character here instead.
Context: ...ity* in the final documentation. Use #[cfg(feature = "...")] or other cfg flags inside th...
(ELLIPSIS)
[style] ~618-~618: You have already used ‘right’ in nearby sentences. Consider using an alternative word to let your writing stand out and sound more polished.
Context: ...a square peg into a round hole. Use the right tool for the job. ### Works cited ...
(REP_RIGHT)
[typographical] ~622-~622: To join two clauses or introduce examples, consider using an em dash.
Context: ...he job. ### Works cited [^1]: rust - How can I write documentation tests for ...
(DASH_RULE)
[typographical] ~625-~625: To join two clauses or introduce examples, consider using an em dash.
Context: ...ules> [^2]: Rustdoc doctests need fixing - Swatinem, accessed on July 15, 2025, <ht...
(DASH_RULE)
[typographical] ~627-~627: To join two clauses or introduce examples, consider using an em dash.
Context: .../fix-rustdoc/> [^3]: Documentation tests - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~627-~627: To join two clauses or introduce examples, consider using an em dash.
Context: ...: Documentation tests - The rustdoc boOK - Rust Documentation, accessed on July 15,...
(DASH_RULE)
[typographical] ~633-~633: To join two clauses or introduce examples, consider using an em dash.
Context: ...l> [^6]: How to organize your Rust tests - LogRocket Blog, accessed on July 15, 202...
(DASH_RULE)
[typographical] ~636-~636: To join two clauses or introduce examples, consider using an em dash.
Context: ..._rust/> [^7]: Writing Rust Documentation - DEV Community, accessed on July 15, 2025...
(DASH_RULE)
[typographical] ~640-~640: To join two clauses or introduce examples, consider using an em dash.
Context: ...hat-is-rustdoc.html> [^9]: Documentation - Rust API Guidelines, accessed on July 15...
(DASH_RULE)
[typographical] ~642-~642: To join two clauses or introduce examples, consider using an em dash.
Context: ...0]: Best practice for doc testing README - help - The Rust Programming Langu...
(DASH_RULE)
[typographical] ~642-~642: To join two clauses or introduce examples, consider using an em dash.
Context: ...t practice for doc testing README - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~645-~645: To join two clauses or introduce examples, consider using an em dash.
Context: ...mpile_fail doc test ignored in cfg(test) - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~645-~645: To join two clauses or introduce examples, consider using an em dash.
Context: ...ail doc test ignored in cfg(test) - help - The Rust Programming Language Forum, acc...
(DASH_RULE)
[typographical] ~650-~650: To join two clauses or introduce examples, consider using an em dash.
Context: ...for-doctests/50426> [^12]: quote_doctest - Rust - Docs.rs, access...
(DASH_RULE)
[typographical] ~650-~650: To join two clauses or introduce examples, consider using an em dash.
Context: ...tests/50426> [^12]: quote_doctest - Rust - Docs.rs, accessed on J...
(DASH_RULE)
[typographical] ~652-~652: To join two clauses or introduce examples, consider using an em dash.
Context: .../quote-doctest> [^13]: Advanced features - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~652-~652: To join two clauses or introduce examples, consider using an em dash.
Context: ...3]: Advanced features - The rustdoc boOK - Rust Documentation, accessed on J...
(DASH_RULE)
[typographical] ~654-~654: To join two clauses or introduce examples, consider using an em dash.
Context: ...tdoc/advanced-features.html> [^14]: rust - How can I conditionally execute a module...
(DASH_RULE)
[uncategorized] ~659-~659: Loose punctuation mark.
Context: ...[^15]: How do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...ow do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2025, <http...
(DASH_RULE)
🔇 Additional comments (3)
docs/rust-testing-with-rstest-fixtures.md (3)
604-608: Replace “wants” with a neutral verbThe clause “or wants to use more idiomatic names” mixes number and style. Rewrite as “or prefers idiomatic names”.
⛔ Skipped due to learnings
Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T00:05:37.557Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or improving argument clarity.Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T00:05:36.857Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is especially useful when destructuring or for clarity.Learnt from: CR PR: leynos/mxd#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T23:40:48.640Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/mdtablefix#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-24T23:09:41.600Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/mxd#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T23:40:09.111Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/lille#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-24T18:32:30.955Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-07-20T17:11:39.979Z Learning: Applies to docs/**/*.{rs} : Use the `#[from(original_fixture_name)]` attribute to rename injected fixtures in test or fixture function arguments for clarity or destructuring.
706-712: Add missing punctuation at paragraph endInsert a full stop after “provides robust support” to close the paragraph properly.
⛔ Skipped due to learnings
Learnt from: CR PR: leynos/mdtablefix#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-24T23:09:41.600Z Learning: rstest supports asynchronous fixtures and tests by allowing async fn for both, and integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.Learnt from: CR PR: leynos/mxd#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T23:40:48.640Z Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the appropriate runtime's #[test] attribute.Learnt from: CR PR: leynos/lille#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-24T18:32:30.955Z Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.Learnt from: CR PR: leynos/mxd#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T23:40:09.111Z Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by using the appropriate test attribute (e.g., #[tokio::test]) alongside #[rstest].Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T00:05:36.857Z Learning: Asynchronous fixtures and tests are supported by defining async fn fixtures and test functions. rstest integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's test attribute.Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T00:05:37.557Z Learning: rstest supports asynchronous testing by allowing async fn fixtures and async test functions, integrating with async runtimes like async-std or tokio via their respective #[async_std::test] or #[tokio::test] attributes.
576-583: Terminate paragraph with a full stopAdd a period after “allows renaming” to satisfy grammar tooling and complete the sentence.
⛔ Skipped due to learnings
Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T00:05:37.557Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or improving argument clarity.Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T00:05:36.857Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is especially useful when destructuring or for clarity.Learnt from: CR PR: leynos/mdtablefix#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-24T23:09:41.600Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/mxd#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T23:40:48.640Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/lille#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-24T18:32:30.955Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/mxd#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-06-25T23:40:09.111Z Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.Learnt from: CR PR: leynos/femtologging#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-07-20T17:11:39.979Z Learning: Applies to docs/**/*.{rs} : Use the `#[from(original_fixture_name)]` attribute to rename injected fixtures in test or fixture function arguments for clarity or destructuring.Learnt from: CR PR: leynos/lille#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-07-20T12:06:42.577Z Learning: Applies to docs/**/*.rs : Use the `#[from(original_fixture_name)]` attribute to rename injected fixture arguments in test functions or other fixtures.Learnt from: CR PR: leynos/ddlint#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-07-18T18:40:11.379Z Learning: Applies to docs/**/*.rs : Use the `#[from(original_fixture_name)]` attribute to rename injected fixture arguments in test functions.Learnt from: CR PR: leynos/netsuke#0 File: docs/rust-testing-with-rstest-fixtures.md:0-0 Timestamp: 2025-07-18T19:05:14.471Z Learning: Applies to docs/**/*.rs : Use the `#[from(original_fixture_name)]` attribute to rename injected fixture arguments for clarity.
There was a problem hiding this comment.
Actionable comments posted: 6
🔭 Outside diff range comments (4)
docs/wireframe-testing-crate.md (2)
23-29: Fix the bogus code-block language tag
```frames.is not a recognised language identifier and breaks syntax highlighting.
Usetoml, which matches the snippet’s content:-```frames. +```toml
84-90: Correct the second malformed code-block fenceThe marker
```helpers.again introduces an invalid language tag.
Select an appropriate identifier (rustfits this snippet) to restore rendering:-```helpers. +```rustdocs/rust-binary-router-library-design.md (2)
90-106: Convert dangling numerals to proper footnotes
Replace the inline “.8”, “.10”, “.11” (and subsequent bare numerals in the same bullet block) with GitHub-style references such as[^bincode],[^bincode-options], etc., and add the matching definitions near the existing footnote block. Bare numerals break linting (MD042) and violate the project’s doc style.Example patch:
- integrates well with Serde.8 It offers high performance and configurable - options for endianness and integer encoding.10 `bincode` 2.0 makes Serde an - optional dependency and provides its own `Encode`/`Decode` traits that can be - derived.11 Its flexibility and performance make it a strong candidate if + integrates well with Serde.[^bincode] It offers high performance and + configurable options for endianness and integer encoding.[^bincode-options] + `bincode` 2.0 makes Serde an optional dependency and provides its own + `Encode`/`Decode` traits that can be derived.[^bincode-derive] Its flexibility + and performance make it a strong candidate ifThen append footnote definitions:
[^bincode]: <https://docs.rs/bincode> [^bincode-options]: See *bincode* documentation – configurable encoding options. [^bincode-derive]: *bincode* 2 derive macro support.
875-878: **Fix invalid code-fence label “trait.”** `trait.` is not a recognised fence language; it trips markdown renderers and MD040. Usemermaid for the diagram or plain ``` for an untyped block.-```trait. +```mermaid
♻️ Duplicate comments (2)
README.md (1)
316-322: Verify the licence file link points to the correct target.The text displays "LICENCE" but links to
LICENSE. Ensure the actual file exists with the correct spelling to avoid broken links.#!/bin/bash # Check if either LICENCE or LICENSE file exists in the repository root echo "Checking for licence files in repository root:" ls -la LICENSE* LICENCE* 2>/dev/null || echo "No licence files found" # Check the actual link target in the README echo -e "\nChecking link target in README.md:" grep -n "LICENCE.*LICENSE" README.md || echo "Link pattern not found"docs/asynchronous-outbound-messaging-design.md (1)
146-148: Hard-wrap the fairness sentenceThe sentence beginning “elapsed time spent handling high-priority frames…” exceeds the 80-column limit. Re-flow the paragraph so no line exceeds ~80 columns, maintaining semantic breaks.
-elapsed time spent handling high-priority frames exceeds this slice, and the low queue is not empty, the actor yields to a low-priority frame. +elapsed time spent handling high-priority frames exceeds this slice, and the +low queue is not empty, the actor yields to a low-priority frame.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (12)
README.md(4 hunks)docs/asynchronous-outbound-messaging-design.md(8 hunks)docs/behavioural-testing-in-rust-with-cucumber.md(3 hunks)docs/documentation-style-guide.md(3 hunks)docs/generic-message-fragmentation-and-re-assembly-design.md(8 hunks)docs/multi-packet-and-streaming-responses-design.md(7 hunks)docs/rust-binary-router-library-design.md(46 hunks)docs/rust-doctest-dry-guide.md(7 hunks)docs/rust-testing-with-rstest-fixtures.md(34 hunks)docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md(12 hunks)docs/wireframe-client-design.md(2 hunks)docs/wireframe-testing-crate.md(5 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.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:
README.mddocs/documentation-style-guide.mddocs/multi-packet-and-streaming-responses-design.mddocs/generic-message-fragmentation-and-re-assembly-design.mddocs/wireframe-client-design.mddocs/asynchronous-outbound-messaging-design.mddocs/behavioural-testing-in-rust-with-cucumber.mddocs/wireframe-testing-crate.mddocs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.mddocs/rust-testing-with-rstest-fixtures.mddocs/rust-binary-router-library-design.mddocs/rust-doctest-dry-guide.md
🧠 Learnings (9)
README.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/asynchronous-outbound-messaging-design.md:0-0
Timestamp: 2025-06-30T23:03:00.249Z
Learning: Applies to docs/src/push.rs : The SessionRegistry must provide methods to get, insert, remove, and enumerate active handles, removing entries whose handles have been dropped.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/asynchronous-outbound-messaging-design.md:0-0
Timestamp: 2025-06-30T23:03:00.249Z
Learning: Applies to docs/src/push.rs : The SessionRegistry must not leak memory when connections are terminated; it must remove handles for closed connections.
docs/documentation-style-guide.md (8)
Learnt from: CR
PR: leynos/lille#0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2025-06-24T18:31:17.075Z
Learning: In Rust source files, public APIs should be documented using doc comments that start with '///', include a short summary, explicit parameter and return value documentation, and sections for panics, errors, and examples. Examples should be placed under '# Examples' and marked with 'no_run' to prevent execution during documentation tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2025-07-18T18:37:43.978Z
Learning: Applies to docs/**/*.rs : Use doc comments to document public APIs in Rust, keeping them consistent with the manual.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2025-06-30T23:04:15.670Z
Learning: Applies to docs/**/*.rs : Use doc comments to document public APIs in Rust code, keeping them consistent with the manual.
Learnt from: CR
PR: leynos/lille#0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2025-07-20T12:04:45.233Z
Learning: Applies to docs/**/*.rs : Use doc comments to document public APIs in Rust code, keeping them consistent with the manual.
Learnt from: CR
PR: leynos/mxd#0
File: AGENTS.md:0-0
Timestamp: 2025-06-25T23:37:47.576Z
Learning: Document public Rust APIs using Rustdoc comments (///) so documentation can be generated with cargo doc.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2025-07-18T18:32:18.243Z
Learning: Applies to docs/**/*.rs : Keep the summary line of Rust API doc comments short, followed by further detail.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/documentation-style-guide.md:0-0
Timestamp: 2025-07-18T18:32:18.243Z
Learning: Applies to docs/**/*.rs : Begin each Rust API doc comment block with ///.
Learnt from: CR
PR: leynos/femtologging#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T17:07:36.701Z
Learning: Applies to **/*.rs : Document public APIs in Rust using Rustdoc comments (///) so documentation can be generated with cargo doc.
docs/multi-packet-and-streaming-responses-design.md (3)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Applies to docs/src/**/*.rs : Use a generic WireframeError<E> enum to distinguish between unrecoverable transport-level I/O errors and recoverable, protocol-specific logical errors.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/observability-operability-and-maturity.md:0-0
Timestamp: 2025-06-30T23:06:50.162Z
Learning: Applies to docs/src/**/*.rs : Provide a generic error enum (WireframeError<E>) to distinguish between fatal I/O errors and protocol-specific logical errors, enabling intelligent error handling.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/hardening-wireframe-a-guide-to-production-resilience.md:0-0
Timestamp: 2025-06-30T23:05:05.706Z
Learning: Applies to docs/**/*.rs : Use a generic error enum (e.g., WireframeError<E>) to distinguish between unrecoverable transport errors and recoverable protocol errors, enabling intelligent error handling and recovery.
docs/generic-message-fragmentation-and-re-assembly-design.md (1)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/generic-message-fragmentation-and-re-assembly-design.md:0-0
Timestamp: 2025-06-30T23:04:39.802Z
Learning: Applies to docs/**/fragment_adapter.rs : The FragmentAdapter must use a concurrently accessible map (such as dashmap::DashMap) for in-flight message re-assembly to support multiplexing.
docs/asynchronous-outbound-messaging-design.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/asynchronous-outbound-messaging-design.md:0-0
Timestamp: 2025-06-30T23:03:00.249Z
Learning: Applies to docs/src/connection_actor.rs : The connection actor's write loop must use a tokio::select! loop with the biased keyword to ensure a strict, deterministic polling order: shutdown signal, high-priority push, low-priority push, then response stream.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Applies to docs/src/**/*.rs : For push mechanisms, offer an optional Dead Letter Queue (DLQ) pattern: if a push fails due to a full queue, route the frame to a separate channel for later inspection or reprocessing.
docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md (8)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Applies to docs/src/**/*.rs : Use the async-stream crate as the canonical method for constructing Response::Stream values in handler implementations.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/wireframe-1-0-detailed-development-roadmap.md:0-0
Timestamp: 2025-06-29T18:04:58.493Z
Learning: The FragmentStrategy trait should define core methods such as decode_header and encode_header, and be extensible to support context-aware fragmentation rules.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Applies to docs/src/**/*.rs : The FragmentStrategy trait must provide methods for determining max fragment payload, decoding headers, and encoding headers, supporting multiplexing and concurrent re-assembly.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/generic-message-fragmentation-and-re-assembly-design.md:0-0
Timestamp: 2025-06-30T23:04:39.802Z
Learning: Applies to docs/**/fragment_strategy.rs : The FragmentStrategy trait must define methods for max_fragment_payload, decode_header, and encode_header, and use the FragmentMeta struct for metadata.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/wireframe-1-0-detailed-development-roadmap.md:0-0
Timestamp: 2025-06-29T18:04:58.493Z
Learning: Multiplexed re-assembly should be supported by using msg_id from FragmentMeta as a key into a dashmap::DashMap of partial messages, enabling concurrent re-assembly of multiple messages.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/generic-message-fragmentation-and-re-assembly-design.md:0-0
Timestamp: 2025-06-30T23:04:39.802Z
Learning: Applies to docs/**/fragment_adapter.rs : The FragmentAdapter must use a concurrently accessible map (such as dashmap::DashMap) for in-flight message re-assembly to support multiplexing.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Applies to docs/src/**/*.rs : Use a concurrent hash map (e.g., dashmap::DashMap) keyed by msg_id for re-assembling multiple logical messages concurrently in the FragmentAdapter.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/wireframe-1-0-detailed-development-roadmap.md:0-0
Timestamp: 2025-06-29T18:04:58.493Z
Learning: Advanced testing should include concurrency verification using loom for select! loops and PushHandle, and property-based testing with proptest for complex protocol interactions.
docs/rust-testing-with-rstest-fixtures.md (118)
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: In Rust, the rstest crate provides a declarative, macro-based approach to fixture-based and parameterized testing, reducing boilerplate and improving test readability.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected as function arguments for improved readability and reduced boilerplate.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros such as #[rstest] and #[fixture], allowing for declarative test setup and dependency injection.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: In Rust, the rstest crate enables declarative fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies as function arguments and generate multiple test cases from a single function.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected into test functions as arguments.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies into test functions by matching argument names to fixture functions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: Compared to standard Rust #[test], rstest provides declarative fixture injection and parameterization, reducing boilerplate and improving test clarity, especially for complex setups and input combinations.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/contents.md:0-0
Timestamp: 2025-07-20T17:08:06.039Z
Learning: Use the rstest crate for fixture-based tests in Rust as explained in rust-testing-with-rstest-fixtures.md
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that provide setup data or resources for tests. They can return any valid Rust type and can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into tests by matching argument names, promoting separation of setup and test logic.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into test functions by matching argument names, promoting test readability and reusability.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: By default, rstest creates a new instance of a fixture for each test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing state leakage between tests.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: By default, rstest creates a fresh instance of each fixture for every test invocation, ensuring test isolation and preventing state leakage between tests.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (each case generates a separate test) and #[values(...)] for combinatorial testing (generating the Cartesian product of values for arguments).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (specific input/output pairs) and #[values(...)] for combinatorial testing (Cartesian product of argument values), generating individual test cases for each combination.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Parameterized tests in rstest are created using #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial testing, generating individual test cases for each set or combination of inputs.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[case(...)] attribute in rstest allows table-driven tests by generating a separate test for each set of input arguments, with each case reported individually by the test runner.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven parameterized tests in Rust with rstest.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures and parameterized arguments (#[case], #[values]) can be combined in the same rstest test function, allowing for expressive and flexible test scenarios.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute in #[rstest] tests to define table-driven, parameterized test cases.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven, parameterized test cases in #[rstest] functions.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[values(...)] attribute in rstest enables combinatorial testing by generating tests for every possible combination of provided values across arguments, which can lead to a combinatorial explosion if not used judiciously.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute in #[rstest] tests to generate tests for all combinations of provided values (combinatorial testing).
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute on test function arguments to generate combinatorial test cases with rstest.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute to generate combinatorial tests for all combinations of provided values.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use #[values(...)] attributes on test function arguments to generate combinatorial (Cartesian product) parameterized tests in rstest.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same #[rstest] test function for expressive test scenarios.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or improving argument clarity.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is especially useful when destructuring or for clarity.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[from(original_fixture_name)] attribute to rename injected fixtures in test or fixture function arguments for clarity or destructuring.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions or other fixtures.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments for clarity.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures can be made configurable using #[default(...)] for fixture arguments and #[with(...)] in tests to override defaults, enabling flexible and DRY test setups.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[default(...)] attribute in fixture arguments provides default values, and #[with(...)] in tests overrides these defaults for specific test cases, enabling flexible and DRY fixture configuration.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[default(...)] attribute provides default values for fixture arguments, and #[with(...)] can override these defaults in specific tests, enabling highly configurable fixtures.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Asynchronous fixtures and tests are supported by defining async fn fixtures and test functions. rstest integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's test attribute.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: rstest supports asynchronous fixtures and tests by allowing async fn for both, and integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by using the appropriate test attribute (e.g., #[tokio::test]) alongside #[rstest].
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the appropriate runtime's #[test] attribute.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest supports asynchronous testing by allowing async fn fixtures and async test functions, integrating with async runtimes like async-std or tokio via their respective #[async_std::test] or #[tokio::test] attributes.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Define asynchronous fixtures as async fn and use them in async tests with #[rstest].
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Define asynchronous fixtures as async fn and use them in async test functions with #[rstest].
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Define asynchronous fixtures as async fn with #[fixture] and use them in async rstest tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Write asynchronous tests as async fn functions annotated with #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Annotate async test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Annotate asynchronous test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Annotate async test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing the need for explicit impl Future types and automating .await calls.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Best practices for organizing rstest-based tests include: placing module-local fixtures in the module's tests submodule, sharing fixtures via a common module or crate, using descriptive names, composing small fixtures, and preferring per-test fixtures for isolation.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Encapsulate mock setup logic for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Encapsulate mock object setup for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to receive pre-configured mock objects and keeping test logic focused and isolated.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mock objects as dependencies.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mocks as arguments and keeping test logic focused.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[files("glob_pattern")] attribute in rstest parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (with mode = "str" or "bytes") as arguments, enabling data-driven testing from the filesystem.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute in rstest to parameterize tests over files matching a glob pattern, injecting file paths or contents as arguments.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[files("glob_pattern")] attribute in rstest can parameterize tests over files matching a glob, injecting either file paths or file contents as test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (as &str or &[u8]) into test arguments, and is useful for data-driven testing.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[files("glob_pattern")] attribute on test arguments to inject file paths or contents matching the specified glob pattern for data-driven tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven testing.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Best practices for organizing rstest-based tests include grouping related fixtures and tests into modules, using descriptive names, composing small focused fixtures, and preferring per-test fixtures for proper resource management.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Best practices for organizing fixtures and tests include: placing module-specific fixtures in the module's tests submodule, sharing fixtures via common modules or #[cfg(test)] in the library, using descriptive names, composing small fixtures, and grouping related tests and fixtures into modules.
Learnt from: CR
PR: leynos/mdtablefix#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T03:26:36.990Z
Learning: Applies to **/*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/wireframe#0
File: AGENTS.md:0-0
Timestamp: 2025-06-30T23:02:18.018Z
Learning: Applies to **/*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)] as appropriate.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)].
Learnt from: CR
PR: leynos/ortho-config#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T21:31:16.982Z
Learning: Applies to /{tests,src}//*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/ddlint#0
File: AGENTS.md:0-0
Timestamp: 2025-07-18T18:35:14.639Z
Learning: Applies to /{tests,src}//*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for trivial tests, standard #[test] may suffice.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for simple unit tests, standard #[test] may suffice.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use rstest for tests with complex setup, parameterization, or where improved readability and DRY principles are desired; use standard #[test] for simple, isolated unit tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Prefer rstest for tests requiring complex setup, parameterization, or improved readability, and use standard #[test] for simple unit tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Use rstest for tests requiring complex setup, parameterization, or improved readability, but consider standard #[test] for simple, non-parameterized unit tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Be aware that rstest test cases generated by #[case], #[values], or #[files] are discovered at compile time and cannot be dynamically generated at runtime.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The rstest-log crate helps integrate logging frameworks into rstest tests, ensuring proper log initialization for each test case.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Integrate logging in rstest tests using the rstest-log crate to ensure proper log initialization and output during test execution.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Integrate logging in tests using the rstest-log crate to ensure proper log initialization in rstest-generated tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The rstest-log crate can be used to ensure proper logging initialization in rstest tests, and the test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: For logging in rstest tests, the rstest-log crate can be used to ensure proper initialization of logging frameworks before each test runs.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the logtest crate to verify log output in tests by capturing and asserting on emitted log records.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the rstest-log crate to ensure logging frameworks are properly initialized in rstest-generated tests.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the rstest-log crate to ensure logging frameworks are properly initialized in rstest-generated tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the logtest crate to assert on log output in tests by starting a Logger before running the code under test.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Integrate logging in tests using the rstest-log crate to ensure proper log initialization in test cases.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions; macro order matters, with rstest generating test cases before test-with applies its logic.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use the test-with crate in conjunction with rstest to conditionally execute tests based on runtime conditions, ensuring rstest generates test cases before applying conditional logic.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Use the test-with crate for conditional test execution, applying its attributes after rstest to generated test cases.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Conditional test execution (e.g., based on environment variables or file existence) can be achieved by combining rstest with the test-with crate, applying its attributes after rstest's macro expansion.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, annotating after #[rstest].
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, applying its attributes after #[rstest].
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, applying its attributes after #[rstest].
docs/rust-binary-router-library-design.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Prioritize protocol-agnosticism, developer experience, and Rust's safety and performance guarantees in all design and implementation decisions.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/roadmap.md:0-0
Timestamp: 2025-06-30T23:07:15.902Z
Learning: Applies to docs/src/{app,server}.rs : Build the Actix-inspired API around WireframeApp and WireframeServer as described, including method signatures (new, route, service, wrap), consistent Result<Self> error strategy, and ergonomic chaining
docs/rust-doctest-dry-guide.md (2)
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : To conditionally execute doctests based on features, use #[cfg(feature = "...")] inside the code block or cfg_attr to conditionally add the ignore flag to the doctest header.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-doctest-dry-guide.md:0-0
Timestamp: 2025-07-20T03:27:06.497Z
Learning: Applies to docs/**/*.rs : Use #[doc(cfg(...))] to visually indicate feature-gated items in generated documentation, requiring #![feature(doc_cfg)] at the crate root.
🪛 LanguageTool
README.md
[locale-violation] ~319-~319: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...e terms of the ISC licence. See LICENCE for details. [data-extraction-guide]:...
(LICENCE_LICENSE_NOUN_SINGULAR)
docs/multi-packet-and-streaming-responses-design.md
[style] ~224-~224: Would you like to use the Oxford spelling “prioritized”? The spelling ‘prioritised’ is also correct.
Context: ...ronous Pushes:** The connection actor's prioritised write loop (as defined in the outboun...
(OXFORD_SPELLING_Z_NOT_S)
docs/generic-message-fragmentation-and-re-assembly-design.md
[style] ~218-~218: You have used the passive voice repeatedly in nearby sentences. To make your writing clearer and easier to read, consider using active voice.
Context: ...ap, and the complete logical frame is passed down the processor chain. 4. **Timeout...
(REP_PASSIVE_VOICE)
docs/asynchronous-outbound-messaging-design.md
[style] ~81-~81: Would you like to use the Oxford spelling “Prioritized”? The spelling ‘Prioritised’ is also correct.
Context: ...l space becomes available. ### 3.2 The Prioritised Write Loop The connection actor's writ...
(OXFORD_SPELLING_Z_NOT_S)
[grammar] ~83-~83: An apostrophe ‘s’ denotes possession. Did you mean to use the plural form of the noun (no apostrophe)?
Context: ... Prioritised Write Loop The connection actor's write logic will be implemented within ...
(NOUN_APOSTROPHE_S_VERB)
docs/behavioural-testing-in-rust-with-cucumber.md
[typographical] ~1116-~1116: To join two clauses or introduce examples, consider using an em dash.
Context: ...the-common-pitfalls> [^23]: Data tables - Cucumber Rust Book, accessed on 14 July ...
(DASH_RULE)
docs/rust-testing-with-rstest-fixtures.md
[grammar] ~580-~580: Please add a punctuation mark at the end of paragraph.
Context: ...useful when destructuring the result of a ```fixture. use rstest::*; #[fixture]...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~607-~607: Use ‘wants’ only when referring to the third person singular such as “he wants”.
Context: ...the test only cares about some parts or wants to use more idiomatic names for destruc...
(CONFUSION_BETWEEN_NNS_OR_WANTS_TO)
[grammar] ~708-~708: Please add a punctuation mark at the end of paragraph.
Context: ... messages. ## VI. Asynchronous Testing with rstest rstest provides robust supp...
(PUNCTUATION_PARAGRAPH_END)
docs/rust-binary-router-library-design.md
[uncategorized] ~75-~75: Loose punctuation mark.
Context: ...h distinct characteristics. - wire-rs: The user query specifically suggests co...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~269-~269: Since ownership is already implied, this phrasing may be redundant.
Context: ...cture. Users should be able to define their own framing logic and message types. - **Pe...
(PRP_OWN)
[style] ~519-~519: Since ownership is already implied, this phrasing may be redundant.
Context: ...os, "wireframe" might need to provide its own wrapper traits and derive macros that i...
(PRP_OWN)
[uncategorized] ~530-~530: Loose punctuation mark.
Context: ...ation will be considered: - bincode: Offers high performance, configurabilit...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~533-~533: Loose punctuation mark.
Context: ...ose binary serialization. - postcard: Ideal for scenarios where serialized si...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~614-~614: To reduce wordiness, try specifying a number or using “many” or “numerous” instead.
Context: ... high-throughput systems that process a large number of messages per second. - Dynamic Routing...
(LARGE_NUMBER_OF)
[style] ~635-~635: This phrasing can be wordy. Try something more concise.
Context: ...lear, declarative API for this routing, as opposed to manual match statements over message ...
(OPPOSED_TO)
docs/rust-doctest-dry-guide.md
[uncategorized] ~20-~20: Loose punctuation mark.
Context: ...a developer executes cargo test --doc, rustdoc initiates a multi-stage proce...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~61-~61: Possible missing comma found.
Context: ...te)`). This is not a bug or an oversight but a fundamental aspect of the design, enf...
(AI_HYDRA_LEO_MISSING_COMMA)
[grammar] ~80-~80: Please add a punctuation mark at the end of paragraph.
Context: ...private functions must either be marked as ignore, forgoing the test guarantee,...
(PUNCTUATION_PARAGRAPH_END)
[uncategorized] ~82-~82: Loose punctuation mark.
Context: ...tions must either be marked as ignore, forgoing the test guarantee, or be dupl...
(UNLIKELY_OPENING_PUNCTUATION)
[grammar] ~121-~121: Please add a punctuation mark at the end of paragraph.
Context: ...tem's purpose. For instance, an example for String::clone() should not just show...
(PUNCTUATION_PARAGRAPH_END)
[misspelling] ~140-~140: This word is normally spelled as one.
Context: ...rongly discouraged. It is considered an anti-pattern because users often copy example code v...
(EN_COMPOUNDS_ANTI_PATTERN)
[style] ~203-~203: Consider using the typographical ellipsis character here instead.
Context: ... error-handling examples, the entire fn main() -> Result<...> {... } and Ok(()) scaffolding ca...
(ELLIPSIS)
[locale-violation] ~203-~203: Lower-case ‘Ok’ is American English. For British English use “OK”.
Context: ...e fn main() -> Result<...> {... } and Ok(()) scaffolding can be hidden, pres...
(OK)
[style] ~219-~219: This word has been used in one of the immediately preceding sentences. Using a synonym could make your text more interesting to read, unless the repetition is intentional.
Context: ...ver, the ideal documentation example is often just a small, illustrative snippet that...
(EN_REPEATEDWORDS_OFTEN)
[uncategorized] ~245-~245: Possible missing comma found.
Context: ... execute it. | OK if compilation succeeds. ...
(AI_HYDRA_LEO_MISSING_COMMA)
[uncategorized] ~250-~250: Loose punctuation mark.
Context: ...Detailed Attribute Breakdown - ignore: This is the bluntest instrument in the ...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~256-~256: Loose punctuation mark.
Context: ...lustrative pseudocode. - should_panic: This attribute inverts the normal test ...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~259-~259: Consider using a more formal/concise alternative here.
Context: ...s successfully or panics for a reason other than the one expected (if a specific panic m...
(OTHER_THAN)
[uncategorized] ~261-~261: Loose punctuation mark.
Context: ...sage is asserted).[^3] - compile_fail: This is a powerful tool for creating ed...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~268-~268: Loose punctuation mark.
Context: ...ch would break the test.[^4] - no_run: This attribute strikes a crucial balanc...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~275-~275: Loose punctuation mark.
Context: ...thout executing it.[^5] - edition20xx: This attribute allows an example to be ...
(UNLIKELY_OPENING_PUNCTUATION)
[formatting] ~301-~301: If the ‘because’ clause is essential to the meaning, do not use a comma before the clause.
Context: ...ed by #[cfg(test)]. This will not work, because rustdoc does not enable the test co...
(COMMA_BEFORE_BECAUSE)
[grammar] ~416-~416: Please add a punctuation mark at the end of paragraph.
Context: ...mpiler.[^13] The compiler only sees the host cfg (e.g., target_os = "windows"),...
(PUNCTUATION_PARAGRAPH_END)
[locale-violation] ~450-~450: Lower-case ‘ok’ is American English. For British English use “OK”.
Context: ... runs, does nothing, and is reported as ok. While simple to write, this can be mi...
(OK)
[style] ~479-~479: Consider using the typographical ellipsis character here instead.
Context: ...ocumentation. This is achieved with the #[doc(cfg(...))] attribute, which requires enabling ...
(ELLIPSIS)
[style] ~506-~506: Since ownership is already implied, this phrasing may be redundant.
Context: ...hree distinct types of tests, each with its own purpose: - Doctests: These are ide...
(PRP_OWN)
[style] ~517-~517: Consider using the typographical ellipsis character here instead.
Context: ...odules within the source files (often mod tests {... }) and are compiled only with `#[cfg...
(ELLIPSIS)
[style] ~563-~563: Consider using the typographical ellipsis character here instead.
Context: ...(http://crates.io), where hidden lines (#...) look like ugly, commented-out code....
(ELLIPSIS)
[grammar] ~578-~578: Please add a punctuation mark at the end of paragraph.
Context: ... first write and debug the example as a standard #[test] function in a temporary fi...
(PUNCTUATION_PARAGRAPH_END)
[style] ~603-~603: Consider using the typographical ellipsis character here instead.
Context: ...f fallible functions, always use the fn main() -> Result<...> pattern, hiding the boilerplate. Avoi...
(ELLIPSIS)
[style] ~610-~610: Consider using the typographical ellipsis character here instead.
Context: ...ity* in the final documentation. Use #[cfg(feature = "...")] or other cfg flags inside th...
(ELLIPSIS)
[style] ~618-~618: You have already used ‘right’ in nearby sentences. Consider using an alternative word to let your writing stand out and sound more polished.
Context: ...a square peg into a round hole. Use the right tool for the job. ### Works cited ...
(REP_RIGHT)
[typographical] ~622-~622: To join two clauses or introduce examples, consider using an em dash.
Context: ...he job. ### Works cited [^1]: rust - How can I write documentation tests for ...
(DASH_RULE)
[typographical] ~625-~625: To join two clauses or introduce examples, consider using an em dash.
Context: ...ules> [^2]: Rustdoc doctests need fixing - Swatinem, accessed on July 15, 2025, <ht...
(DASH_RULE)
[typographical] ~627-~627: To join two clauses or introduce examples, consider using an em dash.
Context: .../fix-rustdoc/> [^3]: Documentation tests - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~627-~627: To join two clauses or introduce examples, consider using an em dash.
Context: ...: Documentation tests - The rustdoc boOK - Rust Documentation, accessed on July 15,...
(DASH_RULE)
[typographical] ~633-~633: To join two clauses or introduce examples, consider using an em dash.
Context: ...l> [^6]: How to organize your Rust tests - LogRocket Blog, accessed on July 15, 202...
(DASH_RULE)
[typographical] ~636-~636: To join two clauses or introduce examples, consider using an em dash.
Context: ..._rust/> [^7]: Writing Rust Documentation - DEV Community, accessed on July 15, 2025...
(DASH_RULE)
[typographical] ~640-~640: To join two clauses or introduce examples, consider using an em dash.
Context: ...hat-is-rustdoc.html> [^9]: Documentation - Rust API Guidelines, accessed on July 15...
(DASH_RULE)
[typographical] ~642-~642: To join two clauses or introduce examples, consider using an em dash.
Context: ...0]: Best practice for doc testing README - help - The Rust Programming Langu...
(DASH_RULE)
[typographical] ~642-~642: To join two clauses or introduce examples, consider using an em dash.
Context: ...t practice for doc testing README - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~645-~645: To join two clauses or introduce examples, consider using an em dash.
Context: ...mpile_fail doc test ignored in cfg(test) - help - The Rust Programming Language For...
(DASH_RULE)
[typographical] ~645-~645: To join two clauses or introduce examples, consider using an em dash.
Context: ...ail doc test ignored in cfg(test) - help - The Rust Programming Language Forum, acc...
(DASH_RULE)
[typographical] ~650-~650: To join two clauses or introduce examples, consider using an em dash.
Context: ...for-doctests/50426> [^12]: quote_doctest - Rust - Docs.rs, access...
(DASH_RULE)
[typographical] ~650-~650: To join two clauses or introduce examples, consider using an em dash.
Context: ...tests/50426> [^12]: quote_doctest - Rust - Docs.rs, accessed on J...
(DASH_RULE)
[typographical] ~652-~652: To join two clauses or introduce examples, consider using an em dash.
Context: .../quote-doctest> [^13]: Advanced features - The rustdoc boOK - Rust Documentation, a...
(DASH_RULE)
[typographical] ~652-~652: To join two clauses or introduce examples, consider using an em dash.
Context: ...3]: Advanced features - The rustdoc boOK - Rust Documentation, accessed on J...
(DASH_RULE)
[typographical] ~654-~654: To join two clauses or introduce examples, consider using an em dash.
Context: ...tdoc/advanced-features.html> [^14]: rust - How can I conditionally execute a module...
(DASH_RULE)
[uncategorized] ~659-~659: Loose punctuation mark.
Context: ...[^15]: How do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~659-~659: To join two clauses or introduce examples, consider using an em dash.
Context: ...ow do you write your doc tests? : r/rust - Reddit, accessed on July 15, 2025, <http...
(DASH_RULE)
🔇 Additional comments (18)
docs/documentation-style-guide.md (3)
61-62: LGTM! Improved line breaks enhance readability.The sentence split across two lines maintains proper flow whilst improving readability within the 80-column limit.
74-74: LGTM! Consistent fenced code block formatting.The standardisation to three backticks maintains consistency with markdown best practices throughout the document.
Also applies to: 93-93
97-100: LGTM! Improved grammar and word choice.The changes correctly add a comma before the coordinating conjunction "so" and replace "short" with the more precise "brief", addressing the previous review feedback.
README.md (4)
85-87: LGTM! Improved line wrapping and readability.The text reflow maintains proper meaning whilst improving line length consistency.
190-195: LGTM! Enhanced markdown link formatting.The formatting improvements maintain readability whilst properly handling the technical references and inline code elements.
223-224: LGTM! Improved line breaks maintain readability.The sentence restructuring enhances flow whilst keeping the technical meaning intact.
313-314: LGTM! Consistent line wrapping applied.The paragraph reflow improves consistency with the document's formatting standards.
docs/multi-packet-and-streaming-responses-design.md (3)
28-28: LGTM! Correct markdown table alignment.The table header separator now uses the proper three-dash format for better markdown compliance.
76-76: LGTM! Consistent Rust code block language specification.The capitalised "Rust" language identifiers improve syntax highlighting consistency throughout the document.
Also applies to: 112-112, 142-142, 154-154, 167-167
219-220: LGTM! Improved paragraph flow and readability.The line break adjustments enhance readability whilst maintaining the technical accuracy of the content.
Also applies to: 225-227
docs/generic-message-fragmentation-and-re-assembly-design.md (4)
13-21: LGTM! Enhanced paragraph structure and flow.The rewrapping improves readability whilst maintaining the technical precision of the middleware concept explanation.
30-30: LGTM! Proper markdown table formatting.The expanded table header separator improves markdown compliance and visual clarity.
54-57: LGTM! Consistent formatting improvements.The line breaks and Rust code block language specifications enhance document consistency and readability.
Also applies to: 59-59, 99-101, 102-102, 161-161
178-179: LGTM! Improved text flow and table formatting.The paragraph rewrapping and table alignment enhance readability whilst preserving the technical content integrity.
Also applies to: 217-218, 270-270
docs/rust-doctest-dry-guide.md (2)
563-566: Remove second-person phrasingEliminate “your” to align with the no-second-person guideline.
- audiences. It needs to render cleanly on platforms like GitHub and [crates.io](http://crates.io), where hidden lines (`#...`) look like ugly, commented-out code. At the same time, it should contain testable examples, which often require hidden lines for setup.[^10] The best practice is to avoid maintaining the README manually. + audiences. It must render cleanly on platforms like GitHub and [crates.io](http://crates.io), where hidden lines (`#...`) appear as unsightly commented-out code. At the same time, it should contain testable examples, which often require hidden lines for setup.[^10] The best practice is to avoid maintaining the README manually.⛔ Skipped due to learnings
Learnt from: CR PR: leynos/mdtablefix#0 File: docs/rust-doctest-dry-guide.md:0-0 Timestamp: 2025-07-20T03:27:06.497Z Learning: Applies to docs/**/README.md : For README.md files, avoid maintaining testable examples with hidden lines manually; instead, generate README.md from crate-level documentation using tools like cargo-readme to strip hidden lines.
240-246: Correct lowercase “ok” → “OK”Maintain “OK” in prose to meet en-GB conventions.
-| no_run | Compiles the code but does not execute it. | ok if compilation succeeds. | Use Case: Essential for examples with undesirable side effects in a test environment, such as network requests, filesystem I/O, or launching a GUI. Guarantees the example is valid Rust code without running it.[^5] | +| no_run | Compiles the code but does not execute it. | OK if compilation succeeds. | Use Case: Essential for examples with undesirable side effects in a test environment, such as network requests, filesystem I/O, or launching a GUI. Guarantees the example is valid Rust code without running it.[^5] |Likely an incorrect or invalid review comment.
docs/behavioural-testing-in-rust-with-cucumber.md (1)
991-1000: Change is acceptableThe capitalisation from
yamltoYAMLdoes not breach any house rule, and the fenced block stays within the 120-column allowance for code.docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md (1)
341-345: Keep table rows ≤ 80 columnsThe updated roadmap table now exceeds the mandated wrap width, breaching
*.mdguidelines.
Wrap each cell entry onto multiple lines or shorten wording so that no rendered line exceeds 80 characters.
| ### 3.2 The Prioritised Write Loop | ||
|
|
||
| The connection actor's write logic will be implemented within a `tokio::select!` | ||
| loop. Crucially, this loop will use the `biased` keyword to ensure a strict, | ||
| deterministic polling order. This prevents high-volume yet critical control | ||
| messages from being starved by large data streams. | ||
| The connection actor's write logic will be implemented within a | ||
| `tokio::select!` loop. Crucially, this loop will use the `biased` keyword to | ||
| ensure a strict, deterministic polling order. This prevents high-volume yet | ||
| critical control messages from being starved by large data streams. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Use oxford-ised “Prioritized”
Replace “Prioritised” with the oxford-ised spelling “Prioritized” to comply with the en-GB-oxendict rule.
-### 3.2 The Prioritised Write Loop
+### 3.2 The Prioritized Write Loop📝 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.
| ### 3.2 The Prioritised Write Loop | |
| The connection actor's write logic will be implemented within a `tokio::select!` | |
| loop. Crucially, this loop will use the `biased` keyword to ensure a strict, | |
| deterministic polling order. This prevents high-volume yet critical control | |
| messages from being starved by large data streams. | |
| The connection actor's write logic will be implemented within a | |
| `tokio::select!` loop. Crucially, this loop will use the `biased` keyword to | |
| ensure a strict, deterministic polling order. This prevents high-volume yet | |
| critical control messages from being starved by large data streams. | |
| ### 3.2 The Prioritized Write Loop | |
| The connection actor's write logic will be implemented within a | |
| `tokio::select!` loop. Crucially, this loop will use the `biased` keyword to | |
| ensure a strict, deterministic polling order. This prevents high-volume yet | |
| critical control messages from being starved by large data streams. |
🧰 Tools
🪛 LanguageTool
[style] ~81-~81: Would you like to use the Oxford spelling “Prioritized”? The spelling ‘Prioritised’ is also correct.
Context: ...l space becomes available. ### 3.2 The Prioritised Write Loop The connection actor's writ...
(OXFORD_SPELLING_Z_NOT_S)
[grammar] ~83-~83: An apostrophe ‘s’ denotes possession. Did you mean to use the plural form of the noun (no apostrophe)?
Context: ... Prioritised Write Loop The connection actor's write logic will be implemented within ...
(NOUN_APOSTROPHE_S_VERB)
🤖 Prompt for AI Agents
In docs/asynchronous-outbound-messaging-design.md around lines 81 to 86, replace
the heading "Prioritised Write Loop" with the oxford-ised spelling "Prioritized
Write Loop" to comply with the en-GB-oxendict style guide.
| The preferred approach is to utilize wire-rs 6 as the underlying | ||
| serialization and deserialization engine. However, this is critically | ||
| dependent on wire-rs supporting, or being extended to support, derivable | ||
| Encode and Decode traits (e.g., through #). The ability to automatically | ||
| generate this logic from struct/enum definitions is paramount. Manual |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Remove stray placeholder “#” in parenthetical note
The fragment “(e.g., through #)” leaves an unfinished placeholder and confuses the reader. Delete the hash or replace it with a concrete example (e.g., “through wireframe_derive”).
- Encode and Decode traits (e.g., through #). The ability to automatically
+ Encode and Decode traits (for example via the upcoming `wireframe_derive`
+ crate). The ability to automatically📝 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.
| The preferred approach is to utilize wire-rs 6 as the underlying | |
| serialization and deserialization engine. However, this is critically | |
| dependent on wire-rs supporting, or being extended to support, derivable | |
| Encode and Decode traits (e.g., through #). The ability to automatically | |
| generate this logic from struct/enum definitions is paramount. Manual | |
| The preferred approach is to utilize wire-rs 6 as the underlying | |
| serialization and deserialization engine. However, this is critically | |
| dependent on wire-rs supporting, or being extended to support, derivable | |
| Encode and Decode traits (for example via the upcoming `wireframe_derive` | |
| crate). The ability to automatically | |
| generate this logic from struct/enum definitions is paramount. Manual |
🤖 Prompt for AI Agents
In docs/rust-binary-router-library-design.md around lines 509 to 513, remove the
stray placeholder "#" in the parenthetical note "(e.g., through #)" as it is
unfinished and confusing. Replace it with a concrete example such as "(e.g.,
through `wireframe_derive`)" or simply delete the "#" to clarify the sentence.
| Using `.unwrap()` or `.expect()` in examples is strongly discouraged. It is | ||
| considered an anti-pattern because users often copy example code verbatim, and |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Standardise spelling of “antipattern”
House style treats the term as a single word. Drop the hyphen.
-considered an anti-pattern because users often copy example code verbatim, and
+considered an antipattern because users often copy example code verbatim, and📝 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.
| Using `.unwrap()` or `.expect()` in examples is strongly discouraged. It is | |
| considered an anti-pattern because users often copy example code verbatim, and | |
| Using `.unwrap()` or `.expect()` in examples is strongly discouraged. It is | |
| considered an antipattern because users often copy example code verbatim, and |
🧰 Tools
🪛 LanguageTool
[misspelling] ~140-~140: This word is normally spelled as one.
Context: ...rongly discouraged. It is considered an anti-pattern because users often copy example code v...
(EN_COMPOUNDS_ANTI_PATTERN)
🤖 Prompt for AI Agents
In docs/rust-doctest-dry-guide.md around lines 139 to 140, the term
"anti-pattern" should be standardized to "antipattern" without the hyphen to
match the house style. Replace all instances of "anti-pattern" with
"antipattern" in this section.
| // In a real test, you'd have more specific assertions | ||
| // based on `expected_next_state`. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Remove second-person pronoun from example comment.
Comply with the docs style guide by rephrasing without “you’d”.
- // In a real test, you'd have more specific assertions
+ // A production-ready test would include more specific assertions📝 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.
| // In a real test, you'd have more specific assertions | |
| // based on `expected_next_state`. | |
| // A production-ready test would include more specific assertions | |
| // based on `expected_next_state`. |
🤖 Prompt for AI Agents
In docs/rust-testing-with-rstest-fixtures.md around lines 410 to 411, the
comment uses the second-person pronoun "you'd," which is against the docs style
guide. Rephrase the comment to remove "you'd" and use a more neutral or passive
voice, such as "In a real test, more specific assertions would be made based on
`expected_next_state`."
| [^1]: See [wireframe router | ||
| design](rust-binary-router-library-design.md#implementation-details). |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Trim unnecessary indentation in the footnote definition
Indenting the second line of a footnote by 18 spaces adds visual noise and invites future line-length violations. Align the link with the opening line:
-[^1]: See [wireframe router
- design](rust-binary-router-library-design.md#implementation-details).
+[^1]: See [wireframe router design](rust-binary-router-library-design.md#implementation-details).📝 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.
| [^1]: See [wireframe router | |
| design](rust-binary-router-library-design.md#implementation-details). | |
| [^1]: See [wireframe router design](rust-binary-router-library-design.md#implementation-details). |
🤖 Prompt for AI Agents
In docs/wireframe-client-design.md around lines 95 to 96, the second line of the
footnote is indented by 18 spaces, which is unnecessary and causes visual
clutter. Remove the extra indentation so that the link aligns directly under the
opening line of the footnote definition, maintaining consistent and clean
formatting.
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (3)
docs/rust-testing-with-rstest-fixtures.md (1)
410-412: Remove second-person pronoun inside example commentThe inline comment still says “you'd”, which violates the project’s “no 2nd person” rule for Markdown docs.
- // In a real test, you'd have more specific assertions + // A production-ready test would include more specific assertionsREADME.md (1)
318-319: Correct the licence link and display textUse British-English spelling for the visible link text and ensure the target path matches to prevent a broken hyperlink.
-Wireframe is distributed under the terms of the ISC licence. See -[LICENSE](LICENSE) for details. +Wireframe is distributed under the terms of the ISC licence. See +[LICENCE](LICENCE) for details.docs/rust-binary-router-library-design.md (1)
508-513: Replace placeholder “#” with an actual crate or remove itThe fragment “(e.g., through #)” is a dangling placeholder and violates clarity rules.
Provide the intended crate name (for examplewireframe_derive) or delete the token.-Encode and Decode traits (e.g., through #). The ability to automatically +Encode and Decode traits (e.g., through `wireframe_derive`). The ability to automatically
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
README.md(4 hunks)docs/rust-binary-router-library-design.md(45 hunks)docs/rust-testing-with-rstest-fixtures.md(34 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.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:
README.mddocs/rust-testing-with-rstest-fixtures.mddocs/rust-binary-router-library-design.md
🧠 Learnings (3)
README.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/asynchronous-outbound-messaging-design.md:0-0
Timestamp: 2025-06-30T23:03:00.249Z
Learning: Applies to docs/src/push.rs : The SessionRegistry must provide methods to get, insert, remove, and enumerate active handles, removing entries whose handles have been dropped.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/asynchronous-outbound-messaging-design.md:0-0
Timestamp: 2025-06-30T23:03:00.249Z
Learning: Applies to docs/src/push.rs : The SessionRegistry must not leak memory when connections are terminated; it must remove handles for closed connections.
docs/rust-testing-with-rstest-fixtures.md (118)
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: In Rust, the rstest crate provides a declarative, macro-based approach to fixture-based and parameterized testing, reducing boilerplate and improving test readability.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected as function arguments for improved readability and reduced boilerplate.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros such as #[rstest] and #[fixture], allowing for declarative test setup and dependency injection.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: In Rust, the rstest crate enables declarative fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies as function arguments and generate multiple test cases from a single function.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected into test functions as arguments.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies into test functions by matching argument names to fixture functions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: Compared to standard Rust #[test], rstest provides declarative fixture injection and parameterization, reducing boilerplate and improving test clarity, especially for complex setups and input combinations.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/contents.md:0-0
Timestamp: 2025-07-20T17:08:06.039Z
Learning: Use the rstest crate for fixture-based tests in Rust as explained in rust-testing-with-rstest-fixtures.md
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that provide setup data or resources for tests. They can return any valid Rust type and can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into tests by matching argument names, promoting separation of setup and test logic.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into test functions by matching argument names, promoting test readability and reusability.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: By default, rstest creates a new instance of a fixture for each test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing state leakage between tests.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: By default, rstest creates a fresh instance of each fixture for every test invocation, ensuring test isolation and preventing state leakage between tests.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (each case generates a separate test) and #[values(...)] for combinatorial testing (generating the Cartesian product of values for arguments).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (specific input/output pairs) and #[values(...)] for combinatorial testing (Cartesian product of argument values), generating individual test cases for each combination.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Parameterized tests in rstest are created using #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial testing, generating individual test cases for each set or combination of inputs.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[case(...)] attribute in rstest allows table-driven tests by generating a separate test for each set of input arguments, with each case reported individually by the test runner.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven parameterized tests in Rust with rstest.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures and parameterized arguments (#[case], #[values]) can be combined in the same rstest test function, allowing for expressive and flexible test scenarios.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute in #[rstest] tests to define table-driven, parameterized test cases.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven, parameterized test cases in #[rstest] functions.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[values(...)] attribute in rstest enables combinatorial testing by generating tests for every possible combination of provided values across arguments, which can lead to a combinatorial explosion if not used judiciously.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute in #[rstest] tests to generate tests for all combinations of provided values (combinatorial testing).
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute on test function arguments to generate combinatorial test cases with rstest.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute to generate combinatorial tests for all combinations of provided values.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use #[values(...)] attributes on test function arguments to generate combinatorial (Cartesian product) parameterized tests in rstest.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same #[rstest] test function for expressive test scenarios.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or improving argument clarity.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is especially useful when destructuring or for clarity.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[from(original_fixture_name)] attribute to rename injected fixtures in test or fixture function arguments for clarity or destructuring.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions or other fixtures.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename fixtures when injecting them as arguments in test functions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures can be made configurable using #[default(...)] for fixture arguments and #[with(...)] in tests to override defaults, enabling flexible and DRY test setups.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[default(...)] attribute in fixture arguments provides default values, and #[with(...)] in tests overrides these defaults for specific test cases, enabling flexible and DRY fixture configuration.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[default(...)] attribute provides default values for fixture arguments, and #[with(...)] can override these defaults in specific tests, enabling highly configurable fixtures.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Asynchronous fixtures and tests are supported by defining async fn fixtures and test functions. rstest integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's test attribute.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: rstest supports asynchronous fixtures and tests by allowing async fn for both, and integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by using the appropriate test attribute (e.g., #[tokio::test]) alongside #[rstest].
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the appropriate runtime's #[test] attribute.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest supports asynchronous testing by allowing async fn fixtures and async test functions, integrating with async runtimes like async-std or tokio via their respective #[async_std::test] or #[tokio::test] attributes.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Define asynchronous fixtures as async fn and use them in async tests with #[rstest].
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Define asynchronous fixtures as async fn and use them in async test functions with #[rstest].
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Define asynchronous fixtures as async fn with #[fixture] and use them in async rstest tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Write asynchronous tests as async fn functions annotated with #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Annotate async test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Annotate asynchronous test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Annotate async test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing the need for explicit impl Future types and automating .await calls.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Best practices for organizing rstest-based tests include: placing module-local fixtures in the module's tests submodule, sharing fixtures via a common module or crate, using descriptive names, composing small fixtures, and preferring per-test fixtures for isolation.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Encapsulate mock setup logic for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Encapsulate mock object setup for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to receive pre-configured mock objects and keeping test logic focused and isolated.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mock objects as dependencies.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mocks as arguments and keeping test logic focused.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[files("glob_pattern")] attribute in rstest parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (with mode = "str" or "bytes") as arguments, enabling data-driven testing from the filesystem.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute in rstest to parameterize tests over files matching a glob pattern, injecting file paths or contents as arguments.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[files("glob_pattern")] attribute in rstest can parameterize tests over files matching a glob, injecting either file paths or file contents as test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (as &str or &[u8]) into test arguments, and is useful for data-driven testing.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[files("glob_pattern")] attribute on test arguments to inject file paths or contents matching the specified glob pattern for data-driven tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven testing.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Best practices for organizing rstest-based tests include grouping related fixtures and tests into modules, using descriptive names, composing small focused fixtures, and preferring per-test fixtures for proper resource management.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Best practices for organizing fixtures and tests include: placing module-specific fixtures in the module's tests submodule, sharing fixtures via common modules or #[cfg(test)] in the library, using descriptive names, composing small fixtures, and grouping related tests and fixtures into modules.
Learnt from: CR
PR: leynos/mdtablefix#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T03:26:36.990Z
Learning: Applies to **/*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/wireframe#0
File: AGENTS.md:0-0
Timestamp: 2025-06-30T23:02:18.018Z
Learning: Applies to **/*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)] as appropriate.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)].
Learnt from: CR
PR: leynos/ortho-config#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T21:31:16.982Z
Learning: Applies to /{tests,src}//*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/ddlint#0
File: AGENTS.md:0-0
Timestamp: 2025-07-18T18:35:14.639Z
Learning: Applies to /{tests,src}//*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for trivial tests, standard #[test] may suffice.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for simple unit tests, standard #[test] may suffice.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use rstest for tests with complex setup, parameterization, or where improved readability and DRY principles are desired; use standard #[test] for simple, isolated unit tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Prefer rstest for tests requiring complex setup, parameterization, or improved readability, and use standard #[test] for simple unit tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Use rstest for tests requiring complex setup, parameterization, or improved readability, but consider standard #[test] for simple, non-parameterized unit tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Be aware that rstest test cases generated by #[case], #[values], or #[files] are discovered at compile time and cannot be dynamically generated at runtime.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The rstest-log crate helps integrate logging frameworks into rstest tests, ensuring proper log initialization for each test case.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Integrate logging in rstest tests using the rstest-log crate to ensure proper log initialization and output during test execution.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Integrate logging in tests using the rstest-log crate to ensure proper log initialization in rstest-generated tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The rstest-log crate can be used to ensure proper logging initialization in rstest tests, and the test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: For logging in rstest tests, the rstest-log crate can be used to ensure proper initialization of logging frameworks before each test runs.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the logtest crate to verify log output in tests by capturing and asserting on emitted log records.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the rstest-log crate to ensure logging frameworks are properly initialized in rstest-generated tests.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the rstest-log crate to ensure logging frameworks are properly initialized in rstest-generated tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the logtest crate to assert on log output in tests by starting a Logger before running the code under test.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Integrate logging in tests using the rstest-log crate to ensure proper log initialization in test cases.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions; macro order matters, with rstest generating test cases before test-with applies its logic.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use the test-with crate in conjunction with rstest to conditionally execute tests based on runtime conditions, ensuring rstest generates test cases before applying conditional logic.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Use the test-with crate for conditional test execution, applying its attributes after rstest to generated test cases.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Conditional test execution (e.g., based on environment variables or file existence) can be achieved by combining rstest with the test-with crate, applying its attributes after rstest's macro expansion.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, annotating after #[rstest].
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, applying its attributes after #[rstest].
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, applying its attributes after #[rstest].
docs/rust-binary-router-library-design.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Prioritize protocol-agnosticism, developer experience, and Rust's safety and performance guarantees in all design and implementation decisions.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/roadmap.md:0-0
Timestamp: 2025-06-30T23:07:15.902Z
Learning: Applies to docs/src/{app,server}.rs : Build the Actix-inspired API around WireframeApp and WireframeServer as described, including method signatures (new, route, service, wrap), consistent Result<Self> error strategy, and ergonomic chaining
🪛 LanguageTool
README.md
[locale-violation] ~319-~319: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...nder the terms of the ISC licence. See LICENSE for details. [data-extractio...
(LICENCE_LICENSE_NOUN_SINGULAR)
docs/rust-testing-with-rstest-fixtures.md
[uncategorized] ~608-~608: Use ‘wants’ only when referring to the third person singular such as “he wants”.
Context: ...the test only cares about some parts or wants to use more idiomatic names for destruc...
(CONFUSION_BETWEEN_NNS_OR_WANTS_TO)
[grammar] ~709-~709: Please add a punctuation mark at the end of paragraph.
Context: ... messages. ## VI. Asynchronous Testing with rstest rstest provides robust supp...
(PUNCTUATION_PARAGRAPH_END)
docs/rust-binary-router-library-design.md
[uncategorized] ~75-~75: Loose punctuation mark.
Context: ...h distinct characteristics. - wire-rs: The user query specifically suggests co...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~269-~269: Since ownership is already implied, this phrasing may be redundant.
Context: ...cture. Users should be able to define their own framing logic and message types. - **Pe...
(PRP_OWN)
[style] ~519-~519: Since ownership is already implied, this phrasing may be redundant.
Context: ...os, "wireframe" might need to provide its own wrapper traits and derive macros that i...
(PRP_OWN)
[uncategorized] ~530-~530: Loose punctuation mark.
Context: ...ation will be considered: - bincode: Offers high performance, configurabilit...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~533-~533: Loose punctuation mark.
Context: ...ose binary serialization. - postcard: Ideal for scenarios where serialized si...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~614-~614: To reduce wordiness, try specifying a number or using “many” or “numerous” instead.
Context: ... high-throughput systems that process a large number of messages per second. - Dynamic Routing...
(LARGE_NUMBER_OF)
[style] ~635-~635: This phrasing can be wordy. Try something more concise.
Context: ...lear, declarative API for this routing, as opposed to manual match statements over message ...
(OPPOSED_TO)
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
docs/rust-binary-router-library-design.md (1)
90-97: Convert bare numerals “10”, “11”, etc. into GitHub-style footnotesHouse style forbids dangling numerals as citations.
Replace each instance with[^label]references and add matching definitions at the end of the file.Example:
- options for endianness and integer encoding.10 `bincode` 2.0 makes Serde an + options for endianness and integer encoding.[^bincode-perf] `bincode` 2.0 makes Serde anThen append:
[^bincode-perf]: *bincode* performance options – <https://docs.rs/bincode>
♻️ Duplicate comments (3)
README.md (1)
316-319: Fix British-English link inconsistency and broken pathThe heading uses “Licence”, but the visible link text and target remain
LICENSE.
Align the spelling and avoid the 404 by updating both the text and the file name.-## Licence - -Wireframe is distributed under the terms of the ISC licence. See -[LICENSE](LICENSE) for details. +## Licence + +Wireframe is distributed under the terms of the ISC licence. See +[LICENCE](LICENCE) for details.docs/rust-binary-router-library-design.md (1)
509-513: Remove the second stray#placeholderAnother “through #” fragment slipped through. Replace it with a concrete example or delete it.
- dependent on wire-rs supporting, or being extended to support, derivable - Encode and Decode traits (e.g., through #). + dependent on wire-rs supporting, or being extended to support, derivable + `Encode` and `Decode` traits (for example via the forthcoming `wireframe_derive` crate).docs/rust-testing-with-rstest-fixtures.md (1)
410-412: Remove second-person pronoun from example comment.The
// In a real test, you'd have more specific assertionsline violates the “no 2nd person” rule. Rephrase to a neutral construction.- // In a real test, you'd have more specific assertions + // In a real test, more specific assertions would be added
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
README.md(4 hunks)docs/rust-binary-router-library-design.md(45 hunks)docs/rust-testing-with-rstest-fixtures.md(34 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.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:
README.mddocs/rust-testing-with-rstest-fixtures.mddocs/rust-binary-router-library-design.md
🧠 Learnings (3)
README.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/asynchronous-outbound-messaging-design.md:0-0
Timestamp: 2025-06-30T23:03:00.249Z
Learning: Applies to docs/src/push.rs : The SessionRegistry must provide methods to get, insert, remove, and enumerate active handles, removing entries whose handles have been dropped.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/asynchronous-outbound-messaging-design.md:0-0
Timestamp: 2025-06-30T23:03:00.249Z
Learning: Applies to docs/src/push.rs : The SessionRegistry must not leak memory when connections are terminated; it must remove handles for closed connections.
docs/rust-testing-with-rstest-fixtures.md (118)
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: In Rust, the rstest crate provides a declarative, macro-based approach to fixture-based and parameterized testing, reducing boilerplate and improving test readability.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected as function arguments for improved readability and reduced boilerplate.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros such as #[rstest] and #[fixture], allowing for declarative test setup and dependency injection.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: In Rust, the rstest crate enables declarative fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies as function arguments and generate multiple test cases from a single function.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], allowing dependencies to be injected into test functions as arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: Compared to standard Rust #[test], rstest provides declarative fixture injection and parameterization, reducing boilerplate and improving test clarity, especially for complex setups and input combinations.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: In Rust, the rstest crate enables fixture-based and parameterized testing using procedural macros like #[rstest] and #[fixture], which inject dependencies into test functions by matching argument names to fixture functions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/contents.md:0-0
Timestamp: 2025-07-20T17:08:06.039Z
Learning: Use the rstest crate for fixture-based tests in Rust as explained in rust-testing-with-rstest-fixtures.md
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects. Fixtures can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that provide setup data or resources for tests. They can return any valid Rust type and can depend on other fixtures by listing them as arguments.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into tests by matching argument names, promoting separation of setup and test logic.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Fixtures in rstest are regular Rust functions annotated with #[fixture]; their return values are injected into test functions by matching argument names, promoting test readability and reusability.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Fixtures in rstest are Rust functions annotated with #[fixture] that encapsulate setup logic and can return any valid Rust type, including primitives, structs, or trait objects.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: By default, rstest creates a new instance of a fixture for each test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing shared mutable state between tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: By default, rstest creates a new instance of each fixture for every test that uses it, ensuring test isolation and preventing state leakage between tests.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: By default, rstest creates a fresh instance of each fixture for every test invocation, ensuring test isolation and preventing state leakage between tests.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (each case generates a separate test) and #[values(...)] for combinatorial testing (generating the Cartesian product of values for arguments).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios (specific input/output pairs) and #[values(...)] for combinatorial testing (Cartesian product of argument values), generating individual test cases for each combination.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Parameterized tests in rstest are created using #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial testing, generating individual test cases for each set or combination of inputs.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Parameterized tests in rstest use #[case(...)] for table-driven scenarios and #[values(...)] for combinatorial (Cartesian product) testing, generating individual test cases for each combination.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[case(...)] attribute in rstest allows table-driven tests by generating a separate test for each set of input arguments, with each case reported individually by the test runner.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven parameterized tests in Rust with rstest.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Fixtures and parameterized arguments (#[case], #[values]) can be combined in the same rstest test function, allowing for expressive and flexible test scenarios.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute in #[rstest] tests to define table-driven, parameterized test cases.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[case(...)] attribute to define table-driven, parameterized test cases in #[rstest] functions.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[values(...)] attribute in rstest enables combinatorial testing by generating tests for every possible combination of provided values across arguments, which can lead to a combinatorial explosion if not used judiciously.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute in #[rstest] tests to generate tests for all combinations of provided values (combinatorial testing).
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute on test function arguments to generate combinatorial test cases with rstest.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[values(...)] attribute to generate combinatorial tests for all combinations of provided values.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use #[values(...)] attributes on test function arguments to generate combinatorial (Cartesian product) parameterized tests in rstest.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same #[rstest] test function for expressive test scenarios.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same rstest test function for expressive test scenarios.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Combine fixtures and parameterized arguments (#[case] or #[values]) in the same test function for expressive test scenarios.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or improving argument clarity.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is especially useful when destructuring or for clarity.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[from(original_fixture_name)] attribute allows renaming a fixture when injecting it into a test or another fixture, which is useful for destructuring or clarity.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[from(original_fixture_name)] attribute to rename injected fixtures in test or fixture function arguments for clarity or destructuring.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions or other fixtures.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename injected fixture arguments in test functions.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[from(original_fixture_name)] attribute to rename fixtures when injecting them as arguments in test functions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Fixtures can be made configurable using #[default(...)] for fixture arguments and #[with(...)] in tests to override defaults, enabling flexible and DRY test setups.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[default(...)] attribute in fixture arguments provides default values, and #[with(...)] in tests overrides these defaults for specific test cases, enabling flexible and DRY fixture configuration.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[default(...)] attribute provides default values for fixture arguments, and #[with(...)] can override these defaults in specific tests, enabling highly configurable fixtures.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: Asynchronous fixtures and tests are supported by defining async fn fixtures and test functions. rstest integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's test attribute.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: rstest supports asynchronous fixtures and tests by allowing async fn for both, and integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by using the appropriate test attribute (e.g., #[tokio::test]) alongside #[rstest].
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the appropriate runtime's #[test] attribute.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest supports async fixtures and async test functions; it integrates with async runtimes like async-std or tokio by combining #[rstest] with the runtime's #[test] attribute.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest supports asynchronous testing by allowing async fn fixtures and async test functions, integrating with async runtimes like async-std or tokio via their respective #[async_std::test] or #[tokio::test] attributes.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Define asynchronous fixtures as async fn and use them in async tests with #[rstest].
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Define asynchronous fixtures as async fn and use them in async test functions with #[rstest].
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Define asynchronous fixtures as async fn with #[fixture] and use them in async rstest tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Write asynchronous tests as async fn functions annotated with #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Annotate async test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Annotate asynchronous test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Annotate async test functions with both #[rstest] and the appropriate async runtime attribute (e.g., #[tokio::test], #[async_std::test]).
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.857Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing the need for explicit impl Future types and automating .await calls.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[future] and #[awt] attributes in rstest simplify working with async fixtures and arguments by removing boilerplate and optionally auto-awaiting futures.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: Best practices for organizing rstest-based tests include: placing module-local fixtures in the module's tests submodule, sharing fixtures via a common module or crate, using descriptive names, composing small fixtures, and preferring per-test fixtures for isolation.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Encapsulate mock setup logic for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Encapsulate mock object setup for external services (e.g., databases, HTTP APIs) within rstest fixtures to isolate tests from real dependencies.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to receive pre-configured mock objects and keeping test logic focused and isolated.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mock objects as dependencies.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Mocking external services (e.g., databases, HTTP APIs) is best encapsulated in fixtures, allowing tests to request pre-configured mocks as arguments and keeping test logic focused.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:09.111Z
Learning: The #[files("glob_pattern")] attribute in rstest parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:36.858Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (with mode = "str" or "bytes") as arguments, enabling data-driven testing from the filesystem.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute in rstest to parameterize tests over files matching a glob pattern, injecting file paths or contents as arguments.
Learnt from: CR
PR: leynos/mxd#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T23:40:48.640Z
Learning: The #[files("glob_pattern")] attribute in rstest can parameterize tests over files matching a glob, injecting either file paths or file contents as test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either PathBufs or file contents (as &str or &[u8]) into test arguments, and is useful for data-driven testing.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The #[files("glob_pattern")] attribute parameterizes tests over files matching a glob, injecting either their PathBuf or contents (as &str or &[u8]) into test arguments.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Applies to docs/**/*.{rs} : Use the #[files("glob_pattern")] attribute on test arguments to inject file paths or contents matching the specified glob pattern for data-driven tests.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the #[files("glob_pattern")] attribute to inject file paths or contents as test arguments for data-driven testing.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Best practices for organizing rstest-based tests include grouping related fixtures and tests into modules, using descriptive names, composing small focused fixtures, and preferring per-test fixtures for proper resource management.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: Best practices for organizing fixtures and tests include: placing module-specific fixtures in the module's tests submodule, sharing fixtures via common modules or #[cfg(test)] in the library, using descriptive names, composing small fixtures, and grouping related tests and fixtures into modules.
Learnt from: CR
PR: leynos/mdtablefix#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T03:26:36.990Z
Learning: Applies to **/*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/wireframe#0
File: AGENTS.md:0-0
Timestamp: 2025-06-30T23:02:18.018Z
Learning: Applies to **/*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)] as appropriate.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Organize fixtures and tests by grouping related fixtures in modules, using clear naming conventions, and placing shared fixtures in common modules or under #[cfg(test)].
Learnt from: CR
PR: leynos/ortho-config#0
File: AGENTS.md:0-0
Timestamp: 2025-07-20T21:31:16.982Z
Learning: Applies to /{tests,src}//*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/ddlint#0
File: AGENTS.md:0-0
Timestamp: 2025-07-18T18:35:14.639Z
Learning: Applies to /{tests,src}//*_test.rs : Use rstest fixtures for shared setup.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for trivial tests, standard #[test] may suffice.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: rstest is most beneficial for complex setups, parameterized testing, and when aiming for readable, DRY, and maintainable test suites; for simple unit tests, standard #[test] may suffice.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use rstest for tests with complex setup, parameterization, or where improved readability and DRY principles are desired; use standard #[test] for simple, isolated unit tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Prefer rstest for tests requiring complex setup, parameterization, or improved readability, and use standard #[test] for simple unit tests.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T17:11:39.979Z
Learning: Use rstest for tests requiring complex setup, parameterization, or improved readability, but consider standard #[test] for simple, non-parameterized unit tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Be aware that rstest test cases generated by #[case], #[values], or #[files] are discovered at compile time and cannot be dynamically generated at runtime.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The rstest-log crate helps integrate logging frameworks into rstest tests, ensuring proper log initialization for each test case.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Integrate logging in rstest tests using the rstest-log crate to ensure proper log initialization and output during test execution.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Integrate logging in tests using the rstest-log crate to ensure proper log initialization in rstest-generated tests.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T23:09:41.600Z
Learning: The rstest-log crate can be used to ensure proper logging initialization in rstest tests, and the test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: For logging in rstest tests, the rstest-log crate can be used to ensure proper initialization of logging frameworks before each test runs.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the logtest crate to verify log output in tests by capturing and asserting on emitted log records.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the rstest-log crate to ensure logging frameworks are properly initialized in rstest-generated tests.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the rstest-log crate to ensure logging frameworks are properly initialized in rstest-generated tests.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the logtest crate to assert on log output in tests by starting a Logger before running the code under test.
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Integrate logging in tests using the rstest-log crate to ensure proper log initialization in test cases.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-24T18:32:30.955Z
Learning: The test-with crate can be combined with rstest to conditionally execute tests based on runtime conditions; macro order matters, with rstest generating test cases before test-with applies its logic.
Learnt from: CR
PR: leynos/lille#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T12:06:42.577Z
Learning: Use the test-with crate in conjunction with rstest to conditionally execute tests based on runtime conditions, ensuring rstest generates test cases before applying conditional logic.
Learnt from: CR
PR: leynos/mdtablefix#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-20T03:27:35.813Z
Learning: Use the test-with crate for conditional test execution, applying its attributes after rstest to generated test cases.
Learnt from: CR
PR: leynos/femtologging#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-25T00:05:37.557Z
Learning: Conditional test execution (e.g., based on environment variables or file existence) can be achieved by combining rstest with the test-with crate, applying its attributes after rstest's macro expansion.
Learnt from: CR
PR: leynos/netsuke#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T19:05:14.471Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, annotating after #[rstest].
Learnt from: CR
PR: leynos/wireframe#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-06-30T23:08:10.890Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, applying its attributes after #[rstest].
Learnt from: CR
PR: leynos/ddlint#0
File: docs/rust-testing-with-rstest-fixtures.md:0-0
Timestamp: 2025-07-18T18:40:11.379Z
Learning: Applies to docs/**/*.rs : Use the test-with crate to conditionally execute tests based on runtime conditions, applying its attributes after #[rstest].
docs/rust-binary-router-library-design.md (2)
Learnt from: CR
PR: leynos/wireframe#0
File: docs/the-road-to-wireframe-1-0-feature-set-philosophy-and-capability-maturity.md:0-0
Timestamp: 2025-06-30T23:08:36.501Z
Learning: Prioritize protocol-agnosticism, developer experience, and Rust's safety and performance guarantees in all design and implementation decisions.
Learnt from: CR
PR: leynos/wireframe#0
File: docs/roadmap.md:0-0
Timestamp: 2025-06-30T23:07:15.902Z
Learning: Applies to docs/src/{app,server}.rs : Build the Actix-inspired API around WireframeApp and WireframeServer as described, including method signatures (new, route, service, wrap), consistent Result<Self> error strategy, and ergonomic chaining
🪛 LanguageTool
README.md
[locale-violation] ~319-~319: LICENSE must be spelled with a “c” when used as a noun in British English. Use “licence”.
Context: ...nder the terms of the ISC licence. See LICENSE for details. [data-extractio...
(LICENCE_LICENSE_NOUN_SINGULAR)
docs/rust-testing-with-rstest-fixtures.md
[uncategorized] ~608-~608: Use ‘wants’ only when referring to the third person singular such as “he wants”.
Context: ...the test only cares about some parts or wants to use more idiomatic names for destruc...
(CONFUSION_BETWEEN_NNS_OR_WANTS_TO)
[grammar] ~709-~709: Please add a punctuation mark at the end of paragraph.
Context: ... messages. ## VI. Asynchronous Testing with rstest rstest provides robust supp...
(PUNCTUATION_PARAGRAPH_END)
docs/rust-binary-router-library-design.md
[uncategorized] ~75-~75: Loose punctuation mark.
Context: ...h distinct characteristics. - wire-rs: The user query specifically suggests co...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~269-~269: Since ownership is already implied, this phrasing may be redundant.
Context: ...cture. Users should be able to define their own framing logic and message types. - **Pe...
(PRP_OWN)
[style] ~519-~519: Since ownership is already implied, this phrasing may be redundant.
Context: ...os, "wireframe" might need to provide its own wrapper traits and derive macros that i...
(PRP_OWN)
[uncategorized] ~530-~530: Loose punctuation mark.
Context: ...ation will be considered: - bincode: Offers high performance, configurabilit...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~533-~533: Loose punctuation mark.
Context: ...ose binary serialization. - postcard: Ideal for scenarios where serialized si...
(UNLIKELY_OPENING_PUNCTUATION)
[style] ~614-~614: To reduce wordiness, try specifying a number or using “many” or “numerous” instead.
Context: ... high-throughput systems that process a large number of messages per second. - Dynamic Routing...
(LARGE_NUMBER_OF)
[style] ~635-~635: This phrasing can be wordy. Try something more concise.
Context: ...lear, declarative API for this routing, as opposed to manual match statements over message ...
(OPPOSED_TO)
| encoding and decoding.14 It provides `BitEncode` and `BitDecode` traits, | ||
| along with custom derive macros (e.g., `#`) for ease of use.14 It allows | ||
| fine-grained control over bit-level layout, such as specifying the number of |
There was a problem hiding this comment.
Replace placeholder # with the actual derive macro
(e.g., \#`)` is a leftover placeholder and violates documentation clarity.
Insert the concrete macro name, for example:
- along with custom derive macros (e.g., `#`) for ease of use.14
+ along with custom derive macros (e.g., ``#[derive(BitEncode, BitDecode)]``) for ease of use.14📝 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.
| encoding and decoding.14 It provides `BitEncode` and `BitDecode` traits, | |
| along with custom derive macros (e.g., `#`) for ease of use.14 It allows | |
| fine-grained control over bit-level layout, such as specifying the number of | |
| encoding and decoding.14 It provides `BitEncode` and `BitDecode` traits, | |
| along with custom derive macros (e.g., ``#[derive(BitEncode, BitDecode)]``) for ease of use.14 It allows | |
| fine-grained control over bit-level layout, such as specifying the number of |
🤖 Prompt for AI Agents
In docs/rust-binary-router-library-design.md around lines 109 to 111, replace
the placeholder `#` in the example of custom derive macros with the actual macro
name used for deriving BitEncode and BitDecode traits, such as
`#[derive(BitEncode, BitDecode)]`, to improve documentation clarity and
correctness.
| binary protocol | ||
| server【F:docs/rust-binary-router-library-design.md†L1126-L1156】. |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Merge the split noun phrase
The hard line-break between “binary protocol” and “server” interrupts the noun phrase.
Re-flow the two words onto the same line; the width will still be well under 80 columns.
🤖 Prompt for AI Agents
In README.md around lines 86 to 87, the phrase "binary protocol" and "server"
are split by a hard line-break, breaking the noun phrase. Remove the line break
between these two words so that "binary protocol server" appears on the same
line, ensuring the line length remains under 80 columns.
Summary
Testing
make fmtmake lintmake testhttps://chatgpt.com/codex/tasks/task_e_687b7fa82acc8322a7ff78cb41fea123
Summary by Sourcery
Improve overall documentation formatting for consistency and readability by standardizing footnote syntax, ordered list numbering, table styles, and paragraph wrapping across all Markdown files.
Documentation: