ADR 001 Release Radar Boundaries - joeroberts/release-radar GitHub Wiki

  • ID: ADR-001
  • Status: Accepted
  • Date: 2026-08-23
  • Date meaning: Original decision date; normalization recorded 2026-10-02.
  • Implementation: No implementation information was recorded in the source status; tickets own progress.
  • Approval qualification: Recorded accepted decision; dated delivery conditions are historical, not new execution authorization.

Context

Release Radar is a personal, local-first delivery dashboard for folder-backed projects. It must present agent-managed delivery state without turning project repositories, Codex runtime data, or notification credentials into competing authorities.

Decision

Release Radar is a standalone, signed, sandboxed macOS application with bundle identifier com.rekonlabs.ReleaseRadar, minimum macOS version 14.0, and an app-owned Application Support data namespace derived from that bundle identifier. The Mac app is authoritative for delivery state. Repository documents and future read-only cloud publications do not become delivery authorities.

The app process is the sole authority allowed to open and write its SQLite database. A separately bounded read-only observer may supply Codex thread, goal, waiting, completion, and freshness context through a supported sandbox-compatible connection. A distinct, narrowly typed mutation bridge may request validated transactional delivery commands from the app. The observer cannot mutate delivery state; the bridge cannot open SQLite, issue generic commands, observe unrelated state, or receive Pushover credentials.

App Sandbox and Hardened Runtime remain enabled. Owner-facing builds use the configured Apple Development identity. Future helpers or tools must have their own signed identities and the minimum entitlements needed for their proven boundary; signing does not grant database authority.

The approved board has exactly five persisted lanes: Backlog, In progress, Needs review, Blocked, and Accepted. This supersedes the earlier Ready-lane concept. Dependency eligibility is derived context, not a sixth lane or an automatic transition. Observed Codex state never changes a formal lane implicitly, and agents may make any formal transition through the typed bridge.

Prohibited alternatives

  • Repository-backed dashboard manifests or recurring synchronization from arbitrary Markdown.
  • Treating Rekon seed JSON, Markdown, repository state, or copied SQLite databases as portable complete-project archives.
  • Direct SQLite access by agent tools, observers, helpers, or project processes.
  • A combined read/write Codex integration or a generic shell/filesystem/JSON-RPC mutation surface.
  • Credentials outside the app-owned Keychain boundary or credentials supplied to agents.
  • A cloud delivery authority, browser-hosted localhost dashboard, folderless projects, or owner-facing manual transition controls. The owner-approved future read-only companion publication boundary does not transfer authority or authorize deployment.
  • Full Disk Access, Accessibility scraping, Codex database/rollout-file scraping, or presenting cached/fixture state as live.
  • A persisted Ready lane or automatic lane transitions inferred from dependencies or runtime observation.

Consequences

Later integrations must prove a supported sandbox-compatible transport before implementation. Unavailable observation remains explicit and stale rather than silently becoming authoritative. All delivery mutations are app-validated, transactional, and audited.