jsunderland323

Yup, this is usually the case in pig butchering operations iirc.

I’m building a video game for our abernic device with my son (no game engine experience, just vibing the game engine ourselves). We’re having a blast. We play up to our progress right before bedtime stories.

The other day I refused to fire it up for him and he had a full meltdown. I told my wife I had never seen product market fit like that before.

It is a little harder with something like a game to maintain motivation and go for perfection when you know your audience is an audience of one but it’s also a relief to just worry about the things he cares about (trains and firetrucks).

I also miss there being something intellectually challenging to a side project but that probably means I just need to learn a real game engine after this.

I'm not sure. The docs on claude -p are sort of ambiguous on third party usage

I’m sorry I didn’t reply sooner. I’d love to hear about the diff/commit/rollback stuff you’re working on. Feel free to message me on discord or however you like (I’m pretty easy to find).

I wanna hear how they compose naturally.

I have waited 12 hours for someone to ask this! You are my hero.

So the name "hot" is a bit misleading. The containers don't actually stay alive through the switch. What happens is we do the umount -l /workspace, mount --bind, mount --make-rshared sequence first, and then we run docker compose up --force-recreate. Force-recreate skips compose down (which would tear down the network, named volumes, everything) and just swaps the container processes in place. The old containers and their file watchers are killed and new ones start up.

By the time the new container processes start, /workspace already points at the new worktree so all their file handles are fresh and correct. There's no window where a watcher could be writing to stale paths because the old processes are just gone.

I was pretty afraid of this at first too but it turns out the force-recreate sidesteps the whole problem.

Actually pretty reliably but you do need to explicitly call out the skill. I usually start agent threads with /coasts or in codex $coasts. Once it’s in the conversation they stick to it though.

One cool thing we do is we have the docs and semantic search of our docs baked into the CLI, so if the agents get lost they can usually figure things out kind of quickly by searching the docs via the cli.

Also we have a little section our agent.md and claude.md,I’m not sure how well it works without that.

I think this was a common perspective from early docker days with regard to local bind mounts (before docker switched from virtual box with hyperkit on macos). I do use Orb Stack and have noticed faster build times with Orb Stack but I haven't really noticed any difference in runtime performance between Orb Stack and Docker Desktop.

Interesting, I was not aware.

Well fortunately it's the name of a local observability ui and not the actual product. We'll change it if it becomes a problem.

There a couple of ways you can go about MCP within coasts (also depends on what the MCP does). You can either install the MCP service host-side (something like playwright), in which case everything should just work out of the box for you.

Alternatively, you can setup the Coast to install MCP services in the containers. There are some cases around specific logging or db MCP's where this might make sense.

>Would love to see this support stdio-to-HTTP bridging so local MCP servers can be exposed as remote ones without rewriting them.

Are you saying if you exposed the MCP service in the Coast and hosted it remotely you could expose back the MCP service remotely? That's actually a sort of interesting idea. Right now, the agents basically need to exec the mcp calls if they are running host-side and need to call an inner mcp. I hadn't considered the case of proxying the stdout to http. I'll think about how best to implement that!

I could definitely see that being useful for folks who are Docker-fearful or just less infra literate in general.

I think we're focused on the other end of the spectrum. Folks who like docker and have a good docker setup but want to have parallel runtimes. Anyway, best of luck!

We started with an approach like that but I think our grounding principal has been that you shouldn't have to modify your docker-compose to get parallelized local development. I think we want to layer onto your existing setup, not make you re-write your stack around us.

I haven't really had a bad experience with Docker on Mac. but Is the idea you basically just build your service on top of specific.dev's provided services (postgres and redis) and those run bare-metal locally and then you can deploy to specific.dev's hosted solution?