# Phase 10.1: Aggressive Workflow Modularization - Context

**Gathered:** 2026-02-04
**Status:** Ready for planning

<domain>
## Phase Boundary

Decompose main workflow (192 nodes) to minimal trigger/auth/routing (~50-80 nodes) with domain sub-workflows handling actual logic. Existing sub-workflows (Update, Actions, Logs) are open to restructuring for better boundaries.

</domain>

<decisions>
## Implementation Decisions

### Decomposition Boundaries
- Claude analyzes workflow and proposes optimal domain boundaries (user approves)
- Existing sub-workflows (Update, Actions, Logs) are open to restructuring
- Extraction threshold: cohesive behavior (one user-facing outcome) + meaningful size (8-15+ nodes)
- Don't extract small utility groups (2-3 nodes) — overhead not worth it
- Target: no workflow exceeds ~80-100 nodes
- Claude analyzes current batch patterns and recommends whether batch orchestration merits separate sub-workflows

### Main Workflow Retention
- Main workflow keeps: trigger, auth, keyword routing, sub-workflow dispatch
- Main workflow sends all Telegram responses (sub-workflows return data only)
- Centralized error handling: sub-workflows return/throw errors, main catches and responds
- Claude analyzes whether dedicated Telegram sub-workflow is valuable (user mentioned potential for complexity in handoffs)
- Claude decides routing structure (single switch vs grouped)

### Sub-workflow Contracts
- Input pattern: common fields (chatId, messageId) + domain-specific fields
- Claude decides output shape (structured response vs raw data)
- File naming: `n8n-{domain}.json` (shorter pattern)
- Rename existing sub-workflows to match: n8n-update.json, n8n-actions.json, n8n-logs.json

### Migration Approach
- Grouped extraction: extract related domains together, verify as group
- Verification: automated checks first, then manual UAT
- If Telegram sub-workflow is validated, create it first as foundation
- Rollback strategy: git commits + explicit backup files before changes

### Claude's Discretion
- Optimal domain boundaries (present for approval)
- Whether Telegram sub-workflow adds value vs overhead
- Batch orchestration architecture (separate sub-workflows or integrated)
- Output shape for sub-workflows (structured vs raw)
- Routing structure in main workflow

</decisions>

<specifics>
## Specific Ideas

- "No workflow too large to work with" — pragmatic threshold over strict rules
- "Telegram sub-workflow could centralize quirks" — message sending, editing, keyboards, error handling, callback answers all in one place
- Reuse pattern: batch operations should call single-container sub-workflows (already working this way)

</specifics>

<deferred>
## Deferred Ideas

None — discussion stayed within phase scope

</deferred>

---

*Phase: 10.1-aggressive-workflow-modularization*
*Context gathered: 2026-02-04*