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>
The transport needed Crafter.Network's callback API, which lived on an
unpushed branch, so project.cpp took Network from whatever project.cpp
$CRAFTER_DEBUG_NETWORK named. That API and the ~ClientQUIC fix are on
Network's master now (79a2f12), so the hook goes: Network comes from
forgejo, unpinned, or from ../Crafter.Network with --local, as before.
The notes and the README stop telling people to set it, and say which
Network the transport needs. Every test passes with Network cloned from
forgejo, and the example builds and is driven end to end that way.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A consumer adds its debug-only sources, the ones that import
Crafter.Debug, under the same condition Use adds the library. Testing
its own flag is not that condition: a build with the flag for a target
other than native Linux gets neither the library nor the define, and
its debug-only sources would then fail to import Crafter.Debug. Use
now returns whether it added them, and the README shows the pattern.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The agent notes describe the wire, list :Transport and :Quic, explain
how to build against a Network worktree with CRAFTER_DEBUG_NETWORK, and
how to test a listening session. They add the one thread Crafter.Debug
starts, the TLS and size limits, and gotchas: Crafter.Network must be
named alike by a consumer that uses it too, last 0, and replying before
raising a flag the main loop acts on. The README says the Session needs
a pool worker, that a project pinning its own Crafter.Network can't add
Crafter.Debug yet, and what ShouldServeOverQuic covers.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- README: how the pieces fit, adding Crafter.Debug to a project
(Debug::Use, the shared-args rule, Session and Pump, the AGENTS.md
checklist), the app-side API with examples, the fixed-step and
Crafter.Graphics patterns, a shim module for calls without #ifdefs,
and the agent side: commands, exit codes, stopping apps, attaching
a debugger, version skew.
- AGENTS.template.md: the configurations and partitions, commands,
test conventions (including the dangling Value::Find pointer two
tests hit), style, design rules, security and gotchas.
- tooling/AGENTS.consumer.md: what every consumer's agents read in
each session, kept short: the loop, exit codes and the gotchas,
pointing at `crafter-debug guide` for the rest.
The QUIC transport the README describes lands next.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
