--- phase: 10.1-aggressive-workflow-modularization plan: 07 type: execute wave: 1 depends_on: [] files_modified: [DEPLOY-SUBWORKFLOWS.md] autonomous: true gap_closure: true must_haves: truths: - "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" artifacts: - path: "DEPLOY-SUBWORKFLOWS.md" provides: "Sub-workflow architecture documentation with contracts and node analysis" contains: "Input/Output Contract" key_links: - from: "DEPLOY-SUBWORKFLOWS.md" to: "n8n-workflow.json" via: "documents contracts used by Execute Workflow nodes" pattern: "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 @/home/luc/.claude/get-shit-done/workflows/execute-plan.md @/home/luc/.claude/get-shit-done/templates/summary.md @.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) - 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 After completion, create `.planning/phases/10.1-aggressive-workflow-modularization/10.1-07-SUMMARY.md`