luckberg/unraid-docker-manager
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(10.1-07): classify all 60 Code nodes in main workflow

Browse Source 
- 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 <noreply@anthropic.com>
This commit is contained in:
Lucas Berger
2026-02-08 09:13:03 -05:00
parent 4eeed1d9e1
commit f0aae416aa
1 changed files with 114 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DEPLOY-SUBWORKFLOWS.md
+114
View File
@@ -155,3 +155,117 @@ After deployment, verify:
- [ ] 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.