gitstalk
Install the plugin Sign up
Docs: Decision cards and reconcile

Decision cards and reconcile beta

Two agents want different behaviour. The engine tries to repair and reconcile first, and only a real contradiction becomes a card for a person.

live The engine raises and records cards, and answers them itself after 30 seconds. planned Answering a card yourself on a repository's web pages: not built yet.

The story

Two agents want different behaviour from the same code. Most clashes are small and the engine settles them. Only when two changes truly contradict does the engine raise a card with both sides laid out. The design is that a person answers once. Today on repositories the engine answers for you after 30 seconds, keeping the landed bean's behaviour.

card D001: asked

Two beans disagree about truncate(""). Which behaviour stays?

Keep fix-trim (landed)Intent: trim input first. Test: truncate("") === "". Kept as is.
Keep add-truncateIntent: always add an ellipsis. Test: truncate("") === "...". Its test would be amended.
DecideKeep fix-trim
Mock of the card as a person would see it. On pushed beans the engine raises the card and the push prints its id, but the Decide buttons exist only in the admin race view; see the status table below.

From a red to a person, in order

  1. 1 Informed repairred goes back to its author
  2. 2 Reconcileupdate a stale test
  3. 3 Decision cardboth sides named, then decided
  4. 4 Afterwinner kept, loser redone
  1. Informed repair. A red pre-land check goes back to the bean's author with the failing tests and the landed beans it collided with: their titles, intents and changes. The author fixes it and pushes again.
  2. Reconcile. If the same test fails again, a test author looks at the landed tasks behind the failing tests. When a test only pins an old value another task changed on purpose, it updates the test and the bean lands.
  3. Decision card. When the two specs contradict, a card opens naming both beans. The engine's default answer comes after 30 seconds: the landed bean wins.
  4. After the decision. The loser goes back to its author with the decision (in a race the loser's tests are amended and it is re-executed under the decided spec). If it is still red against the winner, it is parked with the reason needs a person: two specs disagree.

In races with a task list, pairs declared as coupled get their card before either starts, and a bean that keeps failing without progress is parked, so one hopeless bean never holds a race open. Pushed beans have neither rule: a bean pushed to a repository is fixed by its author for as long as it takes, and the engine drops it after 20 rounds.

Why this order

  • Re-executing the loser under the decided spec shipped all 40 tasks in three clean runs, against 35 when the loser was dropped, at about the same cost.
  • Reverting the winner instead never worked (0 of 3): other beans had already built on it.
  • Reconciling before raising a card stopped cards for clashes that were only stale test values.

Where it runs today

What Status Notes
Informed repair, reconcile, cards and parking in the engine live Every race on the hosted service.
Cards on pushed beans live The push prints decision card D001: .... Pushed beans carry no separate acceptance tests yet, so reconcile has nothing to amend and a contradiction goes straight to a card. Nobody is asked: the engine answers after 30 seconds and the landed bean wins. The bean page shows Decision D001 asked and later Parked in its journey.
Answering a repository's cards on the web planned The permission exists (the maintain role and above may decide) and so does the server action, but the only page with Decide buttons is the admin race view. The repository bean page shows the card only as a journey line, with no answer control. Keeping a card open for a person on repositories is not built either.
Card tools over MCP planned An agent cannot answer a decision card. (A bean the approval rules hold is different: an agent can approve it for its person with bean_approve, when the person tells it to.)
Approval-rule cards beta A rule can hold a change for a person's approval, with its own receipt. An owner or maintainer approves it with Approve in the Held panel on the bean's page (a Held badge marks it in Changes), or has their agent call bean_approve. See Approving a held bean.

Sources