[daily-compiler-quality] Daily Compiler Code Quality Report - 2026-05-17

[github-actions[bot]]

🔍 Compiler Code Quality Analysis Report

Analysis Date: 2026-05-17
Files Analyzed: compiler_orchestrator.go, compiler_jobs.go, compiler_yaml.go
Overall Status: ✅ All analyzed files meet or exceed the human-written quality threshold

---

Executive Summary

Today's analysis covered three files from the pkg/workflow/ compiler suite — a tiny orchestrator shim, the job-building module, and the YAML generation module. All three files scored at or above the 75-point human-written quality threshold, driven by strong error-handling discipline, consistent Go idioms, and excellent debug-logging coverage.

The most notable finding is that compiler_jobs.go contains a single outlier function, buildCustomJobs, that spans approximately 352 lines. While the surrounding codebase is well-organised, this one function carries the majority of the file's complexity and is a refactoring candidate. compiler_yaml.go has two large generators (generatePrompt ~247 lines, generateWorkflowHeader ~174 lines) that inflate the file to 980 lines but are heavily commented and logically sequenced.

compiler_orchestrator.go is exemplary: 22 lines, a package-level doc comment explaining the split architecture, a single shared logger — nothing more. It models exactly the kind of focused, purposeful file the rest of the suite should aspire to.

---

Files Analyzed Today

📁 Detailed File Analysis

1. compiler_orchestrator.go — Score: 96/100 ✅

Rating: Excellent
Size: 22 lines
Last commit: 11f9712 (refactor: eliminate >8-parameter functions)

Score Breakdown

Dimension	Score	Rating
Structure & Organisation	25/25	Excellent
Readability	20/20	Excellent
Error Handling	20/20	N/A (no error-returning code)
Testing & Maintainability	18/20	Good (test file: 694 lines)
Patterns & Best Practices	13/15	Excellent
Total	96/100	Excellent

✅ Strengths

• Package-level doc comment clearly explains the split into 5 sub-modules
• Single exported symbol (detectionLog) — zero ambiguity of purpose
• Correct use of logger.New with the workflow:detection namespace convention

⚠️ Issues Identified

None. File is a clean entry point shim.

---

2. compiler_jobs.go — Score: 79/100 ✅

Rating: Good
Size: 1 028 lines · 23 functions
Test file: compiler_jobs_test.go — 3 698 lines (3.6× source ratio — excellent)

Score Breakdown

Dimension	Score	Rating
Structure & Organisation	14/25	Acceptable
Readability	15/20	Good
Error Handling	18/20	Excellent
Testing & Maintainability	19/20	Excellent
Patterns & Best Practices	13/15	Excellent
Total	79/100	Good

✅ Strengths

• 28 fmt.Errorf calls with %w wrapping — errors carry full context
• 170 inline comments; 20 exported-function doc comments
• Debug logging via compilerJobsLog with structured key-value messages
• Outstanding test coverage: 3.6× test-to-source line ratio
• Consistent use of any, semantic type constants (constants.ActivationJobName, constants.PreActivationJobName)

⚠️ Issues Identified

1. buildCustomJobs function length — High Priority

   • Lines 514–866 ≈ 352 lines in a single function
   • Handles: dependency resolution, needs inference, on.needs logic, runs-on extraction, env mapping, step assembly, job registration
   • Recommendation: extract into buildCustomJob (single job), resolveCustomJobDependencies, and assembleCustomJobSteps helpers
   • Estimated effort: 2–3 hours

2. buildCustomJobs loop nesting depth — Medium Priority

   • 5–6 levels of nesting in places (range loop → type-assertion → needs loop → step loop → inner assertions)
   • Reduces at-a-glance comprehension
   • Recommendation: introduce early-return helper functions to flatten nesting

3. File size 1 028 lines — Low Priority

   • Exceeds the 800-line soft limit
   • The file already represents a good split from the original compiler.go; splitting further would likely reduce cohesion unless it follows the buildCustomJobs refactor

💡 Recommendations

1. Extract buildCustomJobs into 3–4 focused helpers (highest-impact change)
2. Once buildCustomJobs is split, the overall file length will drop significantly (estimated 700 lines)

---

3. compiler_yaml.go — Score: 75/100 ✅

Rating: Good (at threshold)
Size: 980 lines · 17 functions
Test file: compiler_yaml_test.go — 1 440 lines (1.47× source ratio — good)

Score Breakdown

Dimension	Score	Rating
Structure & Organisation	14/25	Acceptable
Readability	14/20	Acceptable
Error Handling	16/20	Good
Testing & Maintainability	17/20	Good
Patterns & Best Practices	14/15	Excellent
Total	75/100	Good

✅ Strengths

• 246 comment lines (25% of file) — well above average comment density
• strings.Builder pattern used consistently for YAML generation (avoids repeated string allocations)
• stringutil.StripANSI applied defensively on all user-supplied strings before embedding in YAML
• generateYAML returns (string, []string, []string, error) — structured results, no mutation side-effects
• Correct ANSI-safe file-path normalisation via filepath.ToSlash

⚠️ Issues Identified

1. generatePrompt function length — High Priority

   • Lines 429–676 ≈ 247 lines
   • Steps 1a/1b/1.5/2/3/4/5 are all inlined; each step could be its own function
   • Recommendation: extract steps into inlineImportsWithInputs, inlineOrMacroImports, extractMainExpressions, filterExpressionMappings, writePromptChunks helpers
   • Estimated effort: 3–4 hours

2. generateWorkflowHeader function length — Medium Priority

   • Lines 83–257 ≈ 174 lines
   • Sections (metadata, manifest, logo, description, source, imports, YAML trigger, permissions) could each be helper functions
   • Recommendation: extract 4–5 writeHeaderXxx helpers
   • Estimated effort: 2 hours

3. generateCreateAwInfo function length — Medium Priority

   • Lines 719–875 ≈ 156 lines
   • Contains engine-specific branching that could benefit from the strategy pattern already in use elsewhere
   • Estimated effort: 1–2 hours

4. Low error-wrapping count (5 uses of %w) — Low Priority

   • Most functions return no error (using strings.Builder), which is intentional and correct
   • The 5 error sites that do return errors all wrap correctly
   • No action needed; note for future additions

💡 Recommendations

1. Refactor generatePrompt first — it is the most complex function and most prone to regressions
2. Consider splitting the file into compiler_yaml_header.go and compiler_yaml_prompt.go after the function refactors to keep file sizes under 500 lines

---

Overall Statistics

Quality Score Distribution

Rating	Count	Percentage
Excellent (90–100)	1	33%
Good (75–89)	2	67%
Acceptable (60–74)	0	0%
Needs Work (40–59)	0	0%
Poor (<40)	0	0%

Average Score: 83/100
Median Score: 79/100
Human-Written Quality: ✅ All 3 files meet or exceed the 75-point threshold

Common Patterns

Strengths Across Files

• ✅ fmt.Errorf with %w error wrapping used consistently
• ✅ logger.New debug logging with namespace convention (workflow:*)
• ✅ Semantic type constants from pkg/constants used throughout
• ✅ Modern Go idioms: any instead of interface{}, strings.SplitSeq (Go 1.23+)
• ✅ Defensive ANSI stripping on all user-controlled strings

Common Issues

• ⚠️ Several functions exceed 150 lines (4 identified across 2 files)
• ⚠️ buildCustomJobs at 352 lines is the single most critical refactoring target
• ⚠️ compiler_yaml.go doc comments sparse for exported functions (7 vs 17 functions)

---

📈 Historical Trends

First Analysis Run

This is the initial analysis run — no historical baseline exists. The rotation index has been set to continue with compiler_activation_jobs.go, compiler_safe_outputs.go, and compiler_safe_outputs_config.go in the next run.

Files in Analysis Queue (Remaining)

Priority	File	Reason
1	compiler_activation_jobs.go	Never analyzed
2	compiler_safe_outputs.go	Never analyzed
3	compiler_safe_outputs_config.go	Never analyzed
4	compiler_safe_outputs_job.go	Never analyzed
5	compiler.go	Never analyzed
6	compiler_yaml_main_job.go	Never analyzed

---

Actionable Recommendations

Immediate Actions (High Priority)

1. Refactor buildCustomJobs in compiler_jobs.go

   • Extract into resolveCustomJobDependencies, buildSingleCustomJob, assembleCustomJobSteps
   • Target: reduce from 352 lines to 3–4 functions of ≤80 lines each
   • Estimated effort: 2–3 hours

2. Refactor generatePrompt in compiler_yaml.go

   • Extract numbered steps (1a, 1b, 1.5, 2, 3, 4, 5) into named helpers
   • Target: reduce from 247 lines to a coordinator function of ≤60 lines
   • Estimated effort: 3–4 hours

Short-term Improvements (Medium Priority)

3. Refactor generateWorkflowHeader in compiler_yaml.go

   • Extract writeMetadata, writeManifest, writeImports, writeTriggerYAML helpers
   • Estimated effort: 2 hours

4. Add exported-function doc comments to compiler_yaml.go

   • Only 7 of 17 functions have opening doc comments
   • Focus: generateYAML, generatePrompt, generateCreateAwInfo, generateOutputCollectionStep
   • Estimated effort: 30 minutes

Long-term Goals (Low Priority)

5. Apply file-size guideline proactively
   • Target: all compiler files under 600 lines
   • After buildCustomJobs refactor: compiler_jobs.go estimated ~700 lines → split to 2 files
   • After prompt/header refactors: compiler_yaml.go estimated ~600 lines → borderline, reassess

Summary Table

File	Lines	Functions	Score	Rating	Top Issue
compiler_orchestrator.go	22	0	96/100	✅ Excellent	None
compiler_jobs.go	1 028	23	79/100	✅ Good	buildCustomJobs at 352 lines
compiler_yaml.go	980	17	75/100	✅ Good	generatePrompt at 247 lines

Average score: 83/100 · Files meeting threshold: 3/3

Top 3 Issues

1. buildCustomJobs in compiler_jobs.go — 352-line function, prime refactoring target
2. generatePrompt in compiler_yaml.go — 247-line function, complex multi-step logic
3. Missing exported-function doc comments in compiler_yaml.go (10 of 17 functions undocumented)

Recommended Action

Priority: refactor buildCustomJobs into 3–4 focused helpers (est. 2–3 hours, highest complexity reduction).

---

💾 Cache Memory Summary

Cache Location: /tmp/gh-aw/cache-memory/compiler-quality/
Note: Cache directory could not be written this run (permission constraint in sandbox). Analysis state is recorded in this discussion for continuity.

Analysis State

• Total files in scope: 9
• Files analyzed today: 3 (compiler_orchestrator.go, compiler_jobs.go, compiler_yaml.go)
• Files remaining: 6
• Git ref at analysis time: 11f9712 (latest commit touching these files)

Next Analysis Schedule

Based on rotation, these files are prioritised for the next run:

1. compiler_activation_jobs.go (never analyzed)
2. compiler_safe_outputs.go (never analyzed)
3. compiler_safe_outputs_config.go (never analyzed)

---

Conclusion

The compiler codebase shows good overall quality with an average score of 83/100 across today's three files. All files meet the human-written quality threshold of 75 points. The codebase demonstrates strong discipline in error handling, debug logging, and Go idiom usage.

Key Takeaways:

• ✅ Excellent test-to-source ratios (especially compiler_jobs_test.go at 3.6×)
• ✅ Strong error wrapping and defensive ANSI stripping practices
• ✅ compiler_orchestrator.go is a model of focused, minimal responsibility
• ⚠️ Two high-priority refactoring targets: buildCustomJobs (352 lines) and generatePrompt (247 lines)
• ⚠️ Both large files (1 028 and 980 lines) would benefit from function extraction before file splitting

Next Steps:

1. Refactor buildCustomJobs to reduce function length from 352 to ≤80 lines per function
2. Refactor generatePrompt by extracting its numbered steps into named helpers
3. Continue rotation with compiler_activation_jobs.go, compiler_safe_outputs.go, compiler_safe_outputs_config.go in the next daily run

---

Report generated by Daily Compiler Quality Check workflow
Analysis powered by Go static analysis + direct code inspection
Workflow run: §25980399706

Generated by 📊 Daily Compiler Quality Check · ● 18.9M · ◷

• expires on May 18, 2026, 3:44 AM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-05-18T03:44:22.511Z.

Closed by Workflow