Another meaningful API refinement just landed in @foldkit! It’s a significant one, but after using it across the codebase and in my own Foldkit projects, I’m confident it’s the right call. Update results have been tuples since Foldkit’s first release. This release replaces them with { model, commands?, outMessage? } records. Using records makes each result easier to read and compose. When an update produces no Commands, just omit the commands field. When it emits no OutMessage, just omit outMessage. No need to specify [] and Option.none() at each return site. The new types also let TypeScript reject code that could silently lose an OutMessage, a nice little correctness win. This also enables a new convention I really like: keep each result bound to the operation that produced it and access its fields directly, rather than destructuring at each call site. The operation stays named, and its Model, Commands, and OutMessage stay grouped together. Overall: less ceremony, more signal, stronger OutMessage safety. Win win win. There is a detailed migration guide in the release notes: github.com/foldkit/foldkit/r… Thank you to everyone building with Foldkit as I continue honing the API for v1. I’m immensely grateful! This change started with a suggestion from @SandroMaglione. Thank you! :)

Foldkit has server rendering now. `foldkit/experimental/server` One view function and one Model, rendered on the server and hydrated on the client. SSR and SSG are both opt-in. No split between server and client views, no Server Components, and no "use client"-style boundaries. Experimental while the API and operational contract settle through real-world use. Start with `foldkit@0.148.0`, pin the exact version you deploy, and test upgrades against your host. foldkit.dev/blog/foldkit-has…

Writing Foldkit by hand is fun, but the framework really shines with AI. Foldkit’s rigid, yet expressive structure means the models are working in a much smaller solution space, and are far more likely to do the correct thing on the first try. A few things help the models perform even better. First, skills. The most useful: - /foldkit, the always on skill for Foldkit dev. Sets the agent’s posture. - /audit-program, for auditing against best practices and de-slopping. Helpful as a cleanup pass. And second, make sure to add the foldkit repo as a subtree. This gives your agents all the docs, all the examples, and the Foldkit website as high-quality, local reference material. foldkit.dev/ai/overview