docs(book): fix drifted source links in the count group-by chapters

[shumkov]

Issue being fixed or feature implemented

Follow-up to #3972 (the merged v3.1-dev → v4.0-dev branch retarget). That PR faithfully swapped the branch name in every book/ source link, but reviewers (thepastaclaw, Claudius-Maginificent) noticed a few of those links had drifted before the rename — they point at code that has since moved or been renamed (one link 404s). Keeping #3972 a clean mechanical rename, the content fixes land here.

What was done?

All targets verified against the current v4.0-dev tree:

• count-index-group-by-examples.md
  • group_by surface-validation link → drive_document_count_query/validate.rs no longer exists; validation now lives in DriveDocumentCountQuery::detect_mode (mode_detection.rs).
  • There is no group_by_* builder family — the group-by modes route to distinct_count_path_query / carrier_aggregate_count_path_query. Corrected on the "Queries in this Chapter" line and in the closing prose.
  • Bench series is query_g1_* … query_g8_* (it skips g6), not … query_g6_*.
• document-count-trees.md
  • read_primary_key_count_tree moved from drive_dispatcher.rs to executors/total.rs; also dropped the inaccurate Drive:: qualifier.

Out of scope (per the reviewer discussion on #3972): converting branch links to commit-ID permalinks — that's a broader docs-link policy question, not this focused fix.

How Has This Been Tested?

• Verified each replacement symbol/path exists at the branch tip: detect_mode (mode_detection.rs:85), distinct_count_path_query / carrier_aggregate_count_path_query (path_query.rs), read_primary_key_count_tree (executors/total.rs:89), and that the bench defines query_g1..g8 with no g6.
• Docs-only change; no code paths affected, no automated tests applicable.

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

Summary by CodeRabbit

• Documentation
  • Clarified query-routing notes to better reflect the current count and group-by flow.
  • Updated benchmark references in the examples guide to match the actual set of contributing benchmark cases.
  • Refined wording in the document-count guide to point directly to the relevant count-tree lookup.

[github-actions]

📖 Book Preview built successfully.

Download the preview from the workflow artifacts.
To view locally: download the artifact, unzip, and open index.html.

Updated at 2026-07-01T08:47:21.312Z

[coderabbitai]

Warning

Review limit reached

@shumkov, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 52 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 0f0af564-0957-47b7-9c13-5ca2dc074882

📥 Commits

Reviewing files that changed from the base of the PR and between 9a80f98 and 7967488.

📒 Files selected for processing (2)

• book/src/drive/count-index-group-by-examples.md
• book/src/drive/document-count-trees.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/book-source-link-accuracy

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

✅ Review complete (commit 7967488)

[thepastaclaw]

Code Review

Docs-only PR fixing drifted source links in two book chapters. Verified PR head 7967488 diff contains only the two markdown files; Codex's blocking Cargo.toml finding is a false positive (the rust-dashcore bump landed in already-merged #3973 and is on master, not in this PR's delta). Codex's docs suggestion is technically valid — the rewritten line points readers to detect_mode as the group_by surface validator, but detect_mode already receives a derived CountMode; the raw group_by shape is mapped to CountMode upstream in drive-abci's compute_aggregate_mode_and_check_limit — kept as a non-blocking suggestion.

🟡 1 suggestion(s)

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `book/src/drive/count-index-group-by-examples.md`:
- [SUGGESTION] book/src/drive/count-index-group-by-examples.md:38: group_by surface validation link points one layer too deep
  The rewritten sentence sends readers to `DriveDocumentCountQuery::detect_mode` for the dispatcher's group_by surface validation, but `detect_mode(where_clauses, mode: CountMode, prove)` already receives a derived `CountMode` (Aggregate / GroupByIn / GroupByRange / GroupByCompound) — the raw request-level `group_by` shape is validated and mapped to `CountMode` upstream in drive-abci's `compute_aggregate_mode_and_check_limit`. `detect_mode` still validates the (mode, where, prove) tuple, so the current wording is not wrong, but since this PR is specifically correcting drifted source references, it's worth distinguishing the two layers so readers land on the code that actually inspects `group_by`.

[thepastaclaw]

🟡 Suggestion: group_by surface validation link points one layer too deep

The rewritten sentence sends readers to DriveDocumentCountQuery::detect_mode for the dispatcher's group_by surface validation, but detect_mode(where_clauses, mode: CountMode, prove) already receives a derived CountMode (Aggregate / GroupByIn / GroupByRange / GroupByCompound) — the raw request-level group_by shape is validated and mapped to CountMode upstream in drive-abci's compute_aggregate_mode_and_check_limit. detect_mode still validates the (mode, where, prove) tuple, so the current wording is not wrong, but since this PR is specifically correcting drifted source references, it's worth distinguishing the two layers so readers land on the code that actually inspects group_by.

Suggested change

All proof-size and behaviour numbers below come from the same bench helper (`report_group_by_matrix`) as chapter 29's. The dispatcher's group_by surface validation lives in [`DriveDocumentCountQuery::detect_mode`](https://github.com/dashpay/platform/blob/v4.0-dev/packages/rs-drive/src/query/drive_document_count_query/mode_detection.rs); the per-mode path-query builders sit in [`packages/rs-drive/src/query/drive_document_count_query/path_query.rs`](https://github.com/dashpay/platform/blob/v4.0-dev/packages/rs-drive/src/query/drive_document_count_query/path_query.rs) (the group-by modes route to `distinct_count_path_query` and `carrier_aggregate_count_path_query`).

All proof-size and behaviour numbers below come from the same bench helper (`report_group_by_matrix`) as chapter 29's. The v1 query handler maps the request's `group_by` shape to `CountMode` in [`compute_aggregate_mode_and_check_limit`](https://github.com/dashpay/platform/blob/v4.0-dev/packages/rs-drive-abci/src/query/document_query/v1/compute_aggregate_mode_and_check_limit/v0/mod.rs), then Drive validates and routes the `(CountMode, where, prove)` tuple in [`DriveDocumentCountQuery::detect_mode`](https://github.com/dashpay/platform/blob/v4.0-dev/packages/rs-drive/src/query/drive_document_count_query/mode_detection.rs); the per-mode path-query builders sit in [`packages/rs-drive/src/query/drive_document_count_query/path_query.rs`](https://github.com/dashpay/platform/blob/v4.0-dev/packages/rs-drive/src/query/drive_document_count_query/path_query.rs) (the group-by modes route to `distinct_count_path_query` and `carrier_aggregate_count_path_query`).

_{source: ['codex']}