unraid-docker-manager/.planning/phases/10.1-aggressive-workflow-modularization/10.1-07-PLAN.md

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

phase	plan	type	wave	depends_on	files_modified	autonomous	gap_closure	must_haves
10.1-aggressive-workflow-modularization	07	execute	1		DEPLOY-SUBWORKFLOWS.md	true	true	truths artifacts key_links All 62+ Code nodes in main workflow are classified as orchestration or domain logic All 7 sub-workflow input/output contracts are formally documented Node count target is updated with evidence-based rationale Each Execute Workflow node's input mapping is verified against sub-workflow expectations path provides contains DEPLOY-SUBWORKFLOWS.md Sub-workflow architecture documentation with contracts and node analysis Input/Output Contract from to via pattern DEPLOY-SUBWORKFLOWS.md n8n-workflow.json documents contracts used by Execute Workflow nodes Execute Workflow

Close Gaps 2 and 3 from VERIFICATION.md: (1) Classify all Code nodes in main workflow as orchestration vs domain logic, proving which must stay and why. (2) Document input/output contracts for all sub-workflows with verification that Execute Workflow nodes pass correct data.

Purpose: The verification found that 62 Code nodes were unanalyzed (Gap 2) and sub-workflow contracts were undocumented (Gap 3). This plan provides the evidence needed to close both gaps and formally documents the architecture.

Output: Updated DEPLOY-SUBWORKFLOWS.md with Code node classification, I/O contracts, and revised node count rationale

<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/STATE.md @.planning/phases/10.1-aggressive-workflow-modularization/10.1-VERIFICATION.md @.planning/phases/10.1-aggressive-workflow-modularization/10.1-01-domain-analysis.md @DEPLOY-SUBWORKFLOWS.md @n8n-workflow.json @n8n-batch-ui.json @n8n-status.json @n8n-confirmation.json @n8n-update.json @n8n-actions.json @n8n-logs.json Task 1: Classify all Code nodes and document contracts DEPLOY-SUBWORKFLOWS.md Read the existing DEPLOY-SUBWORKFLOWS.md and significantly expand it with two new sections.

Section 1: Code Node Classification

Analyze every Code node in n8n-workflow.json (62 nodes currently, may be ~50 after plan 06 extraction). For each Code node, read its jsCode parameter content and classify it into one of these categories:

Category	Definition	Should Stay in Main?
prepare-input	Prepares input data for a sub-workflow Execute Workflow call	YES - glue between routing and sub-workflow
route-result	Processes sub-workflow 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

For each Code node, produce a row in a table:

| Node Name | Category | Lines | Stays in Main? | Reason |

At the bottom, add a summary:

Total Code nodes: NN
  prepare-input: NN (must stay)
  route-result: NN (must stay)
  parse-command: NN (must stay)
  build-response: NN (must stay)
  orchestration: NN (must stay)
  domain-logic: NN (extraction candidates)

Extractable domain logic: NN nodes
Extraction overhead per domain: ~3 nodes (Prepare + Execute + Route)
Net reduction potential: NN nodes

This proves whether any further extraction is viable beyond matching domain.

Section 2: Sub-workflow Input/Output Contracts

For each of the 6 (or 7 after plan 06) sub-workflows, document:

1. Input contract - Read the Execute Workflow Trigger node and the Prepare *Input Code nodes that feed it. Document every field:

   ## n8n-update.json (Container Update)
   
   ### Input Contract
   | Field | Type | Required | Source |
   |-------|------|----------|--------|
   | containerId | string | yes | Docker API container ID |
   | containerName | string | yes | Display name |
   | chatId | number | yes | Telegram chat ID |
   | messageId | number | yes | Telegram message ID |
   | responseMode | string | yes | "text" or "callback" |
   
   ### Output Contract
   | Action | Fields | Routed To |
   |--------|--------|-----------|
   | (no action field) | result, success | Handle Update Result |
   

2. Output contract - Read the sub-workflow's exit nodes and document what it returns. Include the action field values and associated data fields.

3. Verification - For each Execute Workflow node in main workflow, verify that the preceding Prepare *Input node produces all required fields. Document any mismatches.

Sub-workflows to document:

• n8n-update.json (Container Update) — called by 3 Execute nodes
• n8n-actions.json (Container Actions) — called by 3 Execute nodes
• n8n-logs.json (Container Logs) — called by 2 Execute nodes
• n8n-batch-ui.json (Batch UI) — called by 1 Execute node
• n8n-status.json (Container Status) — called by 4 Execute nodes
• n8n-confirmation.json (Confirmation Dialogs) — called by 1 Execute node
• n8n-matching.json (Container Matching) — called by 3 Execute nodes (if plan 06 complete, otherwise note as pending)

Section 3: Revised Node Count Rationale

Add a section that explains the final node count with evidence:

## Node Count Analysis

### Current State
- Main workflow: NNN nodes (after matching extraction)
- 7 sub-workflows: total NNN nodes

### Why 115-125 Target Is Not Achievable
Based on Code node classification:
- NN nodes are locked infrastructure (trigger, auth, routing, switches)
- NN nodes are Telegram responses (locked per design decision)
- NN nodes are Execute Workflow dispatch
- NN nodes are Prepare Input (sub-workflow glue)
- NN nodes are Parse/Build/Handle (orchestration, too small to extract)
- NN nodes are domain logic candidates
  - Of these, NN have been extracted (matching domain)
  - Remaining NN nodes: extraction overhead exceeds reduction benefit

### Revised Realistic Baseline
Minimum viable main workflow: NN nodes (all categories that must stay)
Current: NNN nodes
Gap: NN nodes of domain logic where extraction overhead (~3 nodes per domain) makes extraction net-negative or marginal

Formatting:

• Use the existing DEPLOY-SUBWORKFLOWS.md structure and add new sections
• Keep the existing deployment instructions intact
• Add the new sections after the existing content

1. DEPLOY-SUBWORKFLOWS.md contains "Code Node Classification" section with table covering all Code nodes
2. DEPLOY-SUBWORKFLOWS.md contains "Input/Output Contract" section for each sub-workflow
3. Each sub-workflow contract lists all input fields with types
4. Each sub-workflow contract lists all output actions with fields
5. DEPLOY-SUBWORKFLOWS.md contains "Node Count Analysis" section with revised rationale
6. All Code node categories sum to total Code node count in main workflow All Code nodes classified with evidence, all sub-workflow contracts documented with field-level detail, node count rationale updated with structural analysis proving current count is near-minimal

1. DEPLOY-SUBWORKFLOWS.md exists and contains all three new sections 2. Code node classification covers every Code node in main workflow (verify count matches) 3. Sub-workflow contracts cover all 6-7 sub-workflows 4. Each contract has input fields table and output actions table 5. Node count analysis shows evidence-based rationale 6. No factual errors in classification (spot-check 5 random Code nodes)

<success_criteria>

• Every Code node in main workflow is classified with category and rationale
• Every sub-workflow has documented input contract (all fields, types, required flag)
• Every sub-workflow has documented output contract (all action values, return fields)
• Node count rationale provides clear evidence that further extraction yields diminishing returns
• All three verification gaps (node count, Code analysis, contract consistency) have documented closure evidence </success_criteria>

After completion, create `.planning/phases/10.1-aggressive-workflow-modularization/10.1-07-SUMMARY.md`