feat(core): report examined counts for the three sibling directory rules

[oekazuma]

Fixes #387. Stacked on #409 (base: fix/386-any-case-unit-scopes) — the counts must handle the third option map #409 adds; GitHub will retarget this PR to main when #409 merges.

Summary

architecture/reserved-name-placement reports per-declaration examined counts; its three glob-configured siblings (reserved-directory-names, directory-naming, unit-entry-file) never called recordExamined, so a run configuring all four yielded counts for one rule and silence for three. Per the issue, each rule needed its own small spec of what one "examined" unit is — shipped as three definitions grounded in each rule's own diagnostics:

• reserved-directory-names: identity = bare glob key (the diagnostics' naming, shared across all three maps). Counts one directory per winning key — a key that matched but lost the tie-break governed nothing there and stays 0 (pinned). Under feat(core): govern lowercase units in architecture/reserved-directory-names #409's partition (one glob in unitScopes + anyCaseUnitScopes), both maps' work sums under the shared bare-glob label, consistent with how the diagnostics already name that string regardless of source map (pinned: shared label reads 2 across one capitalised + one lowercase unit).
• directory-naming: a compound route segment (decodeSegment → undefined) was matched but never judged against a casing — not counted. A letterless name (2024) vacuously passes casing and is counted; only the decode-failure path is excluded (pinned).
• unit-entry-file: one namespace over both maps' keys (matching the existing merged inert-key diagnostic); the count goes to whichever key actually supplied the expected extension (units beats pascalCaseUnits where both match — pinned).

Cross-cutting, per the examined-counts design: --route runs (no sourceFiles inventory) produce no entry (the rules' existing early return sits above the counting); counts are unfiltered by --diff/baseline by construction (recorded inside check()); empty-value keys are seeded at 0 (identity is the map key, which the diagnostics also name); override-only keys stay invisible, matching each rule's existing diagnostics scope. The empty-entry vs no-entry distinction is asserted with Object.hasOwn + toEqual({}), not a filtered subset.

Verification

• Every new counting site was mutation-checked (increment disabled → named tests fail → restored, diffed clean): 5/4/7 tests catch the three sites respectively, plus a combined four-rule pin in engine.test.ts.
• pnpm -r typecheck / pnpm test (core 1346, cli 846, vite 209) / pnpm lint all green.
• Changeset: @svelte-vitals/core minor (JSON-only surface). No engine/rule.ts changes needed. Per-rule doc-page mentions of the counts can follow if wanted — the examined map is documented generically today.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 17 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

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: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: bd98b50d-95d5-4e28-98f3-f504f7657796

📥 Commits

Reviewing files that changed from the base of the PR and between 65ce0c1 and 6a6ac3b.

📒 Files selected for processing (8)

• .changeset/examined-counts-sibling-rules.md
• packages/core/src/rules/architecture/directory-naming.ts
• packages/core/src/rules/architecture/reserved-directory-names.ts
• packages/core/src/rules/architecture/unit-entry-file.ts
• packages/core/test/directory-naming.test.ts
• packages/core/test/engine.test.ts
• packages/core/test/reserved-directory-names.test.ts
• packages/core/test/unit-entry-file.test.ts

---

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.}