Someone deliberately broke StareBrain's stale-plan protection to test it

StareBrain's whole premise rests on one gap: a user approves an action, then something changes before it actually executes. A booked slot fills. A contact's info updates. The plan you approved isn't necessarily the plan that runs a few seconds later.

For weeks that's been a described problem, not a tested one. This week someone in the community actually built the test instead of just discussing it with me.

The setup: plan a booking from an available slot, then deliberately flip that slot to unavailable before dispatch — run it two ways.

Without a validation boundary in front of the action: it fired anyway. One booking effect, on a plan that was already stale.

With the boundary: blocked. Zero effects. Flagged as stale reasoning before it could execute.

It's a small filesystem fixture, not StareBrain's real code and not a live calendar integration — deliberately small, so the only thing being tested is whether the boundary catches a plan that's gone stale between confirm and execute. It did.

Next step is running the same shape against a real StareBrain action instead of a fixture. First time this exact failure mode went from something I keep describing to something that was made to happen on purpose, and stopped.

Building StareBrain in public. Waitlist: starebrain.vercel.app/waitlist