From 9285f3e011b4d95587f1df9cf203020483c3d67d Mon Sep 17 00:00:00 2001 From: Lucas Berger Date: Wed, 4 Feb 2026 17:00:37 -0500 Subject: [PATCH] docs(10.1): capture phase context Phase 10.1: Aggressive Workflow Modularization - Implementation decisions documented - Phase boundary established - Fixed misnamed phase directories (10.1/10.2) Co-Authored-By: Claude Opus 4.5 --- .../10.1-CONTEXT.md | 71 +++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 .planning/phases/10.1-aggressive-workflow-modularization/10.1-CONTEXT.md 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 + + +## 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. + + + + +## 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 + + + + +## 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) + + + + +## Deferred Ideas + +None — discussion stayed within phase scope + + + +--- + +*Phase: 10.1-aggressive-workflow-modularization* +*Context gathered: 2026-02-04*