Summary
- Analysis Period: Last 24 hours
- Commit Analyzed:
d510f01 — Rename GetActionPinWithData to ResolveActionPin in pkg/actionpins
- Files Analyzed: 995 (714 Go + 281 JS/CJS, excluding test files)
- Total Violations: 14
- Date: 2026-04-16
| Severity |
Count |
| 🚨 BLOCKER |
9 |
| ⚠️ WARNING |
5 |
| i️ INFO |
0 |
🚨 BLOCKER Violations
These violations indicate serious structural problems that require prompt attention.
1. pkg/workflow/compiler_activation_job.go — 1,027 lines (Go)
File: pkg/workflow/compiler_activation_job.go
Commit: d510f01 — Rename GetActionPinWithData to ResolveActionPin
Issue: File exceeds the 1,000-line threshold at 1,027 lines. Additionally, the primary function buildActivationJob() is 611 lines long — nearly 8× the 80-line function limit.
Why it matters: A 611-line function is essentially untestable in isolation, extremely hard to review, and impossible to understand without reading the entire function body. It accumulates responsibilities that belong in separate, focused functions.
Suggested fix:
- Extract the activation job trigger-building logic into
buildActivationTriggers()
- Extract the checkout/setup step generation into
buildActivationSetupSteps()
- Extract the condition/expression logic into
buildActivationConditions()
- Extract step generation for each engine into separate
buildXxxEngineSteps() helpers
- Target: reduce
buildActivationJob() to ≤ 100 lines by delegating to focused helpers
2. actions/setup/js/create_pull_request.cjs — 1,678 lines (JS)
File: actions/setup/js/create_pull_request.cjs
Commit: d510f01
Issue: File is 1,678 lines with a single main() function of 1,443 lines — the entire file is essentially one giant function.
Why it matters: A 1,443-line main() function contains numerous distinct phases (branch management, diff generation, PR creation, comment handling, label management) all tangled together. It cannot be unit tested, is fragile to change, and extremely hard to review.
Suggested fix:
- Split
main() into logical phases: prepareBranch(), generatePRDescription(), createOrUpdatePR(), applyLabels(), postComments()
- Each phase should be independently testable with a clear signature
- Target file size: ≤ 400 lines after extraction
3. actions/setup/js/log_parser_shared.cjs — 1,703 lines (JS)
File: actions/setup/js/log_parser_shared.cjs
Commit: d510f01
Issue: File is 1,703 lines with multiple large functions: generatePlainTextSummary() (211 lines), generateConversationMarkdown() (166 lines), formatToolUse() (153 lines), formatInitializationSummary() (149 lines).
Why it matters: The file mixes parsing, formatting, and rendering concerns. Changes to rendering logic risk breaking parsing logic.
Suggested fix:
- Split into
log_parser_core.cjs (parsing), log_formatter_markdown.cjs (markdown rendering), log_formatter_text.cjs (plain text rendering)
- Keep
log_parser_shared.cjs as a thin re-export barrel for backward compatibility
4. actions/setup/js/handle_agent_failure.cjs — 1,572 lines (JS)
File: actions/setup/js/handle_agent_failure.cjs
Commit: d510f01
Issue: File is 1,572 lines. main() is 615 lines; buildCodePushFailureContext() is 199 lines; buildEngineFailureContext() is 134 lines.
Why it matters: Failure-handling logic covers multiple distinct failure modes (code push failures, engine failures, timeout handling) all in one file with oversized functions.
Suggested fix:
- Extract
buildCodePushFailureContext() and buildEngineFailureContext() into failure_context_builders.cjs
- Extract parent-issue management into
parent_issue_manager.cjs
- Reduce
main() to an orchestrator of ≤ 80 lines
5. actions/setup/js/update_project.cjs — 1,451 lines (JS)
File: actions/setup/js/update_project.cjs
Commit: d510f01
Issue: File is 1,451 lines. updateProject() is 750 lines — a single function nearly 10× over the function-size limit.
Why it matters: A 750-line function handling project field updates, item creation, column management, and status tracking is impossible to follow or test in isolation.
Suggested fix:
- Extract field-update logic into
updateProjectFields()
- Extract item-creation/linking into
ensureProjectItem()
- Extract status/iteration management into
updateProjectStatus()
- Target:
updateProject() ≤ 100 lines
6. actions/setup/js/safe_output_handler_manager.cjs — 1,301 lines (JS)
File: actions/setup/js/safe_output_handler_manager.cjs
Commit: d510f01
Issue: File is 1,301 lines. processMessages() is 470 lines; main() is 278 lines.
Suggested fix:
- Extract message-processing phases (validation, routing, dispatch) into focused helpers
processMessages() should be ≤ 80 lines, delegating to typed handler functions
7. actions/setup/js/sanitize_content_core.cjs — 1,224 lines (JS)
File: actions/setup/js/sanitize_content_core.cjs
Commit: d510f01
Issue: File is 1,224 lines with multiple oversized functions: decodeHtmlEntities() (115 lines), convertXmlTags() (106 lines), sanitizeContentCore() (100 lines).
Suggested fix:
- Split into
sanitize_html.cjs, sanitize_xml.cjs, and sanitize_content_core.cjs (orchestrator only)
8. actions/setup/js/runtime_import.cjs — 1,022 lines (JS)
File: actions/setup/js/runtime_import.cjs
Commit: d510f01
Issue: File is 1,022 lines — just over the BLOCKER threshold.
Suggested fix: Identify the major logical sections (runtime version resolution, import validation, module loading) and extract each into a dedicated file
9. actions/setup/js/safe_outputs_handlers.cjs — 1,007 lines (JS)
File: actions/setup/js/safe_outputs_handlers.cjs
Commit: d510f01
Issue: File is 1,007 lines — just over the BLOCKER threshold.
Suggested fix: Each output handler type (issue, PR, comment, label, etc.) should have its own focused handler file, with safe_outputs_handlers.cjs as a dispatch router only
⚠️ WARNING Violations
These violations should be addressed soon to prevent further structural debt.
Function size warnings in pkg/workflow/cache.go (973 lines)
File: pkg/workflow/cache.go
| Function |
Lines |
buildUpdateCacheMemoryJob() |
171 |
buildCacheMemoryPromptSection() |
119 |
generateCacheMemorySteps() |
137 |
generateCacheSteps() |
107 |
parseCacheMemoryEntry() |
100 |
Suggested fix: The cache memory step generation functions should each be split into sub-steps (e.g., generateCacheRestoreStep(), generateCacheSaveStep()). buildUpdateCacheMemoryJob() should delegate to per-step builders.
File size warning: pkg/parser/remote_fetch.go (928 lines)
File: pkg/parser/remote_fetch.go
Suggested fix: Split HTTP fetching logic from caching logic and schema validation into separate files: remote_fetch_http.go, remote_fetch_cache.go
File size warning: pkg/workflow/mcp_setup_generator.go (913 lines)
File: pkg/workflow/mcp_setup_generator.go
Suggested fix: Split MCP server type generators (HTTP, stdio, docker) into separate files per server type
File size warning: pkg/workflow/compiler_yaml.go (911 lines)
File: pkg/workflow/compiler_yaml.go
Suggested fix: Already partially split (see compiler_yaml_main_job.go). Continue extracting per-job YAML generation into dedicated files
File size warning: cmd/gh-aw/main.go (895 lines)
File: cmd/gh-aw/main.go
Suggested fix: The command registration and initialization logic should be extracted into a cmd/gh-aw/commands.go registry file. main.go should be ≤ 50 lines
Configuration
Thresholds (defaults — no .architecture.yml found):
- File size BLOCKER: 1,000 lines
- File size WARNING: 500 lines
- Function size: 80 lines
- Max public exports: 10
Action Checklist
🏛️ To configure thresholds, add a .architecture.yml file to the repository root.
🏛️ Architecture report by Architecture Guardian · ● 1.1M · ◷
Summary
d510f01— RenameGetActionPinWithDatatoResolveActionPininpkg/actionpins🚨 BLOCKER Violations
1.
pkg/workflow/compiler_activation_job.go— 1,027 lines (Go)File:
pkg/workflow/compiler_activation_job.goCommit:
d510f01— RenameGetActionPinWithDatatoResolveActionPinIssue: File exceeds the 1,000-line threshold at 1,027 lines. Additionally, the primary function
buildActivationJob()is 611 lines long — nearly 8× the 80-line function limit.Why it matters: A 611-line function is essentially untestable in isolation, extremely hard to review, and impossible to understand without reading the entire function body. It accumulates responsibilities that belong in separate, focused functions.
Suggested fix:
buildActivationTriggers()buildActivationSetupSteps()buildActivationConditions()buildXxxEngineSteps()helpersbuildActivationJob()to ≤ 100 lines by delegating to focused helpers2.
actions/setup/js/create_pull_request.cjs— 1,678 lines (JS)File:
actions/setup/js/create_pull_request.cjsCommit:
d510f01Issue: File is 1,678 lines with a single
main()function of 1,443 lines — the entire file is essentially one giant function.Why it matters: A 1,443-line
main()function contains numerous distinct phases (branch management, diff generation, PR creation, comment handling, label management) all tangled together. It cannot be unit tested, is fragile to change, and extremely hard to review.Suggested fix:
main()into logical phases:prepareBranch(),generatePRDescription(),createOrUpdatePR(),applyLabels(),postComments()3.
actions/setup/js/log_parser_shared.cjs— 1,703 lines (JS)File:
actions/setup/js/log_parser_shared.cjsCommit:
d510f01Issue: File is 1,703 lines with multiple large functions:
generatePlainTextSummary()(211 lines),generateConversationMarkdown()(166 lines),formatToolUse()(153 lines),formatInitializationSummary()(149 lines).Why it matters: The file mixes parsing, formatting, and rendering concerns. Changes to rendering logic risk breaking parsing logic.
Suggested fix:
log_parser_core.cjs(parsing),log_formatter_markdown.cjs(markdown rendering),log_formatter_text.cjs(plain text rendering)log_parser_shared.cjsas a thin re-export barrel for backward compatibility4.
actions/setup/js/handle_agent_failure.cjs— 1,572 lines (JS)File:
actions/setup/js/handle_agent_failure.cjsCommit:
d510f01Issue: File is 1,572 lines.
main()is 615 lines;buildCodePushFailureContext()is 199 lines;buildEngineFailureContext()is 134 lines.Why it matters: Failure-handling logic covers multiple distinct failure modes (code push failures, engine failures, timeout handling) all in one file with oversized functions.
Suggested fix:
buildCodePushFailureContext()andbuildEngineFailureContext()intofailure_context_builders.cjsparent_issue_manager.cjsmain()to an orchestrator of ≤ 80 lines5.
actions/setup/js/update_project.cjs— 1,451 lines (JS)File:
actions/setup/js/update_project.cjsCommit:
d510f01Issue: File is 1,451 lines.
updateProject()is 750 lines — a single function nearly 10× over the function-size limit.Why it matters: A 750-line function handling project field updates, item creation, column management, and status tracking is impossible to follow or test in isolation.
Suggested fix:
updateProjectFields()ensureProjectItem()updateProjectStatus()updateProject()≤ 100 lines6.
actions/setup/js/safe_output_handler_manager.cjs— 1,301 lines (JS)File:
actions/setup/js/safe_output_handler_manager.cjsCommit:
d510f01Issue: File is 1,301 lines.
processMessages()is 470 lines;main()is 278 lines.Suggested fix:
processMessages()should be ≤ 80 lines, delegating to typed handler functions7.
actions/setup/js/sanitize_content_core.cjs— 1,224 lines (JS)File:
actions/setup/js/sanitize_content_core.cjsCommit:
d510f01Issue: File is 1,224 lines with multiple oversized functions:
decodeHtmlEntities()(115 lines),convertXmlTags()(106 lines),sanitizeContentCore()(100 lines).Suggested fix:
sanitize_html.cjs,sanitize_xml.cjs, andsanitize_content_core.cjs(orchestrator only)8.
actions/setup/js/runtime_import.cjs— 1,022 lines (JS)File:
actions/setup/js/runtime_import.cjsCommit:
d510f01Issue: File is 1,022 lines — just over the BLOCKER threshold.
Suggested fix: Identify the major logical sections (runtime version resolution, import validation, module loading) and extract each into a dedicated file
9.
actions/setup/js/safe_outputs_handlers.cjs— 1,007 lines (JS)File:
actions/setup/js/safe_outputs_handlers.cjsCommit:
d510f01Issue: File is 1,007 lines — just over the BLOCKER threshold.
Suggested fix: Each output handler type (issue, PR, comment, label, etc.) should have its own focused handler file, with
safe_outputs_handlers.cjsas a dispatch router onlyFunction size warnings in
pkg/workflow/cache.go(973 lines)File:
pkg/workflow/cache.gobuildUpdateCacheMemoryJob()buildCacheMemoryPromptSection()generateCacheMemorySteps()generateCacheSteps()parseCacheMemoryEntry()Suggested fix: The cache memory step generation functions should each be split into sub-steps (e.g.,
generateCacheRestoreStep(),generateCacheSaveStep()).buildUpdateCacheMemoryJob()should delegate to per-step builders.File size warning:
pkg/parser/remote_fetch.go(928 lines)File:
pkg/parser/remote_fetch.goSuggested fix: Split HTTP fetching logic from caching logic and schema validation into separate files:
remote_fetch_http.go,remote_fetch_cache.goFile size warning:
pkg/workflow/mcp_setup_generator.go(913 lines)File:
pkg/workflow/mcp_setup_generator.goSuggested fix: Split MCP server type generators (HTTP, stdio, docker) into separate files per server type
File size warning:
pkg/workflow/compiler_yaml.go(911 lines)File:
pkg/workflow/compiler_yaml.goSuggested fix: Already partially split (see
compiler_yaml_main_job.go). Continue extracting per-job YAML generation into dedicated filesFile size warning:
cmd/gh-aw/main.go(895 lines)File:
cmd/gh-aw/main.goSuggested fix: The command registration and initialization logic should be extracted into a
cmd/gh-aw/commands.goregistry file.main.goshould be ≤ 50 linesConfiguration
Thresholds (defaults — no
.architecture.ymlfound):Action Checklist
buildActivationJob()incompiler_activation_job.gofrom 611 → ≤ 100 lines (highest priority)main()increate_pull_request.cjsfrom 1,443 → ≤ 80 lines per functionlog_parser_shared.cjsinto parsing + formatting concernsupdateProject()inupdate_project.cjsfrom 750 → ≤ 100 linesprocessMessages()insafe_output_handler_manager.cjsfrom 470 → ≤ 80 linespkg/workflow/cache.go.architecture.ymlto configure and track thresholds over time