Every codebase carries two histories. Git records what changed — every line, forever. But the why lives somewhere far more fragile: a Slack thread, a meeting nobody wrote up, the head of the person who left last spring. And now, increasingly, inside an AI coding session that will be compacted, closed, and forgotten by Thursday.
Elyra 0.9.36 gives the why a home in your repository.
Here's a scene we kept noticing. You spend an afternoon with the agent weighing Livewire against Inertia for a new admin area. You look at the tradeoffs, you pick Inertia, you explain your reasoning, and the agent builds it. Good session.
Three weeks later, a colleague — or you, or the agent in a fresh session — looks at the code and asks: why Inertia? The rest of the app is Livewire. Nobody remembers. The session that held the answer was compacted twice and then closed. The decision survived; the reasoning evaporated.
Elyra already had memory for how — /learn distills procedures into your AGENTS.md, and skills capture hard-won solutions. But a decision is a different kind of knowledge. It has rejected alternatives. It constrains future work. And critically, it belongs to the team, not to the person who happened to be at the keyboard. That means it belongs in the repo.
Decisions now live at .elyra/memory/decisions/, one Markdown file each, in a lightweight ADR format:
.elyra/memory/decisions/
2026-08-14-store-audit-events-in-clickhouse.md
2026-09-02-use-inertia-over-livewire-for-the-admin-ui.md
---
id: 2026-09-02-use-inertia-over-livewire-for-the-admin-ui
title: "Use Inertia over Livewire for the admin UI"
date: 2026-09-02
status: active
---
# Use Inertia over Livewire for the admin UI
## Context
Livewire round-trips became a bottleneck on the dashboard's live tables.
## Decision
Build new admin pages with Inertia + Vue; leave existing Livewire pages as-is.
## Alternatives considered
Keep Livewire (too many round-trips for live tables); Blade + Alpine
(too much manual state management).
## Consequences
CI needs a Vite build step. Two frontend paradigms coexist until the
admin migration is complete.
Why one file per decision instead of a single log? Because two developers compacting sessions in the same week would collide on a shared file every time. Separate files never conflict, and the format is the ADR convention teams already recognize. You get git blame on your reasoning and PR review on your architecture choices — for free.
Decisions are never deleted. When you reverse one, the new decision supersedes the old, and the old file stays with status: superseded and a pointer forward. The history of "why did we switch back?" is half the value.
Two paths, and they cover each other.
The deliberate path. When you settle a choice in conversation — "let's go with ClickHouse for audit events, Postgres won't scale past this" — the agent records it with the new decision_record tool. By default you see an approval dialog first:
─────────────────────────────────────────────────────
Record this architecture decision in the project log?
Store audit events in ClickHouse (2026-09-04)
Write audit events to ClickHouse via a queue; Postgres
audit table grew past 200M rows.
> Record decision
Discard
─────────────────────────────────────────────────────
The bar is deliberately high. The agent's instructions say: lasting impact, alternatives rejected, constrains future work. Naming conventions and one-off fixes don't qualify. Nobody wants a decision log full of "chose camelCase."
The safety net. Sometimes a decision gets made and nobody says "record that." Then compaction comes along and discards the conversation that held it. So compaction now looks before it discards: we append a small machine-parseable request to the summarization call that already runs — no extra request, no extra cost — asking for any lasting decisions in the history about to disappear.
In confirm mode, you'll see:
Compaction found 1 unrecorded decision: Store audit events in ClickHouse.
Ask the agent to record it, or /decisions auto to record automatically.
In auto mode, it's simply written. Either way, nothing is silently lost.
A log nobody reads is just a file. So a compact digest of active decisions — title plus one line each — goes into the agent's system prompt in every session:
# Architecture Decisions
- **Use Inertia over Livewire for the admin UI**: Build new admin pages
with Inertia + Vue; leave existing Livewire pages as-is.
- **Store audit events in ClickHouse**: Write audit events to ClickHouse
via a queue.
The agent respects these unless you explicitly revisit one. The digest is budget-capped, so a long-lived project's decision history can't crowd out the working context it exists to protect. Full text stays on disk for the read tool when the agent needs the reasoning.
And for humans, /decisions:
/decisions
- `2026-09-04-store-audit-events-in-clickhouse` — Store audit events in ClickHouse
- `2026-09-02-use-inertia-over-livewire-for-the-admin-ui` — Use Inertia over Livewire
- `2026-08-01-use-livewire-for-interactivity` — Use Livewire for interactivity
(superseded by 2026-09-02-use-inertia-over-livewire-for-the-admin-ui)
3 decisions (2 active) · mode: confirm
/decisions 2026-09-02 shows one in full (a unique prefix is enough). /decisions auto or /decisions off switches the mode. Tab completion offers modes and ids.
Elyra now remembers three different things, and the boundaries matter:
Memory Answers Lives in AGENTS.md (via /learn) How do we do things here? Repo Skills How did we solve that hard problem? User or repo Decision log What did we choose, and why not the alternatives? Repo, per decision
Procedures, solutions, decisions. Keep them apart and each one stays findable.
GPT-6 Astra landed in the registry — OpenAI's new flagship, on the direct API, GitHub Copilot, and the gateways (with -pro, -fast, and half-price :batch variants). $10/$50, a million tokens of context, reasoning and vision. It sits in the same tier as Claude Fable 5.1, and like Fable it's a deep-tier pick rather than a default: gpt-5.6 stays the OpenAI default.
elyra update
Then, next time you and the agent settle something that matters, watch for the dialog. Say yes. Commit the file with your code. Three weeks from now, someone will thank you — and it might be you.