I see, thanks, but how exactly can it help agents to use Datastar better? If it's a superset on Datastar, isn't it just another set of rules an agent needs to learn?
A very simple example is a stale link to a page that no longer exists. Datapages will not allow `<a href="/account">Account</a>` in your Templ templates, `datapages gen` or `datapages lint` will error. It will give you a hint, that you should be using a URL builder from the generated package instead: `<a href={ href.PageAccount() }>Account</a>`. And if that page is ever changed/removed - that will produce an actual compiler error.
But this is obviously just one of the smallest of mistakes.
A production ready application requires a lot of moving parts: - SSE stream subscription, teardown, per-tab state, panic recovery, and graceful shutdown. - Auth, sessions, CSRF, input validation, cross-origin, CSP, etc. - AI skills (I created and tested them for you so you don't have to). - Logging, metrics. - All the NATS boilerplate for doing proper CQRS. - Service workers, browser-local caches, static assets. - Live reload in dev mode (https://github.com/romshark/templier is built in) - etc.
Basically, I'm trying to move a lot of the "plumbing/infrastructure" code out of your and/or your agents ownership into the ownership of a well tested code generator to make it super cheap and easy to ship production grade Datastar apps in Go. You can literally wipe 2/3 of the code base and recreate it idempotently and deterministically, so you really only own and maintain 1/3 of the code (fewer bugs, fewer AI tokens).