Logan Hartman
Red Eye Tickets

Accepted architecture decision

Keep production repair local-first and release-gated

Red Eye can use agents to investigate and prepare bounded fixes, but production authority stays outside the agent loop. Evidence comes in; reviewed changes go out through existing gates.

ADR status: acceptedDecision owner: CTODocumented: July 2026
01

Context

Red Eye combines checkout, payments, ticket issuance, refunds, event configuration, and live admissions. An operational symptom can cross several of those boundaries, and a plausible-looking repair can still violate a financial or ticket-state invariant. The design goal is faster investigation without quietly transferring production authority to an agent.

02

Options considered

Autonomous production agent

Rejected

Benefit: Fastest path from alert to mutation.

Cost: Requires broad production credentials and makes ambiguous failures too easy to turn into high-blast-radius changes.

CI-hosted repair agent

Deferred

Benefit: Repeatable environment close to merge checks.

Cost: Moves repository write access and sensitive operational context into a remote runner; awkward for long investigations and visual QA.

Local-first bounded repair

Accepted

Benefit: Uses an isolated worktree, local credentials, full developer tooling, and explicit human release control.

Cost: Depends on an operator machine and does not promise unattended 24/7 remediation.

03

Resulting control flow

  1. 1
    Collect evidence

    Read health, deployment, alert, CI, and runbook context without granting write authority.

  2. 2
    Classify the task

    Identify restricted areas, required invariants, missing evidence, and the permitted repair lane.

  3. 3
    Work in isolation

    Plan and patch in a dedicated worktree with a narrow file scope and an explicit rollback path.

  4. 4
    Verify and review

    Run targeted tests, inspect the diff, and produce a durable evidence packet.

  5. 5
    Gate release

    Open a PR or escalate. Existing GitHub and Render controls—not the agent—authorize deployment.

04

Consequences

What this improves

  • Production credentials do not need to live in a general agent runtime.
  • Every attempted repair leaves plan, diff, verification, review, and rollback evidence.
  • Local browser, database, and debugging tools remain available for ambiguous failures.
  • Release authority stays legible to the humans accountable for the system.

What this does not solve

  • It is not an unattended always-on remediation service.
  • Operator workstation health and credential hygiene still matter.
  • Local environment drift can complicate reproduction.
  • Approval queues can limit recovery speed for high-risk changes.
05

Revisit conditions

This decision should be revisited when all of the following are true:

  • A hardened remote runner can use short-lived, least-privilege credentials.
  • The safety benchmark shows sustained recall on restricted areas and required invariants.
  • Rollback and canary controls are automated and independently verified.
  • Observed incident volume justifies always-on automation over the simpler local operating model.

Next: the evals and operational tools that make those boundaries measurable →