[repository-quality] Repository Quality Improvement Report - Large File Refactoring & Maintainability (2026-05-20)

[github-actions[bot]]

🎯 Repository Quality Improvement Report - Large File Refactoring & Maintainability

Analysis Date: 2026-05-20
Focus Area: Large File Refactoring & Maintainability
Strategy Type: Custom
Custom Area: Yes — tailored to gh-aw's specific challenge of maintaining several 1000+ line source files

Executive Summary

This analysis reveals that gh-aw has 29 source files exceeding 800 lines, with the largest at 1,191 lines. While the codebase demonstrates excellent test coverage (2:1 test-to-source ratio) and low technical debt (only 17 TODO/FIXME comments), the large file sizes create maintainability challenges:

1. Cognitive Load: Files like frontmatter_extraction_yaml.go (1,191 lines, 155 if-statements) and import_field_extractor.go (1,172 lines, 164 if-statements, 22 for-loops) require significant mental overhead to understand and modify.

2. Inconsistent Test Coverage: While audit.go has excellent 1:1 test coverage, frontmatter_extraction_yaml.go has only 4% test coverage (53 test lines vs 1,191 source lines), suggesting complexity barriers to testing.

3. Validation Guideline Violations: Nine validation files exceed the documented 300-line hard limit (from scratchpad/validation-refactoring.md), with safe_outputs_validation_config.go at 452 lines and permissions_validation.go at 388 lines.

4. Hidden Modularity Opportunities: The codebase shows natural clustering — 106 compiler-related files, 34 audit-related files, 82 safe-output files — but individual files within these clusters remain monolithic.

This report identifies five high-impact refactoring tasks that will reduce cognitive complexity, improve testability, and align with documented architecture guidelines.

Full Analysis Report

Focus Area: Large File Refactoring & Maintainability

Current State Assessment

Metrics Collected:

Metric	Value	Status
Files > 800 lines	29 files	⚠️ High
Files > 1000 lines	15 files	⚠️ Concerning
Largest file	1,191 lines (frontmatter_extraction_yaml.go)	❌ Critical
Validation files > 300 lines	9 files	❌ Violates guidelines
Average comment ratio (top 5 files)	19.8%	✅ Good
Test coverage (overall)	2.07:1 test-to-source	✅ Excellent
Test coverage (largest file)	0.04:1	❌ Insufficient
File churn (3 months)	1 commit/file average	✅ Stable

Findings

Strengths

• Excellent overall test coverage: 409,624 test LOC vs 197,583 source LOC (2.07:1 ratio)
• Natural modularity patterns: Files are well-organized into cohesive groups (compiler, audit, safe-outputs)
• Low churn rate: Large files average only 1 commit in the last 3 months, indicating stability
• Good documentation: 17-33% comment ratios in major files
• Clean codebase: Only 17 TODO/FIXME comments across entire repository

Areas for Improvement

1. Monolithic frontmatter extraction (Priority: High)

   • frontmatter_extraction_yaml.go: 1,191 lines with 14 functions averaging 85 lines each
   • Contains a 600-line function (commentOutProcessedFieldsInOnSection)
   • Only 4% test coverage despite high complexity (155 if-statements)
   • Mixes YAML manipulation, validation, and business logic

2. Oversized import processing (Priority: High)

   • import_field_extractor.go: 1,172 lines with high cyclomatic complexity (164 if-statements, 22 for-loops, 6 switch-statements)
   • Better test coverage (54%) but still challenging to extend
   • Multiple responsibilities: import resolution, schema validation, observability config

3. Validation guideline violations (Priority: High)

   • Nine files exceed the 300-line hard limit documented in scratchpad/validation-refactoring.md
   • safe_outputs_validation_config.go: 452 lines (150% over limit)
   • permissions_validation.go: 388 lines (129% over limit)
   • engine_validation.go: 429 lines (143% over limit)

4. Large CLI commands (Priority: Medium)

   • forecast.go: 1,142 lines with 28 functions (too many responsibilities)
   • audit.go: 1,132 lines with 452-line AuditWorkflowRun function
   • Both mix command setup, business logic, and rendering

5. Compiler component sprawl (Priority: Medium)

   • 106 compiler-related files in pkg/workflow without internal package structure
   • compiler_yaml_main_job.go: 1,089 lines (30 for-loops, 68 if-statements)
   • Difficult to understand compiler architecture without navigating many files

Detailed Analysis

File Size Distribution

1100+ lines: 5 files (critical refactoring candidates)
900-1099 lines: 10 files (should be reviewed)
800-899 lines: 14 files (acceptable but monitor)

Complexity Indicators

High Complexity Files (complexity = if + for + switch statements):

1. frontmatter_extraction_yaml.go: 171 control flow statements, 600-line function
2. import_field_extractor.go: 192 control flow statements, 124-line function
3. audit.go: 140 control flow statements, 452-line function
4. compiler_yaml_main_job.go: 98 control flow statements, 32.9% comment ratio (good)
5. forecast.go: 121 control flow statements, 28 functions (high function count)

Test Coverage Gaps

Files with test-to-source ratio < 0.5:

• frontmatter_extraction_yaml.go: 0.04 (critical)
• forecast.go: 0.10 (needs improvement)

Root cause: Complex monolithic files are harder to test in isolation.

Validation Architecture Compliance

From scratchpad/validation-refactoring.md:

• Target size: 100-200 lines
• Hard limit: 300 lines
• When to split: File > 300 lines OR contains 2+ unrelated domains

Current violations: 9 files exceed hard limit, with worst offenders at 452, 429, and 388 lines.

---

🤖 Tasks for Copilot Agent

NOTE TO PLANNER AGENT: Split the following tasks into individual work items.

Improvement Tasks

Task 1: Split frontmatter_extraction_yaml.go into Focused Modules

Priority: High
Estimated Effort: Large
Focus Area: Large File Refactoring & Maintainability

Description: Refactor pkg/workflow/frontmatter_extraction_yaml.go (1,191 lines) into smaller, testable modules. The file currently mixes YAML comment manipulation, condition extraction, and GitHub-specific field handling. The 600-line commentOutProcessedFieldsInOnSection function is a major complexity hotspot.

Acceptance Criteria:

• Extract YAML comment utilities into pkg/workflow/frontmatter_yaml_comments.go (~300 lines)
• Move condition extraction logic to pkg/workflow/frontmatter_conditions.go (~200 lines)
• Move GitHub App field handling to pkg/workflow/frontmatter_github_fields.go (~150 lines)
• Refactor 600-line function into 3-5 smaller functions (<150 lines each)
• Increase test coverage from 4% to at least 50% (add ~500 test lines)
• Maintain all existing functionality (run make test-unit to verify)
• Follow naming convention: frontmatter_{subdomain}.go

Code Region: pkg/workflow/frontmatter_extraction_yaml.go

Refactor `pkg/workflow/frontmatter_extraction_yaml.go` (1,191 lines, currently 4% test coverage) into focused modules:

1. **Analysis Phase**:
   - Review the file to identify logical groupings of functions
   - Map dependencies between functions to determine extraction order
   - Identify the responsibilities of the 600-line `commentOutProcessedFieldsInOnSection` function

2. **Extraction Phase**:
   - Create `pkg/workflow/frontmatter_yaml_comments.go` for YAML comment manipulation utilities
   - Create `pkg/workflow/frontmatter_conditions.go` for condition extraction (deployment_status, workflow_run, etc.)
   - Create `pkg/workflow/frontmatter_github_fields.go` for GitHub App field validation
   - Keep core orchestration in the original file (rename to `pkg/workflow/frontmatter_extraction.go`)

3. **Function Refactoring**:
   - Split `commentOutProcessedFieldsInOnSection` (600 lines) into:
     - `identifyProcessedFields` (~100 lines) - identify which fields to comment
     - `commentYAMLSection` (~150 lines) - apply comments to YAML
     - `preserveYAMLStructure` (~100 lines) - maintain formatting
   - Ensure each function has a single, clear responsibility

4. **Testing Phase**:
   - Add unit tests for each new module (target: 50% coverage minimum)
   - Focus on edge cases for YAML comment handling
   - Add table-driven tests for condition extraction
   - Ensure integration tests pass (`make test-unit`)

5. **Validation**:
   - Run `make build && make fmt` after first refactoring
   - Run `make agent-report-progress` before committing
   - Verify no regression in existing tests
   - Check that error messages remain actionable

**Success criteria**: Original file reduced to <400 lines, test coverage >50%, all tests passing, no functionality changes.

---

Task 2: Refactor Validation Files to Comply with 300-Line Guideline

Priority: High
Estimated Effort: Large
Focus Area: Large File Refactoring & Maintainability

Description: Nine validation files violate the documented 300-line hard limit from scratchpad/validation-refactoring.md. The worst offenders are safe_outputs_validation_config.go (452 lines, 150% over), engine_validation.go (429 lines, 143% over), and permissions_validation.go (388 lines, 129% over). Refactor these files following the documented decision tree and naming conventions.

Acceptance Criteria:

• All validation files comply with 300-line hard limit
• Follow naming pattern: {domain}_{subdomain}_validation.go
• Maintain minimum 30% comment coverage per file
• Create separate test files with integration tests for complex validators
• Update scratchpad/validation-refactoring.md with new file references
• All validation tests pass (go test -v ./pkg/workflow/*validation*)

Code Region: pkg/workflow/safe_outputs_validation_config.go, pkg/workflow/engine_validation.go, pkg/workflow/permissions_validation.go, pkg/workflow/agent_validation.go, pkg/workflow/model_alias_validation.go, pkg/workflow/network_firewall_validation.go, pkg/workflow/repository_features_validation.go, pkg/workflow/safe_outputs_max_validation.go, pkg/cli/run_workflow_validation.go

Refactor 9 validation files that exceed the 300-line hard limit documented in `scratchpad/validation-refactoring.md`:

**Target files** (current → target):
1. `safe_outputs_validation_config.go` (452 lines → split into 2 files)
2. `engine_validation.go` (429 lines → split into 2 files)
3. `permissions_validation.go` (388 lines → split into 2 files)
4. `agent_validation.go` (364 lines → reduce to <300)
5. `model_alias_validation.go` (350 lines → reduce to <300)

**Approach**:

1. **For each file over 300 lines**:
   - Apply the decision tree from `scratchpad/validation-refactoring.md`
   - Check: Does file contain 2+ distinct validation domains?
   - If YES → split by domain boundary
   - If NO → extract error message generation or helper functions

2. **Naming convention** (from guideline):
   - Pattern: `{domain}_{subdomain}_validation.go`
   - Example: `safe_outputs_validation_config.go` → 
     - `safe_outputs_validation_config_core.go` (core validation logic)
     - `safe_outputs_validation_config_messages.go` (error messages)

3. **For safe_outputs_validation_config.go (452 lines)**:
   - Identify distinct validation domains (e.g., schema validation vs. cross-field validation)
   - Split into `safe_outputs_validation_config_schema.go` and `safe_outputs_validation_config_cross_field.go`
   - Aim for 200-250 lines per file

4. **For engine_validation.go (429 lines)**:
   - Separate engine-specific validations (copilot, claude, codex) into subfiles
   - Create `engine_validation_copilot.go`, `engine_validation_claude.go`, etc.
   - Keep orchestration in `engine_validation.go` (~150 lines)

5. **Quality requirements**:
   - Each file: minimum 30% comment coverage
   - Add separate `*_test.go` files for complex validators
   - Document the refactoring in commit message with issue reference

6. **Validation**:
   - Run `make build && make fmt` after each file split
   - Run `go test -v ./pkg/workflow/*validation*` before and after
   - Run `make agent-report-progress` before final commit
   - Update `scratchpad/validation-refactoring.md` examples if needed

**Success criteria**: All 9 files <300 lines, no test regressions, 30%+ comment coverage maintained.

---

Task 3: Extract Audit Command Rendering Logic into Separate Package

Priority: Medium
Estimated Effort: Medium
Focus Area: Large File Refactoring & Maintainability

Description: The audit command has 34 related files totaling over 15,000 lines, with core files like audit.go (1,132 lines) and audit_diff.go (981 lines) mixing command logic, business logic, and rendering. The 452-line AuditWorkflowRun function in audit.go is a complexity hotspot. Extract rendering concerns into a focused sub-package.

Acceptance Criteria:

• Create pkg/cli/audit/render package for all rendering logic
• Move audit_report_render*.go files (7 files) to render package
• Move audit_diff_render.go to render package
• Reduce audit.go from 1,132 to <600 lines
• Refactor AuditWorkflowRun (452 lines) into 5-7 smaller functions
• All audit tests pass (go test -v ./pkg/cli/audit*)
• Update import paths in dependent files

Code Region: pkg/cli/audit.go, pkg/cli/audit_diff.go, pkg/cli/audit_report_render*.go, pkg/cli/audit_diff_render.go

Reorganize the audit command's 34 files by extracting rendering logic into a dedicated sub-package:

**Current state**:
- 34 audit-related files in `pkg/cli/`
- `audit.go`: 1,132 lines (command setup + business logic + rendering)
- `audit_diff.go`: 981 lines (similar mix of concerns)
- 8 dedicated render files scattered in `pkg/cli/`

**Refactoring steps**:

1. **Create render package structure**:

pkg/cli/audit/
├── render/
│ ├── overview.go (from audit_report_render_overview.go)
│ ├── findings.go (from audit_report_render_findings.go)
│ ├── firewall.go (from audit_report_render_firewall.go)
│ ├── guard.go (from audit_report_render_guard.go)
│ ├── jobs.go (from audit_report_render_jobs.go)
│ ├── tools.go (from audit_report_render_tools.go)
│ ├── diff.go (from audit_diff_render.go)
│ └── base.go (shared rendering utilities)

2. **Move rendering files**:
- Use `git mv` to preserve history
- Update package declarations to `package render`
- Create `render/render.go` with package documentation

3. **Refactor audit.go** (reduce from 1,132 to <600 lines):
- Keep command setup and `NewAuditCommand()` (~150 lines)
- Extract `AuditWorkflowRun` (452 lines) into smaller functions:
  - `fetchRunData` (~80 lines) - fetch workflow run data
  - `auditJobRun` (already exists, keep as-is)
  - `analyzeRun` (~100 lines) - perform audit analysis
  - `generateReport` (~60 lines) - coordinate report generation (delegates to render package)
  - `displayResults` (~40 lines) - output results
- Move rendering calls to `pkg/cli/audit/render` package

4. **Update imports**:
- Search for imports of moved files: `grep -r "pkg/cli/audit_report_render" .`
- Update to `github.com/github/gh-aw/pkg/cli/audit/render`
- Run `go mod tidy`

5. **Testing**:
- Run `make build && make fmt` after package creation
- Run `go test -v ./pkg/cli/audit...` to catch import issues
- Ensure all 34 audit test files pass
- Run `make agent-report-progress` before committing

6. **Documentation**:
- Add package comment to `render/render.go` explaining responsibilities
- Update any references in `scratchpad/cli-command-patterns.md` if needed

**Success criteria**: Rendering logic isolated in sub-package, `audit.go` <600 lines, all tests passing, clear separation of concerns.

---

Task 4: Refactor import_field_extractor.go to Reduce Complexity

Priority: Medium
Estimated Effort: Medium
Focus Area: Large File Refactoring & Maintainability

Description: pkg/parser/import_field_extractor.go (1,172 lines, 192 control flow statements) handles import resolution, schema validation, and observability configuration. The file has good test coverage (54%) but high cyclomatic complexity makes it difficult to extend. Split into domain-focused modules.

Acceptance Criteria:

• Extract observability handling to pkg/parser/import_observability.go (~300 lines)
• Extract schema validation to pkg/parser/import_validation.go (~250 lines)
• Keep core import resolution in import_field_extractor.go (~400 lines)
• Maintain or improve test coverage (currently 54%, target 60%+)
• All parser tests pass (go test -v ./pkg/parser/)
• Complexity metrics improved: reduce control flow statements to <100 per file

Code Region: pkg/parser/import_field_extractor.go

Refactor `pkg/parser/import_field_extractor.go` (1,172 lines, high complexity) into focused modules:

**Current complexity indicators**:
- 164 if-statements
- 22 for-loops
- 6 switch-statements
- 18 functions
- Test coverage: 54% (634 test lines)

**Analysis phase**:

1. **Map responsibilities** by analyzing function names:
   ```bash
   grep "^func " pkg/parser/import_field_extractor.go

2. Identify domains:
   • Import resolution (core responsibility)
   • Observability configuration (extractOTLPEndpoints, mergeObservabilityConfigs)
   • Schema validation (validateWithImportSchema, validateObjectInput)
   • GitHub App validation (validateGitHubAppJSON)

Extraction phase:

1. Create pkg/parser/import_observability.go (~300 lines):

   • Move extractOTLPEndpointsFromObsMap
   • Move mergeObservabilityConfigs
   • Move observabilityImportEndpoint struct
   • Move related helper functions

2. Create pkg/parser/import_validation.go (~250 lines):

   • Move validateWithImportSchema
   • Move validateObjectInput
   • Move validateGitHubAppJSON
   • Move schema-related error handling

3. Refactor import_field_extractor.go (keep ~400 lines):

   • Keep importAccumulator struct
   • Keep processImportQueue core logic
   • Keep prepareFrontmatter
   • Keep computeImportRelPath
   • Call out to validation and observability modules

Testing phase:

1. Maintain test coverage:

   • Current: 634 test lines (54% coverage)
   • Target: 60%+ coverage
   • Add tests for newly extracted modules
   • Create import_observability_test.go and import_validation_test.go

2. Reduce cyclomatic complexity:

   • Target: <100 control flow statements per file
   • Extract nested conditionals into helper functions
   • Use early returns to reduce nesting depth

3. Validation:

   • Run make build && make fmt after first extraction
   • Run go test -v ./pkg/parser/ after each module extraction
   • Run make agent-report-progress before committing
   • Verify no regression in import resolution behavior

Success criteria: Three focused files (<400 lines each), 60%+ test coverage, <100 control flow statements per file, all tests passing.

---

#### Task 5: Document Large File Guidelines and Add Linter Check

**Priority**: Medium
**Estimated Effort**: Small
**Focus Area**: Large File Refactoring & Maintainability

**Description:** Create clear guidelines for file size limits and add a Go linter (using the existing `pkg/linters` infrastructure) to prevent new large files from being introduced. This provides preventive quality control and makes expectations explicit for contributors.

**Acceptance Criteria:**
- [ ] Create `scratchpad/large-file-guidelines.md` with 300-line soft limit, 600-line hard limit
- [ ] Implement `pkg/linters/largefile/largefile.go` analyzer
- [ ] Add linter to `make lint` target
- [ ] Add exemption mechanism for intentionally large files (e.g., generated code)
- [ ] Document rationale: cognitive load, testability, maintainability
- [ ] Linter passes on current codebase with documented exemptions

**Code Region:** New files: `scratchpad/large-file-guidelines.md`, `pkg/linters/largefile/largefile.go`, `pkg/linters/largefile/largefile_test.go`

```markdown
Establish large file guidelines and enforce them with a custom Go linter:

**Phase 1: Create guidelines document**

Create `scratchpad/large-file-guidelines.md`:

```markdown
# Large File Guidelines

## Limits

- **Soft limit**: 300 lines (target for new files)
- **Hard limit**: 600 lines (requires review justification)
- **Critical threshold**: 800+ lines (refactor immediately)

## Rationale

Large files create several maintainability challenges:

1. **Cognitive load**: Developers must hold more context in memory
2. **Testability**: Large files often indicate mixed responsibilities, making unit testing harder
3. **Merge conflicts**: More code in one file increases collision risk
4. **Review difficulty**: Large PRs with large files are harder to review thoroughly

## When to Refactor

Apply this decision tree:

1. File > 600 lines? → Should refactor
2. File > 300 lines AND growing? → Plan refactor
3. File has 2+ distinct domains? → Should split
4. Test-to-source ratio < 0.5? → Likely too complex, consider refactoring

## How to Refactor

See `scratchpad/validation-refactoring.md` for detailed guidance.

**Exemptions**: Generated files, test fixtures, and files with explicit architecture rationale (document in file header).

Phase 2: Implement linter

Create pkg/linters/largefile/largefile.go:

// Package largefile defines an analyzer that detects Go source files exceeding size limits.
package largefile

import (
    "go/ast"
    "golang.org/x/tools/go/analysis"
    "strings"
)

const (
    SoftLimit = 300  // Lines
    HardLimit = 600  // Lines
)

var Analyzer = &analysis.Analyzer{
    Name: "largefile",
    Doc:  "detects Go source files exceeding recommended size limits",
    Run:  run,
}

func run(pass *analysis.Pass) (any, error) {
    for _, file := range pass.Files {
        pos := pass.Fset.Position(file.Pos())
        end := pass.Fset.Position(file.End())
        lines := end.Line - pos.Line + 1
        
        // Check for exemption comment
        if hasExemption(file) {
            continue
        }
        
        if lines > HardLimit {
            pass.Reportf(file.Pos(), "file has %d lines (hard limit: %d) - refactor immediately", lines, HardLimit)
        } else if lines > SoftLimit {
            pass.Reportf(file.Pos(), "file has %d lines (soft limit: %d) - consider refactoring", lines, SoftLimit)
        }
    }
    return nil, nil
}

func hasExemption(file *ast.File) bool {
    // Check for "(lint/redacted):ignore largefile <reason>" comment
    for _, cg := range file.Comments {
        for _, c := range cg.List {
            if strings.Contains(c.Text, "lint:ignore largefile") {
                return true
            }
        }
    }
    return false
}

Phase 3: Add tests

Create pkg/linters/largefile/largefile_test.go:

package largefile_test

import (
    "testing"
    "github.com/github/gh-aw/pkg/linters/largefile"
    "golang.org/x/tools/go/analysis/analysistest"
)

func TestLargeFile(t *testing.T) {
    testdata := analysistest.TestData()
    analysistest.Run(t, testdata, largefile.Analyzer, "a")
}

Phase 4: Integration

1. Add linter to golangci-lint configuration (.golangci.yml):

   linters-settings:
     custom:
       largefile:
         path: pkg/linters/largefile
         description: Detects files exceeding size limits

2. Update make lint to include the new analyzer

3. Document exemptions for existing large files (add header comment):

   (lint/redacted):ignore largefile Compiler YAML generation requires comprehensive switch statements

Phase 5: Validation

1. Run make build && make fmt
2. Run make lint - expect warnings on existing large files
3. Add exemption comments to intentionally large files
4. Run make agent-report-progress
5. Document in PR: "This linter prevents new large files; existing files will be refactored per tasks 1-4"

Success criteria: Guidelines document created, linter implemented and integrated, passing on current codebase with exemptions documented.

---

</details>

---

## 📊 Historical Context

<details>
<summary>Previous Focus Areas</summary>

| Date | Focus Area | Type | Custom | Key Outcomes |
|------|------------|------|--------|--------------|
| 2026-05-20 | Large File Refactoring & Maintainability | Custom | Y | First analysis run — identified 29 files >800 lines, 9 validation guideline violations |

</details>

---

## 🎯 Recommendations

### Immediate Actions (This Week)
1. **Refactor validation files** (Task 2) — Priority: High — These violate documented guidelines and should be addressed first
2. **Create large file guidelines** (Task 5) — Priority: Medium — Quick win that prevents future issues

### Short-term Actions (This Month)
1. **Split frontmatter_extraction_yaml.go** (Task 1) — Priority: High — Largest and most undertested file
2. **Refactor import_field_extractor.go** (Task 4) — Priority: Medium — High complexity but good tests

### Long-term Actions (This Quarter)
1. **Extract audit rendering package** (Task 3) — Priority: Medium — Larger architectural improvement
2. **Apply learnings to other large files** — Use patterns from tasks 1-4 to address remaining 800+ line files

---

## 📈 Success Metrics

- **Files >800 lines**: 29 → <15 (by end of quarter)
- **Files >1000 lines**: 15 → 0 (by end of quarter)
- **Validation files >300 lines**: 9 → 0 (this month)
- **Average test coverage (large files)**: 32% → 60% (this quarter)
- **Largest file size**: 1,191 lines → <600 lines (this month)

---

## Next Steps

1. Review and prioritise the tasks above
2. Assign tasks to Copilot coding agent via planner agent
3. Track progress on improvement items
4. Re-evaluate this focus area in 90 days after completing initial refactorings

---

*Generated by Repository Quality Improvement Agent*
*Next analysis: 2026-05-21 — Focus area selected by diversity algorithm*




> Generated by [⚡ Repository Quality Improvement Agent](https://github.com/github/gh-aw/actions/runs/26166491160) · ● 4.2M · [◷](https://github.com/search?q=repo%3Agithub%2Fgh-aw+%22gh-aw-workflow-call-id%3A+github%2Fgh-aw%2Frepository-quality-improver%22&type=discussions)
> - [x] expires <!-- gh-aw-expires: 2026-05-21T13:52:33.108Z --> on May 21, 2026, 1:52 PM UTC

<!-- gh-aw-agentic-workflow: Repository Quality Improvement Agent, engine: copilot, version: 1.0.48, model: claude-sonnet-4.5, id: 26166491160, workflow_id: repository-quality-improver, run: https://github.com/github/gh-aw/actions/runs/26166491160 -->

<!-- gh-aw-workflow-id: repository-quality-improver -->
<!-- gh-aw-workflow-call-id: github/gh-aw/repository-quality-improver -->