From fba90a6cc4071d7a9490735238dba75534c95e36 Mon Sep 17 00:00:00 2001 From: Lucas Berger Date: Wed, 4 Feb 2026 20:29:21 -0500 Subject: [PATCH] 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) --- .../10.1-01-domain-analysis.md | 297 ++++++++++++++++++ 1 file changed, 297 insertions(+) create mode 100644 .planning/phases/10.1-aggressive-workflow-modularization/10.1-01-domain-analysis.md diff --git a/.planning/phases/10.1-aggressive-workflow-modularization/10.1-01-domain-analysis.md b/.planning/phases/10.1-aggressive-workflow-modularization/10.1-01-domain-analysis.md new file mode 100644 index 0000000..5b4c49a --- /dev/null +++ b/.planning/phases/10.1-aggressive-workflow-modularization/10.1-01-domain-analysis.md @@ -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.*