Architecture Violations Detected — 2026-04-13

[github-actions]

Summary

• Analysis Period: Last 24 hours
• Commit Analyzed: a5e4ba1 — Extract shared close-older marker search/filter logic into helpers module (Extract shared close-older marker search/filter logic into helpers module #26023)
• Files Analyzed: 1205 source files (675 Go, 530 JS/CJS, excluding test files)
• Total Violations: 85+
• Date: 2026-04-13

Severity	Count
🚨 BLOCKER	13
⚠️ WARNING	65+
i️ INFO	0

No import cycles detected. ✅

---

🚨 BLOCKER Violations

These violations indicate serious structural problems that require prompt attention.

Go files exceeding 1,000 lines

File: pkg/cli/audit_report_render.go — 1,139 lines
Issue: File significantly exceeds the 1,000-line blocker threshold. Contains a single renderConsole() function of 244 lines.
Why it matters: Large rendering files mix data formatting with presentation logic, making them hard to test and extend.
Suggested fix: Extract console rendering sections into focused helpers (e.g., audit_report_render_steps.go, audit_report_render_summary.go). The renderConsole() function should delegate to smaller helpers per section (steps, metrics, tool usage).

---

File: pkg/cli/logs_orchestrator.go — 1,075 lines
Issue: Contains two critically oversized functions: DownloadWorkflowLogs() at 562 lines and downloadRunArtifactsConcurrent() at 394 lines.
Why it matters: A 562-line function is unmaintainable — it combines HTTP coordination, filtering logic, output formatting, error handling, and file I/O in a single block. This is a god-function anti-pattern.
Suggested fix:

1. Extract flag validation into validateDownloadOptions().
2. Extract run fetching/filtering into fetchFilteredRuns().
3. Extract post-download processing (parsing, report generation, metrics) into processDownloadedRuns().
4. Extract the concurrency logic in downloadRunArtifactsConcurrent() into a dedicated runDownloadPool struct.

---

File: pkg/workflow/compiler_orchestrator_workflow.go — 1,073 lines
Issue: ParseWorkflowFile() is 176 lines; extractAdditionalConfigurations() is 140 lines; processAndMergeSteps() is 89 lines.
Why it matters: This is the central orchestration file for the compiler. Large orchestrators become coordination bottlenecks where every new feature adds to an already-heavy function.
Suggested fix: Extract extractAdditionalConfigurations() into compiler_config_extraction.go. Move imports handling into compiler_imports.go. Split ParseWorkflowFile() into parseMarkdown() → extractFrontmatter() → buildWorkflowData().

---

File: pkg/cli/gateway_logs.go — 1,066 lines
Issue: Contains parseRPCMessages() at 205 lines, extractMCPToolUsageData() at 188 lines, buildToolCallsFromRPCMessages() at 142 lines, and guardPolicyReasonFromCode() at 122 lines.
Why it matters: Log parsing and data extraction are separate concerns mixed into one file.
Suggested fix: Split into gateway_rpc_parser.go (RPC message parsing), gateway_mcp_usage.go (MCP tool usage extraction), and gateway_policy.go (policy reason mapping).

---

File: pkg/cli/logs_report.go — 1,065 lines
Issue: buildLogsData() is 200 lines; buildMCPToolUsageSummary() is 141 lines.
Why it matters: Report-building functions that touch many data types tend to grow unbounded over time. At 1,065 lines it's already crossed the blocker threshold.
Suggested fix: Extract MCP tool usage building into logs_mcp_usage.go, move episode/run aggregation into logs_run_aggregator.go.

---

File: pkg/workflow/compiler_safe_outputs_config.go — 1,035 lines
Issue: handlerConfigBuilder.Build() is a single method of 787 lines — the largest function in the entire Go codebase.
Why it matters: A 787-line method is effectively untestable and unreadable. It likely represents a large switch/if tree that has grown by accretion. Every new safe-output handler type extends an already-massive function.
Suggested fix: Decompose Build() by handler category. Create buildIssueHandlerConfig(), buildPRHandlerConfig(), buildDiscussionHandlerConfig(), etc. Each should be a focused method or standalone function. Consider a registry pattern where handlers self-register their config.

---

JS/CJS files exceeding 1,000 lines

File: actions/setup/js/log_parser_shared.cjs — 1,703 lines
Issue: Contains 7 functions all exceeding 80 lines: generatePlainTextSummary() (211), generateCopilotCliStyleSummary() (201), generateConversationMarkdown() (166), formatToolUse() (153), formatInitializationSummary() (149), formatSafeOutputsPreview() (109), parseLogEntries() (96).
Suggested fix: Split by output format — log_parser_markdown.cjs, log_parser_text.cjs, log_parser_conversation.cjs — keeping log_parser_shared.cjs for the core parseLogEntries() and shared type definitions.

---

File: actions/setup/js/create_pull_request.cjs — 1,678 lines
Issue: Contains generatePatchPreview() at an astonishing 1,473 lines — the largest single function in the entire codebase.
Why it matters: A 1,473-line function is effectively a program in itself. It cannot be unit tested meaningfully, cannot be reviewed safely, and is a regression magnet.
Suggested fix: This function likely handles multiple patch formats and rendering strategies. Extract: formatHunkHeader(), renderAddedLines(), renderDeletedLines(), formatPatchStats(), truncateLargePatch(). Each logical section should be its own function ≤ 80 lines. Consider splitting into create_pull_request_patch.cjs.

---

File: actions/setup/js/handle_agent_failure.cjs — 1,536 lines
Suggested fix: Identify the distinct failure-handling strategies (timeout, permission, network, tool-failure) and extract each into a dedicated handler module or named function. Create handle_agent_failure_strategies.cjs for the strategy implementations.

---

File: actions/setup/js/update_project.cjs — 1,451 lines
Suggested fix: Split into update_project_fields.cjs (field update logic), update_project_status.cjs (status transitions), and update_project_api.cjs (GitHub API calls).

---

File: actions/setup/js/safe_output_handler_manager.cjs — 1,266 lines
Suggested fix: Extract handler registration and lookup into safe_output_handler_registry.cjs, keeping lifecycle management in the main file. Similar split opportunity as the Go-side compiler_safe_outputs_config.go.

---

File: actions/setup/js/sanitize_content_core.cjs — 1,171 lines
Suggested fix: Group sanitization strategies by content type: sanitize_content_markdown.cjs, sanitize_content_code.cjs, sanitize_content_text.cjs.

---

File: actions/setup/js/runtime_import.cjs — 1,022 lines
Suggested fix: Split by runtime type (node, python, go, etc.) into individual runtime_import_node.cjs, runtime_import_python.cjs etc., with a thin dispatcher in runtime_import.cjs.

---

⚠️ WARNING Violations

These violations should be addressed soon to prevent further structural debt.

Top 10 Go WARNING files (500–1,000 lines):

File	Lines
pkg/workflow/cache.go	973
pkg/workflow/frontmatter_types.go	957
pkg/workflow/compiler_yaml.go	895
pkg/workflow/mcp_setup_generator.go	893
pkg/cli/logs_download.go	890
pkg/workflow/frontmatter_extraction_yaml.go	868
pkg/workflow/compiler_yaml_main_job.go	868
pkg/workflow/compiler_jobs.go	836
pkg/cli/audit.go	835
pkg/cli/pr_command.go	829

65 Go source files are in the 500–1,000 line warning range.

Top JS WARNING files (500–1,000 lines):

File	Lines
actions/setup/js/parse_copilot_log.cjs	914
actions/setup/js/safe_outputs_handlers.cjs	904
actions/setup/js/send_otlp_span.cjs	850
actions/setup/js/mcp_server_core.cjs	835
actions/setup/js/create_issue.cjs	803
actions/setup/js/validate_secrets.cjs	776
actions/setup/js/push_to_pull_request_branch.cjs	788

Notable oversized functions in WARNING files:

• logs_orchestrator.go::downloadRunArtifactsConcurrent() — 394 lines
• audit_report_render.go::renderConsole() — 244 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

💡 Add a .architecture.yml to the repository root to customize thresholds.

Action Checklist

• Address handlerConfigBuilder.Build() (787 lines) — decompose by handler category
• Address DownloadWorkflowLogs() (562 lines) — extract validation, fetching, processing
• Address generatePatchPreview() (1,473 lines in JS) — extract by patch-rendering concern
• Split log_parser_shared.cjs (1,703 lines) by output format
• Split pkg/cli/audit_report_render.go (1,139 lines) by rendering section
• Split pkg/cli/gateway_logs.go (1,066 lines) by parsing concern
• Review all BLOCKER files and plan refactoring PRs
• Address WARNING violations in upcoming PRs
• Close this issue once all BLOCKER violations are resolved

🏛️ Architecture Guardian — automated scan for run 24349660827

🏛️ Architecture report by Architecture Guardian · ● 1.4M · ◷

[copilot-swe-agent]

The agent encountered an error and was unable to start working on this issue: The service is temporarily unavailable. Please try again later. (Request id: 1340:A2569:5CB2CA7:17D4C80A:69DD0332)