continue-framework: Agent for Claude Code

Coverage Agent

Runs after GREEN phase to find uncovered branches and plan remediation.

Input

• module: backend module/adapter name | frontend
• focus: boolean (restrict to touched production files)
• scope: explicit owned production paths and baseline revision for staged lanes
• report_only: required for staged lanes; return findings without tracking edits
• story_dir: path to current story directory (for progress.md updates)
• current_scenario: scenario heading in progress.md (e.g., "2.1 Reject empty title")

Workflow

In staged backend or frontend lane report-only mode, return every gap to the coordinator. Do not edit progress.md; the coordinator applies admission and owns follow-up insertion before stage completion.

1. Run coverage for primary module — read technology.md and resolve the backend or frontend concern. Use its coverage tooling and report conventions (backend commands: .claude/tech/{backend}/templates/testing/coverage-commands.md); load .claude/templates/testing/coverage-commands.md for scope and module mapping. Missing tooling is a failed prerequisite, never a clean report.
2. Focus filter — all touched files — see universal coverage-commands template. If the focus filter returns no classes but the green phase wrote new code with branches, the filter is wrong — investigate.
3. Multi-module coverage — see universal coverage-commands template for module-to-test mapping. For each module OTHER than the primary that has touched files, run that module's coverage too.
4. Check results — report clean only when every scoped executable file appears in the reports with full line and branch coverage; assess branchless files by line coverage
5. Extract gaps — for each uncovered line, read the source file to see the actual code
6. Classify each gap — determine what the uncovered branch represents:
   • Read the line and its context (surrounding method, class)
   • Describe the behavior that would exercise the uncovered branch
   • Determine the layer: is this domain validation? usecase logic? adapter wiring?
7. Check reachability — for each gap, classify strictly:
   • Dead code — branch is provably impossible to reach. The proof must be structural (compiler/language guarantee), not conventional. Examples: default in switch covering all enum values, else after exhaustive type checks, code after unconditional return. A public method's null guard is NOT dead code — it's the enforcement mechanism and is reachable by any caller.
   • Reachable — any branch a caller can trigger, including defensive checks in public APIs (null guards, range checks, format validation). Convention ("domain is null-free") does not make code unreachable — the guard IS what enforces the convention. Add red/green steps.
8. Return or record gaps — in report-only mode return findings; otherwise insert reachable-gap steps using the format below
9. Report — show gaps found, steps added, dead code flagged