# Sub-workflow Deployment Guide

## Overview

Phase 10.1 (Aggressive Workflow Modularization) reduced the main workflow from 192 nodes to 168 nodes by extracting domain-specific functionality into sub-workflows.

**Final State:**
- Main workflow: 168 nodes (reduced by 24 nodes, -12.5%)
- Total sub-workflows: 7 (3 pre-existing + 4 new)

## Sub-workflows

| File | Purpose | Nodes | Status |
|------|---------|-------|--------|
| n8n-update.json | Container update operations | 34 | Deployed (ID: `7AvTzLtKXM2hZTio92_mC`) |
| n8n-actions.json | Container start/stop/restart | 11 | Deployed (ID: `fYSZS5PkH0VSEaT5`) |
| n8n-logs.json | Container log retrieval | 9 | Deployed (ID: `oE7aO2GhbksXDEIw`) |
| n8n-batch-ui.json | Batch selection UI | 16 | Deployed |
| n8n-status.json | Container list/status | 11 | Deployed (ID: `lqpg2CqesnKE2RJQ`) |
| n8n-confirmation.json | Confirmation dialogs | 16 | Deployed (ID: `fZ1hu8eiovkCk08G`) |
| n8n-matching.json | Container matching/disambiguation | 23 | Deployed (ID: `kL4BoI8ITSP9Oxek`) |

## Deployment Status

All sub-workflows have been deployed. The main workflow (`n8n-workflow.json`) contains all correct workflow IDs.

To redeploy after changes:
1. Import the modified sub-workflow JSON to n8n
2. Re-import `n8n-workflow.json` if main workflow changed
3. Activate the workflow

## Execute Workflow Node Mapping

| Node Name | Target Sub-workflow | Workflow ID |
|-----------|---------------------|-------------|
| Execute Text Update | n8n-update.json | `7AvTzLtKXM2hZTio92_mC` |
| Execute Callback Update | n8n-update.json | `7AvTzLtKXM2hZTio92_mC` |
| Execute Batch Update | n8n-update.json | `7AvTzLtKXM2hZTio92_mC` |
| Execute Container Action | n8n-actions.json | `fYSZS5PkH0VSEaT5` |
| Execute Inline Action | n8n-actions.json | `fYSZS5PkH0VSEaT5` |
| Execute Batch Action Sub-workflow | n8n-actions.json | `fYSZS5PkH0VSEaT5` |
| Execute Text Logs | n8n-logs.json | `oE7aO2GhbksXDEIw` |
| Execute Inline Logs | n8n-logs.json | `oE7aO2GhbksXDEIw` |
| Execute Batch UI | n8n-batch-ui.json | Deployed |
| Execute Container Status | n8n-status.json | `lqpg2CqesnKE2RJQ` |
| Execute Select Status | n8n-status.json | `lqpg2CqesnKE2RJQ` |
| Execute Paginate Status | n8n-status.json | `lqpg2CqesnKE2RJQ` |
| Execute Batch Cancel Status | n8n-status.json | `lqpg2CqesnKE2RJQ` |
| Execute Confirmation | n8n-confirmation.json | `fZ1hu8eiovkCk08G` |
| Execute Action Match | n8n-matching.json | `kL4BoI8ITSP9Oxek` |
| Execute Update Match | n8n-matching.json | `kL4BoI8ITSP9Oxek` |
| Execute Batch Match | n8n-matching.json | `kL4BoI8ITSP9Oxek` |

## Rollback

If issues are encountered, backup files are available:

```bash
# Restore to before batch UI extraction
cp n8n-workflow.json.backup-batch n8n-workflow.json

# Restore to before status extraction
cp n8n-workflow.json.backup-status n8n-workflow.json

# Restore to before confirmation extraction
cp n8n-workflow.json.backup-confirm n8n-workflow.json
```

Then re-import the restored `n8n-workflow.json` to n8n.

## Architecture

```
n8n-workflow.json (168 nodes - orchestrator)
├── Telegram Trigger (1)
├── Auth + Error Handling
├── Keyword Routing (switch/if nodes)
│
├── Update Operations
│   ├── Execute Text Update ──────────┐
│   ├── Execute Callback Update ──────┼── n8n-update.json (34 nodes)
│   └── Execute Batch Update ─────────┘
│
├── Action Operations
│   ├── Execute Container Action ─────┐
│   ├── Execute Inline Action ────────┼── n8n-actions.json (11 nodes)
│   └── Execute Batch Action ─────────┘
│
├── Log Operations
│   ├── Execute Text Logs ────────────┐
│   └── Execute Inline Logs ──────────┴── n8n-logs.json (9 nodes)
│
├── Batch UI
│   └── Execute Batch UI ─────────────── n8n-batch-ui.json (16 nodes)
│       ├── Returns: keyboard/confirmation/execute/cancel/limit
│       └── Main routes response based on action
│
├── Container Status
│   ├── Execute Container Status ─────┐
│   ├── Execute Select Status ────────┼── n8n-status.json (11 nodes)
│   ├── Execute Paginate Status ──────┤   Returns: list/status/paginate
│   └── Execute Batch Cancel Status ──┘
│
└── Confirmation Dialogs
    └── Execute Confirmation ─────────── n8n-confirmation.json (16 nodes)
        ├── Returns: show_stop/show_update/confirm_*/cancel/expired
        └── Calls n8n-actions.json for confirmed stop actions
```

## Sub-workflow Input/Output Contracts

### n8n-batch-ui.json

**Input:**
- `chatId`, `messageId`, `queryId`
- `callbackData`, `action`, `batchPage`
- `selectedCsv`, `toggleName`

**Output:**
- `action`: keyboard | confirmation | execute | cancel | limit_reached

### n8n-status.json

**Input:**
- `chatId`, `messageId`, `queryId`
- `action`, `containerId`, `containerName`
- `page`, `searchTerm`

**Output:**
- `action`: list | status | paginate | status_direct

### n8n-confirmation.json

**Input:**
- `chatId`, `messageId`, `queryId`
- `action`, `containerId`, `containerName`
- `confirmAction`, `confirmationToken`
- `expired`, `responseMode`

**Output:**
- `action`: show_stop | show_update | confirm_stop_result | confirm_update | cancel | expired

## Testing Checklist

After deployment, verify:

- [ ] `/list` - Shows container list
- [ ] `/status <container>` - Shows container details
- [ ] `/stop <container>` - Shows confirmation dialog
- [ ] Confirm stop - Executes stop action
- [ ] Cancel stop - Returns to status view
- [ ] `/update <container>` - Shows confirmation dialog
- [ ] Confirm update - Executes update flow
- [ ] `/stop` (no args) - Shows batch selection UI
- [ ] Select multiple containers - Batch selection works
- [ ] Execute batch - All selected containers processed
- [ ] `/logs <container>` - Shows container logs

---

## Code Node Classification

Analysis of all 60 Code nodes in the main workflow (`n8n-workflow.json`), classifying each as orchestration infrastructure or domain logic.

### Classification Categories

| Category | Definition | Must Stay in Main? |
|----------|-----------|-------------------|
| `prepare-input` | Prepares input data for a sub-workflow Execute Workflow call or Execute Command | YES - glue between routing and sub-workflow |
| `route-result` | Processes sub-workflow or command return data for routing/display | YES - glue between sub-workflow and Telegram response |
| `parse-command` | Parses user text input into structured command data | YES - part of keyword routing infrastructure |
| `build-response` | Builds Telegram response text/keyboards from data | YES - tightly coupled to Telegram response nodes |
| `orchestration` | Batch loop control, state management, result aggregation | YES - main workflow orchestration logic |
| `domain-logic` | Pure domain computation that could theoretically live in sub-workflow | CANDIDATE - but assess extraction overhead |

### Code Node Classification Table

| Node Name | Category | Lines | Stays in Main? | Reason |
|-----------|----------|-------|---------------|--------|
| Build Action Command | build-response | 22 | YES | Builds curl command for Docker action execution |
| Build Batch Keyboard | build-response | 56 | YES | Builds batch confirmation keyboard for multiple matches |
| Build Batch Stop Confirmation | build-response | 36 | YES | Builds Telegram message for batch stop confirmation |
| Build Batch Stop Expired | build-response | 10 | YES | Builds expired confirmation message |
| Build Batch Summary | build-response | 62 | YES | Builds batch result summary message with success/failure counts |
| Build Callback Action | build-response | 24 | YES | Builds curl command for callback action execution |
| Build Cancel Return Submenu | domain-logic | 72 | CANDIDATE | Container name matching + submenu building (search + normalize + build) |
| Build Immediate Action Command | domain-logic | 43 | CANDIDATE | Container lookup by name + curl command building |
| Build Progress Message | build-response | 30 | YES | Builds progress message for batch loop iteration |
| Build Update All Confirmation | build-response | 35 | YES | Builds Telegram confirmation message for update-all |
| Check Available Updates | orchestration | 44 | YES | Filters containers by :latest tag, orchestrates update-all flow |
| Detect Batch Command | parse-command | 70 | YES | Detects batch commands (multiple container names) from text input |
| Find Container For Callback Update | prepare-input | 38 | YES | Resolves container name to ID for callback update sub-workflow |
| Format Immediate Result | route-result | 49 | YES | Formats action result into Telegram message with inline keyboard |
| Format Inline Logs Result | route-result | 36 | YES | Formats logs result with inline keyboard and refresh button |
| Get Update All Data | prepare-input | 18 | YES | Prepares data for update-all re-fetch |
| Handle Batch Action Result Sub | route-result | 33 | YES | Aggregates batch action sub-workflow result into loop state |
| Handle Batch Update Result | route-result | 33 | YES | Aggregates batch update sub-workflow result into loop state |
| Handle Cancel | route-result | 10 | YES | Prepares cancel callback query response data |
| Handle Expired | route-result | 10 | YES | Prepares expired callback query response data |
| Handle Inline Action Result | route-result | 36 | YES | Routes inline action result to Telegram edit with keyboard |
| Handle Text Action Result | route-result | 13 | YES | Routes text action result to Telegram send |
| Handle Update Multiple | route-result | 14 | YES | Builds error message for ambiguous update match |
| Initialize Batch State | orchestration | 43 | YES | Initializes batch execution loop state from multiple input sources |
| Parse Action Command | parse-command | 49 | YES | Parses /stop, /start, /restart text commands |
| Parse Action Result | route-result | 42 | YES | Parses curl HTTP status code into success/failure message |
| Parse Callback Data | parse-command | 441 | YES | Central callback data parser (all button clicks) |
| Parse Callback Result | route-result | 54 | YES | Parses callback action curl result with keyboard building |
| Parse Logs Command | parse-command | 45 | YES | Parses /logs text command with optional line count |
| Parse Update Command | parse-command | 25 | YES | Parses /update text command |
| Prepare Action Match Input | prepare-input | 17 | YES | Prepares input for matching sub-workflow (action commands) |
| Prepare Batch Action Input | prepare-input | 19 | YES | Prepares input for actions sub-workflow (batch loop) |
| Prepare Batch Cancel Return | prepare-input | 10 | YES | Prepares data for return to container list from batch cancel |
| Prepare Batch Cancel Return Input | prepare-input | 14 | YES | Prepares input for status sub-workflow from batch cancel |
| Prepare Batch Exec | orchestration | 26 | YES | Prepares batch exec data, normalizes container name formats |
| Prepare Batch Execution | prepare-input | 13 | YES | Transforms matching sub-workflow output to batch execution format |
| Prepare Batch Loop | orchestration | 42 | YES | Stores progress message ID, prepares first batch iteration |
| Prepare Batch Match Input | prepare-input | 21 | YES | Prepares input for matching sub-workflow (batch commands) |
| Prepare Batch Stop Exec | prepare-input | 16 | YES | Prepares batch stop data from callback confirmation |
| Prepare Batch UI Input | prepare-input | 27 | YES | Prepares input for batch UI sub-workflow |
| Prepare Batch Update Input | prepare-input | 17 | YES | Prepares input for update sub-workflow (batch loop) |
| Prepare Callback Update Input | prepare-input | 15 | YES | Prepares input for update sub-workflow (inline mode) |
| Prepare Cancel From Confirm | prepare-input | 10 | YES | Prepares cancel return data from confirmation result |
| Prepare Cancel Return | prepare-input | 9 | YES | Prepares cancel data from callback for container submenu |
| Prepare Confirm Input | prepare-input | 26 | YES | Prepares input for confirmation sub-workflow |
| Prepare Immediate Action | prepare-input | 18 | YES | Prepares inline keyboard action data for Docker execution |
| Prepare Inline Action Input | prepare-input | 41 | YES | Prepares input for actions sub-workflow (inline keyboard path) |
| Prepare Inline Logs Input | prepare-input | 12 | YES | Prepares input for logs sub-workflow (inline action) |
| Prepare Next Iteration | orchestration | 18 | YES | Advances batch loop counter, checks completion |
| Prepare Paginate Input | prepare-input | 14 | YES | Prepares input for status sub-workflow (pagination callback) |
| Prepare Select Status Input | prepare-input | 14 | YES | Prepares input for status sub-workflow (container select) |
| Prepare Show Stop Input | prepare-input | 13 | YES | Prepares input for confirmation sub-workflow (show stop) |
| Prepare Show Update Input | prepare-input | 13 | YES | Prepares input for confirmation sub-workflow (show update) |
| Prepare Status Input | prepare-input | 24 | YES | Prepares input for status sub-workflow (/status command) |
| Prepare Text Action Input | prepare-input | 18 | YES | Prepares input for actions sub-workflow (text command) |
| Prepare Text Logs Input | prepare-input | 23 | YES | Prepares input for logs sub-workflow (text command) |
| Prepare Text Update Input | prepare-input | 15 | YES | Prepares input for update sub-workflow (text mode) |
| Prepare Update All Batch | orchestration | 41 | YES | Prepares batch data for update-all from container list |
| Prepare Update Match Input | prepare-input | 16 | YES | Prepares input for matching sub-workflow (update commands) |
| Strip Status Keyboard | route-result | 9 | YES | Strips inline keyboard for text-mode status display |

### Classification Summary

```
Total Code nodes: 60

  prepare-input:  27 (must stay - sub-workflow integration glue)
  route-result:   12 (must stay - sub-workflow result routing)
  parse-command:   5 (must stay - keyword routing infrastructure)
  build-response:  8 (must stay - Telegram response building)
  orchestration:   6 (must stay - batch loop + state management)
  domain-logic:    2 (extraction candidates)

Extractable domain logic: 2 nodes (72 + 43 = 115 lines)
  - Build Cancel Return Submenu (72 lines) — container name matching + submenu building
  - Build Immediate Action Command (43 lines) — container lookup + curl command building

Extraction overhead per domain: ~3 nodes (Prepare Input + Execute Workflow + Route Result)
Net reduction potential: 2 extracted - 3 overhead = -1 node (net increase)
```

### Extraction Viability Assessment

The 2 domain-logic candidates (`Build Cancel Return Submenu` and `Build Immediate Action Command`) both perform container name matching followed by response building. However:

1. **Both are already partially handled by n8n-matching.json** -- the matching sub-workflow handles the primary matching paths. These two nodes handle edge cases (cancel return to submenu, and immediate inline actions like start/restart) where the matching has already been resolved by callback data.

2. **Extraction would be net-negative** -- extracting 2 nodes but adding 3 integration nodes (Prepare Input, Execute Workflow, Route Result) would increase the node count by 1.

3. **Complexity is low** -- both nodes are under 75 lines and perform straightforward container name normalization + lookup against Docker API output already fetched.

**Conclusion:** No further Code node extraction is viable. All 58 non-candidate nodes are demonstrably orchestration infrastructure (input preparation, result routing, command parsing, response building, or loop control). The 2 domain-logic candidates would yield a net-negative extraction.