Feature

Verify the initiative is well-scoped before any plan work begins.

Required elements:

• A specific, unambiguous title
• A one-line summary of the user-visible outcome
• A clear statement of the problem solved or value delivered

If any element is missing or ambiguous, identify the gap and ask
the operator to clarify. Do not advance with an under-specified
initiative.

Decompose the initiative into the minimum set of child work items
required to ship it. Types are semantic, not structural — most
substantial work becomes a plan (which elaborates into phases), but
a small, self-contained item can be a direct task or bug child of
the initiative with no plan wrapper. Pick the type that matches the
work. For each item, produce:

• Title (action-oriented, 5-10 words)
• Type (plan for work that needs its own phases; task/bug for a
  small, directly executable item)
• Scope (what it includes and what it explicitly excludes)
• Surface area (components, files, or systems it touches)
• Sequencing notes (only if execution order is load-bearing)

Prefer fewer, broader plans over many narrow ones. Present the
decomposition to the operator and request approval before
creating any child tasks.

Create one child task per approved work item, attached to this
initiative as the parent, using the type chosen at define-plans:

• type: plan for work that will elaborate into its own phases;
  type: task or bug for a small, directly executable item
• title and summary: from the approved decomposition
• status: backlog (each child's own workflow takes over from there)

For plans, do not pre-define phases — that is the responsibility of
each plan's workflow. Confirm all children were created and linked
before advancing.

Execution is in progress. This step blocks until every child
(plan, task, or bug) reaches a terminal state (completed or cancelled).

If a child stalls or is blocked, address the issue on that child's
own workflow — not here. The gate re-evaluates on each advance attempt.

Validate the initiative as a whole. Individual children were verified
in isolation; this step confirms they integrate into the outcome
the initiative promised.

Report:

• The user-facing path or scenario exercised
• What worked
• What did not work, and which child owns the gap

If gaps remain, reject this step. The workflow returns to
execute-plans so the responsible child can be reopened. Do not
patch the gap inline here.

Request operator approval before advancing.

Initiative shipped. Mark it completed and close out.