Docs/Projects/Decisions (ADRs)
// PROJECTS

Decisions (ADRs)

Not every piece of a project ships a diff. Some of it is figuring out how to do the work — choosing an approach, settling an open question. Leroy handles that with spikes: decision and investigation tickets that record an ADR (architecture decision record) instead of producing code, and that can gate the tickets which depend on the answer.

01 Spikes

A spike is a ticket whose output is a decision, not a change. When a project has an unresolved choice — which library, which data model, which migration strategy — that question becomes a spike. Leroy investigates it, weighs the options, and writes down the decision and the reasoning behind it.

Normal ticket
Ships a diff — code lands in a PR and merges.
Spike
Ships a decision — records an ADR in the decision log; no diff to merge.
i
Spikes live in the same graph. A spike is a node in the project's dependency DAG like any other ticket — other tickets can be blocked by it, so the decision lands before the work that relies on it starts.

02 What an ADR is

An architecture decision recordis a short, durable note that captures a single decision: what was decided, why, and what the alternatives were. It's the standard way teams keep a paper trail of significant choices so the reasoning survives past the moment.

An ADR a spike records typically captures:

  • The decision — what was chosen.
  • The context — the question being answered and the constraints in play.
  • The options considered — and why the alternatives lost.
  • The consequences — what this commits the rest of the project to.

03 The decision log

Every ADR a spike records lands in the project's decision log — a running history of the choices made along the way. Later tickets (and you) can read it to understand why the project is shaped the way it is, instead of re-litigating settled questions or reverse-engineering intent from the diff.

i
Decisions are context. The log is part of what Leroy pulls in when it plans and codes the dependent tickets, so the recorded choice actually steers the work that follows it.

04 Gating dependent tickets

Because a spike sits in the dependency graph, the tickets that hinge on its outcome can be blocked by it. They stay blocked until the spike records its decision — only then do they become ready and get scheduled. That keeps Leroy from coding against an approach that might still change.

  1. The spike runs first. Leroy investigates the open question while dependent tickets wait.
  2. The decision is recorded. The ADR lands in the decision log, resolving the spike.
  3. Dependents unblock. Tickets gated on the spike become ready and build on the recorded decision.

From there the unblocked tickets flow through the normal pipeline — triage, plan, code, review, ship — under your policy gates, with the ADR as part of their context.