# The Lattice Workspace

The Lattice Workspace is a session where the whole lattice substrate is **warm and wired**, so
working and building happen at lattice speed. It's the practical form of the "lattice virtual
environment" idea: not a new operating system, but an environment where every primitive an agent
or developer reaches for is already the fast, warm, cached lattice version.

## Enter it

```
python C:\sd\latticesearch\workspace.py            # interactive
python C:\sd\latticesearch\lattice.py workspace    # same, via the CLI
python C:\sd\latticesearch\workspace.py -c "cmd; cmd"   # batch / scripting
```

On entry it ensures three things are up: the **engine** (:8765), the **warm model host** (:8767 —
started for you if it isn't running, so no model ever cold-starts inside the session), and the
**Rust name sidecar** (:8766). It prints their status and drops you at a `lattice>` prompt.

## What you can do inside

| Command | What it does |
|---|---|
| `search <q>` / `find <q>` / `ask <q>` | meaning search over the whole machine, instant |
| `fs du\|find\|tree\|glob\|largest <dir>` | filesystem questions from RAM (~1–30ms, no disk walk) |
| `grep <pat> --about <topic>` | semantic-narrowed exact grep |
| `read <path> [--about topic]` | whole file, or just the relevant chunks |
| `write` / `edit` / `mv` / `cp` / `rm` | index-synced file ops (rm is recoverable, mv is O(1)) |
| `remember <fact>` / `recall <q>` | cross-session memory |
| `sym <q>` | code symbol → file:line |
| `build <step> --in <files> --out <files> -- <cmd>` | build via lattice-make (cached) |
| `!<cmd>` | a raw shell command, timed |
| `help` / `exit` | help / leave |

Every command is **timed** (shown inline, e.g. `[build 316ms]`) and **logged** to
`workspace_log.jsonl` — so you can compare "inside the workspace" vs "outside" objectively.

## Building faster: `build`

The `build` command wraps **lattice make**. It fingerprints the inputs in one fast stat-sweep
(no content hashing) and keeps a content-addressed, zstd-compressed cache of the outputs. If the
inputs haven't changed, the build is **skipped** and the outputs are restored from cache.

```
lattice> build rust --in src Cargo.toml --out target\release\latticesearch.exe -- cargo build --release
[lattice-make] rust: inputs changed (4 files, fingerprint 2ms) — building…
[lattice-make] rust: built in 56.5s, 1 output(s) cached

lattice> build rust --in src Cargo.toml --out target\release\latticesearch.exe -- cargo build --release
[lattice-make] rust: CACHE HIT — 4 inputs fingerprinted in 2ms, 1 output restored (2.2MB) in 57ms. Build SKIPPED (was 56.5s).
```

That's the trial worth running: a **56.5-second build becomes a 57-millisecond restore** when
nothing changed — roughly a 1000× win on the unchanged case, with everything logged for comparison.

## What it does and doesn't speed up

The workspace makes you fast at **knowing, deciding, and avoiding repeated work** — finding files,
answering filesystem questions, skipping unchanged builds, keeping models warm. It does **not** make
the CPU compute faster or the disk move bytes faster; a build that genuinely must compile still
compiles. The lattice never beats physics — it eliminates *redundant* physics. See
[How It Works](ARCHITECTURE.md) and [Developing](DEVELOPING.md).

## The environment it sets

Inside the workspace, subprocesses inherit: `LATTICE_URL`, `LS_MODEL_HOST=1` (engine restarts stay
light), the MinGW toolchain on `PATH` (so `cargo`/`gcc` builds just work), and `LS_WORKSPACE=1`.
