Repository Quality Improvement Report – Untested Large Files (2026-02-24)

[github-actions[bot]]

🎯 Repository Quality Improvement Report – Untested Large Files

Analysis Date: 2026-02-24
Focus Area: Untested Large Files (Custom)
Strategy Type: Custom — first run, no history; invented a repository-specific focus area
Custom Area: Yes — with 564 source files and a 2.32× test-to-source ratio the overall test posture is impressive, but a cluster of large files (>500 lines) in the hot pkg/cli and pkg/workflow packages entirely lack test companions. These files contain business-critical logic (cache management, MCP configuration, compilation orchestration, log rendering) and represent the highest-risk untested surface area in the codebase.

Executive Summary

Analysis of all Go source files revealed 68 files exceeding 500 lines and 159 files exceeding the 300-line target stated in AGENTS.md. Of the largest files, 11 files over 500 lines have no _test.go companion — 6 in pkg/cli and 5 in pkg/workflow. Combined they represent over 6,600 lines of untested code in packages that are central to the tool's core value proposition.

The most critical gaps are pkg/workflow/cache.go (871 lines, manages cache-memory persistence), pkg/workflow/mcp_config_custom.go (767 lines, renders MCP server configuration), pkg/workflow/tools_parser.go (596 lines, parses all tool frontmatter), and pkg/cli/logs_metrics.go (740 lines, processes workflow log metrics). All four are heavily depended-upon by other tested modules, making regression risk high.

Full Analysis Report

Focus Area: Untested Large Files

Current State Assessment

Metrics Collected:

Metric	Value	Status
Total source files	564	✅
Total test files	972	✅
Test-to-source line ratio	2.32×	✅
Files >300 lines (AGENTS.md target)	159	⚠️
Files >500 lines	68	⚠️
Large files (>500 lines) WITHOUT test companion	11	❌
Untested lines of code in large files	~6,600	❌

Untested large files (>500 lines):

File	Lines	Functions
pkg/workflow/cache.go	871	~12
pkg/cli/logs_metrics.go	740	7
pkg/workflow/mcp_config_custom.go	767	~8
pkg/workflow/tools_parser.go	596	14
pkg/workflow/compiler_types.go	576	~6
pkg/workflow/claude_logs.go	543	~6
pkg/cli/audit_report_render.go	611	14
pkg/cli/trial_repository.go	567	8
pkg/cli/update_workflows.go	569	10
pkg/cli/mcp_inspect_mcp.go	609	10
pkg/cli/compile_orchestration.go	513	8

Findings

Strengths

• Exceptional overall test ratio (2.32× test-to-source lines) — among the highest seen in Go codebases
• The largest files with complex logic (compiler_activation_jobs.go 1038 lines, frontmatter_types.go 851 lines) all have test companions
• pkg/workflow/cache.go and pkg/workflow/tools_parser.go are extensively exercised indirectly through integration-style compiler tests

Areas for Improvement

• pkg/workflow/cache.go (871 lines) — HIGH risk: manages all cache-memory persistence; no direct unit tests for individual cache strategies, key generation, or retention logic
• pkg/workflow/mcp_config_custom.go (767 lines) — HIGH risk: custom MCP rendering for Claude/Codex engines; brittle JSON template logic with no isolated tests
• pkg/workflow/tools_parser.go (596 lines) — MEDIUM risk: 14 parse functions; edge cases in parseBashTool, parsePlaywrightTool, parseMCPServerConfig are untested
• pkg/cli/logs_metrics.go (740 lines) — MEDIUM risk: metrics aggregation logic for log analysis; 7 large functions with no tests
• pkg/cli/audit_report_render.go (611 lines) — LOW risk: rendering-only, but 14 functions with complex conditional logic

---

🤖 Tasks for Copilot Agent

NOTE TO PLANNER AGENT: The following 5 tasks are designed for GitHub Copilot coding agent execution. Each task is self-contained and can be processed independently. Please split these into individual work items for Claude to process sequentially or in priority order.

---

Task 1: Add unit tests for pkg/workflow/cache.go

Priority: High
Estimated Effort: Medium
Focus Area: Untested Large Files

Description:
pkg/workflow/cache.go (871 lines) is the core module for cache-memory functionality — it manages CacheMemoryConfig, individual CacheMemoryEntry objects, key generation, artifact scoping, restore-only modes, and retention days logic. There is no cache_test.go. Because cache configuration feeds directly into GitHub Actions YAML generation, regressions here affect all workflows that use cache-memory:.

Acceptance Criteria:

• Create pkg/workflow/cache_test.go with //go:build !integration tag
• Test CacheMemoryConfig parsing from frontmatter YAML (ParseCacheMemoryConfig or equivalent entry point)
• Test cache key generation with and without custom keys, with workflow-scope vs repo-scope
• Test AllowedExtensions defaults and overrides
• Test RetentionDays boundary values (nil, 0, 90, max)
• Test RestoreOnly flag propagation
• Pass make test-unit and make lint

Code Region: pkg/workflow/cache.go

In the file `pkg/workflow/cache.go`, analyze all exported and package-level functions and types.
Create a new file `pkg/workflow/cache_test.go` with comprehensive unit tests.

Requirements:
1. Add `//go:build !integration` as the first line
2. Use table-driven tests with `t.Run()` and descriptive names
3. Use `require.*` for setup assertions, `assert.*` for validations
4. Test all exported functions; cover normal, edge case, and invalid input paths
5. Run `make fmt` and `make lint` to ensure the file passes all checks
6. Run `go test -v -run "Test" ./pkg/workflow/` scoped to cache-related tests to verify

Focus especially on:
- CacheMemoryConfig struct initialization and defaults
- Cache key generation logic
- AllowedExtensions default population
- RetentionDays nil vs zero vs positive value handling
- Scope field ("workflow" vs "repo") defaulting behavior

---

Task 2: Add unit tests for pkg/workflow/tools_parser.go

Priority: High
Estimated Effort: Medium
Focus Area: Untested Large Files

Description:
pkg/workflow/tools_parser.go (596 lines) contains 14 parsing functions that convert raw frontmatter map[string]any values into typed tool configuration structs (BashToolConfig, PlaywrightToolConfig, MCPServerConfig, etc.). These are called during every workflow compilation. Incorrect parsing silently drops tool configuration, resulting in broken workflows with no error.

Acceptance Criteria:

• Create pkg/workflow/tools_parser_test.go with //go:build !integration tag
• Test NewTools() with empty map, nil, and a map with all known tool keys
• Test parseGitHubTool() with valid toolsets, invalid toolsets, and mode values
• Test parseBashTool() with timeout, allowed-packages, and missing fields
• Test parsePlaywrightTool() with version, allowed_domains, and browser settings
• Test parseMCPServerConfig() with all server types (stdio, http, sse)
• Pass make test-unit and make lint

Code Region: pkg/workflow/tools_parser.go

In the file `pkg/workflow/tools_parser.go`, analyze all parse functions.
Create a new file `pkg/workflow/tools_parser_test.go` with comprehensive unit tests.

Requirements:
1. Add `//go:build !integration` as the first line
2. Use table-driven tests covering: valid complete input, partial/minimal input, nil/empty input, invalid values
3. For each `parseXxxTool` function, test that required fields are populated and optional fields default correctly
4. Test `NewTools()` with various combinations of known and unknown tool keys
5. Verify that unrecognized tool keys do not panic and are handled gracefully
6. Run `make fmt` and `make lint` after creating the file

---

Task 3: Add unit tests for pkg/workflow/mcp_config_custom.go

Priority: Medium
Estimated Effort: Medium
Focus Area: Untested Large Files

Description:
pkg/workflow/mcp_config_custom.go (767 lines) renders custom MCP server configuration for Claude and Codex engines using JSON template strings. The JSON generation is hand-constructed using fmt.Fprintf into a strings.Builder, making it susceptible to formatting errors (missing commas, incorrect nesting, invalid JSON) that would silently corrupt workflow YAML. No test file exists.

Acceptance Criteria:

• Create pkg/workflow/mcp_config_custom_test.go with //go:build !integration tag
• Test that rendered output is valid JSON (parse with encoding/json)
• Test renderCustomMCPConfigWrapper with stdio, http, and sse server types
• Test handling of missing optional fields (headers, env vars, args)
• Test the isLast parameter correctly controls trailing comma presence
• Pass make test-unit and make lint

Code Region: pkg/workflow/mcp_config_custom.go

In the file `pkg/workflow/mcp_config_custom.go`, analyze the MCP configuration rendering functions.
Create a new file `pkg/workflow/mcp_config_custom_test.go` with unit tests.

Requirements:
1. Add `//go:build !integration` as the first line
2. The most important invariant: rendered output must always be valid JSON — test this with `json.Valid()` or `json.Unmarshal()`
3. Test each MCP server type (stdio with command/args, http with url/headers, sse)
4. Test the comma-control logic (isLast=true produces no trailing comma, isLast=false does)
5. Test with empty/nil tool config map values
6. Run `make fmt` and `make lint` after creating the file

---

Task 4: Add unit tests for pkg/cli/logs_metrics.go

Priority: Medium
Estimated Effort: Small
Focus Area: Untested Large Files

Description:
pkg/cli/logs_metrics.go (740 lines, 7 functions) aggregates and summarizes workflow log metrics for the gh aw logs command — step durations, token counts, tool call frequencies, and cost estimates. These calculations are pure functions that transform log data into summary structs, making them ideal candidates for unit tests. Currently there is no logs_metrics_test.go.

Acceptance Criteria:

• Create pkg/cli/logs_metrics_test.go with //go:build !integration tag
• Test each metric aggregation function with synthetic log input data
• Test zero-value/empty input handling (no steps, no tool calls)
• Test boundary cases for duration and token count calculations
• Test that output structs have expected field values
• Pass make test-unit and make lint

Code Region: pkg/cli/logs_metrics.go

In the file `pkg/cli/logs_metrics.go`, analyze the metric aggregation functions.
Create a new file `pkg/cli/logs_metrics_test.go` with unit tests.

Requirements:
1. Add `//go:build !integration` as the first line
2. These functions transform log data to metrics — construct synthetic log structs as test inputs
3. Use table-driven tests for functions with multiple calculation paths
4. Test empty input (no steps, no tool calls, no tokens) to ensure no divide-by-zero or nil panics
5. Test with realistic values (e.g., 5 steps, 3 tool calls, known token counts) and verify calculated totals
6. Run `make fmt` and `make lint` after creating the file

---

Task 5: Add unit tests for pkg/cli/audit_report_render.go

Priority: Low
Estimated Effort: Small
Focus Area: Untested Large Files

Description:
pkg/cli/audit_report_render.go (611 lines, 14 functions) renders the audit report to the console using the console rendering system. While rendering logic is lower risk than data logic, 14 functions with conditional branches for different output formats (JSON vs. terminal, verbose vs. compact) benefit from smoke tests that ensure no panics on valid and edge-case inputs. The companion audit_report.go already has 1587 lines of tests that could be extended.

Acceptance Criteria:

• Create pkg/cli/audit_report_render_test.go with //go:build !integration tag (or extend audit_report_test.go)
• Test each render function with a minimal valid AuditReport struct
• Test with empty/nil fields to ensure graceful handling
• Test JSON output path and terminal output path produce non-empty results
• Pass make test-unit and make lint

Code Region: pkg/cli/audit_report_render.go

In the file `pkg/cli/audit_report_render.go`, analyze the rendering functions.
Either create a new file `pkg/cli/audit_report_render_test.go` or add to the existing `pkg/cli/audit_report_test.go`.

Requirements:
1. If creating a new file: add `//go:build !integration` as the first line
2. Construct a minimal valid `AuditReport` (or equivalent) struct as test fixture
3. Call each render function and verify: no panic, non-empty output for non-empty input
4. Test the JSON output path separately from the terminal output path
5. Test nil/zero-value struct to confirm graceful degradation
6. Run `make fmt` and `make lint` after making changes

---

📊 Historical Context

Previous Focus Areas

Date	Focus Area	Type	Custom	Key Outcomes
2026-02-24	Untested Large Files	First run	Yes	Identified 11 large files (>500 lines) with no test companion; ~6,600 untested lines

---

🎯 Recommendations

Immediate Actions (This Week)

1. Add tests for pkg/workflow/cache.go — Priority: High (cache key regression risk)
2. Add tests for pkg/workflow/tools_parser.go — Priority: High (silent tool config drops)

Short-term Actions (This Month)

1. Add tests for pkg/workflow/mcp_config_custom.go — Priority: Medium (JSON validity)
2. Add tests for pkg/cli/logs_metrics.go — Priority: Medium (pure calculation functions)

Long-term Actions (This Quarter)

1. Add smoke tests for pkg/cli/audit_report_render.go — Priority: Low
2. Review remaining untested files: pkg/workflow/compiler_types.go, pkg/workflow/claude_logs.go, pkg/cli/trial_repository.go, pkg/cli/update_workflows.go, pkg/cli/mcp_inspect_mcp.go, pkg/cli/compile_orchestration.go

---

📈 Success Metrics

Track these metrics to measure improvement in Untested Large Files:

• Untested large files (>500 lines): 11 → 0
• Test-to-source line ratio: 2.32× → 2.50×
• Files >300 lines without tests: ~15 → <5

---

Next Steps

1. Review and prioritize the 5 tasks above
2. Assign Tasks 1 & 2 to Copilot coding agent via planner agent (highest risk reduction)
3. Track which files gain test coverage over the next sprint
4. Re-evaluate this focus area in 30 days

---

References:

• §22353200612

AI generated by Repository Quality Improvement Agent

• expires on Feb 25, 2026, 1:42 PM UTC