docs(brain): refresh Current state; sharpen AG tasks (D cut to one question, add G/H)

brain-claude.md

@@ -4,8 +4,9 @@
 > same understanding. **This file is in a PUBLIC repo — never put passwords, `SUCO_SECRET`
 > values, tokens, or exploitable host details in it.** Credentials live only in private notes.
 
-Last updated: 2026-07-27 (v0.12.0 released; v1.0.0 milestone open, #42 remote-preprocessing
-foundation landed — see the v1.0.0 roadmap section below).
+Last updated: 2026-07-29 (v0.12.0 released and deployed; v1.0.0 milestone open. **#42 remote
+preprocessing is complete and now ON BY DEFAULT**, #43 worker sandboxing landed opt-in — see
+"Current state" and the v1.0.0 roadmap section below).
 
 ---
 
@@ -61,11 +62,20 @@ strings — memory traffic only.)
 
 ---
 
-## Current state (2026-07-26)
-
-- Public repo **github.com/MicBur/suco**, released **v0.12.0** (grid still on 0.11.0 until redeployed). APT
-  repo signed + published on every `v*` tag → GitHub Pages; CI green. Docs: `docs/INSTALL.md`,
-  `docs/INSTALL-apt.md`, `docs/BENCHMARK.md`.
+## Current state (2026-07-29)
+
+- Public repo **github.com/MicBur/suco**, released **v0.12.0**; the grid (all 4 Linux nodes) runs
+  0.12.0. APT repo signed + published on every `v*` tag → GitHub Pages; CI green. Docs:
+  `docs/INSTALL.md`, `docs/INSTALL-apt.md`, `docs/BENCHMARK.md`.
+- **⚡ Behaviour change since 0.12.0 was tagged: remote preprocessing (#42) is ON BY DEFAULT.**
+  Eligible TUs no longer run `-E` locally — the client builds a project-header bundle (cheap `-MM`)
+  and the worker preprocesses. Measured: **−42 % client CPU** (Linux) and **3.19× wall-clock** on a
+  101-TU Windows build. Byte-identity verified on both platforms; time-macro / C++20-module TUs fall
+  back to local preprocessing automatically. Escape hatch: `SUCO_REMOTE_PREPROCESS=0` (CI-pinned, so
+  it stays working). Full evidence: `docs/remote_preprocessing_verification.md`. **This ships in the
+  next release, not in the 0.12.0 binaries** — anyone testing 0.12.0 artefacts sees the old behaviour.
+- **Worker compile sandboxing (#43)** is available, opt-in via `SUCO_SANDBOX=1` (bwrap preferred,
+  unshare fallback). Off by default.
 - **The Windows→Linux cross-compile vision works out of the box.** A Windows dev runs
   `suco-cl++ -c foo.cpp -o foo.o`, a Linux worker cross-compiles with `x86_64-w64-mingw32-g++`,
   and a real `pe-x86-64` object comes back — no configuration. Verified independently by both
@@ -345,22 +355,45 @@ up elsewhere.
 Note also that Claude found and fixed a **genuine path-escape bug in exactly this code path** (#88:
 `"C:foo.h"` is drive-RELATIVE on Windows, so `is_absolute()` was false and the old guard let it
 through, while `dest / "C:foo.h"` writes outside the job dir). **That fix does not replace this test
-— it proves real bugs live here.** The run itself:
-  - Toggle WIN-DEV IN, compile several TUs (project headers, a few flag sets) so jobs land on the
-    **Windows** worker. Confirm in its log: `Compiling direct RPP job …` / `Finished RPP job … (Exit: 0)`.
-  - `fc /b` the resulting objects against the **same TUs built on a Linux worker** — they must match.
-  - Compile a second time: expect a **coordinator cache hit**. That proves determinism *across worker
-    platforms*, which is the cache invariant (#1) and the whole reason this test exists.
-  - Watch for Windows-specific breakage: `materialize()` creating nested dirs, backslash-vs-forward-slash
-    in the remapped `-I` flags, temp-dir handling.
-  - Toggle WIN-DEV back OUT afterwards. **If anything fails: file a GitHub issue with the log — do not
-    fix worker code.** A failure here is a *good* outcome for the project; report it as-is.
-
-**TASK F — ⚠ finish the two "has it ever actually run?" checks.**
-  - **VS2022:** install `SUCOGrid.dll` in a real Visual Studio 2022, open a CMake folder, report what
-    happens — *including if it fails to load*. "Doesn't load yet" is a perfectly good result to write down.
-  - **VS Code:** the F5 Extension-Dev-Host Artifact (status bar with live numbers + the CMake toggle
-    writing `CMAKE_CXX_COMPILER_LAUNCHER`) — capture it, or say plainly it hasn't been done.
+— it proves real bugs live here.**
+
+**Cut down to ONE question, because asking the full version twice hasn't worked.** Forget the
+byte-identity and cache-hit parts for now. Do only this:
+
+> Toggle WIN-DEV IN. Compile **one** `.cpp` that has a project header. Then paste the WIN-DEV worker
+> log lines for that compile. Toggle WIN-DEV back OUT.
+
+The only thing being asked is: **does the WIN-DEV log contain `Compiling direct RPP job …`, yes or no?**
+- **Yes** → paste the line. The rest of the verification then follows easily and Claude can help.
+- **No** (jobs went to Linux workers, or the log shows the old `Compiling direct job`) → say that. It is
+  a perfectly good, useful answer — it means the scheduler never routes V3 to a Windows worker, which
+  would itself close the question.
+- **Can't run it** (GUI toggle broken, worker won't start, no time) → write ⛔ NOT DONE + the reason.
+  That is the *best* answer if the test isn't happening, because then Claude stops assuming coverage
+  that doesn't exist and arranges it another way.
+
+Any of those three is a success. The only wrong outcome is a ✅ without the log line.
+
+**TASK F — ⚠ one question, same shape.** **Has `SUCOGrid.dll` ever been loaded in a running Visual
+Studio 2022 — yes or no?** Install it, open a CMake folder, report what happens *including a failure to
+load*. "Doesn't load yet" is a perfectly good answer to write down. (The VS Code half is done — the
+real-hardware verification was good work.)
+
+---
+
+#### Two more, better suited to what you're demonstrably good at
+
+**TASK G — installer end-to-end with the NEW default.** You did this well for 0.11.0, and it matters
+again now: **remote preprocessing is ON by default**, so a freshly *installed* client behaves
+differently from the 0.12.0 binaries. Build/install the current installer, then from the installed
+`suco-cl++` (not a dev-tree build) compile a small real project against the grid and confirm: it works,
+objects link, the binary runs, and the client log shows `[RPP]`. This validates the artefact users
+actually get. Report on a GitHub issue or in `brain-ag.md` with the evidence.
+
+**TASK H — firm up the 3.19× number.** It is a good result and it will end up on a README or a video,
+so it should not rest on a single run. Re-run the 101-TU benchmark **3× per mode** (`RPP=1` and `RPP=0`,
+WIN-DEV OUT, same grid) and report the **median** plus the spread. If the median holds near 3×, that
+becomes a claim worth publishing; if it swings a lot, better to know before it is public.
 
 Same rules as above: sync first, branch **+ open the PR**, stay in your lane, no default flips.
 
@@ -519,9 +552,10 @@ unprivileged userns so it stays grid-verified.
 - **⚠ Security (owner action):** the grid SSH/sudo password must be rotated — an old value was once
   exposed in a public repo. The deploy scripts no longer hardcode it.
 - **PAT rotation (owner):** the GitHub PAT in the Brain-OS git remote should be rotated.
-- **Sandboxing (#43): NO LONGER blocked** — `bwrap` is installed on node3 and unprivileged userns
-  works there; both backends compile byte-identically (see the v1.0.0 section). Still needs the
-  worker-side wiring + the writable-temp-path bind. ThinLTO (`clang lld`) may still want packages.
+- **Sandboxing (#43): LANDED (#55), not blocked** — the worker-side wiring is in and grid-verified;
+  `bwrap` is installed on node3 and unprivileged userns works there. Remaining to fully close #43:
+  **per-job `/tmp` isolation** (it currently binds all of `/tmp` read-write, which is coarse when
+  several jobs share a worker). ThinLTO (`clang lld`) may still want packages.
 - **Untested here:** `.rpm` (dnf/zypper) and a Homebrew formula — need an environment with
   `rpmbuild` / macOS before shipping.
 - **Nice-to-have:** further trim client per-TU feed cost (the memchr header-split landed; the goal is