Spec Delivery Goals Phase Board - joeroberts/release-radar GitHub Wiki

Visual baseline

Keep the five-lane layout, spacing, color, card-density behavior, and selected ticket inspector established by docs/design/mockups/phase_board.png. Use docs/design/mockups/goals.png and docs/design/mockups/goal_to_work_flow.png only for goal/work navigation vocabulary. Their observed-goal content is not the Delivery Goal data model.

Wide board

release_radar
Established product roadmap

Viewed phase  [Established product roadmap โ–พ]   Active phase  Post-MVP remediation
Plan          Ready ยท revision 3 ยท 11/11 covered ยท 0 unassigned
Delivery Goal [All goals โ–พ]  [Show unassigned]   Card density [Full outcomes โ–พ]

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ฌโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚ Backlog 8  โ”‚ In progress โ”‚ Needs review โ”‚ Blocked 3  โ”‚ Accepted 0 โ”‚
โ”‚ RR-RM1     โ”‚ 0           โ”‚ 0            โ”‚ RR-RM5     โ”‚            โ”‚
โ”‚ RR-RM2     โ”‚             โ”‚              โ”‚ RR-RM6     โ”‚            โ”‚
โ”‚ ...        โ”‚             โ”‚              โ”‚ RR-RM7     โ”‚            โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”ดโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Selected ticket: RR-RM5
Delivery Goal     RR-DG2 ยท Portable project continuity ยท Planned
Codex execution   No linked Codex execution goal
Requires / Unlocks / Owner attention / Evidence / Audit / Notifications

Interaction contract

  • Viewed phase changes only the local board view. It never calls the active-phase mutation.
  • The persisted active phase is always named next to the viewed-phase control.
  • Existing authorized active-phase selection remains a separate Make active phase action and retains ADR-003 confirmation, audit, replay, and recovery.
  • Plan state, revision, coverage, and unassigned counts update coherently with the viewed phase.
  • Delivery Goal filtering hides nonmatching cards without moving them between lanes, changing persisted state, or creating a filter-local order. All-phases, viewed-phase, and goal-filtered boards project the same persisted project-and-lane sequence.
  • Show unassigned is available in Draft and Legacy-unassessed plans and truthfully returns zero only after an authoritative load.
  • Finalizing a phase with zero upcoming tickets is invalid. A previously Ready phase that reaches zero upcoming because all assigned tickets became Accepted remains valid and displays Ready ยท delivery complete ยท 0 upcoming ยท 0 unassigned instead of a misleading initial-readiness claim.
  • Draft and Legacy-unassessed plans show an inline warning that Backlog and Blocked tickets cannot start until coverage is finalized. Already grandfathered In progress and Needs review tickets are labelled as legacy continuation, not as covered.
  • Selecting a card retains its current lane/card behavior and opens the inspector.
  • The explicit owner-app ticket-order controls described below change only the app-owned planning order. They are not execution controls and do not alter ticket delivery state. No direct execution controls are added.
  • Awaiting Delivery Goal acceptance appears in the existing Needs Review inbox. Its explicit Accept action is owner-app-only; the Phase Board remains read-only for delivery/execution and Delivery Goal acceptance, except for the explicit owner-app planning-order controls described below and external agent tools cannot assert owner acceptance.

Ticket ordering

  • Each project and existing lane has one app-owned canonical sequence, separate from ticket placement. Ticket records remain authoritative for phase, lane, lifecycle, completion, acceptance, dependencies, readiness, execution, and ticket/phase revisions.
  • Migration seeds that sequence from the existing All-phases order. A newly placed ticket or a ticket entering another lane appends to that lane; tickets that remain in a lane retain their persisted order identities.
  • A move target must be placed, nonretired, outside Accepted, and in a phase that is not Completed. Nonretired hidden or otherwise protected tickets can remain identity anchors and crossed positions, but are not rewritten merely because another ticket crosses them; their displayed position may change.
  • Move earlier and Move later are explicit owner-app controls on eligible cards and work with pointer input, Space, and Return. Drag-and-drop is not required.
  • Moves resolve before/after ticket identities against the complete lane sequence, including nonretired tickets hidden by phase or Delivery Goal filters. A filtered board never derives a move from rendered-array indexes.
  • A move preserves the ticket's lane, phase, goal, completion, acceptance, dependency, readiness, execution, and task/phase revision state. The app validates the submitted ordering context and traverses the full stored project dependency graph, including hidden, off-lane, unassigned, and retired witnesses. Only explicitly Accepted prerequisites cut satisfaction edges. A move is rejected for an unmet reachable prerequisite/dependent pair only when both endpoints have comparable positions in the same lane and at least one endpoint is the moving ticket or a logically crossed/shifted ticket. Untouched endpoint pairs do not block a move merely because their path traverses a shifted ticket, and lanes do not form a cross-lane timeline. A conflict identifies the prerequisite, dependent, witness chain, lane, and phases.
  • Reordering is one atomic owner command with its audit event and receipt. Only one move or ordering reload is active at a time; no duplicate mutation is submitted. Reordering does not provide auto-sort, batch repair, override, or an implicit recovery for a legacy dependency-invalid sequence.
  • While a move is saving, the last committed projection remains visible and ordering controls are disabled. The selected ticket and keyboard and accessibility focus remain on that ticket when the result is presented.

Goal language

  • App-owned planning records are always labelled Delivery Goal.
  • Runtime observations and exact ticket/runtime links are always labelled Codex execution goal.
  • The generic inspector heading GOAL CONTEXT is replaced by the two explicit sections when either type of context is shown.
  • Delivery Goal lifecycle words are Draft, Planned, Active, Awaiting acceptance, Accepted, and Superseded.
  • Codex goal status retains its own observed/last-known/stale/unavailable vocabulary and timestamp.

Compact and accessible behavior

  • At compact widths, goal and plan controls may wrap below the phase heading; they must not collapse into an unlabeled icon or hide the active/viewed distinction.
  • Compact cards retain the approved ticket-ID and constraint-count density. Goal membership remains available in the inspector and filter summary.
  • Keyboard order is Viewed phase, Make active phase when applicable, plan summary, Delivery Goal filter, Unassigned filter, density, lanes, inspector.
  • VoiceOver labels include the viewed phase, whether it is active, plan state, revision, covered/eligible count, unassigned count, and whether a filter is applied.
  • Focus remains on a selected ticket when filters still include it; otherwise focus moves to the filter summary and announces that the prior selection is outside the current filter.
  • Eligible cards expose labelled Move earlier and Move later controls in keyboard and VoiceOver navigation; saving and reload states disable those controls without losing the selected ticket or its focus.

Failure and recovery states

  • Store unavailable: replace plan and board content with the existing actionable store-recovery state; do not show cached readiness as current.
  • Refresh failure after a successful plan mutation: state that the plan was saved and a refresh is needed; do not invite duplicate submission.
  • Revision conflict: show the current revision and reload action while preserving the owner's unsubmitted view state where safe.
  • Observation unavailable: Delivery Goal content remains visible; only Codex execution context becomes unavailable or stale.
  • No goals in Legacy/Draft: show No Delivery Goals recorded and the exact unassigned upcoming-ticket count.
  • Stale or unavailable complete ordering context fails closed and offers Reload ordering. A rejected move or save failure retains the last committed sequence and makes no partial write; a successful concurrent change is shown only after the latest committed context is reloaded.
  • If the move commits but the immediate refresh fails or returns a different context, show Ticket order saved with Reload ordering. Reload must only fetch the committed sequence and must not repeat the mutation; the notice clears only when the matching committed context is displayed.
  • If the command outcome is unknown, direct the owner to reload persisted state before continuing rather than inviting a duplicate move.

Visual acceptance

The running signed application must be compared with the approved Phase Board reference at relevant wide and compact window sizes. Acceptance requires the same five-lane hierarchy and design language, explicit active/viewed separation, truthful plan and coverage states, unambiguous goal labels, complete keyboard and VoiceOver behavior, and no regression to card density or inspector access.