```

Get TAP to actually start
DONE: Integrate with Tauri — `buld cargo-shim` + scripts/buld-cargo runner.
  `tauri build --runner scripts/buld-cargo` compiles tap-app via buld and the
  CEF bundler produces `The AI Platform.app`. See docs/TAURI.md.

Two notes:
  - The hookup is opt-in via BULD_RUNNER. If you'd rather pnpm dev always use buld on your machine without typing the env var each time, I can make tauri.js
  default it on when buld is on PATH (with a CI/opt-out guard) — say the word.
  - First build is a full ~35min cold compile; subsequent runs hit buld's cache. BULD_SHIM_INCREMENTAL=1 further speeds repeated dev rebuilds.

One gotcha worth knowing: tauri/build.rs canonicalizes its script path against the mounted manifest dir, baking a per-session path into tauri's rlib. Since
  buld keys crates on inputs (not output), rebuilding tauri alone desyncs its SVH from cached dependents (E0460→E0463). A clean single-session build is
  consistent; partial rebuilds after evicting tauri are not.

Enable incremental rebuilds for workspace crates (and put it outside the CAS) - https://chatgpt.com/c/6a2e8150-c098-83ec-8e59-eca80810583d

Moving CAS to users home folder:
 - CAS *integrity* under concurrent builds is now handled lock-free: ephemeral
   staging/scratch/bscopy dirs are named per-process (Compiler::session) so
   concurrent `buld`s can't clobber each other, and commit is an atomic
   rename-or-discard (first writer wins). What's left is *work dedup* — two
   concurrent builds of the same crate still both compile it. That's the case for
   the build daemon (accept jobs over a socket, dedup in-memory by primary key).
 - Using a CAS? Eg. hash objects and then a manifest between input hash and asset hash for lookups???

Ensuring the hash isn't path dependant. I should be able to move the project and the cache should hold???

 Known follow-up (noted in memory, not blocking): an all-cached build still takes ~75s because entry_hash re-reads and hashes every traced input across
  ~1415 crates — there's no mtime fast-path like Cargo's fingerprints. Correct, just a perf opportunity if you want near-instant no-op builds next.

Make `zephyr-bindings` build script work

Parellalize builds???
Remove the `traces` folder



Replace `install` subcommand so we can use it
Replication `--offline`

We need smart utitilies for flagging stuff which never hits the cache (and hence is probs us doing something wrong???)


Maybe rename "anvl"

Configuration file for sandbox capabilities:
 - per-crate for:
 - network
 - file system paths (with default allowed list)
 - env vars
 - files which can be accessed (as it can break reproducability of build, it needs to be present on the system with the same hash for the cache to be restored?)

Maybe some dependencies need to be immpure???


Should we expose `.gitignored` or local changes into the sandbox as it breaks reproducability but should be covered by hashing so probs fine.
 - We need to hash binaries and paths accessed and check they exist before restoring from network cache.

Don't use current folder, instead use Cargo workspace root.

Can we define OS hook for whether env var is used.


We need to account for build script watching paths, and other configurations they emit.

built 49 crate(s), reused 0 from cache in 25.95s
Finished `dev` profile [unoptimized + debuginfo] target(s) in 9.94s

Configuring features properly
Support for `.cargo/config.toml`

Agent focused output (maybe automatically detect) to reduce token usage. Eg. ignore "compiling..." just have errors/warnings
Add `--verbose` and reduce default logging for better perf
Move logging off the main thread for better perf
Multi-threading for perf
io_uring/macOS version for really fast FS

Ensure `build` command verifies full-disk access is allowed for the current folder

CAS static build?
Hotreloading Axum server?

Reduce IPC communication by making the daemon in-charge of more and just communicating from the CLI to it???

Make this capable of:
 - Specta dev
 - Specta release
 - Zephyr dev
 - Zephyr release

Hot-reloading powered by the smart build system: https://chatgpt.com/c/6a281a62-1970-83ec-8491-e253fc241c96

Benchmarking performance internally to file
Remote CAS using Cloudflare?

Do we want to keep direct (untraced) mode?

One inherent limitation worth noting: a build script's reads via absolute paths or in subprocesses (e.g. shelling out to cc) aren't routed through the
mount, so they aren't traced — rerun-if-changed covers the explicit case. I documented this in TODO.

[done] Implement support for build scripts. We should copy Cargo semantics with the stdout of them affecting build information. Automatically detect if they are present and run them.
  - build.rs is compiled + run under the same sandbox + monitor as every compile
    (src/buildscript.rs, run_build_script in src/builder.rs). Its input reads
    fold into the unit's read-set, so the existing primary-key + read-set CAS
    address captures it and a second build is an ordinary cache hit that never
    re-runs the script — no separate build-script cache.
  - stdout directives parsed: rustc-env, rustc-cfg, rustc-link-lib/search/arg,
    rustc-flags, rerun-if-changed (folded into the trace), rerun-if-env-changed
    (recorded only — env is fixed), warning, and cargo::metadata / legacy
    cargo:KEY=VAL for `links` packages (persisted in the CAS entry, surfaced to
    dependents as DEP_<LINKS>_<KEY>).
  - OUT_DIR codegen works: OUT_DIR is a scratch dir, passed to the crate compile
    so include!(concat!(env!("OUT_DIR"), ...)) resolves; generated sources are
    baked into the rlib so the scratch dir is never committed.
  - build-dependencies are built (as ordinary rlibs) and linked into the script;
    proc-macro build deps are now built too (compiled to a CAS dylib and passed
    to the script via --extern), see Macros [done] below.
  - Limitation: a build script's reads via *absolute* paths or in subprocesses
    (e.g. running `cc`) aren't routed through the mount, so they aren't traced.
    rerun-if-changed covers the explicit case.

[done] Use sandbox-exec + fskit
  - rustc runs under sandbox-exec; sources routed through an fskit-rs mount that
    records reads. Cache key = primary key + observed read-set (src/sandbox.rs,
    src/monitor.rs, src/trace.rs). Requires FSKitBridge enabled in System
    Settings > General > Login Items & Extensions > File System Extensions.

Why:
 - With Git worktree's should be able to share the same target dir:
    - without locking
    - and using a huge amount of disk space (sccache still requires `target` directory)

[done] Figure out reads to 3rd party files (Eg. `include_dir!()`)
  - relative-path reads (include_str!/include_bytes!/mod files) are now traced
    and keyed. include_dir! via the `include_dir` crate still needs proc-macro
    support; env-var-based paths need env support (below).
[partial] Find static environment variables
  - env is now cleared to a fixed policy and that policy is hashed; tracking
    *which* vars a build actually reads is still future work.

Support cylib, staticlib, etc.
[done] Build scripts (see top of file)
[done] Macros
  - proc-macro crates compile to a loadable lib<name>.dylib (rustc --crate-type
    proc-macro, with proc_macro from the sysroot + -C prefer-dynamic) committed
    to the CAS like any other unit (src/builder.rs: compile + finish_unit). Their
    own rlib deps link into the dylib, so it's self-contained. A dependent links
    it with --extern name=<cas>/lib<name>.dylib and rustc runs it straight out of
    the store — content-addressed, so the same compiled macro is reused across
    crates/projects instead of rebuilt. Works for normal and build-dep macros.
  - topo_order now descends into proc-macro deps (no longer pruned); the dep loop
    adds them as externs but, since the dylib is self-contained, does NOT add the
    macro's -L closure or links metadata to the dependent.
  - tests/fixtures/proc_macro (mac_support rlib -> mac proc-macro -> pm_user bin)
    + 3 integration tests: build+run, full cache hit, and edit-the-macro's-dep
    busts the chain and changes the expansion.

We should probally replace `rustup` so can ensure the toolchains are stable??
  - we already invoke the real toolchain rustc directly (toolchain::rustc_path),
    bypassing the rustup shim, so a cleared env doesn't break it.

Aquire lock on the CAS for each dependency efficiently
CAS cleanup
Multi-process operations on the CAS

Heavily unit test the sandbox and caching semantics

Sandbox:
 - Prevent access to systemtime???
 - [done] Environment variables (cleared to a fixed allowlist)
 - [done] Network access (denied)
 - [partial] Restrict FS access (writes confined to out-dir + temp & warned;
   reads still broad)
 - etc.

https://crates.io/crates/ai-sandbox
https://crates.io/crates/sbexec
https://github.com/madsmtm/cargo-sandbox

Version subcommand

GUI for user to manage disk usage and assets.
 - Settings for automatically purging old assets
 - Separate assets for crates.io vs local stuff so we can cleanup easier

GUI for duplicate crate versions and propose upgrades which can resolve them, taking into account `links` property, and other dependencies.

Command for pruning dependency graph

GitHub Actions commenter output + JSON for programatic tools

Documentation website


Clean onboarding + setup flow. Maybe launch and install the `.app` from the Rust CLI?

Keep HTTP socket alive across reloads

Windows and Linux support

`.env` loading for dev command



  - Hermeticity angle — broadening the build-script PATH doesn't touch rustc compiles (they keep the minimal PATH
  and stay offline). But host tools like cmake/ninja are versioned outside the cache key, so their output isn't
  captured by the read-trace — same kind of impurity you already accepted for trusted downloaders.


   1. The actual failure is a bare-name PATH lookup, not a denied file access. The sandbox already allows
  file-read* and process-exec* broadly — a build script can

Maybe cloud updater service for binaries, Tauri, etc.

Maybe include SBOM dashboard and stuff like that? Maybe even tied to releases???







⏺ Both grants engaged and CEF downloaded. New issue: cef-dll-sys calls canonicalize on its OUT_DIR, which walks
  the path from / down — including /Users/oscar and /Users/oscar/gh (ancestors of the project). My deny-home rule
  blocks reading those ancestors, so path resolution into the project fails with "Operation not permitted while
  canonicalizing".

  The fix is a cleaner security model anyway: deny file contents (file-read-data) under home, but keep
  metadata/traversal (file-read-metadata) allowed — directory names aren't the secret, file contents are. That
  lets canonicalize/stat resolve paths everywhere while still blocking exfiltration of files like ~/.ssh/id_rsa.
  Let me refine sandbox.rs:

Should we alias these into the sandbox???
        Progress: cargo is found and runs, but it's the rustup shim, which tries to create /var/empty/.rustup (the
        sandbox's empty HOME) and fails. It needs RUSTUP_HOME/CARGO_HOME pointed at the real dirs — the
        --allow-define-env use case. Let me grant them and continue:


Would the CAS be faster as a single file append only log but where we keep an index for quickly finding it?
    - This could avoid opening a lot of files but would make cleanup much harder (although it's a background task so it's like fineeee)

We could allow hosting with a CDN via: https://docs.railway.com/sandboxes
https://github.com/railwayapp/railway-ts-sdk

Built-in Docker builds which doesn't require the daemon

Make `include_dir` alternative that is build-system aware so it can hot-reload in development???
 - Maybe use `Asset` type with thread-local reference count so it can be `Copy` while using `Cow<'_, static>` return type from getter so it's non-copy if within a single scope.

Warnings for outdated dependencies


What are the `.staging-...` folders



Can we allow changes to downstream crates be relink (via a stable ABI somehow) so the tip-crate doesn't need to be rebuilt???



Don't rebuild tip-crate for changes if the ABI allows it:
 - https://chatgpt.com/share/6a2c52da-1d9c-83ec-abdb-3c4e1bd7480c

```