Building and verifying

One command per platform. Each finds the repo from its own path, runs every stage, and prints a pass/fail line per stage plus a test count.

.\scripts\verify.ps1     # Windows: everything, including the collectors and the live e2e suite

./scripts/verify.sh      # macOS or Linux: everything that is not Win32

Nothing in either script captures anything or touches the network. The tests use temporary stores and an in-process transport.

The two are not interchangeable, and this matters more than it sounds

verify.sh runs the contract, the store, the gate, the uploader, the OS seam and the whole TypeScript half. verify.ps1 runs those plus the Windows half: here-win, the indicator, the supervisor, the collectors, the five Win32 spikes, and the end-to-end suite that starts a real gate process and talks to it over real named pipes.

So a change touching a collector, the indicator or the supervisor is unverified until it has been run on Windows. verify.sh says this in its own summary rather than leaving a green line to imply otherwise, and it fails if the list of packages it skips has drifted from the packages that actually exist.

Which one you ran is worth stating out loud when you report a result, because "green" means different things on the two machines.

Current counts: 453 on Windows (367 Rust, 86 TypeScript). The Mac's number is whatever verify.sh prints there — it reports its own total and what it skipped, which is more reliable than a number written down here.

Stages, in the order they run

Stage	What it catches
pnpm install	lockfile drift
console front-end build	a broken React build before the Rust host embeds it
contracts-lint	263 checks over 15 event types and 7 manifests — a manifest disagreeing with the registry, a content field not marked, a retention number out of step
codegen-check	generated Rust or TypeScript that is stale relative to contracts/
cargo clippy -D warnings	lints, as a gate rather than advice
cargo test --workspace	the unit, integration and end-to-end suites
console status tests	the console's status derivation, where two UI-honesty bugs lived
platform-adapter tests	the server-side rules, which live in the adapter rather than in the dev server
typechecks	each TypeScript package and the admin app

After touching contracts/ or a manifest

Regenerate, or codegen-check fails:

cargo run -p xtask -- codegen

contracts/ is the source of truth for both languages. Editing generated files in crates/here-contract or @here/contract is not a fix; it is a thing codegen-check will undo.

Running it by hand

.\scripts\start.ps1 -Suffix live -Grants "session,indicator,focus,input.metrics"
node scripts\dump-session.mjs live
.\scripts\stop.ps1

start.ps1 deliberately does not apply the firewall rules — only the supervisor does that, and only with administrator rights. So a run started this way does not have the network-denial invariant in force. Use the supervisor, or the console's Start button, for one that does.

It also spawns every role the way the product does, with no console windows and output redirected to logs/<role>.log, so testing by hand looks like the real thing rather than like malware.

If a stage fails on the first run

On Windows the clippy stage may. The Windows-only crates went a long time without ever being linted, and that stage is doing its job when it stops you. See What running it taught us for what it found the first time it ran.