Crafter.Debug/tooling/AGENTS.consumer.md

## Crafter.Debug

Spike placeholder: the real notes land with the client. This project can be inspected and driven at runtime: build it with the project's debug flag, then run `./build/crafter-debug`.
feat(tooling): wire consumers in through Debug::Use and a launcher A consumer loads Crafter.Debug.Build through #pragma crafter dependency "<Crafter.Debug>" project "tooling/project.cpp" and calls Debug::Use in its own CrafterBuildProject, the way Crafter.LintRules gets in. With the consumer's flag on, Use adds the library from the checkout the pragma loaded, and writes build/crafter-debug: a POSIX sh launcher for the client that library builds. The client is one of the library's dependencies, so a debug build compiles it in the same pass as the app, from the same sources. Why a launcher and not a script: every `crafter-build run` loads the whole project first, which costs 13-28 s per call on 3DForts (a git pull per unpinned dependency plus rescanning sources), while the launcher is one sandbox start, 0.08 s. A client built in the Flatpak links the Flatpak's libc++ against the runtime's glibc, so the launcher starts it through `flatpak run` and never on the host itself; inside a CrafterBuild sandbox it runs it directly. The library, the client and examples/Basic are placeholders that prove the wiring: the debug build writes a launcher whose client exists, a plain build has no Crafter::Debug symbols and keeps the notes from tooling/AGENTS.consumer.md, and a fresh plain build writes a stub that names the flag. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> 2026-11-01 01:18:07 +01:00			`## Crafter.Debug`

			Spike placeholder: the real notes land with the client. This project can be inspected and driven at runtime: build it with the project's debug flag, then run `./build/crafter-debug`.