refactor(init): initCommand action handler 1704 lines

[dean0x]

Problem

src/cli/commands/init.ts:296-2000 — the initCommand action handler is a ~1,704-line monolithic function. This PR (PR #316) added ~28 executable lines to it (attribution wizard call site), pushing the function further into unmaintainability.

A function this large is difficult to test in isolation, hard to review, and resistant to incremental refactoring. Line count alone isn't the issue; architecture is: the Advanced prompt list, phase sequencing, and settings pass all live inline with zero separation of concerns.

Current Status

• Pre-existing: Monolithic structure predates PR feat: gate AI-attribution suppression behind typed flag with init wizard #316
• PR feat: gate AI-attribution suppression behind typed flag with init wizard #316 growth: ~28 lines added (attribution wizard integration)
• Confidence: 95% (from complexity review)
• Scope outside this PR: Requires full architectural restructure, not a contained fix
• Partial mitigation in PR feat: gate AI-attribution suppression behind typed flag with init wizard #316:
  • complexity-01 extracted shared prompt-IO seam (src/cli/commands/prompt-io.ts)
  • testing-02 extracted attribution wizard helpers (attributionSeedFrom, applyAttributionAnswer)

Expected Behavior

The function should be decomposed into separately testable units with clear responsibilities:

1. Advanced prompt list construction (what prompts, in what order, with what defaults)
2. Phase sequencing (flow through Recommended vs Advanced modes)
3. Settings pass (applying wizard answers to settings.json)

Each unit should have unit tests that can run without invoking the full init command.

Suggested Sequencing

Phase 1: Extract the Advanced prompt list definition

• Move prompt construction and phase sequencing into a separate module
• Example: src/cli/commands/init-wizard.ts — pure definition, no I/O

Phase 2: Decompose the settings application logic

• applyAttributionAnswer / applyCageAnswer patterns become a registry
• Each setting has a dedicated apply_* function, tested independently

Phase 3: Reduce init.ts to a thin orchestrator

• Call the wizard, get the answers, apply them, done
• Line count target: <500 lines for the action handler

Acceptance Criteria

• Prompt list extracted to separately testable module
• Phase sequencing logic isolated with clear input/output contracts
• Settings application decomposed into per-setting functions
• initCommand line count reduced to <500
• All new modules have unit test coverage
• Existing e2e tests pass without modification
• Code review surfaces no new regressions

Related

• PR feat: gate AI-attribution suppression behind typed flag with init wizard #316 (feat/315-gate-attribution-flag) — triggered the growth
• Partial fixes landed: complexity-01 (prompt-IO), testing-02 (wizard helpers)
• Source: complexity.md review finding, 2026-09-01
• Ref: src/cli/commands/init.ts:296-2000
• Architectural: CLAUDE.md § "LLM-vs-plumbing principle" (seams and orchestration)