# 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.*