bartwaardenburg

Thanks for trying it out! Accuracy is the #1 priority every finding should be real and actionable. Glad to hear that's holding up on your project. If you do hit any false positives, please open an issue!

The fields/flags state model is a nice idea, having structured values separate from boolean state is something I haven't seen in other frameworks. How does this compare to Alpine.js or htmx in practice? They're in a similar space (no build, SSR-first) but I'm curious what made you go with a new framework rather than building on top of those?

It's a CLI. CLIs have man pages and cheat sheets. That's not a UX failure, that's the format. The same argument would apply to git, ripgrep, or ffmpeg.

The actual complexity in Claude Code isn't the commands, it's figuring out a workflow that works for your codebase. CLAUDE.md files, hooks, MCP servers, custom skills. Once you have that set up the daily usage is just typing what you want done.

This matches my experience. The bottleneck isn't what the agent knows, it's what the agent can verify. A knowledge base tells it "don't do X", but the agent still has to remember to check. Giving it a tool that returns ground truth works better. The agent calls the tool, gets a concrete answer, acts on it. No memory required, no drift over time.

This is a good point. For anything without a DOM, screenshot diffing is basically your only option. Mozilla did this for Gecko layout regression testing 20+ years ago and it was remarkably effective. The interesting part now is that you can feed those screenshots to a vision model and get semantic analysis instead of just pixel diffing.