claudetools/.claude/memory/reference_guru5070_rust_toolchain.md

name, description, metadata

name	description	metadata
reference_guru5070_rust_toolchain	GURU-5070 has a full Rust toolchain installed BUT a WDAC/Smart App Control policy now blocks running rustc/cargo locally (os error 4551) — build the Windows agent on Beast, not here; toolchain paths + CI gates still valid for reference	type reference

BLOCKED AS OF 2026-07-04 — do NOT rely on local Rust builds on GURU-5070. A Windows Application Control (WDAC / Smart App Control) policy now blocks execution of rustc.exe/cargo.exe (and sops.exe, openssl, gawk, Python cryptography's native DLL) — attempts fail with An Application Control policy has blocked this file. (os error 4551). This is the same policy behind the "Windows can't confirm who published …" blocks on unsigned binaries. Until the policy is adjusted to trust the toolchain, compile Windows agent/GuruConnect changes on Beast (guru@100.101.122.4, Tailscale; sccache at C:\sccache) via a throwaway git worktree + cargo check — see gururmm-beast-windows-build-host. The paths/gates below remain accurate for reference and for when the policy is relaxed. WDAC impact also breaks the vault/sops path here (use age+Node fallback per feedback_vault_gcm_shadow_auth) and silently swallowed error logging (CLAUDETOOLS_ROOT=D:/claudetools wrong-case → log-skill-error.sh can't write; real repo is D:/ClaudeTools).

As of 2026-05-30, GURU-5070 has the full Rust dev toolchain installed (able to build locally until the 2026-07-04 WDAC block above):

• cargo/rustc/clippy/rustfmt: C:\Users\guru\.cargo\bin\ (rustup; cargo 1.96, rustfmt 1.9, clippy 0.1.96).
• MSVC C++ Build Tools: VS2022 BuildTools (VCTools workload) — provides the x86_64-pc-windows-msvc linker.
• protoc: 35.0 via winget. The build.rs prost codegen needs it — set the env var first: $env:PROTOC = "C:\Users\guru\AppData\Local\Microsoft\WinGet\Packages\Google.Protobuf_Microsoft.Winget.Source_8wekyb3d8bbwe\bin\protoc.exe" (also set persistently as a User env var).
• Default target is x86_64-pc-windows-msvc (per the repo .cargo/config.toml), so this machine builds BOTH the server AND the Windows agent — better coverage than the Linux build host, which can't compile the agent.
• Local gates that mirror CI (run from the guru-connect dir with PROTOC set): cargo fmt --all, cargo clippy --workspace --all-targets --all-features -- -D warnings, cargo test --workspace, cargo build --workspace. Local rustfmt agrees with CI (verified — no skew).
• CI gap to know: CI only runs clippy on the Linux server build; the Windows agent crate is never clippy-checked in CI (let 77 errors accumulate, cleaned up 2026-05-30). Todo to add agent clippy to the build-agent (Pluto) job. So: clippy the agent LOCALLY before committing.

How to apply: when a Coding Agent works on GuruConnect Rust, have it self-verify with the local toolchain (set PROTOC, run the four gates, iterate to green) and commit CI-green code — don't delegate fmt/clippy to the build host. See project_guruconnect.

CI fmt gate — don't omit it from agent briefs (incident 2026-05-31): the CI Build Server (Linux) job runs cargo fmt --check as a hard gate FIRST (before build/test). SPEC-004 Task 2 + Task 4 (commits ffca7f0, 4e80573) went red on Linux CI even though the Coding Agents reported "clippy clean, tests pass" — because the briefs listed only cargo check + clippy + test and NOT cargo fmt --check, so rustfmt drift slipped through (compactly- written new test code). Fixed with a cargo fmt follow-up commit (cef1928). Every Coding-Agent brief that touches GuruConnect Rust MUST list cargo fmt --check (server: cd server && cargo fmt --check) as a required gate alongside clippy/test — a clippy-clean, test-green change can still fail CI on formatting.