Architecture Violations Detected — 2026-04-22

### Summary

- **Analysis Period**: Last 24 hours
- **Commit Analyzed**: `a1e4bf0` — Increase Q workflow timeout to prevent Copilot engine timeout failures (#27846)
- **Files Analyzed**: 1,024
- **Total Violations**: 22
- **Date**: 2026-04-22

| Severity | Count |
|----------|-------|
| 🚨 BLOCKER | 0 |
| ⚠️ WARNING | 14 |
| i️ INFO | 17 |

---

### ✅ No BLOCKER Violations

No import cycles or files exceeding 2,000 lines were detected.

---

### ⚠️ WARNING Violations

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

#### File Size: `actions/setup/js/create_pull_request.cjs` (1,765 lines)

**File**: `actions/setup/js/create_pull_request.cjs` | **Lines**: 1,765
**Commit**: `a1e4bf0` — Increase Q workflow timeout
**Issue**: File is 1,765 lines — 76% over the 1,000-line threshold.
**Why it matters**: Large files increase cognitive load, make code review harder, and cause merge conflicts. This file mixes PR validation, label handling, and patch preview generation.
**Suggested fix**: Extract the `generatePatchPreview()` function (lines 251–1765, **1,514 lines** alone — see function violation below) into a dedicated `patch_preview.cjs` module. Move `parseAllowedBaseBranches`/`isBaseBranchAllowed` into a `pr_validation_helpers.cjs` file.

---

#### Function Size: `generatePatchPreview` in `create_pull_request.cjs` (~1,514 lines)

**File**: `actions/setup/js/create_pull_request.cjs` | **Function**: `generatePatchPreview` | **Lines**: ~1,514
**Issue**: This is the longest function in the codebase — nearly the entire file is one function.
**Why it matters**: Functions this large are impossible to test in isolation, debug, or review meaningfully. This is a critical structural issue even though the file doesn't cross the BLOCKER threshold.
**Suggested fix**: Decompose into smaller helpers: `generateDiffSummary()`, `formatPatchSection()`, `truncatePatchForPreview()`, etc. Each should be independently testable.

---

#### File Size: `actions/setup/js/handle_agent_failure.cjs` (1,590 lines)

**File**: `actions/setup/js/handle_agent_failure.cjs` | **Lines**: 1,590
**Commit**: `a1e4bf0`
**Issue**: File contains 18+ functions handling many different failure contexts. It has grown into a "failure kitchen sink."
**Suggested fix**: Group related failure context builders into separate modules: `engine_failure_context.cjs`, `code_push_failure_context.cjs`, `mcp_failure_context.cjs`. The main file becomes a thin orchestrator.

---

#### Function Size: `buildEngineFailureContext` in `handle_agent_failure.cjs` (~750 lines)

**File**: `actions/setup/js/handle_agent_failure.cjs` | **Function**: `buildEngineFailureContext` (line 840–EOF) | **Lines**: ~750
**Issue**: This function spans the entire tail of the file and handles all engine failure scenarios in a single monolithic block.
**Suggested fix**: Extract sub-builders per failure scenario (e.g., `buildTimeoutFailureSection()`, `buildInferenceErrorSection()`) and let `buildEngineFailureContext` orchestrate them.

---

#### Function Size: `getActionFailureIssueExpiresHours` in `handle_agent_failure.cjs` (~272 lines)

**File**: `actions/setup/js/handle_agent_failure.cjs` | **Function**: `getActionFailureIssueExpiresHours` (line 23–295) | **Lines**: ~272
**Issue**: A function named `get*` should return a value with minimal logic, but this one spans 272 lines.
**Suggested fix**: Extract the body into a `resolveExpirationConfig()` helper and keep `getActionFailureIssueExpiresHours` as a thin wrapper.

---

#### File Size: `actions/setup/js/update_project.cjs` (1,451 lines)

**File**: `actions/setup/js/update_project.cjs` | **Lines**: 1,451
**Commit**: `a1e4bf0`
**Issue**: File mixes project field validation, type checking, and update orchestration.
**Suggested fix**: Move field type validation into `project_field_validators.cjs`. Keep `update_project.cjs` focused on the update workflow.

---

#### File Size: `actions/setup/js/safe_output_handler_manager.cjs` (1,378 lines)

**File**: `actions/setup/js/safe_output_handler_manager.cjs` | **Lines**: 1,378
**Commit**: `a1e4bf0`
**Issue**: The two largest functions (`formatManifestLogMessage` and `getContentToCheck`) each exceed 500 lines.
**Suggested fix**: Extract manifest log formatting into `manifest_log_formatter.cjs` and content inspection logic into `safe_output_content_inspector.cjs`.

---

#### Function Size: `formatManifestLogMessage` in `safe_output_handler_manager.cjs` (~507 lines)

**File**: `actions/setup/js/safe_output_handler_manager.cjs` | **Function**: `formatManifestLogMessage` (line 368) | **Lines**: ~507
**Suggested fix**: Break into per-manifest-field formatters and a central dispatch function.

---

#### Function Size: `getContentToCheck` in `safe_output_handler_manager.cjs` (~503 lines)

**File**: `actions/setup/js/safe_output_handler_manager.cjs` | **Function**: `getContentToCheck` (line 875) | **Lines**: ~503
**Suggested fix**: Decompose by message type into separate `getContentFor{Type}()` helpers with a switch-dispatch entry point.

---

#### File Size: `actions/setup/js/sanitize_content_core.cjs` (1,224 lines)

**File**: `actions/setup/js/sanitize_content_core.cjs` | **Lines**: 1,224
**Commit**: `a1e4bf0`
**Issue**: Core sanitization logic has grown to over 1,200 lines.
**Suggested fix**: Split into `sanitize_patterns.cjs` (regex definitions), `sanitize_transforms.cjs` (transformation logic), and keep `sanitize_content_core.cjs` as the public API surface.

---

#### File Size: `actions/setup/js/runtime_import.cjs` (1,022 lines)

**File**: `actions/setup/js/runtime_import.cjs` | **Lines**: 1,022
**Commit**: `a1e4bf0`
**Issue**: Just over the warning threshold.
**Suggested fix**: Monitor for growth. If it exceeds 1,200 lines, extract runtime-specific import helpers into per-runtime files (`runtime_import_node.cjs`, etc.).

---

#### File Size: `actions/setup/js/safe_outputs_handlers.cjs` (1,013 lines)

**File**: `actions/setup/js/safe_outputs_handlers.cjs` | **Lines**: 1,013
**Commit**: `a1e4bf0`
**Issue**: Just over the warning threshold.
**Suggested fix**: Monitor for growth. If individual handlers grow, extract them into per-output-type handler files.

---

#### File Size: `pkg/workflow/domains.go` (1,015 lines)

**File**: `pkg/workflow/domains.go` | **Lines**: 1,015
**Commit**: `a1e4bf0`
**Issue**: Go file slightly exceeds the 1,000-line threshold with 24 exported identifiers.
**Suggested fix**: Extract domain-specific validation logic into sub-files such as `domains_network.go` and `domains_tools.go` following the existing pattern in the `pkg/workflow/` directory.

---

#### File Size: `pkg/workflow/cache.go` (1,002 lines)

**File**: `pkg/workflow/cache.go` | **Lines**: 1,002
**Commit**: `a1e4bf0`
**Issue**: Marginally over the 1,000-line threshold. Functions are well-sized (none exceed 200 lines).
**Suggested fix**: Monitor for growth. If cache types and cache operations diverge, split into `cache_types.go` and `cache_operations.go`.

---

### i️ INFO Violations

> Informational findings. Consider addressing in future refactoring.

| File | Exported Identifiers | Note |
|------|---------------------|------|
| `pkg/constants/job_constants.go` | 62 | Constants-only file — acceptable, but consider splitting by domain (activation, agent, conclusion) |
| `pkg/constants/constants.go` | 40 | Consider splitting into focused constants files |
| `pkg/constants/version_constants.go` | 30 | Version constants — acceptable as-is |
| `pkg/styles/theme.go` | 27 | Theme/style constants — acceptable |
| `pkg/workflow/domains.go` | 24 | Already flagged as WARNING above |
| `pkg/workflow/tools_types.go` | 20 | Types file — may benefit from splitting by tool category |
| `pkg/workflow/permissions_factory.go` | 20 | Consider splitting factory methods by permission domain |
| `pkg/workflow/expression_builder.go` | 20 | Monitor for growth |
| `pkg/workflow/compiler_types.go` | 20 | Types file — acceptable |
| `pkg/console/console_wasm.go` | 20 | Platform-specific file — acceptable |
| `pkg/cli/logs_models.go` | 19 | Models file — acceptable |
| `pkg/cli/audit_report.go` | 18 | Monitor for growth |
| `pkg/console/console.go` | 17 | Core console API — acceptable |
| `pkg/actionpins/actionpins.go` | 17 | Monitor for growth |
| `pkg/workflow/agentic_engine.go` | 16 | Monitor for growth |
| `pkg/workflow/js.go` | 14 | Monitor for growth |
| `pkg/workflow/expression_nodes.go` | 11 | Marginally over threshold — acceptable |

---

### Configuration

Thresholds from `.architecture.yml`:
- File size BLOCKER: **2,000 lines**
- File size WARNING: **1,000 lines**
- Function size: **200 lines**
- Max public exports: **10**

### Action Checklist

- [ ] Decompose `generatePatchPreview()` in `create_pull_request.cjs` — 1,514-line function is the highest priority
- [ ] Extract `buildEngineFailureContext()` into sub-builders in `handle_agent_failure.cjs`
- [ ] Split `safe_output_handler_manager.cjs` — two 500+ line functions need decomposition
- [ ] Break up `update_project.cjs` — field validation logic should be separated
- [ ] Split `sanitize_content_core.cjs` — patterns, transforms, and public API should be separate
- [ ] Monitor `pkg/workflow/domains.go` and `cache.go` — marginally over threshold
- [ ] Review `pkg/constants/job_constants.go` — 62 exports suggests it could be split by domain
- [ ] Close this issue once all WARNING violations are resolved

> 🏛️ *Thresholds are configured in `.architecture.yml` at the repository root.*

> 🏛️ *Architecture report by [Architecture Guardian](https://github.com/github/gh-aw/actions/runs/24784724848)* · ● 1.7M · [◷](https://github.com/search?q=repo%3Agithub%2Fgh-aw+is%3Aissue+%22gh-aw-workflow-call-id%3A+github%2Fgh-aw%2Farchitecture-guardian%22&type=issues)