Files

T

Lucas Berger 9285f3e011 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 <noreply@anthropic.com>

2026-02-04 17:00:37 -05:00

2.8 KiB

Raw Blame History

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

2.8 KiB Raw Blame History