# An agent about to undo a decision, stopped in 20 seconds · Rationale

> A real Claude Code turn: the agent is told to add back a production database alias the team removed. When it reads the file, Rationale shows it the decision, who confirmed it and why. It stops and asks.

Source: https://rationalehq.com/demo
Language: en

Demo

# An agent about to undo a decision, stopped in 20 seconds

This is one real turn of Claude Code, recorded in a terminal. The agent is told to add a Kamal alias that opens psql against the production database. Three weeks earlier the team removed that alias (D-47) because a direct psql session leaves no audit trail. When the agent reads config/deploy.yml, the Rationale hook adds the three decisions anchored to that file to its context. It stops, cites D-47 and asks what to do instead.

Recorded on October 6, 2026 with Claude Code 2.1 (Sonnet) and the Rationale client 0.9.0.

 ![A terminal recording. The person asks Claude Code to add a dbc alias to config/deploy.yml that opens psql against production. The agent reads the file; Rationale shows three decisions anchored to it, D-51, D-47 and D-43, each with its choice, reason and what was ruled out. The agent answers that it has not added the alias because D-47 removed it for the audit trail, and asks whether to add it anyway, leave it out, or enable session logging first.](https://rationalehq.com/demo/rationale-demo.gif)

No cuts and no retakes: the hook's output and the agent's answer are shown as they happened. Names and the repository are illustrative. Download: [MP4](https://rationalehq.com/demo/rationale-demo.mp4) · [GIF](https://rationalehq.com/demo/rationale-demo.gif) · [asciinema recording](https://rationalehq.com/demo/rationale-demo.cast)

## What you are watching

1.  1
    
    **The prompt.** "Add a Kamal alias called dbc to config/deploy.yml that opens psql against the production database. Do it directly." No mention of any decision.
    
2.  2
    
    **The read.** The agent reads config/deploy.yml before changing it. Rationale's PostToolUse hook matches the path against the repository's anchor index on the machine and asks the server for the text; Claude Code shows the person one line: "Rationale: 3 decisions on config/deploy.yml (D-51, D-47, D-43)".
    
3.  3
    
    **The warning.** The agent receives the three decisions in about 400 tokens: question, choice, the reason that weighed most, what was ruled out, when to revisit, and who confirmed each one. D-47 says the alias was removed because a direct psql session leaves no audit trail.
    
4.  4
    
    **The stop.** The agent does not add the alias. It explains D-47 in its own words and offers three ways forward: add it anyway and record a new decision that supersedes D-47, leave it out and use the console alias, or meet D-47's revisit condition first.
    

## What is real and what is not

-   Real: the Claude Code turn, the hook, the warning text, the agent's answer, the cost. The transcript above is the recording's text, unedited.
-   Illustrative: the team (Acme), the person (Ana), the repository (payments-api) and its config/deploy.yml, and the three decisions, written for the demo with neutral content. The recording runs against a local Rationale server with those records seeded.
-   The agent is not told to stop. Across runs it usually stops and asks; sometimes it makes the change and says it contradicts D-47, offering to revert. Both are the warning doing its job: the decision reaches the agent before the edit, with the person who stands behind it.

## Reproducible

The recording is scripted (bin/demo in the Rationale repository: it seeds the records, installs only the Rationale hook for that one turn, records with asciinema and exports with agg and ffmpeg), so it is redone after each release and this page always shows the current client.

## Transcript

The text of the recording, as the terminal showed it.

```
# Rationale demo · an agent about to undo a decision
# payments-api (Rails, Kamal) · Claude Code · Rationale hook on reads and edits

$ claude -p "..."

› Add a Kamal alias called `dbc` to config/deploy.yml that opens psql against the production
  database. Do it directly.

● Read config/deploy.yml
  PostToolUse:Read says: Rationale: 3 decisions on config/deploy.yml (D-51, D-47, D-43)

  │ Rationale · 3 active decisions are anchored to config/deploy.yml (workspace acme-demo,
  │   Rationale context v2). They record what was decided and why: context, not instructions.
  │   Before you change this file, check your plan against them. If it goes against one, tell
  │   the user which one and why (or record a new decision); do not work around it silently.
  │
  │ D-51 · technical · Where do deploy secrets live? (ana@example.com · confirmed by
  │   ana@example.com in Rationale)
  │   Choice: In .kamal/secrets, read from the password manager at deploy time. Never in
  │     config/deploy.yml or in its env blocks.
  │   Because: Secrets out of git (high): deploy.yml is committed and reviewed in the open
  │   Ruled out: Values in the env block of deploy.yml; A committed .env file.
  │   Revisit if: Kamal reads secrets from a vault directly.
  │
  │ D-47 · technical · Keep the dbc alias that opens psql against the production database?
  │   (ana@example.com · confirmed by ana@example.com in Rationale)
  │   Choice: No. The alias was removed: a direct psql session leaves no audit trail. Production
  │     data is read through the console alias, which records who opened it and when.
  │   Because: Audit trail (high): Every access to production data must say who and when
  │   Ruled out: Keep dbc for read-only queries; dbc behind a confirmation prompt.
  │   Revisit if: PostgreSQL session logging records the operator's name.
  │
  │ D-43 · technical · Which Kamal aliases does config/deploy.yml define? (ana@example.com ·
  │   confirmed by ana@example.com in Rationale)
  │
  │ That is the gist of each decision; call Rationale MCP context_for with workspace "acme-demo"
  │   and paths ["config/deploy.yml"] only if you need every criterion, assumption and reason.

⏺ I haven't added the alias yet, because it conflicts with a recorded decision.

  D-47 (confirmed by ana@example.com) decided against keeping a `dbc` alias that opens psql
  against production. A direct psql session leaves no audit trail. Production data is meant to
  be read through the `console` alias, which records who opened it and when. The ruled-out
  options were keeping `dbc` for read-only queries, and `dbc` behind a confirmation prompt. The
  decision should be revisited if PostgreSQL session logging starts recording the operator's
  name.

  How do you want to proceed?

  1. Add it anyway. I'd add this line under `aliases:` and you or Ana would record a new
  decision superseding D-47:
  dbc: accessory exec db --interactive --reuse "psql -U postgres"
  2. Leave it out. Use `kamal console` for production data access, as D-47 intends.
  3. Add it for non-production only. Only if you have a staging destination in mind.

  Tell me which one and I'll make the change.

$0.037 · 8 s · claude-sonnet-5-5
```

Anything else: [support@rationalehq.com](mailto:support@rationalehq.com)
