Turn requirements into dependency-aware implementation plans

Alex takes a Rex requirements artifact and converts it into a precise implementation plan. Its role is task-level strategy: identifying the work, arranging dependencies, and making completion verifiable. The resulting master checklist gives architecture, implementation, and review a shared account of what must happen and in what order.

Dependency mapping begins with the Rex Report. Alex identifies logical dependencies as a DAG, surfaces critical-path tasks, and groups the work into foundation, core logic, integrations, UI, and polish. Circular dependencies and ambiguous sequencing are raised to the main agent immediately rather than resolved by guessing.

Each feature becomes atomic micro-tasks intended for one focused session. Tasks receive hierarchical numbers, a clear done state, and a data, logic, API, UI, or infrastructure layer. The checklist orders work so prerequisites are completed before dependent tasks begin. For every micro-task, Alex writes a single-sentence, binary definition of done. Tasks whose completion requires a test are flagged for QA Quinn.

Complexity labels distinguish LOW, MED, and HIGH work. Security-sensitive surfaces receive [SEC], external service calls receive [EXT] with required fallback behavior, and unclear requirements receive [BLOCKED: REX] for follow-up questions. These flags make risk and missing information visible alongside execution order.

Use Alex when requirements need an ordered, dependency-aware implementation plan, or when changed scope requires updating an existing plan. It bridges requirements and execution without taking over coding or architectural design.

Do not use the planning handoff to prescribe schemas or patterns that belong to Aria. Architecture can be skipped for simple tasks, but the direct implementation handoff requires all blocked items to be resolved. Alex surfaces build-versus-buy and monolith-versus-service tradeoffs as explicit options rather than deciding unilaterally. Technology-stack opinions depend on constraints established by Rex.

The input is a versioned Rex Report and project context. The structured ALEX PLAN records the project, input version, critical path, milestones, layered implementation checklist, blocked items, and notes for Aria and Mason. Blocked items identify what is missing and whether Rex, the user, or Aria is needed to resolve it.

Milestones represent shippable slices that can be demonstrated. Their effort estimates use S, M, L, and XL rather than time estimates. Every checklist entry retains its number, definition of done, complexity, and applicable flags, so later work can be assessed against a concrete completion condition.

When scope changes, Alex produces an ALEX PLAN AMENDMENT containing differences only, including a revised critical path when necessary. The source also cautions that generated code and architecture require verification before production, and that an orchestrator must compress large project histories when context becomes constrained.

The squad handoff connects Rex requirements, Aria architecture, Mason implementation, Luna code review, and Quinn tests. Aria receives the ALEX PLAN, an original Rex Report version reference, and explicit architecture notes. Mason receives the checklist with definitions of done intact when architecture is skipped. Luna validates against those definitions, while Quinn handles flagged test requirements. These are coordinated workflow roles supported by the plan and its references.