StareBrain is a confirm-before-execute layer for phone commands — send a text, book a calendar slot, whatever — show the user exactly what's about to happen, get a real confirmation, then execute. The part I keep coming back to isn't the confirmation screen itself, it's the gap right after it: the seconds between "user approved this" and "this actually ran."
A lot can change in that gap. A calendar slot fills. A contact's number updates. The plan a user approved isn't necessarily the plan that fires a moment later. I've been calling this the stale-plan problem, and until this week it was something I described in threads, not something I'd actually made happen and caught.
The naive answer, and why it wasn't enough
My first-pass fix was simple: re-check the specific fields an action depends on immediately before firing, and re-prompt if anything material shifted. That's fine as a sketch, but it's ad hoc — every action type ends up with its own bespoke staleness check, written slightly differently, tested inconsistently, easy to forget on the next action I add.
A few weeks ago, in a thread about exactly this problem, someone pointed me at FreshCtx — a library that formalizes dependency tracking and revalidation at an action boundary, rather than leaving it scattered per-feature. The pitch: ctx.run() checks the relevant evidence and invokes the action in one call, so there's no gap between "checked" and "acted" where the dependency file could change out from under you.
Reviewing before trusting
I didn't want to wire an unfamiliar library into a solo project without reading it first — no one else is reviewing my changes, so integrating on trust felt like the wrong habit to build. Went through the README and code structure before anything else.
Two things stood out. First, FreshCtx is Python and my backend is already FastAPI/Python, so no language mismatch to work around. Second, and more useful: the built-in adapters cover filesystem, Git, HTTP, Postgres, Stripe, and MCP — no calendar adapter out of the box. For the calendar-booking case I actually care about, I'd likely be writing a custom adapter, not using an existing one. Worth knowing going in rather than assuming a fit.
One correction I got from the maintainer that mattered: I'd described ctx.run() as atomic with the downstream action. It's not, quite. It revalidates immediately before invocation, which closes the stale-evidence gap at the boundary FreshCtx controls — but it can't make an external API call part of the same atomic transaction. If a calendar changes again after that point, or a request times out after the remote side already executed, that's a separate reconciliation problem FreshCtx doesn't claim to solve. Good to have that corrected before I built any assumptions on top of it.
Starting smaller than the real case
Given the calendar adapter gap, the obvious next move wasn't to build a custom calendar integration — it was to prove the mechanism works at all, on something with nothing provider-specific in the way. The actual question worth answering first wasn't "can StareBrain use FreshCtx," it was: can I put a FreshCtx boundary around one real action and deliberately change the evidence between planning and execution, and have it actually block?
The test
Small, deliberate, filesystem-based:
Plan a booking from a state where a slot is available (v7).
Change the underlying state — the slot becomes unavailable (v8) — before dispatch.
Run the same frozen action two ways: once through FreshCtx, once without any protection.
Unprotected path: the booking fired anyway. One booking effect, on a plan that was already stale by the time it executed.
Protected path: STALE_REASONING. Blocked. Zero booking effects.
Same frozen plan, same staled evidence, opposite outcomes depending on whether the boundary was in place. That's the whole test — not a writeup of what should happen, just the evidence, the protected action, and what the unprotected path did differently.
What this is not
This is a local filesystem fixture, not StareBrain's real code and not a calendar-provider integration. It doesn't touch OAuth, doesn't touch any real user data, doesn't prove the calendar adapter question is solved. It proves one narrower thing: the boundary catches a plan that's gone stale, in the smallest possible harness where that claim can be checked.
What's next
Same v7/v8 staleness shape, but against a real StareBrain action instead of a fixture — and eventually, the calendar adapter gap I flagged earlier, once there's a reason to build it rather than guess at what it needs in advance.
This is the first time this specific failure mode went from something I kept describing in comment threads to something that was deliberately made to happen, on purpose, with a receipt showing the difference.
Top comments (0)