47 lines
3.8 KiB
Markdown
47 lines
3.8 KiB
Markdown
---
|
|
name: reference_guru5070_rust_toolchain
|
|
description: 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
|
|
metadata:
|
|
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.
|