fix(tooling): build first, then start the app, then list it
The notes had agents start `crafter-build <flag> -r` in the background and run `crafter-debug ls --wait 60s` straight after. That raced the build: the first agent to follow them ran the plain build's stub, which said "no debug build yet" and exited, since the client `ls --wait` needs is one of the things the debug build compiles, and it polled by hand until the build was done. The race came from the order, so the order changes: build with the flag in the foreground, which ends once the app and the client are built, then start the app with -r in the background, then `ls --wait`, which now only waits for what it is for, the app registering. A launcher that polls for the build instead was tried and dropped: a shell loop that reruns itself each second, and waits out its whole --wait when no build is coming at all. The consumer notes, the client's guide and the README say so, and the stub and the not-yet-built launcher name the step that was skipped. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
parent
4b37f872e7
commit
8e7f8c5f3b
4 changed files with 14 additions and 10 deletions
|
|
@ -12,7 +12,8 @@ Runtime debugging for AI agents, and for people. An app built with Crafter.Debug
|
|||
Breakpoints and memory stay with a debugger; `crafter-debug debugger` prints how to attach one.
|
||||
|
||||
```console
|
||||
$ crafter-build --debug-api -r & # the app's debug build, in the background
|
||||
$ crafter-build --debug-api # the app's debug build, and the client with it
|
||||
$ crafter-build --debug-api -r & # the app, in the background
|
||||
$ ./build/crafter-debug ls --wait 60s
|
||||
game id 4f1c09a2b7e3d851 pid 3 (sandbox 48211) up 4s port 41207
|
||||
$ ./build/crafter-debug call Lobby_Start && ./build/crafter-debug wait --frames 30
|
||||
|
|
|
|||
Loading…
Reference in a new issue