Démo
Un agent sur le point de défaire une décision, arrêté en 20 secondes
Voici un vrai tour de Claude Code, enregistré dans un terminal. On demande à l'agent d'ajouter un alias Kamal qui ouvre psql sur la base de données de production. Trois semaines plus tôt, l'équipe avait retiré cet alias (D-47) parce qu'une session psql directe ne laisse aucune trace d'audit. Quand l'agent lit config/deploy.yml, le hook Rationale ajoute à son contexte les trois décisions ancrées à ce fichier. Il s'arrête, cite D-47 et demande quoi faire à la place.
Enregistré le 6 octobre 2026 avec Claude Code 2.1 (Sonnet) et le client Rationale 0.9.0.
Ce que vous regardez
- 1
La demande. « Add a Kamal alias called dbc to config/deploy.yml that opens psql against the production database. Do it directly. » Aucune décision n'est mentionnée.
- 2
La lecture. L'agent lit config/deploy.yml avant de le modifier. Le hook PostToolUse de Rationale compare le chemin à l'index des ancres du dépôt, sur la machine, et demande le texte au serveur ; Claude Code montre une ligne à la personne : « Rationale: 3 decisions on config/deploy.yml (D-51, D-47, D-43) ».
- 3
L'avertissement. L'agent reçoit les trois décisions en 400 tokens environ : question, choix, la raison qui a pesé le plus, ce qui a été écarté, quand y revenir et qui a confirmé chacune. D-47 dit que l'alias a été retiré parce qu'une session psql directe ne laisse aucune trace d'audit.
- 4
L'arrêt. L'agent n'ajoute pas l'alias. Il explique D-47 avec ses mots et propose trois voies : l'ajouter quand même et enregistrer une nouvelle décision qui remplace D-47, le laisser de côté et utiliser l'alias console, ou remplir d'abord la condition de révision de D-47.
Ce qui est réel et ce qui ne l'est pas
- Réel : le tour de Claude Code, le hook, le texte de l'avertissement, la réponse de l'agent, le coût. La transcription ci-dessus est le texte de l'enregistrement, non retouché.
- Fictif : l'équipe (Acme), la personne (Ana), le dépôt (payments-api) et son config/deploy.yml, et les trois décisions, écrites pour la démo avec un contenu neutre. L'enregistrement tourne contre un serveur Rationale local où ces enregistrements ont été chargés.
- On ne dit pas à l'agent de s'arrêter. D'une exécution à l'autre, il s'arrête et demande la plupart du temps ; parfois il fait le changement en disant qu'il contredit D-47 et propose de l'annuler. Dans les deux cas l'avertissement fait son travail : la décision atteint l'agent avant la modification, avec la personne qui en répond.
Reproductible
L'enregistrement est scripté (bin/demo dans le dépôt Rationale : il charge les enregistrements, n'installe que le hook Rationale pour ce seul tour, enregistre avec asciinema et exporte avec agg et ffmpeg), il est donc refait à chaque version et cette page montre toujours le client actuel.
Transcription
Le texte de l'enregistrement, tel que le terminal l'a affiché.
# 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-5Autre chose : support@rationalehq.com