ADR 018 Saved Additive Planning Proposals - joeroberts/release-radar GitHub Wiki

  • ID: ADR-018
  • Status: Accepted
  • Date: 2026-09-10
  • Date meaning: Original dated decision/source section; extraction recorded 2026-10-02.
  • Implementation: No implementation information was recorded in the source status; tickets own progress.
  • Approval qualification: Recorded owner-approved Phase 5 scope; slice-specific exclusions and later dependencies remain as stated.

Context

Saved proposal versions, owner decisions and application are separate facts; this decision covers the original additive operation set.

Approval and application authority

Saved immutable plan-change versions, explicit owner-app decisions and separate atomic application are distinct persisted facts. Approval binds exact version, complete planning baseline and current registration; it neither executes work nor approves external writes. Stale state requires a new preview/version and approval. The initial operation set is additive planning and first placement, preserving started/Accepted history and existing obligations. Successor/carry-forward and full phase lifecycle remain later slices. Retained approval history never survives registration rotation as live application authority. The Phase 5C brief defines the bounded operation set, baseline, recovery and native acceptance contract. The packaged agent interface exposes release_radar_save_plan_change_proposal and the read-only release_radar_plan_change_proposals query. It intentionally exposes no decision or application tool: those operations remain trusted owner-app actions and the dispatcher rejects external-origin attempts before replay lookup.

Phase and goal additions

An approved proposal may atomically add a phase, phase-owned Draft goals and done criteria, first-place an unassigned ticket into Backlog, make its initial goal assignment and add new dependency edges. It reuses the existing planning policies, revision increments and readiness invalidation inside the proposal application transaction. Approval itself changes none of these records.

This slice cannot replace a phase or goal identity, transfer or remove an existing goal assignment, supersede a goal, retarget/remove a dependency, start work or change goal/phase lifecycle. Existing ticket subjects must still be unassigned or Backlog and satisfy the existing unstarted protections. Those limits preserve the outstanding carry-forward contract for Phase 5D rather than treating an additive proposal as reconciliation.

Task additions

A saved proposal may add pending task definitions to a new or eligible existing unassigned/Backlog ticket. The saved baseline includes task-plan presence and revision plus every task definition, completion and lifecycle fact. Apply rechecks that exact baseline and calls the existing task-plan revision policy inside the same transaction as the rest of the approved work package.

Proposal operations cannot revise, replace, complete or supersede existing tasks, and cannot mutate started or Accepted tickets. Existing task IDs, completion, lifecycle and outstanding obligations are preserved; successor and carry-forward reconciliation remain Phase 5D.

Recorded source impacts

Saving a proposal records the exact current reference-link versions for every affected existing ticket, including both ends of a proposed ticket dependency. Each impact retains ticket/link identity, repository/artifact identity, link version, source digest and observed path/lifecycle/authority. These are immutable proposal facts derived from the already accepted reference record; they do not accept a catalog, read a different source into history or authorize repository mutation.

Native proposal detail opens an impact through the existing exact-version source route. That route retains the Phase 5B bounded reader, expected-digest and authority checks. Missing access, different current bytes or unavailable historical content remain explicit and never cause another version, source or ticket to be selected.