Someone Turned a Bubble Tea Shop Into a State Machine, and the Comments Are Asking Why Formal Verification Doesn't Work

lauren asked on X for use cases of /statechart and /create-formal-verification. The request was straightforward: post the diagrams you made with /statechart and the bugs you found with the formal verification skill. The install location for pstack was also provided: pstack.

The featured video first gives an answer that doesn't look much like a state diagram. April used /statechart plus Colorfigures to make a set of isometric scenes, then had characters move around inside them. A subway station cross-section, coffee beans going from branch to cup, Saturday being decided by dice, and farm animals that talk. Every scene is clickable; the animations are decoration, and underneath it is still states and transitions.

Kevin Ngo's reply is closer to everyday use of the tool. He used @poteto's /statechart to draw the business flow of a bubble tea shop; it's open source, and the model was Claude Opus 5.5. The first diagram shows order states from queuing to getting the drink: queuing, ordering, paying, staff making it, refunding if there aren't enough pearls, calling out the order number, picking up the order. The second diagram breaks a day into 7 a.m. to 9 p.m.: prep, open, quiet, busy, peak, closing. The next two break down more details.

Fanfulla left a comment below: I didn't expect a bubble tea shop could be made into such a good state machine. That judgment isn't exaggerated. The biggest risk with state machines is drawing them as abstract boxes, while a bubble tea shop happens to have clear states like queuing, paying, refunding, and calling numbers; even “out of pearls” can become a transition.

The comments weren't just showing off diagrams. max said this was a quick draft for trying the tool out on a current project, and that he likes visualizing flows.

swaglord420 posted a screenshot of formal verification not working and asked why.

Morgan's feedback was the opposite: he didn't know what he was doing, but the skill found a bug. Donnie Cornwell also said he found a bug while creating the diagram.

D3 and cradrrat also posted result diagrams.

Asmir gave a suggestion that sounds more like an engineering process: have the tool draw a statechart from existing code, then diff it against the one drawn from the spec. Transitions that don't match are very likely bugs worth investigating. This idea is closer to verification than just looking at a generated diagram: draw the spec and the implementation once each, and the differences speak for themselves.

Krrish's question is also key: can /statechart actually start from a plain-English flow, or does it have to read a codebase? The original post didn't give a clear answer under that reply. For people who want to try it, this question determines whether the entry point is a design document or a repository.

Here's the pstack install location again: pstack. If you have a development background, you can look directly at the plugin repository. If you don't have a coding background, you can still understand what the state machine is doing from these diagrams: break the flow into states, events, and transitions, then see which path doesn't work. The diagrams in the material are already enough to show that once state diagrams get specific to bubble tea shops and subway stations, the discussion shifts from whether the diagram looks good to where the flow will break.