ADR 023 Generic Task Adoption - joeroberts/release-radar GitHub Wiki

  • ID: ADR-023
  • 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: Authorized Phase 6 local outcome; source completion and architecture authorization do not imply full owner manual acceptance or deployment authority.

Context

Adoption uses existing app-owned task commands and one explicit owner reconciliation without a competing task model.

Read inventory and owner reconciliation

The read-only agent surface exposes one bounded, project-scoped delivery inventory containing the exact registered root, all phases and lifecycle state, placed and unassigned tickets, retirement and Accepted restrictions, task-plan presence/revision, every active or superseded task row, and the derived active count. Capture and authorization are revalidated before the result is returned; an oversized, partial, stale-registration or unavailable read fails without presenting itself as complete and writes no delivery, audit or receipt state.

Task adoption remains a guidance-driven use of the existing revisioned task commands. Owner approval applies to one exact reconciliation and does not give repository prose, tests, commits, evidence or an agent independent mutation authority. Exact command receipts remain the recovery mechanism: uncertain outcomes replay the original complete envelope, while a changed baseline requires a refreshed reconciliation. Phase 6C evidence can support an explicitly approved prior completion only when its exact ticket/task scope is currently applicable, available and successful; evidence never completes a task by itself.

This decision adds no task database, proposal engine, watcher or owner-state mutation. Adoption cannot change ticket lanes or outcomes, Delivery Goals, phase readiness, review or acceptance, and the existing Accepted, retired, Completed- phase and unassigned-execution guards continue to control the typed commands.

Task commands and replay

Generic adoption does not introduce another task model or mutation path. A complete typed inventory supplies the exact plan absence or revision and retains all task identities, including superseded history. One owner-visible reconciliation classifies each scoped non-Accepted ticket as atomic, non-atomic, already planned or blocked, and names every proposed addition, permitted definition revision and supersession while showing unchanged rows. Atomic tickets may continue to have no plan.

Approved changes use reviseTicketTaskPlan and completeTicketTask with the existing optimistic revisions, lifecycle guards, atomic audit and durable receipt semantics. New plans start at revision 1 with Active/Pending rows. Omission is not deletion or supersession, completing all tasks moves no ticket, and evidence or delivery artifacts never imply completion. Evidence-backed prior completion is a separate explicit owner decision after a current Phase 6C applicability read. Exact replay is the only recovery for an uncertain request; reconstructing a similar request is a different command against a newly reconciled baseline.

Managed guidance

Managed guidance v3 adds the generic task-adoption workflow while leaving catalog schema v1, managed evidence identity and the release-radar-handoff:v1: audit identity unchanged. Exact shipped guidance v2 remains recognized as an outdated, narrowly upgradeable state. Exact v3 is current; modified, duplicated, malformed or newer managed declarations remain unavailable/recovery states and are never silently replaced.

The packaged Release Radar skill uses the read-only complete delivery inventory, produces one exact owner-visible reconciliation, and then uses the existing task commands and receipts. It does not parse Markdown into runtime tasks or treat a catalog, ledger, implementation approval, commit, test or evidence record as approval to mutate task state. The product-owned onboarding and repair prompt can install the exact v3 block only through the existing explicit handoff workflow; this delivered source change does not upgrade owner repositories or installed plugins.