unraid-docker-manager/.planning/phases/10-workflow-modularization/10-05-PLAN.md

phase, plan, type, wave, depends_on, files_modified, autonomous, must_haves

phase	plan	type	wave	depends_on	files_modified	autonomous	must_haves
10-workflow-modularization	05	execute	4	10-04	n8n-workflow.json n8n-container-logs.json	true	truths artifacts key_links Batch update uses Container Update sub-workflow Batch actions use Container Actions sub-workflow Logs flow extracted to sub-workflow Main workflow reduced to ~120-140 nodes path provides contains n8n-container-logs.json Container logs sub-workflow executeWorkflowTrigger path provides max_nodes n8n-workflow.json Streamlined main workflow 150 from to via pattern n8n-workflow.json n8n-container-logs.json Execute Sub-workflow node executeWorkflow

Complete workflow modularization by wiring batch operations to existing sub-workflows and extracting the logs flow.

Purpose: The main workflow is still 209 nodes with significant duplication. Batch operations duplicate logic that exists in sub-workflows. Logs flow is self-contained and should be extracted. Target: reduce main workflow to ~120-140 nodes while maintaining all functionality.

Output: Streamlined main workflow using sub-workflows for all container operations, plus new logs sub-workflow.

<execution_context> @/home/luc/.claude/get-shit-done/workflows/execute-plan.md @/home/luc/.claude/get-shit-done/templates/summary.md </execution_context>

@.planning/PROJECT.md @.planning/ROADMAP.md @.planning/phases/10-workflow-modularization/10-01-SUMMARY.md @.planning/phases/10-workflow-modularization/10-02-SUMMARY.md @.planning/phases/10-workflow-modularization/10-03-SUMMARY.md @.planning/phases/10-workflow-modularization/10-04-SUMMARY.md @n8n-workflow.json @n8n-container-update.json @n8n-container-actions.json Task 1: Wire batch update to Container Update sub-workflow n8n-workflow.json Replace inline batch update logic with calls to the existing Container Update sub-workflow.

Current state:

• Batch update has its own inline logic (Prepare Update All Batch, etc.)
• Single update uses Container Update sub-workflow
• This creates duplication

Changes needed:

1. Find batch update execution path (around "Prepare Update All Batch", batch loop nodes)

2. Replace inline update logic with:

   • Loop/SplitInBatches node to iterate over containers
   • Execute Sub-workflow node calling Container Update for each container
   • Aggregate results

3. Remove redundant nodes:

   • Any batch-specific update execution nodes
   • Duplicate Docker API calls for update
   • Keep: batch UI, confirmation, progress display nodes

Input to sub-workflow (per container):

{
  "containerId": "from batch list",
  "containerName": "from batch list",
  "chatId": "from batch context",
  "messageId": "for progress updates",
  "responseMode": "inline"
}

Key principle: The sub-workflow handles the actual update. Main workflow handles:

• Batch selection/confirmation UI
• Loop orchestration
• Progress aggregation/display
• Batch update path calls Execute Sub-workflow with Container Update workflow ID
• No duplicate update logic remains in main workflow for batch path
• Batch update still works end-to-end Batch update wired to use Container Update sub-workflow

Task 2: Wire batch actions to Container Actions sub-workflow n8n-workflow.json Replace inline batch action logic with calls to the existing Container Actions sub-workflow.

Current state (25 batch action nodes):

• Execute Batch Action, Execute Batch Container Action, Execute Batch Action 2
• Route Batch Action, Route Batch Loop Action
• Build Batch Action Command, etc.
• These duplicate logic in Container Actions sub-workflow

Changes needed:

1. Find batch action execution paths

2. Replace inline action logic with:

   • Loop/SplitInBatches to iterate over selected containers
   • Execute Sub-workflow node calling Container Actions for each
   • Aggregate results

3. Remove redundant nodes:

   • Execute Batch Action, Execute Batch Container Action
   • Build Batch Action Command
   • Route Batch Loop Action (if only routing to inline execution)
   • Keep: batch UI, confirmation dialogs, progress display

Input to sub-workflow (per container):

{
  "containerId": "from batch list",
  "containerName": "from batch list",
  "action": "start|stop|restart",
  "chatId": "from batch context",
  "messageId": "for progress updates",
  "responseMode": "inline"
}

Estimated node reduction: ~15-20 nodes removed

• Batch start/stop/restart paths call Execute Sub-workflow with Container Actions workflow ID
• No duplicate action execution logic in main workflow
• Batch actions still work end-to-end Batch actions wired to use Container Actions sub-workflow

Task 3: Extract logs flow to sub-workflow n8n-workflow.json, n8n-container-logs.json Create a new Container Logs sub-workflow and wire the main workflow to use it.

Current logs nodes (17 total):

• Parse Logs Command
• Docker List for Logs
• Match Logs Container
• Check Logs Match Count
• Build Logs Command
• Execute Logs
• Format Logs
• Send Logs Response/Error
• Format Logs No Match/Multiple
• Prepare Logs Action
• Get Container For Logs
• Build Logs Action Command
• Execute Logs Action
• Format Logs Action Result
• Send Logs Result

Create n8n-container-logs.json:

Input contract:

{
  "containerId": "string - Docker container ID (optional if using name)",
  "containerName": "string - Container name for matching",
  "lineCount": "number - Number of log lines (default 50)",
  "chatId": "number - Telegram chat ID",
  "messageId": "number - Message ID for inline edits (0 for text mode)",
  "responseMode": "string - 'text' or 'inline'"
}

Output contract:

{
  "success": "boolean",
  "message": "string - Formatted logs or error message",
  "containerName": "string",
  "lineCount": "number"
}

Sub-workflow flow:

1. If containerId provided, use directly; else match by name
2. Execute docker logs command
3. Format output (truncate if needed, add header)
4. Return formatted result

Main workflow changes:

1. Replace 17 logs nodes with:
   • Code node to prepare sub-workflow input
   • Execute Sub-workflow node
   • Handle result (send message)
2. Keep: Routing to logs path, final message sending

Estimated reduction: 17 nodes -> ~3-4 nodes in main + 10-12 in sub-workflow

• n8n-container-logs.json exists and is valid
• Main workflow has Execute Sub-workflow node for logs
• Text "logs " command works
• Inline keyboard logs button works
• "logs 100" (with line count) works Logs flow extracted to sub-workflow and deployed

Task 4: Clean up and deploy n8n-workflow.json, n8n-container-logs.json Final cleanup and deployment of all workflow changes.

1. Remove orphaned nodes:

   • Any nodes no longer connected after refactoring
   • Duplicate/vestigial nodes from prior iterations

2. Verify node count:

   • Target: ~120-140 nodes in main workflow
   • Document actual reduction achieved

3. Deploy all workflows to n8n:

   • Import n8n-container-logs.json (new)
   • Update main workflow
   • Verify all three sub-workflows are active

4. Test all paths:

   • Single update (text + inline)
   • Batch update
   • Single actions (start/stop/restart via text + inline)
   • Batch actions
   • Logs (text + inline)

5. Document final architecture:

   Main Workflow (n8n-workflow.json)
   ├── Telegram Trigger + Auth
   ├── Command Routing
   ├── Confirmation Dialogs
   ├── Batch UI/Selection
   └── Sub-workflow Orchestration
       ├── Container Update (all update operations)
       ├── Container Actions (all start/stop/restart)
       └── Container Logs (all logs operations)
   

- Main workflow node count: 120-150 nodes - All functionality works - No orphan nodes - Architecture documented in SUMMARY Modularization complete, all workflows deployed and verified 1. Main workflow reduced from 209 to ~120-140 nodes 2. Batch update uses Container Update sub-workflow 3. Batch actions use Container Actions sub-workflow 4. Logs flow uses new Container Logs sub-workflow 5. All text commands work (status, start, stop, restart, update, logs) 6. All inline keyboard flows work 7. All batch operations work 8. No duplicate container operation logic in main workflow

<success_criteria>

• Main workflow is manageable size (~120-140 nodes)
• All container operations routed through 3 sub-workflows
• No code duplication between single and batch paths
• All existing functionality preserved </success_criteria>

After completion, create `.planning/phases/10-workflow-modularization/10-05-SUMMARY.md`