unraid-docker-manager/.planning/phases/10.1-aggressive-workflow-modularization/10.1-01-domain-analysis.md

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.