diff --git a/brain-claude.md b/brain-claude.md index 3ddc297..ea7cf3d 100644 --- a/brain-claude.md +++ b/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