Statewave Guide
The Journey Index
We're building a help chat that actually understands the product — by reading the codebase, not a wiki — and we're showing the whole build, including the parts that didn't work. Every episode lands here, in order.
Episodes
- Day 0
Statewave Guide — Day 0: The Beginning
A help chat that actually knows how the product works. We're building it in public, starting now.
Read episode
- Day 1
Statewave Guide — Day 1: The DOM is not the product
Day 0 ended with 257 tests passing and a working closed loop. Adversarial review found six bugs anyway — and forced the decision that shapes the whole project.
Read episode
- Day 2
Statewave Guide — Day 2: Unknown is better than wrong
We can follow a real user action from a button to the backend without guessing. Getting there meant discovering that our own benchmark was wrong — and fixing the benchmark, not the indexer.
Read episode
- Day 3
Statewave Guide — Day 3: True is not the same as relevant
We finally put a real model behind the Guide, and not one invented route reached the product model. It still produced a claim that was true about the application and wrong about the feature we asked about.
Read episode
- Day 4
Statewave Guide — Day 4: We passed the safety test. Then failed the product test
Nothing dangerously wrong, nothing useless, almost everything mediocre — and the reason was not the missing capabilities we expected.
Read episode
- Day 5
Statewave Guide — Day 5: We taught it to speak. Then realized it still doesn't finish the job
Guidance compilation fixed the language, and the system still stopped halfway through the task. Correct English is not the same as complete guidance.
Read episode
Follow the build
Get each new Statewave Guide post by email.
Along with occasional Statewave updates. Unsubscribe anytime — privacy.
What is Statewave Guide?
An AI help system with Statewave underneath. It works only from the program code and its comments, and from that alone it takes a visitor straight to what they are trying to do — pointing at the right control, explaining it, and walking them through the task. It is built to replace manuals and tutorial videos, not to sit beside them.
Why is this series written after the build?
Because the code is ahead of the story. Every build day is already a commit in the public repository, and it shows how the project ended. The posts are about why each step went the way it did — nearly every day ended with something we got wrong, and a rule we took away from it.
The running threads
Every episode advances at least one of these.
#source-of-truth
The code as documentation — routes, forms, schemas and git history read as product knowledge.
#memory
The assistant remembering the user across sessions, so it stops explaining the same thing twice.
#guidance
Actually pointing at things inside the live UI, rather than describing where they are.
#trust
Permissions, being wrong, and the things it must never do.
