Phase 10: Workflow Modularization - 4 plan(s) in 3 wave(s) - Wave 1: Orphan cleanup (1 plan) - Wave 2: Sub-workflow extraction (2 plans parallel) - Wave 3: Integration verification (1 plan) - Ready for execution Plans: - 10-01: Remove 8 orphan nodes - 10-02: Extract container-update sub-workflow (DEBT-03) - 10-03: Extract container-actions sub-workflow - 10-04: Integration verification with user checkpoint Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
7.8 KiB
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 | 03 | execute | 2 |
|
|
true |
|
Purpose: Like the update flow, start/stop/restart actions are handled in both text command and callback paths. Extracting to a sub-workflow creates a single source of truth for container state changes and supports MOD-01/MOD-02 requirements.
Output: New container-actions sub-workflow JSON file and updated main workflow that calls it from both text and callback paths.
<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-RESEARCH.md @.planning/phases/10-workflow-modularization/10-01-SUMMARY.md @n8n-workflow.json Task 1: Create container-actions sub-workflow n8n-container-actions.json Create a new sub-workflow file `n8n-container-actions.json` that encapsulates container start/stop/restart operations.Input contract (Execute Sub-workflow Trigger with defined fields):
{
"containerId": "string - Docker container ID",
"containerName": "string - Container name for messages",
"action": "string - 'start' | 'stop' | 'restart'",
"chatId": "number - Telegram chat ID",
"messageId": "number - Message ID for inline edits (0 for text mode)",
"responseMode": "string - 'text' or 'inline'"
}
Flow to implement:
- Route based on action type (Switch node)
- For each action:
- Call Docker API endpoint (/containers/{id}/start, /stop, /restart)
- Handle success response
- Handle error response
- Format result message
- Return result (or send message directly if simpler)
Output contract:
{
"success": "boolean",
"message": "string - Result message for user",
"action": "string - Which action was performed",
"containerName": "string"
}
Implementation notes:
- Use "Define using fields" schema type for input contract
- Stop and restart require confirmation in the caller (main workflow handles confirmation dialogs)
- This sub-workflow executes the action AFTER confirmation is received
- Include proper error handling for API failures
- Message formatting should match existing bot style (emoji + container name + result)
- JSON file is valid:
python3 -c "import json; json.load(open('n8n-container-actions.json'))" - Contains "executeWorkflowTrigger" node
- Has proper input schema with all 6 fields
- Has Switch node routing to start/stop/restart paths Container actions sub-workflow created with proper input/output contracts
Changes needed:
-
Text command path (immediate actions - start/restart):
- Find where text commands route to start/restart handlers
- Replace inline action execution with: a. Code node to prepare sub-workflow input b. Execute Sub-workflow node pointing to container-actions workflow
- Keep confirmation handling in main workflow (stop still needs confirmation)
-
Text command path (stop with confirmation):
- Keep confirmation dialog handling in main workflow
- After confirmation received, call sub-workflow with action='stop'
-
Callback/inline path (immediate actions):
- Find where callback routes to start/restart handlers
- Replace inline execution with Execute Sub-workflow call
-
Callback/inline path (stop with confirmation):
- Keep confirmation keyboard generation in main workflow
- After confirmation callback received, call sub-workflow with action='stop'
-
Batch action path:
- Find where batch operations execute individual actions
- Route through the sub-workflow for consistency
Key principle: Confirmation dialogs stay in main workflow. Only the actual Docker API call moves to sub-workflow.
Execute Sub-workflow node configuration:
{
"parameters": {
"source": "database",
"workflowId": "<will be set after import>",
"mode": "once",
"options": {
"waitForSubWorkflow": true
}
},
"type": "n8n-nodes-base.executeWorkflow"
}
Deployment steps:
- Import container-actions sub-workflow to n8n via API
- Note the workflow ID assigned by n8n
- Update main workflow's Execute Sub-workflow node(s) with correct workflow ID
- Deploy main workflow update to n8n via API
Verification tests:
-
Text command actions:
- "start " - Should start and confirm
- "stop " - Should prompt for confirmation, then stop
- "restart " - Should restart and confirm
-
Inline keyboard actions:
- Use /status and select a container
- Test Start button (on stopped container)
- Test Stop button (should show confirmation)
- Test Restart button
-
Batch actions:
- Select 2 containers for batch stop
- Verify confirmation and execution work
- Sub-workflow imported and has valid ID in n8n
- Main workflow deployed with correct sub-workflow reference
- Text commands work: start, stop (with confirmation), restart
- Inline buttons work: Start, Stop (with confirmation), Restart
- Batch operations work for start/stop/restart Actions sub-workflow deployed and all action paths verified working
<success_criteria>
- Container actions (start/stop/restart) exist in ONE place (sub-workflow)
- Both text and inline action paths use the sub-workflow
- Confirmation dialogs still function correctly
- All action functionality works as before </success_criteria>