Add property-based tests for renderer and date-validation invariants in weaver-docs-gate

[coderabbitai]

Summary

PR #151 introduces several algorithmic invariants in crates/weaver-docs-gate — column-width calculation, Markdown table-cell escaping, date-window validation, and phase grouping — without property-based tests to verify their correctness across arbitrary inputs.

Problem

The existing tests cover concrete, hand-crafted fixtures. They do not exercise the following invariants across the full input space:

1. Column-width calculation — rendered column widths must always be at least as wide as the widest cell in that column.
2. Markdown table-cell escaping — cells containing | or newlines must be escaped so the rendered output is a structurally valid Markdown table.
3. Date-window validation — validate_pending_review_date must accept any date within the 270-day window and reject any date beyond it, regardless of the reference date.
4. Phase grouping — every task must appear in exactly one phase section, and the section heading must correspond to the task-ID prefix.

Suggested approach

Implement property-based tests using proptest to cover the above invariants. Tests should live in crates/weaver-docs-gate/tests/ or in a dedicated proptest module under src/.

Candidate test harnesses:

• Renderer: generate arbitrary BoundaryManifest values (via proptest::arbitrary::Arbitrary or hand-rolled strategies); assert that every pipe character in a cell value is escaped and that the output parses as a table with the correct number of columns per row.
• Date window: generate arbitrary (review_date, build_date) pairs; assert acceptance iff the difference is ≤ 270 days.
• Phase grouping: generate manifests with varied task-ID prefixes; assert one section heading per distinct prefix and that every task appears under the correct heading.

References

• PR introducing the invariants: Downstream consumer boundary tracking (12.1.1) #151
• Comment thread: Downstream consumer boundary tracking (12.1.1) #151

Raised by @leynos.

[leynos]

@CodeRabbit plan

[coderabbitai]

🔗 Related PRs

leynos/mdtablefix#276 - Cli matrix testing [merged]
leynos/repovec-appliance#23 - Add proptest property tests for Qdrant Quadlet parser and validator (#17) [merged]
leynos/actix-v2a#27 - Add SSE property tests (#18) [merged]
leynos/cuprum#93 - Add UTF-8 property tests (#79) [merged]
leynos/mdtablefix#301 - Keep GFM footnote references with preceding code and link spans (#299) [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[coderabbitai]

Coding Plan

Summary

• Follow the workspace pattern of isolating property tests in src/tests/property_tests.rs with proptest! blocks
• Use time::Date arithmetic (subtraction to Duration, then .whole_days()) for date-window tests without requiring additional crate features
• Build reusable strategies via prop_compose! for BoundaryManifest and task-ID generation
• Validate renderer output by parsing column widths and delimiter counts rather than fragile string matching

Design Choices

Design Choice 1: What interfaces does `weaver-docs-gate` expose?

Options Considered:

1. Wait for PR #151 to merge and inspect actual interfaces
2. Plan against the interfaces described in the ticket (BoundaryManifest, validate_pending_review_date, renderer output, phase grouping)

Chosen Option: 2

Rationale: The ticket provides sufficient detail to design property tests against the described interfaces; the implementation agent can adapt to any minor signature differences.

Design Choice 2: Where should property tests reside?

Options Considered:

1. Create crates/weaver-docs-gate/tests/property_tests.rs as an integration test file
2. Create crates/weaver-docs-gate/src/tests/property_tests.rs following the sempai and weaver-cards pattern

Chosen Option: 2

Rationale: The workspace convention (demonstrated in sempai and weaver-cards) places property tests in src/tests/property_tests.rs registered via mod property_tests; in src/tests/mod.rs.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Infrastructure and Date Validation Tests

Establish the property test module structure and implement the date-window validation tests, which are the simplest invariant to verify and serve as a template for subsequent tests.

Task 1: Add proptest dependency to weaver-docs-gate

Declare proptest as a dev-dependency in crates/weaver-docs-gate/Cargo.toml.

• Add proptest = { workspace = true } under [dev-dependencies] in crates/weaver-docs-gate/Cargo.toml
• Ensure the crate's src/tests/mod.rs (or equivalent test root) exists and is gated behind #[cfg(test)]

Task 2: Create property test module

Establish a dedicated property test module following codebase conventions.

• Create crates/weaver-docs-gate/src/tests/property_tests.rs (or add mod property_tests nested in mod tests if the crate uses the simpler pattern)
• Add mod property_tests; declaration in the test module root
• Import proptest::prelude::* and any required strategy combinators (prop_oneof!, prop_compose!)

Task 3: Implement date-window validation property tests

Verify that validate_pending_review_date accepts dates within 270 days and rejects dates beyond.

• Create a strategy that generates arbitrary (review_date, build_date) pairs using time::Date::from_ordinal_date(year, ordinal) with year in 2000i32..2100 and ordinal in 1u16..=365
• Create a helper to compute the day difference between two dates (using Date subtraction yielding Duration, then .whole_days())
• Write a proptest! block asserting: validate_pending_review_date(review_date, build_date) returns success iff (review_date - build_date).whole_days().abs() <= 270
• Include edge-case generators for exactly 270 days (boundary acceptance) and 271 days (boundary rejection)

🤖 Prompt for AI agents

Implement Phase 1: set up the property test infrastructure and date-window
validation tests for the `weaver-docs-gate` crate.

- In `crates/weaver-docs-gate/Cargo.toml`, add `proptest = { workspace = true }`
under `[dev-dependencies]`
- Ensure `crates/weaver-docs-gate/src/tests/mod.rs` exists and is gated behind
`#[cfg(test)]`; add `mod property_tests;` to it
- Create `crates/weaver-docs-gate/src/tests/property_tests.rs` with the
following structure:
- Import `proptest::prelude::*` and any required strategy combinators
(`prop_oneof!`, `prop_compose!`)
- Import `time::Date` from the `time` crate (v0.3); use
`Date::from_ordinal_date(year, ordinal)` — do NOT use the `date!()` macro
  - Import `validate_pending_review_date` from the crate root
- Define a strategy generating arbitrary `(review_date, build_date)` pairs:
  - `year` drawn from `2000i32..2100`
  - `ordinal` drawn from `1u16..=365`
  - Construct dates via `time::Date::from_ordinal_date(year, ordinal)`
- Write a `proptest!` block asserting that
`validate_pending_review_date(review_date, build_date)` returns success **if and
only if** `(review_date - build_date).whole_days().abs() <= 270`
  - Use `Date` subtraction to obtain a `Duration`, then call `.whole_days()`
- Add explicit edge-case generators:
  - A test for exactly 270 days apart (must accept)
  - A test for exactly 271 days apart (must reject)

Phase 2: Renderer Property Tests

Verify Markdown table output correctness: column widths accommodate all cell contents, and special characters are escaped to preserve table structure.

Task 1: Create BoundaryManifest strategy

Build a proptest strategy that generates arbitrary BoundaryManifest values with varied cell contents.

• Use prop_compose! to construct BoundaryManifest with:
  • A vector of tasks (length 1–20)
  • Each task containing string fields generated from "[^\x00]*" (arbitrary non-null UTF-8) with occasional embedded | and \n characters via prop_oneof!
• Ensure the strategy produces manifests with at least one task to guarantee non-empty output

Task 2: Implement column-width invariant tests

Assert that rendered column widths are always at least as wide as the widest cell in that column.

• Render a generated BoundaryManifest to a Markdown table string
• Parse the rendered output to extract column widths (count characters between | delimiters on each row, using unicode_width::UnicodeWidthStr for display width)
• For each column index, compute the maximum display width of the source cell values
• Assert that rendered_column_width >= max_source_cell_width for every column

Task 3: Implement escaping invariant tests

Assert that pipe characters and newlines in cell values do not corrupt the table structure.

• Generate manifests containing cells with embedded | and \n characters
• Render to Markdown and split by lines
• Assert every non-separator row has the same number of | delimiters (i.e., column count is consistent)
• Assert no cell's raw | character appears unescaped (search for the escape sequence the renderer uses, e.g., \| or HTML entity)

🤖 Prompt for AI agents

Implement Phase 2: renderer property tests for `BoundaryManifest` Markdown table
output in `crates/weaver-docs-gate/src/tests/property_tests.rs`.

**BoundaryManifest strategy:**
- Use `prop_compose!` to define a strategy that constructs a `BoundaryManifest`
with:
  - A vector of tasks with length in the range 1–20
- String fields for each task generated from the regex `"[^\x00]*"` (arbitrary
non-null UTF-8)
  - Occasional embedded `|` and `\n` characters injected via `prop_oneof!`
  - At least one task guaranteed (lower bound of 1) to ensure non-empty output

**Column-width invariant tests:**
- In a `proptest!` block, render a generated `BoundaryManifest` to a Markdown
table string
- Parse the rendered output to extract column widths by counting characters
between `|` delimiters on each row; use `unicode_width::UnicodeWidthStr` for
display width
- For each column index, compute the maximum display width across all source
cell values
- Assert `rendered_column_width >= max_source_cell_width` for every column

**Escaping invariant tests:**
- In a separate `proptest!` block, generate manifests with cells that contain
embedded `|` and `\n` characters
- Render to Markdown and split the output by lines
- Assert every non-separator row has the same number of `|` delimiters
(consistent column count)
- Assert no raw `|` from a cell value appears unescaped in the output (verify
against the renderer's chosen escape sequence, e.g. `\|` or an HTML entity)

Phase 3: Phase Grouping Property Tests

Verify that every task appears in exactly one phase section and that section headings match task-ID prefixes.

Task 1: Create task-ID prefix strategy

Generate manifests with varied task-ID prefixes to exercise the grouping logic.

• Define a strategy for task IDs: "[A-Z]{1,3}-[0-9]{1,4}" (e.g., "A-1", "ABC-1234")
• Use prop::collection::vec to generate 1–30 tasks with IDs drawn from this strategy
• Ensure some IDs share prefixes (to test grouping) and some are unique (to test single-task sections)

Task 2: Implement phase grouping invariant tests

Assert correct partitioning of tasks into phase sections.

• Render or invoke the phase-grouping function on a generated manifest
• Extract task IDs that appear under each section heading (parse the output or inspect the intermediate data structure)
• Assert every task ID from the input appears exactly once in the output
• Assert each task's section heading matches its ID prefix (e.g., task "ABC-42" appears under a heading containing "ABC")
• Assert no duplicate task IDs across sections

🤖 Prompt for AI agents

Implement Phase 3: phase-grouping property tests in
`crates/weaver-docs-gate/src/tests/property_tests.rs`.

**Task-ID prefix strategy:**
- Define a proptest strategy for task IDs using the regex
`"[A-Z]{1,3}-[0-9]{1,4}"` (e.g., `"A-1"`, `"ABC-1234"`)
- Use `prop::collection::vec` to generate vectors of 1–30 tasks with IDs drawn
from this strategy
- Construct the strategy such that some IDs share prefixes (to exercise
grouping) and some are unique (to exercise single-task sections)

**Phase grouping invariant tests:**
- In a `proptest!` block, render or invoke the phase-grouping function on a
generated manifest
- Extract the task IDs listed under each section heading by either:
  - Parsing the rendered string output, or
  - Inspecting the intermediate data structure returned by the grouping function
- Assert every task ID from the input appears **exactly once** across all
sections
- Assert each task's section heading matches its ID prefix (e.g., `"ABC-42"`
must appear under a heading containing `"ABC"`)
- Assert there are no duplicate task IDs across any sections

Research

The workspace uses proptest = "1.5" as a workspace-level dev-dependency. Existing crates follow a pattern of isolating property tests in a nested mod property_tests within #[cfg(test)] mod tests, or in a dedicated src/tests/property_tests.rs file. The time crate (v0.3) is available with formatting feature only; date construction must use Date::from_calendar_date or Date::from_ordinal_date rather than the date!() macro. The weaver-docs-gate crate is introduced by PR #151 and contains BoundaryManifest, validate_pending_review_date, a Markdown table renderer, and phase-grouping logic.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement Phase 1: set up the property test infrastructure and date-window
validation tests for the `weaver-docs-gate` crate.

- In `crates/weaver-docs-gate/Cargo.toml`, add `proptest = { workspace = true }`
under `[dev-dependencies]`
- Ensure `crates/weaver-docs-gate/src/tests/mod.rs` exists and is gated behind
`#[cfg(test)]`; add `mod property_tests;` to it
- Create `crates/weaver-docs-gate/src/tests/property_tests.rs` with the
following structure:
- Import `proptest::prelude::*` and any required strategy combinators
(`prop_oneof!`, `prop_compose!`)
- Import `time::Date` from the `time` crate (v0.3); use
`Date::from_ordinal_date(year, ordinal)` — do NOT use the `date!()` macro
  - Import `validate_pending_review_date` from the crate root
- Define a strategy generating arbitrary `(review_date, build_date)` pairs:
  - `year` drawn from `2000i32..2100`
  - `ordinal` drawn from `1u16..=365`
  - Construct dates via `time::Date::from_ordinal_date(year, ordinal)`
- Write a `proptest!` block asserting that
`validate_pending_review_date(review_date, build_date)` returns success **if and
only if** `(review_date - build_date).whole_days().abs() <= 270`
  - Use `Date` subtraction to obtain a `Duration`, then call `.whole_days()`
- Add explicit edge-case generators:
  - A test for exactly 270 days apart (must accept)
  - A test for exactly 271 days apart (must reject)
===============================================================================

Task: 2

Implement Phase 2: renderer property tests for `BoundaryManifest` Markdown table
output in `crates/weaver-docs-gate/src/tests/property_tests.rs`.

**BoundaryManifest strategy:**
- Use `prop_compose!` to define a strategy that constructs a `BoundaryManifest`
with:
  - A vector of tasks with length in the range 1–20
- String fields for each task generated from the regex `"[^\x00]*"` (arbitrary
non-null UTF-8)
  - Occasional embedded `|` and `\n` characters injected via `prop_oneof!`
  - At least one task guaranteed (lower bound of 1) to ensure non-empty output

**Column-width invariant tests:**
- In a `proptest!` block, render a generated `BoundaryManifest` to a Markdown
table string
- Parse the rendered output to extract column widths by counting characters
between `|` delimiters on each row; use `unicode_width::UnicodeWidthStr` for
display width
- For each column index, compute the maximum display width across all source
cell values
- Assert `rendered_column_width >= max_source_cell_width` for every column

**Escaping invariant tests:**
- In a separate `proptest!` block, generate manifests with cells that contain
embedded `|` and `\n` characters
- Render to Markdown and split the output by lines
- Assert every non-separator row has the same number of `|` delimiters
(consistent column count)
- Assert no raw `|` from a cell value appears unescaped in the output (verify
against the renderer's chosen escape sequence, e.g. `\|` or an HTML entity)
===============================================================================

Task: 3

Implement Phase 3: phase-grouping property tests in
`crates/weaver-docs-gate/src/tests/property_tests.rs`.

**Task-ID prefix strategy:**
- Define a proptest strategy for task IDs using the regex
`"[A-Z]{1,3}-[0-9]{1,4}"` (e.g., `"A-1"`, `"ABC-1234"`)
- Use `prop::collection::vec` to generate vectors of 1–30 tasks with IDs drawn
from this strategy
- Construct the strategy such that some IDs share prefixes (to exercise
grouping) and some are unique (to exercise single-task sections)

**Phase grouping invariant tests:**
- In a `proptest!` block, render or invoke the phase-grouping function on a
generated manifest
- Extract the task IDs listed under each section heading by either:
  - Parsing the rendered string output, or
  - Inspecting the intermediate data structure returned by the grouping function
- Assert every task ID from the input appears **exactly once** across all
sections
- Assert each task's section heading matches its ID prefix (e.g., `"ABC-42"`
must appear under a heading containing `"ABC"`)
- Assert there are no duplicate task IDs across any sections

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!