docs(10.1-01): analyze main workflow domain boundaries
Domain analysis of 192-node main workflow: - Batch UI/Orchestration: 48 nodes (HIGH extraction value) - Container List/Menu: 17 nodes (HIGH extraction feasibility) - Confirmation Dialogs: 30 nodes (MEDIUM extraction feasibility) - Matching/Disambiguation: 15 nodes (optional extraction) - Telegram Responses: 58 nodes (LOCKED to remain in main) Key finding: Target of 50-80 nodes not achievable due to locked Telegram response pattern. Realistic target: 115-125 nodes. Recommended extraction order: - Wave 2: Batch UI + Container List - Wave 3: Confirmation + Matching (optional)
This commit is contained in:
Lucas Berger
@@ -0,0 +1,297 @@
|
|||||||
|
# Domain Boundary Analysis - Phase 10.1-01
|
||||||
|
|
||||||
|
**Analyzed:** 2026-02-05
|
||||||
|
**Main Workflow:** 192 nodes
|
||||||
|
**Target:** 50-80 nodes after extraction
|
||||||
|
|
||||||
|
## Executive Summary
|
||||||
|
|
||||||
|
Analysis of the main workflow (192 nodes) reveals that reaching the target of 50-80 nodes is **not feasible** without fundamentally restructuring the Telegram response pattern (which is a locked decision to keep in main workflow).
|
||||||
|
|
||||||
|
**Key insight:** The main workflow contains 58 Telegram response nodes (Answer*, Send*, Delete*) that are locked decisions to remain in main workflow per CONTEXT.md. Combined with 22 essential infrastructure nodes, this leaves a baseline of 80 nodes before any domain logic.
|
||||||
|
|
||||||
|
**Realistic target:** 100-120 nodes (50% reduction from 192) by extracting highest-value domains.
|
||||||
|
|
||||||
|
## Node Distribution
|
||||||
|
|
||||||
|
| Category | Count | Notes |
|
||||||
|
|----------|-------|-------|
|
||||||
|
| Total nodes | 192 | Current state |
|
||||||
|
| Telegram responses (Answer/Send/Delete) | 58 | LOCKED: Must stay in main per CONTEXT.md |
|
||||||
|
| Infrastructure (trigger, routing, auth) | 22 | Must stay in main |
|
||||||
|
| Sub-workflow calls (existing) | 9 | Execute Workflow nodes |
|
||||||
|
| **Baseline (cannot extract)** | **89** | Minimum main workflow size |
|
||||||
|
| **Extractable candidates** | **103** | Domain logic nodes |
|
||||||
|
|
||||||
|
## Domain Analysis
|
||||||
|
|
||||||
|
### Domain 1: Batch UI and Orchestration
|
||||||
|
|
||||||
|
**Node count:** 48 nodes
|
||||||
|
**Cohesion:** HIGH - Single user-facing outcome (batch selection and execution)
|
||||||
|
|
||||||
|
**Nodes included:**
|
||||||
|
- Build Batch Keyboard, Build Batch Select Keyboard
|
||||||
|
- Initialize Batch State, Handle Batch Toggle/Clear/Exec
|
||||||
|
- Prepare Batch Loop, Prepare Batch Nav, Prepare Batch Exec
|
||||||
|
- Match Batch Containers, Is Batch Complete, Is Batch Command
|
||||||
|
- Detect Batch Command, Needs Batch Confirmation
|
||||||
|
- Rebuild Batch Select Keyboard, Edit Batch Select Keyboard
|
||||||
|
- Various batch-related Code nodes
|
||||||
|
|
||||||
|
**Entry points (16):**
|
||||||
|
- Keyword Router -> Detect Batch Command
|
||||||
|
- Route Callback -> Answer Batch * queries
|
||||||
|
- Edit Progress Message -> Route Batch Loop Action
|
||||||
|
- Fetch containers -> Rebuild/Prepare nodes
|
||||||
|
|
||||||
|
**Exit points (12):**
|
||||||
|
- Handle Batch * -> Prepare Next Iteration
|
||||||
|
- Is Batch Complete -> Build Progress Message
|
||||||
|
- Match Batch Containers -> Needs Disambiguation
|
||||||
|
- Execute Batch * -> sub-workflows
|
||||||
|
|
||||||
|
**External dependencies:**
|
||||||
|
- Requires telegram response nodes (Send Batch *, Delete Batch *)
|
||||||
|
- Requires confirmation flow (Edit To Stop Confirmation)
|
||||||
|
- Requires iteration loop with main workflow (Prepare Next Iteration)
|
||||||
|
|
||||||
|
**Extraction feasibility:** MEDIUM-HIGH
|
||||||
|
- Pro: Large cohesive domain, clear user-facing outcome
|
||||||
|
- Con: Complex integration with iteration loop and confirmation flow
|
||||||
|
- Con: 12+ Telegram response nodes would need refactoring to return data only
|
||||||
|
|
||||||
|
**RECOMMENDATION:** EXTRACT (Wave 2)
|
||||||
|
- Estimated reduction: 30-35 nodes (some stay for orchestration)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Domain 2: Confirmation Dialogs
|
||||||
|
|
||||||
|
**Node count:** 30-37 nodes (depending on boundary definition)
|
||||||
|
**Cohesion:** MEDIUM - Multiple confirmation types (stop, update, expiry)
|
||||||
|
|
||||||
|
**Nodes included:**
|
||||||
|
- Build Stop Confirmation, Build Update Confirmation
|
||||||
|
- Check Confirm Expired, Check Update All Expired
|
||||||
|
- Handle Confirm Expired, Handle Cancel
|
||||||
|
- Get Container For Stop, Get Container For Cancel
|
||||||
|
- Prepare Confirmed Stop, Execute Confirmed Stop
|
||||||
|
- Format Confirmed Stop Result, Handle Confirmed Stop Result
|
||||||
|
- Build Update All Confirmation
|
||||||
|
- All expiry handling nodes
|
||||||
|
|
||||||
|
**Entry points (11):**
|
||||||
|
- Route Action Type -> Build Stop/Update Confirmation
|
||||||
|
- Route Callback -> Answer Confirm/Cancel/Expired callbacks
|
||||||
|
- Has Updates Available -> Build Update All Confirmation
|
||||||
|
|
||||||
|
**Exit points (3):**
|
||||||
|
- Route Confirm Action -> Prepare Callback Update Input
|
||||||
|
- Check Update All Expired -> Get Update All Data
|
||||||
|
- Delete Update All Confirm -> Fetch Containers For Update All Exec
|
||||||
|
|
||||||
|
**External dependencies:**
|
||||||
|
- Requires Get Container nodes (may need to include or pass as input)
|
||||||
|
- Requires Answer* and Send* telegram nodes
|
||||||
|
|
||||||
|
**Extraction feasibility:** MEDIUM
|
||||||
|
- Pro: Clear domain boundary (all confirmations)
|
||||||
|
- Con: Multiple entry/exit points
|
||||||
|
- Con: Heavy integration with batch flow
|
||||||
|
|
||||||
|
**RECOMMENDATION:** EXTRACT (Wave 3)
|
||||||
|
- Estimated reduction: 15-20 nodes
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Domain 3: Container List and Menu
|
||||||
|
|
||||||
|
**Node count:** 17 nodes
|
||||||
|
**Cohesion:** HIGH - Single outcome (container list display and navigation)
|
||||||
|
|
||||||
|
**Nodes included:**
|
||||||
|
- Docker List Containers, Docker List for Action, Docker List for Update
|
||||||
|
- Get Containers For List, Get Single Container
|
||||||
|
- Build Container List Keyboard, Build Paginated List
|
||||||
|
- Build Container Submenu, Build Container Submenu Direct
|
||||||
|
- Check Single Container, Edit Container List
|
||||||
|
- Show Menu
|
||||||
|
|
||||||
|
**Entry points (7):**
|
||||||
|
- Keyword Router -> Docker List Containers, Show Menu
|
||||||
|
- Parse Action/Update Command -> Docker List for Action/Update
|
||||||
|
- Prepare Batch Cancel Return -> Get Containers For List
|
||||||
|
- Route Callback -> Answer List Callback
|
||||||
|
|
||||||
|
**Exit points (3):**
|
||||||
|
- Build Container List Keyboard -> Check Single Container
|
||||||
|
- Docker List for Action -> Match Container
|
||||||
|
- Docker List for Update -> Match Update Container
|
||||||
|
|
||||||
|
**External dependencies:**
|
||||||
|
- Requires Send Container List, Send Container Submenu (Telegram nodes)
|
||||||
|
- Feeds into Match Container for subsequent actions
|
||||||
|
|
||||||
|
**Extraction feasibility:** HIGH
|
||||||
|
- Pro: Clear boundaries, cohesive function
|
||||||
|
- Pro: Relatively isolated
|
||||||
|
- Con: Small size (17 nodes) - borderline threshold
|
||||||
|
|
||||||
|
**RECOMMENDATION:** EXTRACT (Wave 2)
|
||||||
|
- Estimated reduction: 12-15 nodes
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Domain 4: Matching and Disambiguation
|
||||||
|
|
||||||
|
**Node count:** 15 nodes
|
||||||
|
**Cohesion:** HIGH - Single outcome (container matching and suggestions)
|
||||||
|
|
||||||
|
**Nodes included:**
|
||||||
|
- Match Container, Match Update Container
|
||||||
|
- Find Closest Match, Find Container For Callback Update
|
||||||
|
- Check Match Count, Check Update Match Count
|
||||||
|
- Needs Disambiguation, Check Suggestion
|
||||||
|
- Build Disambiguation Message, Build Suggestion Keyboard
|
||||||
|
- Delete Suggestion Message
|
||||||
|
|
||||||
|
**Entry points:**
|
||||||
|
- Docker List * -> Match Container / Match Update Container
|
||||||
|
- Match Batch Containers -> Needs Disambiguation
|
||||||
|
|
||||||
|
**Exit points:**
|
||||||
|
- Match found -> specific action handlers
|
||||||
|
- No match -> Send No Match / Send Suggestion
|
||||||
|
|
||||||
|
**External dependencies:**
|
||||||
|
- Requires Send Disambiguation, Send Suggestion, Send No Match (Telegram nodes)
|
||||||
|
|
||||||
|
**Extraction feasibility:** HIGH
|
||||||
|
- Pro: Very cohesive function
|
||||||
|
- Pro: Well-defined input (container list + search term)
|
||||||
|
- Con: Size at lower threshold (15 nodes)
|
||||||
|
|
||||||
|
**RECOMMENDATION:** EXTRACT (Wave 3) or DEFER
|
||||||
|
- If extracted: 10-12 node reduction
|
||||||
|
- Alternative: Keep in main, it's compact and well-integrated
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Domain 5: Telegram Responses (NOT RECOMMENDED)
|
||||||
|
|
||||||
|
**Node count:** 58 nodes (Answer*, Send*, Delete* patterns)
|
||||||
|
**Cohesion:** MEDIUM - All Telegram API calls, but different contexts
|
||||||
|
|
||||||
|
**Analysis:**
|
||||||
|
Per CONTEXT.md locked decision: "Main workflow sends ALL Telegram responses (sub-workflows return data only)"
|
||||||
|
|
||||||
|
This domain is explicitly locked to remain in main workflow. The rationale from CONTEXT.md and RESEARCH.md:
|
||||||
|
- Sub-workflows return structured data
|
||||||
|
- Main workflow handles user-facing responses
|
||||||
|
- Centralizing error handling at one layer
|
||||||
|
- Avoiding handoff complexity between sub-workflows
|
||||||
|
|
||||||
|
**RECOMMENDATION:** DO NOT EXTRACT (Locked decision)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Domain 6: Update All Operations
|
||||||
|
|
||||||
|
**Node count:** 12 nodes
|
||||||
|
**Cohesion:** HIGH - Single feature (update all containers)
|
||||||
|
|
||||||
|
**Nodes included:**
|
||||||
|
- Get All Containers For Update All
|
||||||
|
- Get Update All Data, Check Available Updates, Has Updates Available
|
||||||
|
- Fetch Containers For Update All Exec, Prepare Update All Batch
|
||||||
|
- Build/Send/Delete Update All * nodes
|
||||||
|
|
||||||
|
**Entry points:**
|
||||||
|
- Keyword Router -> Get All Containers For Update All
|
||||||
|
- Route Callback -> Answer Update All *
|
||||||
|
|
||||||
|
**Exit points:**
|
||||||
|
- Prepare Update All Batch -> Send Batch Start Message
|
||||||
|
- Get All Containers -> Check Available Updates
|
||||||
|
|
||||||
|
**Extraction feasibility:** MEDIUM
|
||||||
|
- Pro: Cohesive feature
|
||||||
|
- Con: Size at lower threshold (12 nodes)
|
||||||
|
- Con: Heavy overlap with batch flow
|
||||||
|
|
||||||
|
**RECOMMENDATION:** DEFER or MERGE with Batch
|
||||||
|
- Small size, better to keep as part of batch orchestration
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Extraction Plan Summary
|
||||||
|
|
||||||
|
### Recommended Extractions
|
||||||
|
|
||||||
|
| Priority | Domain | Nodes | Reduction | Complexity |
|
||||||
|
|----------|--------|-------|-----------|------------|
|
||||||
|
| Wave 2 | Batch UI/Orchestration | 48 | 30-35 | HIGH |
|
||||||
|
| Wave 2 | Container List/Menu | 17 | 12-15 | LOW |
|
||||||
|
| Wave 3 | Confirmation Dialogs | 30 | 15-20 | MEDIUM |
|
||||||
|
| Wave 3 | Matching (optional) | 15 | 10-12 | LOW |
|
||||||
|
|
||||||
|
### Expected Outcome
|
||||||
|
|
||||||
|
| Metric | Value |
|
||||||
|
|--------|-------|
|
||||||
|
| Current nodes | 192 |
|
||||||
|
| After Wave 2 (Batch + List) | ~145-150 |
|
||||||
|
| After Wave 3 (Confirm + Match) | ~115-125 |
|
||||||
|
| Target from CONTEXT.md | 50-80 |
|
||||||
|
| **Realistic achievable** | **115-125** |
|
||||||
|
|
||||||
|
### Why Target Cannot Be Met
|
||||||
|
|
||||||
|
The 50-80 node target from CONTEXT.md assumes Telegram responses could be extracted. Analysis shows:
|
||||||
|
|
||||||
|
1. **58 Telegram response nodes** are locked to remain in main workflow
|
||||||
|
2. **22 infrastructure nodes** (trigger, routing, auth, sub-workflow calls) must remain
|
||||||
|
3. **Baseline: 80 nodes minimum** before any domain logic
|
||||||
|
|
||||||
|
To reach 50-80 nodes, the Telegram response handling would need to be reconsidered:
|
||||||
|
|
||||||
|
**Option A:** Accept 115-125 nodes as realistic target (recommended)
|
||||||
|
**Option B:** Reconsider Telegram centralization (extract to sub-workflow despite complexity)
|
||||||
|
**Option C:** Create "thin response proxy" pattern where sub-workflows return response specs, main workflow has single "Send Response" dispatcher
|
||||||
|
|
||||||
|
## Domains NOT Recommended for Extraction
|
||||||
|
|
||||||
|
| Domain | Reason |
|
||||||
|
|--------|--------|
|
||||||
|
| Telegram Responses | Locked decision per CONTEXT.md |
|
||||||
|
| Update All | Too small (12 nodes), better merged with Batch |
|
||||||
|
| Action Routing | Infrastructure, tightly coupled to routing |
|
||||||
|
| Parse/Prepare nodes | Scattered, not cohesive domain |
|
||||||
|
|
||||||
|
## Risk Assessment
|
||||||
|
|
||||||
|
### Batch Extraction Risks
|
||||||
|
- **Iteration loop complexity:** Batch uses Prepare Next Iteration -> Is Batch Complete loop that spans main workflow
|
||||||
|
- **Confirmation integration:** Batch stop confirmation shares nodes with general confirmation
|
||||||
|
- **Mitigation:** May need to keep iteration orchestration in main, extract batch UI only
|
||||||
|
|
||||||
|
### General Risks
|
||||||
|
- **Data chain references:** Sub-workflows need explicit input passing, no `$('Node Name')` references to main workflow nodes
|
||||||
|
- **Testing complexity:** More sub-workflows = more integration points to verify
|
||||||
|
- **Mitigation:** Thorough UAT after each wave, explicit input contracts
|
||||||
|
|
||||||
|
## Next Steps
|
||||||
|
|
||||||
|
1. **User approval** on extraction boundaries
|
||||||
|
2. **Wave 2 execution** (Plans 10.1-02, 10.1-03):
|
||||||
|
- Extract Batch UI sub-workflow
|
||||||
|
- Extract Container List sub-workflow
|
||||||
|
3. **Wave 3 execution** (Plans 10.1-04, 10.1-05):
|
||||||
|
- Extract Confirmation sub-workflow
|
||||||
|
- Optionally extract Matching sub-workflow
|
||||||
|
4. **Final integration verification**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*Analysis complete. Awaiting user approval on extraction boundaries.*
|
||||||
Reference in New Issue
Block a user