Skip to content

Architecture Violations Detected — 2026-04-16 #26663

@github-actions

Description

@github-actions

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

  • Reduce buildActivationJob() in compiler_activation_job.go from 611 → ≤ 100 lines (highest priority)
  • Split main() in create_pull_request.cjs from 1,443 → ≤ 80 lines per function
  • Split log_parser_shared.cjs into parsing + formatting concerns
  • Reduce updateProject() in update_project.cjs from 750 → ≤ 100 lines
  • Reduce processMessages() in safe_output_handler_manager.cjs from 470 → ≤ 80 lines
  • Break up remaining BLOCKER CJS files to be < 1,000 lines each
  • Address WARNING function sizes in pkg/workflow/cache.go
  • Consider adding .architecture.yml to configure and track thresholds over time
  • Close this issue once all violations are resolved

🏛️ To configure thresholds, add a .architecture.yml file to the repository root.

🏛️ Architecture report by Architecture Guardian · ● 1.1M ·

Metadata

Metadata

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions