cov-loupe 4.0.0.pre → 4.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0e8d1ac0b9d486b7c52f210bec91595b29ada420148f6953d3a1de5ac9580337
-  data.tar.gz: 01302faaa61ceb94affa19af5a253173805f525a45cfc7d60ee506dbba775417
+  metadata.gz: ad1c10a98b23420df309b322178fb9a128faa58fe45d1aee8ba2578b6d3f8c23
+  data.tar.gz: 8044f1ac74ee62852f11204f971d9e750a08f9e1c7b2eabb4eef7794056e7fd0
 SHA512:
-  metadata.gz: 1b347a3ce7d484d0fa644683a0cb84677c1f106404b5888c6c8b6bbc73e47e1f82676799e597cbafef33f0d801362d0918531465e682eb5780e1d829315aa5f4
-  data.tar.gz: c721b691a014c12714bf6330096d525d8bec5853e2804681c70fe8e27059dcc6f425e7622e4f7cb7cbab7409095e875941279338e2775e5e405acc2d22cb6e9e
+  metadata.gz: 53f869c7166b313f11310b2164fd08384cfe713fde38900a925b0f2846ba0b0b043e50e2d0901482152328e17fc9970ee24a5bb10b8e9d46f32b4bec6061d2d3
+  data.tar.gz: 3a4d9f649e566bbf8228c5c8e2237cde16a518d6ce39b1d6b9ae92d1888e8481ce620d4d51f5081dd228d49ad05677c0358dfdb12f37de99e27d455134df2736

data/AGENTS.md

@@ -96,8 +96,8 @@ Use `bundle exec rspec spec/path_spec.rb` to target specific specs when needed.
   ```
 - Exercise the MCP server manually by piping JSON-RPC:
   ```sh
-  echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"coverage_summary_tool","arguments":{"path":"lib/cov_loupe/model.rb"}}}' | bundle exec exe/cov-loupe
-  echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"help_tool","arguments":{}}}' | bundle exec exe/cov-loupe
+  echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"coverage_summary_tool","arguments":{"path":"lib/cov_loupe/model.rb"}}}' | bundle exec exe/cov-loupe -m mcp
+  echo '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"help_tool","arguments":{}}}' | bundle exec exe/cov-loupe -m mcp
   ```
 
 ### Building

data/README.md

@@ -153,7 +153,6 @@ Full documentation is available at **[https://keithrbennett.github.io/cov-loupe/
 - [Release Notes](docs/release_notes.md)
 - [License](docs/license.md)
 - [MCP Input Examples](docs/examples/mcp-inputs.md)
-- [Prompt Examples](docs/examples/prompts.md)
 - [Predicate Examples](docs/examples/success_predicates.md)
 
 ## Requirements

data/RELEASE_NOTES.md

@@ -3,7 +3,7 @@
 [Back to main README](docs/index.md)
 
 
-## v4.0.0, v4.0.0.pre (Breaking)
+## v4.0.0 (Breaking)
 
 - **Removed Branch Coverage Support**: Removed logic that synthesized line coverage from branch-only coverage data. This feature was complex and rarely used. Users should use standard line coverage configuration in SimpleCov.
   - Removed `docs/dev/BRANCH_ONLY_COVERAGE.md`.
@@ -59,6 +59,8 @@
 
 ### ✨ Enhancements
 
+- **New `-f p` shortcut for pretty-json format**: Added `-f p` as a shortcut for `--format pretty-json`. This follows the pattern of other format shortcuts (`-f j` for json, `-f y` for yaml, etc.). The previous `-f J` shortcut no longer works (use `-f p` instead).
+
 - **Project totals now include coverage breakdowns**: The `totals` subcommand and `coverage_totals_tool` now return explicit `with_coverage` and `without_coverage` breakdowns, plus tracking metadata, so totals clearly separate fresh coverage from missing coverage.
 
   **Example output:**

data/dev/prompts/improve/update-documentation.md

@@ -1,21 +1,80 @@
 # Review and Revise Documentation as Necessary
 
-Examine carefully the Markdown documentation files in:
+**Purpose:** Keep the project's Markdown documentation accurate, clear, complete, and internally consistent.
 
-- *.md
-- docs/**/*.md
-- docs/user/**/*.md
-- docs/dev/arch-decisions/**/*.md
+## Scope
 
-Make any changes necessary to make them accurate, clear, and complete.
+Examine all Markdown files in:
 
-Make sure that documents are linked in both directions, e.g. from the top level readme
-to the specialized document, and vice versa.
+- `*.md`
+- `docs/**/*.md`
+- `docs/user/**/*.md`
+- `docs/dev/arch-decisions/**/*.md`
 
-Ensure that there is enough verbiage to explain a given point, but not too much as to 
-unnecessarily reduce the signal to noise ratio. 
+## What to Look For
 
-If a given point is addressed in multiple documents, look to see if that is sensible, and fix if necessary.
+### Accuracy
 
-Ensure that any code examples are correct and relevant.
+- Claims that no longer match the code (CLI flags, method names, output formats, file paths).
+- Code examples that produce different output than documented, or that refer to removed features.
+- Version numbers, dependency names, or configuration keys that have changed.
 
+### Clarity
+
+- Sections that assume prior knowledge not provided in the doc or a clearly-linked prerequisite.
+- Ambiguous pronouns or unexplained jargon — if the meaning is unclear on first read, rewrite it.
+- Paragraphs that mix distinct topics; split or reorganise them.
+- Over-long explanations where a concise rewrite would preserve meaning with less noise.
+
+### Completeness
+
+- Missing prerequisites: if a command requires setup, the setup must be described or linked.
+- Gaps between what a feature does and what the docs say it does.
+- New CLI subcommands, MCP tools, or options not yet documented.
+
+### Link Integrity
+
+Check internal links (relative Markdown paths) and anchor links (`#heading-id`):
+
+- Verify that the target file exists at the referenced path.
+- Verify that named anchors (`#section-name`) match an actual heading in the target document.
+- Check that bidirectional navigation links exist where expected (e.g., a top-level README links
+  to a specialist doc, and that doc links back with `[Back to main README](...)`).
+
+### Duplication
+
+- If the same point is explained in multiple documents, decide which is the canonical location
+  and replace the others with a brief note and a link to it.
+- Do not duplicate content that is already maintained elsewhere — link instead.
+
+### Code Examples
+
+- Confirm that shell/CLI examples use current flag names and produce valid output.
+- For thorough validation of all runnable examples across the docs, use
+  [`dev/prompts/validate/test-documentation-examples.md`](../validate/test-documentation-examples.md).
+
+## Special Cases
+
+### MkDocs Include-Markdown Stubs
+
+Some files under `docs/` are intentional single-line stubs that use the MkDocs
+`include-markdown` plugin to pull in content from the repository root. Do **not**
+flag these as incomplete. See
+[`dev/prompts/guidelines/ai-code-evaluator-guidelines.md` — MkDocs Include-Markdown Stubs](../guidelines/ai-code-evaluator-guidelines.md#mkdocs-include-markdown-stubs)
+for the full explanation.
+
+## Actions to Take
+
+1. **Fix in place** — edit the doc file directly; no separate report is needed unless the scope
+   of changes warrants a summary.
+2. **Prefer linking over duplicating** — when the same information belongs in two places, keep
+   the authoritative copy and add a short cross-reference elsewhere.
+3. **Match existing tone** — keep edits consistent with the surrounding prose style.
+4. **Do not rewrite for rewriting's sake** — only change what is inaccurate, unclear, or missing.
+
+## Constraints
+
+- Do not alter code files unless a documented example is genuinely broken and a code fix is
+  clearly correct; prefer updating the docs to match current behaviour.
+- Do not run `git commit`. Stage only the documentation files you changed, and propose a concise
+  commit message describing what was corrected and why.

data/dev/prompts/review/comprehensive-codebase-review.md

@@ -174,3 +174,15 @@ Suggest prompts to a coding AI tool that would be helpful in addressing the majo
 - Report the final **Overall Weighted Score** with justification.
 
 ### Summarize suggested changes
+
+Provide a short, plain-prose recap of the most important changes—distinct from the Prioritized
+Issue List (which is a table) and the High-Level Recommendations (which are strategic). Group
+them by horizon:
+
+- **Immediate (blocking or high-risk):** Changes that should happen before the next release or
+  before onboarding new contributors.
+- **Near-term (1–2 sprints):** Improvements with clear ROI and moderate cost-to-fix.
+- **Longer-term (backlog):** Worthwhile but lower urgency; note any dependencies between items.
+
+Keep this section to 10–15 lines. Its purpose is a quick decision-making aid, not a full
+re-statement of everything above.

data/docs/user/ADVANCED_USAGE.md

@@ -3,9 +3,9 @@
 [Back to main README](../index.md)
 
 > Examples use `clp`, an alias pointed at the demo fixture with partial coverage:
-> 
-> `alias clp='cov-loupe -R docs/fixtures/demo_project' # (-R = --root_dir)`
-> 
+>
+> `alias clp='cov-loupe -R docs/fixtures/demo_project'`  # -R = --root
+>
 > Replace `clp` with `cov-loupe` if you want to target your own project/resultset.
 
 ## Table of Contents

data/docs/user/CLI_USAGE.md

@@ -39,7 +39,7 @@ clp raw app/models/order.rb
 
 # Get project totals
 clp totals
-clp -fJ totals
+clp -fp totals
 
 # Show version
 clp version
@@ -57,7 +57,7 @@ Show coverage summary for all files (default subcommand).
 ```sh
 clp list
 clp -o d list  # -o = --sort-order, d = descending
-clp -fJ list           
+clp -fp list           
 ```
 
 Default sort order is descending (highest coverage first) so the lowest-coverage files stay visible at the bottom of the scrollback.
@@ -69,7 +69,7 @@ Default sort order is descending (highest coverage first) so the lowest-coverage
 | `-o`    | `--sort-order`           | Sort by coverage percentage (ascending or descending) |
 | `-g`    | `--tracked-globs`        | Filter to specific file patterns                      |
 | `-S`    | `--raise-on-stale`       | Raise error if coverage is stale (default false)      |
-| `-fJ`   | `--format pretty-json`   | Output as pretty-printed JSON                         |
+| `-fp`   | `--format pretty-json`   | Output as pretty-printed JSON                         |
 | `-fj`   | `--format json`          | Output as single-line JSON                            |
 | `-f y`  | `--format yaml`          | Output as YAML                                        |
 | `-f ap` | `--format amazing_print` | Output using AmazingPrint                             |                             |
@@ -98,8 +98,8 @@ Show covered/total/percentage for a specific file.
 
 ```sh
 clp summary app/models/order.rb
-clp summary app/models/order.rb -fJ
-clp summary app/models/order.rb -s full  # -s = --source
+clp -fp summary app/models/order.rb
+clp -s full summary app/models/order.rb  # -s = --source
 ```
 
 **Arguments:**
@@ -109,7 +109,7 @@ clp summary app/models/order.rb -s full  # -s = --source
 
 | Short | Long             | Description                                |
 |-------|------------------|--------------------------------------------|
-| `-fJ` | `--format pretty-json` | Output as pretty-printed JSON         |
+| `-fp`   | `--format pretty-json` | Output as pretty-printed JSON         |
 | `-fj` | `--format json`        | Output as single-line JSON            |
 | `-f y` | `--format yaml`        | Output as YAML                        |
 | `-f ap` | `--format amazing_print` | Output using AmazingPrint                             |         |
@@ -143,8 +143,8 @@ Show uncovered line numbers for a specific file.
 
 ```sh
 clp uncovered app/controllers/orders_controller.rb
-clp uncovered app/controllers/orders_controller.rb -s uncovered  # -s = --source
-clp uncovered app/controllers/orders_controller.rb -s uncovered -c 3  # -c = --context-lines
+clp -s uncovered uncovered app/controllers/orders_controller.rb  # -s = --source
+clp -s uncovered -c 3 uncovered app/controllers/orders_controller.rb  # -s = --source, -c = --context-lines
 ```
 
 **Arguments:**
@@ -157,7 +157,7 @@ clp uncovered app/controllers/orders_controller.rb -s uncovered -c 3  # -c = --c
 | `-s`    | `--source uncovered`     | Show uncovered lines with context                    |
 | `-c`    | `--context-lines N`      | Lines of context around uncovered lines (default: 2) |
 | `-C`    | `--color BOOLEAN`        | Enable (`true`)/disable (`false`) syntax coloring    |
-| `-fJ`   | `--format pretty-json`   | Output as pretty-printed JSON                        |
+| `-fp`   | `--format pretty-json`   | Output as pretty-printed JSON                        |
 | `-fj`   | `--format json`          | Output as single-line JSON                           |
 | `-f y`  | `--format yaml`          | Output as YAML                                       |
 | `-f ap` | `--format amazing_print` | Output using AmazingPrint                             |                            |
@@ -197,8 +197,8 @@ Show per-line coverage with hit counts.
 
 ```sh
 clp detailed app/models/order.rb
-clp detailed app/models/order.rb -fJ
-clp detailed app/models/order.rb -s full  # -s = --source
+clp -fp detailed app/models/order.rb
+clp -s full detailed app/models/order.rb  # -s = --source
 ```
 
 **Arguments:**
@@ -208,7 +208,7 @@ clp detailed app/models/order.rb -s full  # -s = --source
 
 | Short   | Long                     | Description                   |
 |---------|--------------------------|-------------------------------|
-| `-fJ`   | `--format pretty-json`   | Output as pretty-printed JSON |
+| `-fp`   | `--format pretty-json`   | Output as pretty-printed JSON |
 | `-fj`   | `--format json`          | Output as single-line JSON    |
 | `-f y`  | `--format yaml`          | Output as YAML                |
 | `-f ap` | `--format amazing_print` | Output using AmazingPrint                             |     |
@@ -260,7 +260,7 @@ Show the raw SimpleCov lines array.
 
 ```sh
 clp raw app/models/order.rb
-clp raw app/models/order.rb -fJ
+clp -fp raw app/models/order.rb
 ```
 
 **Arguments:**
@@ -292,7 +292,7 @@ Show aggregated totals for all tracked files.
 
 ```sh
 clp totals
-clp -fJ totals
+clp -fp totals
 clp -g "lib/ops/jobs/*.rb" totals  # -g = --tracked-globs
 ```
 
@@ -372,7 +372,7 @@ Show version information.
 
 ```sh
 clp version
-clp -fJ version
+clp -fp version
 ```
 
 **Output:**
@@ -398,12 +398,12 @@ Project root directory (default: current directory).
 clp -R /path/to/project  # -R = --root
 ```
 
-### `-fJ`
+### `-fp`
 
 Output as pretty-printed JSON instead of human-readable format.
 
 ```sh
-clp summary lib/api/client.rb -fJ
+clp -fp summary lib/api/client.rb
 ```
 
 Useful for:
@@ -478,8 +478,8 @@ clp --raise-on-stale yes    # enforce stale coverage failures
 Enable or disable ANSI color codes in source output. Requires an explicit boolean value.
 
 ```sh
-clp uncovered lib/api/client.rb -s uncovered --color true
-clp uncovered lib/api/client.rb -s uncovered -C false
+clp -s uncovered --color true uncovered lib/api/client.rb
+clp -s uncovered -C false uncovered lib/api/client.rb
 ```
 
 **Default:** Colors enabled if output is a TTY
@@ -549,7 +549,7 @@ clp -g "lib/api/**/*.rb" list
 clp -g "lib/**/*.rb,app/models/**/*.rb" list
 
 # Export for CI (with globs to match SimpleCov)
-clp -g "lib/**/*.rb,app/**/*.rb" -fJ list > coverage.json
+clp -g "lib/**/*.rb,app/**/*.rb" -fp list > coverage.json
 ```
 
 **Use cases:**
@@ -754,17 +754,17 @@ Default command-line options applied to all invocations.
 **Format:** Shell-style string containing any valid CLI options
 
 ```sh
-export COV_LOUPE_OPTS="--resultset coverage -fJ"
+export COV_LOUPE_OPTS="--resultset coverage -fp"
 clp summary lib/api/client.rb  # Automatically uses options above
 ```
 
 **Precedence:** Command-line arguments override environment options
 
 ```sh
-# Environment sets -fJ; explicit CLI options still take precedence
-export COV_LOUPE_OPTS="-fJ"
+# Environment sets -fp; explicit CLI options still take precedence
+export COV_LOUPE_OPTS="-fp"
 clp summary lib/api/client.rb  # Uses JSON (from env)
-clp summary lib/api/client.rb -f table  # Explicit override to table format
+clp -f table summary lib/api/client.rb  # Explicit override to table format
 ```
 
 **Examples:**
@@ -779,7 +779,7 @@ export COV_LOUPE_OPTS="--error-mode debug"
 export COV_LOUPE_OPTS='-r "/path with spaces/coverage"'
 
 # Multiple options
-export COV_LOUPE_OPTS="-r coverage -S -fJ"
+export COV_LOUPE_OPTS="-r coverage -S -fp"
 ```
 
 
@@ -806,7 +806,7 @@ clp summary lib/payments/refund_service.rb
 clp uncovered lib/payments/refund_service.rb
 
 # View uncovered code in context
-clp uncovered lib/payments/refund_service.rb -s uncovered -c 3
+clp -s uncovered -c 3 uncovered lib/payments/refund_service.rb
 
 # Get detailed hit counts
 clp detailed lib/payments/refund_service.rb
@@ -816,31 +816,31 @@ clp detailed lib/payments/refund_service.rb
 
 ```sh
 # Get JSON for parsing
-clp -fJ list > coverage.json
+clp -fp list > coverage.json
 
 # Extract files below threshold
-clp -fJ list | jq '.files[] | select(.percentage < 80)'
+clp -fp list | jq '.files[] | select(.percentage < 80)'
 
 # Ruby alternative:
-clp -fJ list | ruby -r json -e '
+clp -fp list | ruby -r json -e '
   JSON.parse($stdin.read)["files"].select { |f| f["percentage"] < 80 }.each do |f|
     puts JSON.pretty_generate(f)
   end
 '
 
 # Rexe alternative:
-clp -fJ list | rexe -ij -mb -oJ 'self["files"].select { |f| f["percentage"] < 80 }'
+clp -fp list | rexe -ij -mb -oJ 'self["files"].select { |f| f["percentage"] < 80 }'
 
 # Count files below 80% coverage
-clp -fJ list | jq '[.files[] | select(.percentage < 80)] | length'
+clp -fp list | jq '[.files[] | select(.percentage < 80)] | length'
 
 # Ruby alternative:
-clp -fJ list | ruby -r json -e '
+clp -fp list | ruby -r json -e '
   puts JSON.parse($stdin.read)["files"].count { |f| f["percentage"] < 80 }
 '
 
 # Rexe alternative:
-clp -fJ list | rexe -ij -mb -op 'self["files"].count { |f| f["percentage"] < 80 }'
+clp -fp list | rexe -ij -mb -op 'self["files"].count { |f| f["percentage"] < 80 }'
 ```
 
 ### Filtering and Sorting
@@ -875,16 +875,16 @@ clp list  # Stale column shows missing/newer/length_mismatch/error markers
 
 ```sh
 # Show full source with coverage markers
-clp summary lib/api/client.rb -s full
+clp -s full summary lib/api/client.rb
 
 # Show only uncovered lines with context
-clp uncovered lib/api/client.rb -s uncovered
+clp -s uncovered uncovered lib/api/client.rb
 
 # More context around uncovered code
-clp uncovered lib/api/client.rb -s uncovered -c 5
+clp -s uncovered -c 5 uncovered lib/api/client.rb
 
 # Without colors (for logging)
-clp uncovered lib/api/client.rb -s full --color false
+clp -s full --color false uncovered lib/api/client.rb
 ```
 
 ### CI/CD Integration
@@ -894,7 +894,7 @@ clp uncovered lib/api/client.rb -s full --color false
 clp -S true || exit 1
 
 # Generate JSON report for artifact
-clp -fJ list > artifacts/coverage-report.json
+clp -fp list > artifacts/coverage-report.json
 
 # Check specific directory in monorepo
 clp -R services/api -r services/api/coverage  # -R = --root, -r = --resultset

data/docs/user/INSTALLATION.md

@@ -29,6 +29,10 @@ Then run:
 bundle install
 ```
 
+### Prerelease Versions
+
+See [Installing a Prerelease](installing-a-prelease-version-of-covloupe.md) for instructions on installing prerelease versions.
+
 ### From Source
 
 ```sh

data/docs/user/MCP_INTEGRATION.md

@@ -374,7 +374,7 @@ cov-loupe version   # Test basic functionality
 
 **JSON-RPC Parse Errors**
 - Ensure JSON is on a single line (no newlines)
-- Test manually: `echo '{"jsonrpc":"2.0",...}' | cov-loupe`
+- Test manually: `echo '{"jsonrpc":"2.0",...}' | cov-loupe -m mcp`
 
 ## Advanced Configuration
 

data/docs/user/TROUBLESHOOTING.md

@@ -100,7 +100,7 @@ when merging resultsets.
 
 2. **Test MCP server mode manually:**
    ```bash
-   echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"version_tool","arguments":{}}}' | cov-loupe
+   echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"version_tool","arguments":{}}}' | cov-loupe -m mcp
    ```
    Should return JSON-RPC response.
 
@@ -183,7 +183,7 @@ ls -la coverage/.resultset.json
 head -20 coverage/.resultset.json
 
 # Test MCP mode
-echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"version_tool","arguments":{}}}' | cov-loupe 2>&1
+echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"version_tool","arguments":{}}}' | cov-loupe -m mcp 2>&1
 ```
 
 ## Getting More Help

data/docs/user/migrations/MIGRATING_TO_V2.md

@@ -111,7 +111,7 @@ simplecov-mcp --source uncovered summary lib/foo.rb
 
 ### --json Replaced with --format
 
-**Change:** The `--json` flag (and related `-j`, `-J`, `--pretty-json` flags) have been removed. Use `-f/--format` instead.
+**Change:** The `--json` flag (and related `-j`, `--pretty-json` flags) have been removed. Use `-f/--format` instead.
 
 **Rationale:** Supports multiple output formats beyond JSON (YAML, awesome_print, etc.) with a consistent interface.
 

data/docs/user/prompts/README.md

@@ -4,6 +4,5 @@
 
 Starter prompts you can paste into MCP-compatible assistants when you need cov-loupe to run targeted reports or fall back to CLI execution.
 
-- [Rails Coverage Analysis](rails-coverage-analysis-prompt.md) – Guide an assistant through triaging a Rails `.resultset.json`
-- [Non-Web Coverage Analysis](non-web-coverage-analysis-prompt.md) – Prompts for service/library repos
-- [Use CLI Instead of MCP](use-cli-not-mcp-prompt.md) – Scripted fallback when MCP transport is blocked
+- [Coverage Analysis](coverage-analysis-prompt.md) – Analyze coverage for any Ruby project; adapts component categories to the framework in use (Rails example included)
+- [Use CLI Instead of MCP](use-cli-not-mcp-prompt.md) – Include in another prompt to instruct the model to use cov-loupe CLI as a fallback when MCP transport is blocked or unavailable

data/docs/user/prompts/coverage-analysis-prompt.md

@@ -0,0 +1,118 @@
+# Test Coverage Analysis Prompt for Ruby Projects
+
+[Back to main README](../../index.md)
+
+Use the cov-loupe MCP server tool to analyze the test coverage data generated by simplecov for this Ruby project. Generate a detailed coverage analysis report and output it to a markdown file named `test_coverage_analysis.md`.
+
+**Before diving into the sections below**, identify the project type by examining the Gemfile, directory structure, and file-naming conventions (e.g., Rails app, CLI tool, service library, microservice). Adapt the component categories in sections 2 and 6 to match what is actually present — the Rails-specific names used as examples throughout are illustrative, not prescriptive.
+
+The report should include:
+
+## 1. Executive Summary
+- Overall coverage percentage and trend direction
+- High-level assessment of testing health across the application
+- Key strengths and critical gaps at a glance
+
+## 2. Coverage by Application Component
+Detailed analysis of coverage across the application layers that are present in this project.
+
+For a **Rails app** these are typically: Models, Controllers, Views, Mailers, Jobs, Services/POROs, Concerns, Lib files, Configuration.
+
+For a **non-web Ruby app** these are typically: Core Domain Logic, Services/Commands, Data Access Layer, External Integrations, Utilities/Helpers, CLI Components, Configuration, Lib files, Concerns/Mixins.
+
+Adapt this list to the actual project — drop categories that don't exist, add any that do.
+
+## 3. Well-Tested Areas
+- What's working well and why
+- Testing patterns and practices to replicate
+- Examples of strong test coverage with specific file references
+
+## 4. Poorly-Tested Areas
+Organize by:
+- **Complexity to Test**: Simple/Moderate/Complex (considering dependencies, I/O operations, external services, etc.)
+- **Risk Level**: High/Medium/Low (impact on data integrity, system reliability, business logic correctness)
+- **Coverage Gap Size**: Percentage of uncovered lines and number of untested methods
+
+## 5. Priority Issues Table
+Create a markdown table with these columns:
+- File/Module Path
+- Component Type (Model/Service/Domain/Integration/etc.)
+- Current Coverage %
+- Uncovered Lines Count
+- Risk Level (High/Medium/Low)
+- Complexity to Fix (High/Medium/Low)
+- Priority Score (1-10, with 10 being highest priority)
+- Recommended Action (specific next steps)
+
+Sort by Priority Score descending.
+
+## 6. Framework-Specific Testing Analysis
+Cover the topics that apply to this project. For a **Rails app**:
+- **Model Testing**: Validations, associations, scopes, callbacks, custom methods
+- **Controller Testing**: Happy paths vs error handling, authentication/authorization
+- **Integration Testing**: Request specs, feature specs, system tests
+- **API Testing**: JSON/XML responses, API versioning
+- **Database Operations**: Migrations, seeds, complex queries
+- **Background Jobs**: Execution, retry logic, error handling
+- **Security**: Authentication, authorization, input sanitization, CSRF protection
+- **Missing Test Types**: Unit/integration/system/feature test gaps
+
+For a **non-web Ruby app**, focus instead on:
+- **Domain Logic Testing**: Business rules, validations, calculations, state transitions
+- **Service Layer Testing**: Orchestration logic, error handling, transaction boundaries
+- **Data Access Testing**: Queries, data transformations, persistence operations
+- **Integration Testing**: Interactions between components and external systems
+- **API Client Testing**: HTTP requests, response parsing, error handling
+- **File I/O Operations**: Reading/writing, parsing, serialization
+- **Concurrency/Threading**: Thread-safe operations and race conditions (if applicable)
+- **Error Handling**: Exception handling, retry logic, fallback mechanisms
+
+Include the security and missing-test-types bullets regardless of project type.
+
+## 7. Common Testing Anti-Patterns Detected
+Report only those actually observed:
+- Unnecessary verbosity — identical or near-identical code fragments that should be deduplicated using input arrays, extracted methods, shared examples, etc.
+- Over-reliance on controller tests vs request specs (Rails)
+- Over-mocking leading to brittle tests
+- Missing edge case coverage in core domain / model logic
+- Untested error handling and failure scenarios
+- Missing tests for background jobs and mailers (Rails)
+- Missing tests for external service integrations
+- Lack of integration tests for critical user flows / workflows
+- Untested authorization/permission logic
+- Untested concurrency or threading logic (if applicable)
+- Insufficient testing of data transformation pipelines
+- Missing tests for CLI argument parsing and validation (if applicable)
+
+## 8. Actionable Testing Roadmap
+Prioritized list of specific issues to resolve, organized by effort level:
+- **Quick Wins** (< 2 hours): Simple tests with high impact
+- **Sprint 1** (2-8 hours): Medium complexity, high priority
+- **Sprint 2** (1-2 days): Complex but critical coverage gaps
+- **Long-term** (> 2 days): Large refactoring or architectural test improvements
+
+Also flag testing infrastructure issues — inadequate fixtures, missing helpers, or code patterns that make tests brittle — and place them in the Long-term bucket.
+
+Include specific file paths, method names, and recommended testing approaches for each item.
+
+## 9. Metrics Dashboard
+Key numbers:
+- Overall coverage percentage
+- Number of files at 0% coverage
+- Number of files at 100% coverage
+- Number of files above 90% coverage
+- Number of files below 50% coverage
+- Coverage by component type (adapted to project)
+- Trend direction (if historical data available)
+- Lines of code vs lines of test code ratio
+- Average cyclomatic complexity of untested methods (if available)
+
+## 10. Risk Assessment
+- **Critical Paths**: Identify core user journeys / business workflows and their test coverage
+- **High-Risk Untested Code**: Payment processing, authentication, data deletion, financial calculations, etc.
+- **Security Implications**: Areas where lack of tests could lead to vulnerabilities
+- **Technical Debt**: Old code with no tests that should be prioritized for coverage
+- **External Dependencies**: Integration points with poor test coverage
+- **Data Integrity Risks**: Operations that modify or delete data without adequate test coverage
+
+Include specific file paths, line numbers, and code examples where relevant. Focus on actionable insights rather than just reporting numbers. Provide concrete recommendations for improving the test suite architecture and coverage strategy.