ADR 010 Scoped Development Exceptions - joeroberts/release-radar GitHub Wiki

  • ID: ADR-010
  • Status: Accepted
  • Date: 2026-10-02
  • Date meaning: Recorded proposal date; not an acceptance date.
  • Implementation: Not implemented; this document proposes the contract.
  • Approval qualification: Acceptance is separate from drafting, publication, and implementation authorization.

Context

An integrity failure can block useful, bounded development work. A bypass needs explicit authority, exact limits, expiry and visible tracking so it cannot become a silent or permanent waiver.

Decision

Provide a reusable development-exception skill, initially supporting only the eligible ADR-integrity failures defined in its supporting contract.

  • Bind each exception to the exact repository, failed condition, content, operation and scope. Require explicit owner authorization, an accountable person, an expiry and concrete resolution criteria.
  • Record it in an open GitHub issue associated with the work. Bind approval to the exact record version; shared GitHub credentials and an “approved” comment do not prove owner authorization.
  • Permit only the narrowly defined retained-content, missing-record, stale-hash and informational uncatalogued-record cases. Never waive changed accepted bodies, unresolved authority or scope, missing baselines, unsafe inputs or unauthorized transitions.
  • Recheck eligibility, content and current approval before dependent work. Expiry, revocation, resolution, issue closure or changed approval terms invalidate reliance. Renewal requires new explicit authority.
  • Report proceeding under exception, never verified. Keep the integrity problem visible until direct checks establish repair; expiration alone does not resolve it.

The supporting contract defines eligibility, the issue-record schema, approval binding, validation, labels, recovery and test requirements. It remains proposed alongside this ADR. Additional exception categories require deliberate authorization and a new architectural decision.

Rationale

A bounded exception allows necessary work while preserving the unresolved failure and its owner. Reusing the existing issue avoids a separate approval database. Exact content and approval binding prevent an exception from silently expanding to different work.

Boundaries and consequences

An exception cannot override STOP, grant execution or destructive-action permissions, accept a decision, edit an accepted body or reset its baseline. Retrieved content remains untrusted data.

Fresh GitHub access and trusted authorization context are required for exception-dependent work. Ordinary verified work does not depend on the exception service. Labels provide visibility, not authority.

Checks and subsequent actions are not atomic. A withdrawal never observed and absent from retained history cannot be detected. The skill must disclose these limits rather than claim universal enforcement. Implementation and activation await owner acceptance.