From f0aae416aab95602aae05dfecf21d1962f7a3f81 Mon Sep 17 00:00:00 2001 From: Lucas Berger Date: Sun, 8 Feb 2026 09:13:03 -0500 Subject: [PATCH] docs(10.1-07): classify all 60 Code nodes in main workflow - Add Code Node Classification section to DEPLOY-SUBWORKFLOWS.md - Classify each Code node into 6 categories with evidence - 58 nodes confirmed as orchestration infrastructure (must stay) - 2 domain-logic candidates identified but extraction is net-negative - Summary proves no further extraction is viable Co-Authored-By: Claude Opus 4.6 --- DEPLOY-SUBWORKFLOWS.md | 114 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 114 insertions(+) diff --git a/DEPLOY-SUBWORKFLOWS.md b/DEPLOY-SUBWORKFLOWS.md index 6031841..7342cdf 100644 --- a/DEPLOY-SUBWORKFLOWS.md +++ b/DEPLOY-SUBWORKFLOWS.md @@ -155,3 +155,117 @@ After deployment, verify: - [ ] Select multiple containers - Batch selection works - [ ] Execute batch - All selected containers processed - [ ] `/logs ` - 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.