Epic: Evolve Squad planning from cast-through-accept into an executable SDLC plan #1648

Problem

Squad's distributable gh-aw workflow now supports /squad cast, /squad research, /squad plan, /squad plan accept, and plan revision. The Aspiregregator modernization exercise proved this can cast a credible specialist team, research a real repository, and produce a substantial backlog with acceptance criteria and native sub-issue links.

It also exposed an ontological gap: the current flow moves directly from research to issue creation without an explicit model for triage, decisions, initiatives/epics, milestones, implementation-ready work, sizing, dependency validation, or staged acceptance.

The result is a strong research-derived backlog, but not necessarily an executable SDLC plan.

Reference exercise: bradygaster/Aspiregregator#8 and its generated children #12–#25.

Goal

Evolve the Squad planning workflow into a reusable planning capability for customer repositories and downstream automation.

Target lifecycle:

Intent
  → Cast
  → Research
  → Triage
  → Decision gate
  → Program plan
  → Implementation plan
  → Plan validation
  → Accept scope
  → Accept implementation plan
  → Activate execution

This capability belongs to Squad and must remain independently useful and customizable.

Core ontology

Design principles

• Preserve the initiating intent through every phase; after-the-fact triage must not reconstruct intent from generated issues alone.
• Research produces evidence, not an automatic backlog.
• Triage decides what becomes work, what needs a decision, and what is excluded.
• Program planning and implementation planning are separate products.
• Native GitHub hierarchy, dependencies, milestones, issue types, Projects fields, and state should be preferred over labels.
• Labels are a fallback for dimensions GitHub cannot otherwise represent and must include names, descriptions, and intentional color families.
• Sizing is relative planning metadata, not elapsed-time prediction. Prefer a Project single-select field; use Size: XS/S/M/L/XL in structured issue metadata when no project is configured rather than creating repository labels by default.
• Acceptance must validate postconditions before creating or activating work.
• Commands and output contracts must support persistent and ephemeral Squad execution models.

Proposed command surface

/squad research
/squad triage
/squad plan program
/squad plan implementation
/squad plan validate
/squad plan accept scope
/squad plan accept implementation
/squad plan activate
/squad plan revise <feedback>

Backward compatibility for /squad plan and /squad plan accept should be deliberate and documented.

Acceptance criteria

• The lifecycle ontology and structured artifacts are documented and machine-validated.
• Research findings can be triaged against the original intent before issues are created.
• Program plans can create initiatives/epics, outcome milestones, and user-story/feature groupings.
• Implementation plans can create PR-sized leaf work with real dependencies, acceptance criteria, and relative sizes.
• Plan validation detects unresolved temporary IDs, missing mappings, invalid hierarchy, dependency cycles, oversized work, missing decisions, and incomplete metadata.
• Scope acceptance, implementation acceptance, and execution activation are distinct operations.
• GitHub-native representations are used when available, with predictable fallbacks when issue types, Projects, or permissions are unavailable.
• Customers can customize ontology and policy without forking core workflow logic.
• Downstream automation can consume accepted planning contracts without Squad depending on a specific executor.
• Aspiregregator is captured as an end-to-end regression fixture or documented acceptance scenario.

Out of scope

• Implementing downstream execution, review, merge, or completion workflows.
• Making Squad state persistence mandatory for gh-aw runs.
• Automatically implementing accepted work.
• Requiring every customer repository to configure GitHub Projects.

Size

XL — epic; decomposed into independently deliverable children below.