NodeFlow: Speak it, IBM Bob 2.0 builds it

The problem. An unclear request costs you three times: in implementation (you build too much or too little), in review (there is nothing to compare against, so review becomes opinion) and in fixes (the defect surfaces late, when other code already sits on top of it). The workflow. Every request starts as a contract — scope, function signature, enumerated cases — committed before any code, so the request has a fixed date. IBM Bob 2.0 implements against that text. Then an independent review by a different agent audits the delivery against the same contract. One real request: the contract for the partial-transcript segmenter was committed first (docs/hackathon/PEDIDO-BOB-01.md); Bob implemented the module and its endpoint and delivered cff0baa; a later revision fixed its stability (e84fb5b). A second request — creating nodes when the voice turn closes — landed in 8582026, and the review caught that nodes were being created once per audio segment instead of once per turn, fixed in 0e059ed. The steps are manual and deliberate: this is not an automatic voice-to-code pipeline. What we built. A local-first desktop app (Tauri + Rust + React Flow) where you think out loud and the canvas draws itself: a deterministic segmenter decides whether what you said is an idea, a correction or noise; a draft node appears while you speak; and when the turn closes, each topic becomes a real node — chained, draggable, connectable — created without a confirmation step, because the safety net is undo. A public web demo runs the same interface in the browser, with real dictation powered by a temporary session the server issues, so nobody has to bring their own key. The interface ships in Spanish and English. Why it holds together. The canvas is where the request becomes the contract: you talk, the nodes appear, and it is written down while it is still fresh. The contract is what makes review objective, and the review is what catches the defect before merge. The limits, stated up front. The test counts (324/324 Rust, 141/141 frontend) are recorded results from the suites on the named commits, not a measured saving. The defect caught in review is one case, not a controlled experiment. The process was applied to this project: it does not prove general productivity.