unraid-docker-manager/.planning/STATE.md

Project State — Unraid Docker Manager

Current Position

• Milestone: v1.2 — Modularization & Polish
• Phase: 10.1 of 13 (Aggressive Workflow Modularization)
• Plan: 3 of 5 complete
• Status: In progress
• Last activity: 2026-02-05 — Completed 10.1-03 (Container Status Sub-workflow)

Progress

v1.0: [██████████] 100% SHIPPED
v1.1: [██████████] 100% SHIPPED

v1.2: [█████░░░░░] 50%

Phase 10:   Workflow Modularization         [██████████] 100% COMPLETE (+ 10-07 UAT fixes)
Phase 10.1: Aggressive Modularization       [██████    ] 60% (3/5 plans)
Phase 10.2: Better Logging & Log Management [          ] Pending (INSERTED)
Phase 11:   Update All & Callback Limits    [          ] Pending
Phase 12:   Polish & Audit                  [          ] Pending
Phase 13:   Documentation Overhaul          [          ] Pending

Phase 10 Completion Summary

Plan	Description	Status
10-01	Orphan node cleanup	Complete
10-02	Container Update sub-workflow	Complete
10-03	Container Actions sub-workflow	Complete
10-04	Integration verification	Complete
10-05	Complete modularization (batch, logs)	Complete
10-06	Remediation: routing, logs, cleanup	Complete
10-07	UAT gap closure (5 fixes)	Complete

Achievements:

• 3 sub-workflows created and deployed (Update, Actions, Logs)
• All container operations consolidated (no duplicate logic)
• Old inline batch execution path removed
• Legacy callbacks modernized to new format
• Main workflow: 209 -> 192 nodes (-8%)
• 6 Python helper scripts removed
• UAT gaps closed: race condition, data chain errors, fuzzy matching, refresh errors

Key Artifacts

• n8n-workflow.json — Main workflow (178 nodes, down from 192)
• n8n-batch-ui.json — Batch UI sub-workflow (16 nodes) — TODO_DEPLOY
• n8n-status.json — Container Status sub-workflow (11 nodes) — TODO_DEPLOY
• n8n-update.json — ID: 7AvTzLtKXM2hZTio92_mC
• n8n-actions.json — ID: fYSZS5PkH0VSEaT5
• n8n-logs.json — ID: oE7aO2GhbksXDEIw

Technical Notes

n8n typeVersion 1.2 requirement:

"workflowId": { "__rl": true, "mode": "list", "value": "<id>" }

Docker API success detection:

• 204 No Content = success (empty response body)
• Check !response.message && !response.error

Sub-workflow input contracts:

• Container Update: containerId, containerName, chatId, messageId, responseMode
• Container Actions: containerId, containerName, action, chatId, messageId, responseMode
• Container Logs: containerId/containerName, lineCount, chatId, messageId, responseMode
• Batch UI: chatId, messageId, queryId, callbackData, action, batchPage, selectedCsv, toggleName
• Container Status: chatId, messageId, action, containerId, containerName, page, queryId, searchTerm

Sub-workflow output patterns:

• Batch UI returns action field (keyboard/confirmation/execute/cancel/limit_reached)
• Container Status returns action field (list/status/paginate/status_direct)
• Main workflow routes based on action to appropriate Telegram response handler

Data chain pattern (10-07):

• Use $('Build Progress Message').item.json to reference data across async nodes
• Do not rely on $json after Telegram API calls (response overwrites data)

Accumulated Decisions

Phase	Decision	Rationale
10-05	Use placeholder workflow ID for logs sub-workflow	ID assigned by n8n on import
10-05	Retain Parse Logs Command in main workflow	Handles error cases before sub-workflow call
10-06	Remove old batch inline path	Migrated to bexec: callback format, uses sub-workflow
10-06	Defer aggressive modularization to 10.1	Core goals achieved, deeper work needs separate phase
10-07	Timestamp on logs refresh	Prevents "message not modified" error, shows freshness
10-07	Fuzzy matching in logs sub-workflow	Simpler than duplicating Docker query infrastructure
10.1-01	Realistic target 115-125 nodes (not 50-80)	58 Telegram response nodes locked to main workflow
10.1-01	Wave 2: Batch UI + Container List extraction	Highest-value domains with clear boundaries
10.1-02	Partial batch UI extraction (UI only, not loop)	Batch execution loop cannot be in sub-workflow due to n8n limitations
10.1-02	Action-based sub-workflow routing	Sub-workflow returns action field, main routes to Telegram handlers
10.1-03	Minimal net node reduction due to integration overhead	Removed 10 nodes but added 9 integration nodes; value is complexity reduction

Phase 10.1 Progress

Plan	Description	Status
10.1-01	Foundation and Domain Analysis	Complete
10.1-02	Batch UI Sub-workflow (Wave 2)	Complete
10.1-03	Container Status Sub-workflow (Wave 2)	Complete
10.1-04	Confirmation Sub-workflow (Wave 3)	Pending
10.1-05	Integration Verification	Pending

Node count progress:

• Start: 192 nodes
• After 10.1-02: 179 nodes (-13)
• After 10.1-03: 178 nodes (-1)
• Target: 115-125 nodes

Wave 2 Complete:

• Batch UI: -13 nodes (16 nodes in sub-workflow)
• Container Status: -1 net (11 nodes in sub-workflow, complexity reduction)

Remaining extraction (Wave 3):

• Confirmation (30->15-20 node reduction expected)
• Matching (optional)
• Target: 115-125 nodes (realistic given 58 locked Telegram nodes)

Deployment Required

n8n-batch-ui.json needs deployment:

1. Import to n8n instance
2. Note assigned workflow ID
3. Replace TODO_DEPLOY_BATCH_UI_WORKFLOW in n8n-workflow.json
4. Re-import main workflow

n8n-status.json needs deployment:

1. Import to n8n instance
2. Note assigned workflow ID
3. Replace TODO_DEPLOY_STATUS_WORKFLOW (4 occurrences) in n8n-workflow.json
4. Re-import main workflow

Next Step

Run plan 10.1-04 to extract Confirmation sub-workflow (Wave 3).

---

Auto-maintained by GSD workflow