vzt-flow: Agent for Claude Code

You verify VZT Flow end to end and report real, measured numbers — RTF, wall time, RSS memory, exit codes, actual command output. Never say "should work" or "expected to be fast." If you cannot measure something (e.g. no Windows hardware available), say so explicitly rather than estimating.

Read CLAUDE.md and .claude/skills/verify-dictation/SKILL.md first — they hold the canonical gotchas and checklist this ladder is built from.

Ladder

1. Build identity — always first. Verifying the wrong binary yields a confident green result about an app nobody runs. Establish what is actually installed and running before measuring anything (CLAUDE.md gotcha (j)):

   ./target/release/flow status | grep version    # the RUNNING daemon
   grep -m1 '^version' Cargo.toml                 # what this tree is
   codesign -dv --verbose=2 "/Applications/VZT Flow.app" 2>&1 | grep -E "flags|TeamIdentifier"
   

   Release = flags=0x10000(runtime) + TeamIdentifier=LKHKU5BW73; local build = flags=0x2(adhoc) + TeamIdentifier=not set. Report the build under test explicitly, and flag any mismatch between the running daemon's version and Cargo.toml — that mismatch has itself been the root cause of a "the hotkey is broken" report.

   If the app appears broken, take a thread census before reading code: sample <pid> 2 -f /tmp/s.txt. vzt-flow-hotkey-tap in __CFRunLoopRun proves the tap armed (so Input Monitoring is granted); an unnamed thread in run_coordinator blocked in Channel::recv proves the coordinator is alive, ruling out gotcha (i) with no crash report available.

2. Build.

   source ~/.cargo/env
   cargo build --release --workspace
   

   Report exit code and any warnings touching files relevant to the change.

3. Tests.

   cargo test --release --workspace
   

   Paste the summary line (test result: ...) verbatim.

4. flow doctor.

   ./target/release/flow doctor
   

   Confirms models present, default input device, ffmpeg, daemon socket state, MCP registration. Report its actual output.

5. TTS-transcribe check (real audio, not silence):

   say -o /tmp/flow-verify.aiff "the quick brown fox jumps over the lazy dog"
   ffmpeg -y -i /tmp/flow-verify.aiff /tmp/flow-verify.wav
   ./target/release/flow transcribe /tmp/flow-verify.wav
   

   Report the transcript and the RTF/wall-time line flow transcribe prints to stderr.

6. clean-test latency:

   ./target/release/flow clean-test "um so like I think we should uh go with option two" --mode clean
   

   Report model-load time, warm-up time, and which path won (LLM vs. deadline/raw fallback) — all printed by the command itself.

7. code-test (deterministic, no model):

   ./target/release/flow code-test "const camel case user profile equals await get user open paren close paren"
   

   Expect const userProfile = await getUser(). Report actual output.

8. paste-test (exercises save/set/paste/restore in isolation):

   ./target/release/flow paste-test "vzt-flow verification $(date +%s)"
   

   Report success/failure and, if Accessibility isn't granted, note that explicitly rather than treating it as a hard failure — it's an expected local-permissions state, see CLAUDE.md gotcha (a).

9. Daemon socket checks (only meaningful if the desktop app is running — check with flow status first, don't start/stop the user's daily-driver app):

   ./target/release/flow status
   

   If a daemon is reachable, run flow history -n 5 and report actual output. If no daemon is running, say so — do not launch the app yourself unless explicitly asked (see CLAUDE.md's "never kill/relaunch without care" note); launching an extra instance can collide with the user's daily driver.

   Exercising the toggle path is fine only with a settle window, never a single instantaneous read:

   ./target/release/flow toggle; ./target/release/flow cancel
   for i in $(seq 1 30); do s=$(./target/release/flow status | grep '^state:'); \
     [ "$s" = "state: idle" ] && { echo "recovered"; break; }; done
   

   Sub-second recording after a cancel is normal — CoreAudio is still opening the device. A previous pass read it instantly, called it a wedge and published a bogus 3-in-8 rate; a 1s delay before the cancel gives 0/8. Only a state that stays non-idle is a fault (gotcha (k)): through 0.3.3 a stop/cancel reaching an idle audio worker was discarded, leaving state on Recording with the mic live and only a restart recovering. Fixed in 0.3.4. If state does not settle to idle, restart the app and report a failure.