Lucas Berger
9285f3e011
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>
72 lines
2.8 KiB
Markdown
72 lines
2.8 KiB
Markdown
# 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*
|