unraid-docker-manager/.planning/phases/10.1-aggressive-workflow-modularization/10.1-01-PLAN.md at afda21cf3eb90599b132ad14e9a6b83f2c7bfebb

Files

T

Lucas Berger 25dd3ab2d2 docs(10.1): create phase plan

Phase 10.1: Aggressive Workflow Modularization
- 5 plan(s) in 3 wave(s)
- Wave 1: Foundation (rename files, analyze boundaries, user approval)
- Wave 2: 3 parallel extractions (batch-ui, status, confirmation)
- Wave 3: Integration verification and UAT
- Ready for execution

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

2026-02-04 20:20:29 -05:00

6.3 KiB

Raw Blame History

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

phase

plan

type

wave

depends_on

files_modified

autonomous

must_haves

10.1-aggressive-workflow-modularization

execute

n8n-container-update.json

n8n-container-actions.json

n8n-container-logs.json

n8n-update.json

n8n-actions.json

n8n-logs.json

false

truths

artifacts

key_links

Existing sub-workflows renamed to shorter pattern

Domain boundaries analyzed and documented

User has approved extraction boundaries before work begins

path	provides	contains
n8n-update.json	Renamed container update sub-workflow	Container Update

path	provides	contains
n8n-actions.json	Renamed container actions sub-workflow	Container Actions

path	provides	contains
n8n-logs.json	Renamed container logs sub-workflow	Container Logs

from	to	via	pattern
n8n-workflow.json	sub-workflows	Execute Workflow nodes unchanged (IDs stable)	executeWorkflow

Rename existing sub-workflows to shorter naming pattern and analyze main workflow for optimal domain boundaries.

Purpose: Establish consistent naming convention and get user approval on extraction plan before modifying main workflow. Output: Renamed sub-workflow files, documented domain analysis, user-approved extraction boundaries.

<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-CONTEXT.md @.planning/phases/10.1-aggressive-workflow-modularization/10.1-RESEARCH.md @n8n-workflow.json @n8n-container-update.json @n8n-container-actions.json @n8n-container-logs.json Task 1: Rename existing sub-workflows to shorter pattern n8n-container-update.json -> n8n-update.json n8n-container-actions.json -> n8n-actions.json n8n-container-logs.json -> n8n-logs.json Rename the three existing sub-workflow files to match the locked decision for shorter naming: - `git mv n8n-container-update.json n8n-update.json` - `git mv n8n-container-actions.json n8n-actions.json` - `git mv n8n-container-logs.json n8n-logs.json`

NOTE: The workflow IDs in n8n remain the same (assigned by n8n on import). Only the file names change. The main workflow's Execute Workflow nodes reference by ID, not filename, so no main workflow changes needed.

ls n8n-*.json shows: n8n-workflow.json, n8n-update.json, n8n-actions.json, n8n-logs.json
git status shows renamed files
Old filenames no longer exist Three sub-workflow files renamed to shorter pattern. Git tracks the renames.

Task 2: Analyze main workflow and document domain boundaries n8n-workflow.json (read only) Analyze the main workflow (192 nodes) to identify optimal extraction boundaries. For each candidate domain:

Count nodes in the domain
Identify entry/exit points (which nodes connect to main workflow)
Check for internal dependencies (does domain reference nodes outside itself?)
Assess cohesion (does domain represent single user-facing outcome?)

Expected domains to analyze:

Batch UI: ~50 nodes (batch selection keyboard, navigation, toggle, execution dispatch)
Container Status: ~10-15 nodes (container list, pagination, status display)
Confirmation: ~15-20 nodes (stop confirmation, update confirmation, expiry handling)
Telegram responses: ~21 nodes (evaluate: does centralization add value?)

For each domain, document:

Node count
Entry nodes (where main workflow calls into domain)
Exit nodes (where domain returns to main workflow)
External dependencies (what data/nodes does domain need from outside?)
Extraction feasibility (yes/no with reasoning)

Create analysis output showing:

Proposed extractions with node counts
Expected main workflow node count after extraction
Domains NOT recommended for extraction (with reasoning)
Potential issues or complications Analysis output includes:

At least 3 candidate domains evaluated
Node counts for each domain
Clear recommendation (extract vs keep)
Expected final main workflow size (target: 50-80 nodes) Domain boundary analysis complete with extraction recommendations documented.

Approve domain boundaries for extraction Before extracting domains to sub-workflows, user approval is needed on which domains to extract and how they should be structured. This is per CONTEXT.md: "Claude analyzes workflow and proposes optimal domain boundaries (user approves)".

The analysis from Task 2 will be presented with recommendations. Approve proposed boundaries Proceed with extraction as analyzed None Modify boundaries User can adjust domain boundaries before extraction work May require re-analysis Skip specific domain(s) Focus on highest-value extractions first Main workflow may not reach target node count Review the domain analysis and respond: "approved", "modify: [changes]", or "skip: [domains]"

- [ ] Old filenames (n8n-container-*.json) no longer exist - [ ] New filenames (n8n-update.json, n8n-actions.json, n8n-logs.json) exist - [ ] Domain analysis documented with clear recommendations - [ ] User has approved extraction boundaries

<success_criteria>

Sub-workflow files renamed to shorter pattern
Domain boundary analysis complete
User approval received for extraction plan
Ready to proceed with domain extractions in Wave 2 </success_criteria>

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

6.3 KiB Raw Blame History

6.3 KiB

Raw Blame History