varve 0.26.0

The PulseEngine toolchain layer manager — pinned, signed, dated toolchain bundles
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

# varve export-vsix [--layer <l>] --out <dir>

Lays the layer's verified `vsix` entries out as `publisher.name-version.vsix`
files — the marketplace's own asset name — so `code --install-extension <file>`
installs an editor extension whose bytes varve signed, with no marketplace
round-trip.

A reproducible development environment pins its compiler, its linker and its
test runner, and then installs editor extensions from a marketplace with no
verification at all. A `.vsix` is one zip file, so it is a payload kind like
any other: signed digest, checked against the trust root, refused when it does
not match (`varve docs payload-kinds`).

`--layer` defaults to the resolved project pin, so the export tracks the pin.
Every export writes a `.varve-export.json` stamp binding it to the producing
layer; `varve verify --export <dir>` fails if the pin later moves and the
export goes stale (REQ-EXPORT-SYNC-001).

## Depositing an extension

`kind = "vsix"` in the deposit spec, with the extension's marketplace id as the
payload name. A layer may hold several extensions, and several **versions** of
one extension — an extension is not dispatched by name, so its identity is
(name, version), exactly as for a crate.

```toml
layer = "2026.08.0"
channel = "qualified"
counter = 1

[[tool]]
name = "rust-lang.rust-analyzer"
version = "0.3.2260"
kind = "vsix"
path = "vsix/rust-analyzer-0.3.2260.vsix"

[[tool]]
name = "vadimcn.vscode-lldb"
version = "1.11.4"
kind = "vsix"
path = "vsix/codelldb-1.11.4.vsix"
```

## Exporting and installing

```sh
varve install
varve export-vsix --out ./extensions

# exported 2 verified VS Code extension(s) to /w/extensions — install them with:
#   code --install-extension /w/extensions/rust-lang.rust-analyzer-0.3.2260.vsix
#   code --install-extension /w/extensions/vadimcn.vscode-lldb-1.11.4.vsix

code --install-extension ./extensions/rust-lang.rust-analyzer-0.3.2260.vsix
```

The printed lines name every file, one per extension: `code` installs one
`.vsix` per invocation, and it dispatches on the `.vsix` suffix — an argument
without it is read as a marketplace id and **fetched from the network**, which
is what this export exists to avoid.

Later, when the pin moves and the committed export does not:

```sh
varve verify --export ./extensions
# export ./extensions — STALE: stamped from layer 2026.07.0 (sha256:…)
```

## What is deliberately not done

* The `.vsix` files carry **no execute bit** (mode 0644), in the store and in
  the export. They are zips handed to `code`, not programs varve dispatches —
  `varve which` and `varve run` do not resolve them.
* varve does not run `code` for you and does not manage an extensions
  directory. It hands you verified bytes under a name your editor accepts; the
  install is yours to run, script, or bake into an image.
* varve does not read inside the zip. The name and version come from the
  **signed manifest**, not from the extension's own `package.json`, so what
  the export is named is what the trust root anchored.
* An extension id that could not be a safe file name — one containing `/`, or
  starting with `-`, which `code` would read as a flag — is refused before
  anything is written, whole, rather than half-exported.