diff --git a/.planning/phases/10.1-aggressive-workflow-modularization/10.1-CONTEXT.md b/.planning/phases/10.1-aggressive-workflow-modularization/10.1-CONTEXT.md
new file mode 100644
index 0000000..86b27cd
--- /dev/null
+++ b/.planning/phases/10.1-aggressive-workflow-modularization/10.1-CONTEXT.md
@@ -0,0 +1,71 @@
+# 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*