majority of this was handcoded and written. So yeah, this next piece is another one of those huge lifesaver ones because I was running into a lot of problems where I would make a change in T3 code and it would only apply to one of the surfaces. For example, it would only be changed on the desktop app and not the website or mobile. I wanted to stop doing that and also to make sure the docs kept up to date as well. So I said as much hit every surface. The most common defect in this repo is a change that works on the path you tested and is missing everywhere else. Before calling frontend work done, walk this list and say which entries apply. Make sure all the entry points are addressed. Things like settings page, command pallet, and key bindings. So if you add a feature in the chat view, it should be accessible in those places. You have clients because we need to make sure things work in all the different clients. the web version, the desktop version, as well as the mobile apps. Shared logic lives in the shared package client runtime section. And then the providers, each of our providers have their own adapters. Provider shape features need a decision per adapter, even if the decision is not supported here. Very helpful, especially when we add features for codeex and claude. Now you have to decide, okay, not cursor, grock, or open code because their implementations aren't quite as far along. Or maybe you do decide to sneak in Grock because their SDK has made a lot of progress. Super helpful. We also have this contracts package which describes everything that crosses the wire over the websocket server or the new HTTP backed like cold store. A lot of the time changes will be made in the app that aren't properly reflected in the contracts package. This one line has fully fix that. This was another really big one reverse states. I had a lot of instances where I added things like settle and snooze but the logic to unsettle or unsneeze was not provided. This helped a ton with that. Same with the connection modes, telling it the ways it can connect, make sure that they all work as expected, and then the docs. This call out ended up making me go even further. And I believe I still have a PR open for this. I do. I made a PR that I have to update and get merged soon where I properly split user and maintainer docs. So, they're two entirely separate entry points because I've had a lot of problems with models writing a bunch of the internal details of how something works in the userfacing docs. I had this a lot with lake bed and I still have it a bit with T3 code and I found that a really clear split plus a little bit of tuning in your agents MD to steer the model in the right direction helps a ton with this. Also gave some context on dev