Ten packages carried ~5,900 lines as one artifact in ten wrappers: lockstep
versions, ten manifests, ten release entries, and the workspace:* drift trap,
buying no consumer anything. `preset` pulled in six of them anyway.

Everything is now `packages/vibekit`, published as `@initlabs/vibekit` with
subpath exports. Each old package is a directory under `src/`; tests mirror it
under `test/`. The root export is the core contract, so `./preset` no longer
drags four third-party plugins into a types-only import.

- @initlabs/vibekit-core            -> @initlabs/vibekit
- @initlabs/vibekit-tools           -> @initlabs/vibekit/tools[, /views]
- @initlabs/vibekit-agent           -> @initlabs/vibekit/agent[, /config]
- @initlabs/vibekit-mcp             -> @initlabs/vibekit/mcp[, /stdio, /http]
- @initlabs/vibekit-signer-keystore -> @initlabs/vibekit/signer-keystore
- @initlabs/vibekit-preset          -> @initlabs/vibekit/preset
- @initlabs/vibekit-plugin-<name>   -> @initlabs/vibekit/plugins/<name>

verify-packed packs one tarball and drops the overrides block that pinned the
packages' own @initlabs peers. The changesets `fixed` group is gone.

Done now because the old names are hours old with zero dependents; after
anyone installs them this becomes a breaking change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Invoke-RestMethod emits a JSON array as ONE pipeline object, so
`Get-Releases | Where-Object` handed the whole array to $_. `-match` over an
array returns the matching elements rather than a boolean, so the array was
truthy and every release 'passed' the filter -- producing a download URL with
all 14 tags in it. Assign first, then iterate.

Also: Join-Path threw on a null $env:APPDATA when checking for pre-1.0 state.

CI now runs install.ps1 for real under Windows PowerShell 5.1 instead of only
parsing it. The parse check passed on every one of these bugs.

Bare 'irm getvibekit.ai/...' defaults to http, and Windows PowerShell will
not follow the 308 upgrade to https -- it reports the redirect as an error.
curl -L follows it silently, which is why this only broke on Windows.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Signing needs node and building needs node 24+, which the install story did
not say plainly. README and the installation page now split what works with
nothing installed from what needs a toolchain.

PRODUCTION.md gets the prototype result: a compiled binary read the real OS
keychain with no node on PATH, blocked only by two upstream packaging details.
Also drops the install.ps1 and installation-docs entries, both now done.

The managed keystore CLI is a '#!/usr/bin/env node' program, so node must be
on PATH to run the daemon -- not just npm to install it. Without node the
spawn succeeded, the daemon died instantly, and the only trace of the real
cause was 'env: node: No such file or directory' in the log file.

doctor never checked node or npm at all, so a machine that could not sign
still reported 'No blocking problems found'.

PowerShell cannot run 'curl ... | VIBEKIT_CHANNEL=alpha sh' at all, and the
command was long enough to overflow the hero box and slide under the copy
button.

- /alpha and /alpha.ps1 serve the canonical installers with the channel
  pre-set, so both one-liners are short
- the hero swaps to the .ps1 form on Windows
- the copy button reads the rendered command, so it cannot drift from it

Also print the full alpha command in the prerelease error instead of just
naming the variable. Revert the hero to the bare command when 1.0.0 ships.

The 1.0 rewrite dropped install.ps1, so Windows had no install path and
install.sh pointed at a URL that 404'd.

- install.ps1, ported to 1.0: both binaries, v* tags only (the heritage
  cli-v* releases are excluded), same env vars as install.sh
- served at /install.ps1 from the repo file, same ?raw pattern as /install
- explore: resolve .exe sidecars, so the installed vibekit-tui.exe is found
- docs: real install instructions for both platforms; the page still said
  the public install channel did not exist
- CI: parse install.ps1 on a Windows runner, since nobody develops on Windows