# Changelog

## 0.1.89 - April 8, 2026

### Changed

- the ghostOS kernel P2P driver and transport now self-prime their uplink interfaces directly: before mobile P2P init and before transport interface selection they attempt `DhcpProbe/NetIfUp` on `eth0/default`, so `P2P STACK` no longer depends on a side-effect from `ghost wifi scan`
- this is aimed at the exact cold-runtime regression where the operator and contacts restored correctly but `P2PTransport::Initialize()` still failed early, leaving `ready=no`, `interface=none`, `announced=pending`, and `bootstrapped=no`

## 0.1.88 - April 8, 2026

### Changed

- the ghostOS kernel now resets VMware P2P network-priming backoff immediately after operator restore, login, and register, so a fresh post-`HELLO` runtime does not stay stuck serving a stale cold `P2P STACK` snapshot
- `P2P STATUS`, `P2P ADDRESS`, `P2P BOOTSTRAP CONFIG`, `P2P STACK STATUS`, and explicit `P2P ANNOUNCE/BOOTSTRAP` now force a short kernel-side network prime plus auto-bringup pass before formatting their response, which is meant to restore `ready=yes / announced=... / bootstrapped=yes` without requiring a manual `ghost wifi scan`

## 0.1.87 - April 8, 2026

### Changed

- the ghostOS kernel P2P priming path now performs VMware uplink configuration end-to-end: once the host-backed Wi-Fi state is restored, it runs `DhcpProbe`/`NetIfUp` on the virtual uplink so `ghost p2p stack` can surface a live `eth0` without requiring `ghost wifi scan` or `ghost wifi details` first
- this specifically fixes the cold post-restore state where the operator wallet and contacts were already back, but `P2P STACK` still reported `ready=no`, `interface=none`, `announced=pending`, and `bootstrapped=no` because the guest net interface had not been brought up again

## 0.1.86 - April 7, 2026

### Changed

- the ghostOS kernel now primes the VMware-backed host network state for P2P on every runtime tick and before `P2P STATUS`, `P2P ADDRESS`, `P2P STACK STATUS`, `P2P BOOTSTRAP`, and `P2P BOOTSTRAP CONFIG`, so `ghost p2p stack` no longer depends on a prior `ghost wifi scan` just to surface `eth0`
- operator auth and restore flows now reset terminal auto-bringup tracking immediately after `AUTH LOGIN`, `AUTH REGISTER`, `MN RESTORE COMMIT`, and cached P2P contact restore, which lets the kernel retry `announce/bootstrap` right away instead of serving a stale `ready=no / announced=pending / bootstrapped=no` snapshot

## 0.1.85 - April 7, 2026

### Changed

- the command-level self-healing path for `ghost p2p stack`, `ghost p2p address`, and `ghost p2p overview` no longer performs a full kernel contact restore just to recover the transport view after a stray `HELLO`; it now restores only the operator/runtime state and reuses the local encrypted contact snapshot for display when needed
- this keeps `ghost p2p contacts` as the only command that pays the heavier contact-restore cost, while `ghost p2p stack` can recover `ready / bootstrapped / announced` faster and still print the expected contact count

## 0.1.84 - April 7, 2026

### Changed

- `ghost p2p stack`, `ghost p2p address`, and the `ghost p2p` overview now detect a cold post-`HELLO` runtime snapshot (`wallet already valid in the shell, but `P2P` returns `contacts=0 / ready=no / route=pending`) and perform one command-level operator/P2P recovery before retrying the inspection
- that recovery happens at the shell command layer instead of inside every low-level pipe round-trip, which keeps the transport path simpler while restoring the expected `ready / bootstrapped / announced` view after an in-session GhostTransport reset

## 0.1.83 - April 7, 2026

### Changed

- read-only P2P inspection commands no longer trigger an automatic secure-vault restore inside the low-level GhostTransport `HELLO` recovery path; the shell-level operator session check remains the source of truth, which stops `ghost p2p stack` and `ghost p2p contacts` from looping through `HELLO -> restore -> timeout`
- `ghost p2p stack`, `ghost p2p address`, `ghost p2p contacts`, and `ghost p2p list` now reuse the already-validated shell wallet state for display instead of issuing another live `MN STATUS` query inside the same command, removing an extra round-trip that could retrigger stray `HELLO` on healthy sessions

## 0.1.82 - April 7, 2026

### Changed

- after a stray in-session `HELLO`, GT now probes the live runtime auth and wallet state again before attempting a full secure-vault restore, so `ghost p2p stack` and `ghost p2p contacts` stop forcing unnecessary `restore -> HELLO -> timeout` loops when the operator session is still alive in ghostOS
- automatic kernel P2P contact restore now also checks whether contacts are already present in the live runtime before replaying the cached snapshot, which reduces redundant restore traffic on the first `ghost p2p contacts` after a reconnect

## 0.1.81 - April 7, 2026

### Changed

- GT now treats an in-command GhostTransport `HELLO` during read-only P2P inspection as a full `runtime readiness -> operator restore -> replay` path instead of probing live auth and wallet state first, which prevents `ghost p2p stack` / `ghost p2p contacts` from getting stranded on nested `HELLO -> restore -> timeout` loops
- the post-`HELLO` reconnect path now waits for command readiness again before replaying read-only P2P commands and restore-family commands, so status inspection no longer depends on a prior `wifi scan/details` warm-up

## 0.1.80 - April 7, 2026

### Changed

- GT bundled-runtime prepare now resets the `runtime/vm` workspace before staging the public VM, which removes stale `nvram`, lock directories, scoreboards, and leftover VMware metadata that could keep headless public installs stuck at `boot=0`
- the generated public VMware image now matches the known-good ghostOS boot profile much more closely by staging `ghostOS.nvram`, recreating `ghostOS.vmxf` / `ghostOS.vmsd`, and emitting the same core device layout that successfully boots the bundled ISO and VMDK chain

## 0.1.79 - April 7, 2026

### Changed

- GT now resets the VMware serial log by deleting the previous run's file instead of pre-creating it before launch, which avoids VMware's hidden `msg.serial.file.open` prompt and restores bundled-runtime boot readiness in headless starts
- the generated bundled-runtime VMX now enables automatic question handling and explicitly answers the serial-log replacement prompt, so stale serial output files no longer block `boot-entry` / `transport-ready` detection during startup

## 0.1.78 - April 7, 2026

### Changed

- when a stray `HELLO` interrupts a read-only P2P inspection command, GT now restores the operator session before replaying `P2P STATUS`, `P2P ADDRESS`, `P2P STACK STATUS`, `P2P BOOTSTRAP CONFIG`, and the contact-list queries, so the replay no longer lands on a blank kernel wallet state
- the recovery path still skips heavy contact-snapshot replay for those read-only queries, which keeps `ghost p2p stack` fast while fixing the `wallet: UNSET / ready=no / bootstrapped=no` regression after a mid-command runtime reset

## 0.1.77 - April 7, 2026

### Changed

- GT now treats a stray in-session `HELLO` as a lightweight pipe reconnect for read-only command replay instead of forcing a full command-readiness wait up front, which stops `ghost p2p stack` and `ghost p2p contacts` from stalling on the `HELLO -> readiness timeout` path
- the read-only P2P inspection queries now use a longer response budget, so the first `P2P ADDRESS`, `P2P STACK STATUS`, `P2P CONTACT LIST`, `P2P CONTACT GET`, `P2P STATUS`, and `P2P BOOTSTRAP CONFIG` calls can survive the slowest post-attach bring-up windows without requiring a prior `wifi scan/details` warm-up

## 0.1.76 - April 7, 2026

### Changed

- GT now treats repeated `HELLO` interrupts during a single command as a recoverable condition: it can reconnect and re-establish command readiness multiple times before failing, instead of only attempting one prelude recovery and then timing out
- `ERROR runtime-not-ready` recovery now uses the same clean reconnect-and-ready cycle as `HELLO`, which makes read-only P2P status commands much less likely to get stranded on a stale pipe

## 0.1.75 - April 7, 2026

### Changed

- after a stray `HELLO`, GT now always reconnects to a clean GhostTransport pipe before replaying the pending command, instead of trying to continue on the same potentially stale pipe session
- every interactive `ghost p2p ...` command now revalidates the operator session against the live runtime before it runs, rather than trusting a possibly stale cached shell session
- `ghost p2p stack`, `ghost p2p address`, and the P2P overview no longer try to hydrate cached P2P contacts first, so P2P status inspection is no longer coupled to contact-restore timing

## 0.1.74 - April 7, 2026

### Changed

- read-only status commands such as `P2P ADDRESS`, `P2P STACK STATUS`, `P2P CONTACT LIST`, `P2P STATUS`, `MN STATUS`, `WHOAMI`, and the Wi-Fi status queries no longer try to launch a full operator vault restore when a stray `HELLO` arrives; GT now replays those queries cleanly and leaves real operator recovery to the shell/session layer
- every interactive `ghost p2p ...` command now refreshes the live operator state before it runs, so a stale in-memory session can no longer force `p2p stack` to depend on a prior `wifi scan/details` just to succeed
- the printed P2P identity header now prefers the live wallet address when it exists, so the header no longer falls back to `wallet: UNSET` just because the kernel `P2P ADDRESS` response has not materialized its own cached address field yet

## 0.1.73 - April 7, 2026

### Changed

- GT once again restores the operator automatically when a normal status-style command such as `P2P ADDRESS`, `P2P STACK STATUS`, or `MN STATUS` is interrupted by a stray `HELLO`, but it still refuses to recurse while an actual `MN RESTORE ...` or `P2P CONTACT RESTORE ...` command is already in flight
- `ghost p2p list`, `ghost p2p contacts`, `ghost p2p address`, and `ghost p2p stack` now refresh the live wallet state from the runtime before printing, so the P2P identity header no longer drifts to `wallet: UNSET` while the operator is actually unlocked

## 0.1.72 - April 7, 2026

### Changed

- GT startup now treats kernel P2P contact replay as a lazy-on-first-P2P-command step instead of a shell-entry blocker, which removes the long startup stall caused by cached contact restore timeouts
- before entering the `ghostos[...]` prompt, GT now revalidates the live operator session against the runtime and re-recovers it if needed, so the banner, prompt serial, `ghost whoami`, and `ghost p2p stack` no longer drift apart after a partial prelude reset

## 0.1.71 - April 7, 2026

### Changed

- GT now treats read-only transport queries such as `AUTH STATUS`, `MN STATUS`, `P2P ADDRESS`, `P2P STACK STATUS`, and `P2P CONTACT LIST` as replay-only commands after a stray `HELLO`, instead of launching another operator vault restore cycle, which removes the repeated restore spam when asking for `ghost p2p stack`
- the attached `ghostos[...]` shell now reuses its already-authenticated in-memory operator state for `p2p` commands instead of re-running full operator-session recovery every time, which makes P2P commands much faster and less likely to bounce through unnecessary restore logic

## 0.1.70 - April 6, 2026

### Changed

- GT no longer attempts to launch a second operator/P2P restore from inside `MN RESTORE ...` or `P2P CONTACT RESTORE ...` commands when a stray `HELLO` arrives mid-restore, which closes the nested restore loop that could still trap startup on some machines
- startup will now continue into the `ghostos[...]` shell even if restoring the cached P2P contact snapshot is temporarily delayed, so operator recovery is no longer blocked by a non-critical sidecar contact replay

## 0.1.69 - April 6, 2026

### Changed

- GT now guards the entire operator and P2P prelude-restore probes, not just the inner commit phase, so `AUTH/WALLET/P2P ADDRESS` checks can no longer recurse into another vault restore on a stray `HELLO` banner and trap startup in a repeated `Restoring real ghostOS identity...` loop

## 0.1.68 - April 6, 2026

### Changed

- GT now waits for command readiness immediately after `MN RESTORE COMMIT`, and a single interrupted command will only attempt one operator/P2P restore cycle even if multiple stray `HELLO` banners arrive, which closes the restore loop that could trap startup before the `ghostos[...]` prompt appeared

## 0.1.67 - April 6, 2026

### Changed

- GT now restores the operator vault state and the kernel P2P contact snapshot immediately after a stray mid-command `HELLO` or `ERROR runtime-not-ready`, before replaying the interrupted request, which closes the startup failure where the shell could recover the wallet and then still fall back to the host console on the first P2P command

## 0.1.66 - April 6, 2026

### Changed

- the mobile kernel now kicks its automatic P2P bring-up path again when `P2P STATUS`, `P2P ADDRESS`, `P2P BOOTSTRAP CONFIG`, or `P2P STACK STATUS` are queried, which closes the race where a second machine could still report `ready=no` even though wallet and network were already up
- kernel `P2P STATUS` and `P2P ADDRESS` now report the real published-route state instead of a hardcoded `published=0`
- GT no longer drops out of the attached ghostOS shell back to the host console when a raw `ghost send ...` command hits a transient GhostTransport error, and mid-command stray `HELLO` banners now try an in-session readiness recovery before forcing a reconnect

## 0.1.65 - April 6, 2026

### Changed

- the mobile kernel now distinguishes a local-only staged route from a route that was actually fanned out into the public FreedomNet discovery fabric, so auto bring-up can republish automatically once real public bootstrap is ready
- FreedomNet DHT route publication no longer stops at local-only just because no peer is already connected; the kernel can now fan out route stores through the bootstrap routing table itself, which unblocks first-contact discovery between remote operators

## 0.1.64 - April 6, 2026

### Changed

- the first real public FreedomNet bootstrap service is now deployed and verified on UDP `4001`, so the kernel/runtime pipeline can finally ship a real public seed instead of stopping at a placeholder deployment step
- GT now carries a Fly deployment path for that public bootstrap adapter, while the bootstrap policy and wire protocol remain owned by the mobile kernel

## 0.1.63 - April 6, 2026

### Changed

- the mobile kernel now runs an automatic P2P bring-up tick after wallet unlock and network-up, so normal GT sessions no longer need manual `ghost p2p announce` and `ghost p2p bootstrap` commands just to reach the ready `announce/bootstrap/stack` state
- host-assisted bootstrap inference now happens in the kernel driver from the live network interface itself when no public seeds are pinned yet, which keeps GT as an integration surface while the OS remains the source of truth for route publication and bootstrap policy

## 0.1.62 - April 6, 2026

### Changed

- the installed public GT bundle now ships the bootstrap-node payload under `releases/bootstrap/current`, so operators can run `gt.cmd bootstrap-node install|status|uninstall` directly from an installed GT without unpacking a second bootstrap zip by hand
- GT public install cleanup and install manifests now understand that bundled bootstrap-ops surface, which keeps bootstrap-node updates aligned with the same product install you already use for the runtime, kernel shell, and VS Code extension

## 0.1.61 - April 6, 2026

### Changed

- GT now exposes the public bootstrap-node ops flow directly from `ghostterm_host.exe`, including `bootstrap-node bundle`, `bootstrap-node install`, `bootstrap-node uninstall`, `bootstrap-node status`, and `bootstrap-node pin`, so standing up the first public bootstrap path can stay inside the GT surface instead of bouncing through ad-hoc scripts
- the mobile kernel remains the source of truth for bootstrap policy, while GT now acts as the operator console that can install the host-side daemon and pin the public seed back into the kernel build config

## 0.1.60 - April 6, 2026

### Changed

- the mobile kernel now auto-attempts public bootstrap bring-up during `ghost p2p announce` and `ghost p2p connect <alias>` whenever real public seeds are pinned, so public-capable runtimes no longer wait for a GT-side nudge before trying to lift the discovery fabric
- host-assisted bootstrap remains the fallback only when the kernel sees no public-capable seeds, which keeps the bootstrap policy owned by `mobile` while still preserving the current VMware/GT development flow

## 0.1.59 - April 6, 2026

### Changed

- GT now reopens the GhostTransport pipe cleanly after an unexpected `HELLO` instead of trying to keep driving a dirty session, which removes the `HELLO -> restore -> timeout` desync that was still breaking `ghost p2p add`, `ghost p2p contacts`, and `ghost p2p connect` in the standalone shell
- the standalone shell now re-runs the kernel-first operator session check before every `ghost p2p ...` command, so the mobile runtime stays the source of truth and GT only retries against a fresh kernel state instead of forcing an eager mid-command restore

## 0.1.58 - April 6, 2026

### Changed

- GT now ships `bootstrap-node serve`, a public FreedomNet bootstrap daemon that speaks the same kernel-owned `freedomnet_types.h` wire protocol and shared relay envelope as the mobile driver layer instead of inventing a GT-only bootstrap format
- the relay envelope now lives in shared mobile headers, so both the kernel transport and the public bootstrap/relay adapter consume the same packed structure and version constants from the mobile core
- the next worldwide P2P step is now operational rather than hypothetical: we can stand up a real public bootstrap node, pin its seed in `mobile/config/freedomnet_bootstrap_nodes.txt`, rebuild the runtime, and validate two operators behind different NATs against a kernel-defined public fabric

## 0.1.57 - April 6, 2026

### Changed

- the mobile kernel now exposes `P2P BOOTSTRAP CONFIG`, so public/bootstrap seed selection is owned by the `mobile` driver layer instead of being guessed inside GT
- GT now queries that kernel-owned bootstrap config before staging VMware host-assisted bootstrap, which keeps the future public/bootstrap-node path kernel-first while preserving the current local host-NIC test flow
- the FreedomNet wire parser in the kernel transport now accepts the real serialized header size, which unblocks the upcoming public bootstrap/relay work from relying on an off-by-five header guard

## 0.1.56 - April 6, 2026

### Changed

- the kernel-owned P2P and MultiNode status surfaces now report host-assisted bootstrap state as a real staged driver state again, so `ghost p2p stack` and `ghost multinodes` stay aligned after a clean `public-bootstrap-required` connect result instead of dropping back to `ready=no` / `ring1=fail`
- GT/public artifacts were rebuilt after that kernel-first reporting fix so the standalone installer, bundled runtime, and VS Code extension all expose the same post-bootstrap status semantics

## 0.1.55 - April 6, 2026

### Changed

- `ghost p2p stack` and the MultiNode network status surfaces are now kernel-introspection only and no longer re-enter `ensure_p2p_stack(...)` just to answer a status query, which prevents the standalone GT runtime from resetting the guest after a clean `public-bootstrap-required` connect result
- the public GT artifacts were rebuilt again after that kernel-only status fix, so the bundled installer no longer mixes an updated host binary with a status path that still pokes the transport stack too aggressively

## 0.1.54 - April 6, 2026

### Changed

- the public GT release pipeline now refuses to seal a bundled runtime whose `runtime_manifest.txt` version or ISO hash does not match the current GT release, which closes the bad `new host binary + old ghostOS kernel` packaging gap that slipped into `0.1.53`
- the bundled/public installer artifacts were rebuilt around the current mobile kernel/runtime pair, so the standalone GT install now carries the same host-assisted P2P behavior already verified from the repo-backed shell

## 0.1.53 - April 6, 2026

### Changed

- host-assisted bootstrap is now treated as staged kernel driver state instead of a real public discovery bootstrap, so private VMware/GT seeds no longer promote the discovery core into a heavier state that can destabilize the guest
- the mobile discovery core now refuses to treat private bootstrap seeds as public routing-table fabric, which prevents `ghost p2p connect <alias>` from re-entering the heavy stack path when no real worldwide bootstrap route exists yet
- GT/public artifacts were rebuilt from a clean mobile kernel build so the bundled runtime uses the new kernel-first host-assisted bootstrap semantics end-to-end

## 0.1.52 - April 6, 2026

### Changed

- the mobile kernel now exports and restores P2P bootstrap seed state as part of the kernel-owned contact snapshot, so GT replays a real driver protocol instead of guessing bootstrap context after a fresh `HELLO`
- `PrepareTerminalContactRoute` in the mobile kernel now refuses to enter heavy stack bring-up when a contact has no endpoint and no public discovery fabric exists, which turns the old `connect -> reset -> HELLO -> timeout` loop into a clean kernel response
- GT now refreshes the kernel-backed P2P snapshot after `ghost p2p announce` and `ghost p2p bootstrap`, replays staged restore seeds through `P2P CONTACT RESTORE SEED`, and drains larger bursts of prelude noise before replaying the original command

## 0.1.51 - April 4, 2026

### Changed

- GhostTransport replay after a fresh `HELLO` now drains stale structured replies until the pipe is quiet, which stops orphaned `STATUS`, `P2PADDRESS`, and restore replies from corrupting the next command
- operator restore and P2P contact snapshot restore now re-enter the kernel with quieter, staged recovery semantics, so `ghost p2p add`, `ghost p2p contacts`, and `ghost p2p connect` no longer desync immediately after a runtime prelude
- command-response matching now tolerates larger bursts of prelude traffic over time instead of giving up after a handful of stray lines, which keeps the standalone GT shell aligned with the kernel-backed runtime during reboot/reconnect moments

## 0.1.50 - April 4, 2026

### Changed

- GhostTransport readiness after a fresh `HELLO` now keeps only one live `STATUS` probe in flight at a time, which stops orphaned `STATUS` replies from leaking into the next restore or P2P command
- GT rebalanced post-`HELLO` recovery around operator restore first and explicit kernel-backed P2P state checks, which reduced the pipe desync that was corrupting `ghost p2p add` and `ghost p2p contacts`
- bundled/public GT shell recovery after a runtime prelude was rebalanced around operator restore first, then explicit P2P state checks, so `GhostTransport prelude: ...` lines no longer poison the next command response

## 0.1.49 - April 4, 2026

### Changed

- the mobile kernel now re-emits `handshake ring1-ready` and `handshake selfhost-finished` immediately after `handshake boot-entry`, so GT no longer loses core readiness markers during a fresh boot of the bundled/runtime-backed guest
- GT now treats `boot-entry + transport-ready` as sufficient serial readiness for the operator shell attach path, which removes the false `Waiting for real ghostOS runtime readiness on serial...` timeout that was still hitting `enter ghostos --shell --headless --restart-vm`
- bundled GT headless restart was revalidated end-to-end against the rebuilt kernel/runtime pair, so the public/runtime shell reaches the real ghostOS operator prompt again instead of hanging before pipe attach

## 0.1.48 - April 3, 2026

### Changed

- `ghost p2p announce` now stages the local wallet route from the mobile kernel itself without forcing a full P2P transport/discovery bring-up first, which stops the runtime reset loop that was still appearing during announce on bundled GT installs
- GhostTransport `STATUS` now exposes a kernel-owned `runtime=1/0` readiness bit, and GT waits for that bit before replaying commands after a fresh `HELLO`, which removes the `HELLO -> restore -> timeout` announce hang
- the bundled/public runtime and GT host tooling were rebuilt together around that kernel-first readiness path, so announce now fails cleanly or succeeds cleanly instead of wedging the session

## 0.1.47 - April 3, 2026

### Changed

- operator/session recovery after a fresh `HELLO ghostOS GT/1` now runs through a kernel-owned `MN RESTORE BEGIN/WORD/COMMIT` flow instead of a long GT-side replay of `MN IMPORT`, `AUTH REGISTER`, and `MN UNLOCK`, which makes identity restore much more OS-first and less brittle during reconnects
- `ghost p2p connect <alias>` now drives the kernel through `P2P CONTACT ENSURECONNECT ...`, so the replayed command carries the alias/address/endpoint state it needs even if a `HELLO` interrupts the route-prep flow
- GT now waits for GhostTransport command readiness after a fresh `HELLO` before replaying the interrupted request, which closes the mid-restore timeout window that was still breaking `ghost p2p connect <alias>`

## 0.1.46 - April 3, 2026

### Changed

- GhostTransport command replay now resends any interrupted in-flight command after a fresh `HELLO ghostOS GT/1`, so operator restore and P2P restore can survive a guest-side reset instead of timing out mid-sequence
- the ghostOS kernel GhostTransport receive buffer was widened, which makes the driver-side GT command path less fragile when handling richer P2P restore and control commands

## 0.1.45 - April 3, 2026

### Changed

- the kernel-backed mobile P2P driver now accepts chunked `P2P CONTACT RESTORE BEGIN/ITEM/COMMIT` commands, so GT can rehydrate contact state after a `HELLO` prelude without overflowing the tiny GhostTransport command buffer
- GT now restores cached kernel P2P contacts back into ghostOS one item at a time instead of sending a single oversized restore payload, which closes the `ERROR command-too-long` and pipe desync that blocked `ghost p2p connect <alias>` after runtime resets

## 0.1.44 - April 3, 2026

### Changed

- the kernel-backed mobile P2P driver now exports and restores terminal contact state through explicit `P2P CONTACT SNAPSHOT` and `P2P CONTACT RESTORE` commands, so the contact list, active route, prepared state, and last sequence no longer live only in one guest runtime instance
- GT now keeps only a DPAPI-protected cache of that kernel-defined snapshot and rehydrates it automatically after a `HELLO` prelude or fresh attach, which closes the `ghost p2p add ...` then `ghost p2p connect ...` gap that appeared after runtime resets
- standalone and bundled runtime builds were refreshed together so the public GT path and the VS Code path both consume the same updated ghostOS kernel behavior

## 0.1.43 - April 2, 2026

### Changed

- `ghost p2p connect <contact>` no longer drives the guest into a reboot when no remote route is discoverable yet; the kernel now fails that path cleanly and reports that a public/bootstrap-backed route is still required
- terminal contact route preparation now defers NAT probing until a real endpoint exists and uses a direct connect path for private/local endpoints, which keeps local VM-backed operator sessions stable while we bring up world-facing bootstrap infrastructure

## 0.1.42 - April 2, 2026

### Changed

- standalone/public GT launches now force `enter ghostos --shell --headless --restart-vm` by default, so the installed terminal starts the newest bundled ghostOS runtime instead of reattaching to a stale VM session with outdated Wi-Fi state
- bundled `ghostterm_host.exe` now follows that same restart-first operator flow when launched directly outside VS Code, which brings the public terminal path back into line with the validated runtime behavior

## 0.1.41 - April 2, 2026

### Changed

- the ghostOS kernel Wi-Fi path now reapplies the host machine's connected SSID whenever seed or host-synced scan results are loaded, so `ghost wifi details` stays aligned with the real connected network instead of falling back to `ssid: UNSET`
- VMware-mode host Wi-Fi commits that preserve or refresh the kernel cache now also restore the connected network state, which brings the standalone/public GT runtime back in line with the VS Code runtime flow

## 0.1.40 - April 2, 2026

### Changed

- GT now refreshes the public install Wi-Fi cache through `ghostterm_host.exe` itself, so installer-time and runtime host Wi-Fi export use the same parser and cache format that the kernel-facing sync path already consumes
- the installed Wi-Fi refresh task now runs under the current interactive Windows user with highest privileges instead of `SYSTEM`, which restores access to the real visible SSIDs seen by the operator session
- GT now reuses an already valid installed Wi-Fi cache immediately and refreshes it in the background, so the ghostOS kernel can keep real host SSIDs instead of dropping back to the `192.168.217.x` placeholder during refresh failures

## 0.1.39 - April 2, 2026

### Changed

- the public GT installer now captures the host machine's real visible Wi-Fi networks during setup itself, while it already has administrator approval, and writes them into GT's runtime cache for the kernel-facing Wi-Fi sync path
- the installed Wi-Fi refresh task now prefers a highest-privilege `SYSTEM` registration and only falls back to the current user when the machine blocks that service-account path
## 0.1.38 - April 2, 2026

### Changed

- `Overwrite existing GT install` now updates the install in place instead of deleting the whole install root first, which avoids hangs on VMware-owned files such as `ghostos_gt.scoreboard`
- the installer still closes GT-owned terminal processes first, but it no longer waits on long VMware shutdown paths before continuing with the update
## 0.1.37 - April 2, 2026

### Changed

- the public GT installer now shuts down the existing bundled GT runtime and closes install-owned terminal processes before overwrite, which fixes locked VMware files such as `ghostos_gt.scoreboard` during reinstall
- the public GT setup EXE now launches its embedded PowerShell installer hidden, so the operator only sees the branded GT installer window instead of an extra foreground console
## 0.1.36 - April 2, 2026

### Changed

- the public GT installer now requests administrator approval once so it can register a highest-privilege local Wi-Fi probe task for the installed user, which lets bundled/public GT restore real host SSID scanning even when plain `netsh wlan` is blocked in normal shells
- public GT now falls back to that installed Wi-Fi probe cache when both `netsh` and direct WLAN API calls are blocked or empty, instead of dropping straight back to the `192.168.217.x` placeholder network

## 0.1.35 - April 2, 2026

### Changed

- the native Windows Wi-Fi fallback now triggers a real `WlanScan` refresh before reading available networks, and GT no longer wipes the guest Wi-Fi list with an empty host result if Windows momentarily returns zero SSIDs

## 0.1.34 - April 2, 2026

### Changed

- public GT installs now link against the native Windows WLAN API and fall back to it automatically when `netsh` requires elevation, so host Wi-Fi sync can keep using the real SSIDs the machine sees instead of collapsing to the `192.168.217.x` placeholder
- bundled/public GT installs now generate a per-install `GhostTransport` pipe name, which prevents collisions with other local GT or ghostOS sessions and keeps the standalone launcher from stalling on a pipe owned by another runtime

## 0.1.33 - April 2, 2026

### Changed

- the installer now generates a rounded GT icon for the installed launcher, keeps the primary action visible as an `Installed` state after success, and launches GT through the same operator surface used by the desktop/start shortcuts
- public shortcut launches now share one launch path end-to-end, which reduces the mismatch between the standalone shell and the VS Code terminal entry

## 0.1.32 - April 2, 2026

### Changed

- `ghostterm_host.exe` now defaults to the bundled `ghostos --shell --headless` operator flow when GT is running as a public install, so standalone launches finally line up with the VS Code experience even if an older shortcut still points at the host binary

## 0.1.31 - April 2, 2026

### Changed

- the public installer now falls back to direct VSIX deployment into the VS Code extensions folder when `code.cmd` cannot complete the install, so extension updates are far more reliable
- standalone GT installs now align the default launcher, shell wrapper, and operator shortcut flow around the same ghostOS session entry path

## 0.1.30 - April 2, 2026

### Changed

- in public installs, `gt.cmd` now opens the real `ghostos --shell --headless` operator flow by default, so shortcuts and manual launches finally match the VS Code terminal experience
- a dedicated `gt_host.cmd` launcher is now generated for raw host-shell work when operators explicitly want the lower-level host console

## 0.1.29 - April 2, 2026

### Changed

- GT public shortcuts now prefer Windows Terminal when it is available and fall back to a UTF-8 shell launcher, so standalone launches stay much closer to the VS Code terminal experience
- the bundled shell launcher now forces the real `enter ghostos --shell --headless` path with terminal-friendly defaults instead of dropping operators into a disconnected host-style flow

## 0.1.28 - April 2, 2026

### Changed

- desktop and Start Menu launches now enter the same `ghostos --shell --headless` runtime flow as the VS Code terminal profile, instead of dropping operators into a different local host shell
- the installer action buttons now use rounded styling and darker primary surfaces so the branded setup feels closer to a finished product

## 0.1.27 - April 2, 2026

### Changed

- GT setup no longer fails the whole installation when desktop or Start Menu shortcuts cannot be created, and it now keeps those issues as post-install guidance instead
- the installer shell now uses a deeper black operator panel with neutral accents instead of the older blue-heavy look
- the GT website page now uses a darker install-flow panel, a darker VS Code download button, and clearer manual VSIX fallback guidance

## 0.1.26 - April 2, 2026

### Changed

- the public GT installer now keeps running even if VS Code cannot install the extension automatically, and it points operators to the bundled VSIX for manual install instead of failing the whole setup
- the branded installer accent palette now leans dark so the GT identity panel reads cleanly without the previous bright blue emphasis

## 0.1.25 - April 2, 2026

### Added

- GT public installs now support a guided branded installer experience for operators, with shortcut creation, VS Code extension installation, and polished first-run setup instead of a bare script-only flow

### Fixed

- public GT installs now keep the bundled runtime sealed at rest as a DPAPI-protected payload and stage the runnable ISO only when GT prepares a live session
- public operator bundles now ship the compiled sealed runtime ISO plus manifest only, instead of exposing extra raw runtime artifacts that were not needed by end users

## 0.1.24 - April 2, 2026

### Changed

- new MultiNode wallets now derive public addresses as `Ghost0x...` instead of `FN...`, while legacy `FN...` addresses remain accepted for compatibility across P2P and existing runtime state
- GT onboarding, wallet validation, P2P command hints, and operator docs now present `Ghost0x...` as the primary public wallet format
- canonical `ghost0x...` node handles now derive cleanly from the address body without leaking the `0x` marker into the node suffix

## 0.1.23 - April 2, 2026

### Fixed

- GT now derives attached Ghost nodes as `ghost0x...` identities instead of the old `gt-node` label, and it will reattach stale nodes to the canonical naming scheme
- GT runtime bundling now forces an ISO rebuild when the kernel artifacts are newer than the packaged ISO, preventing stale guest runtimes from masking fresh OS fixes

## 0.1.22 - April 2, 2026

### Fixed

- restored serial-first ghostOS shell bring-up semantics, so GT waits for serial/runtime markers before attaching the operator shell
- opening a shell against an already-running VM no longer truncates the serial log, but it also no longer bypasses the serial-auth/readiness path

## 0.1.21 - April 2, 2026

### Fixed

- `enter ghostos --shell --headless` now reuses an already-running ghostOS VM instead of truncating the serial log and timing out on startup
- GT now falls back to direct GhostTransport attachment when serial markers are temporarily unavailable, which prevents the VS Code terminal profile from closing with `exit code 1` during live attach scenarios

## 0.1.20 - April 2, 2026

### Added

- GT now ships a public release builder and installer flow, so the product can be packaged as a distributable runtime + VS Code bundle instead of assuming every operator has a full local repo checkout

### Fixed

- `ghost p2p bootstrap` now tolerates short ghostOS networking bring-up races before it decides the runtime is not ready

## 0.1.19 - March 29, 2026

### Added

- `ghost p2p bootstrap` now provisions a GT-hosted bootstrap seed automatically for the active ghostOS runtime before triggering kernel bootstrap/discovery

### Fixed

- ghostOS can now accept dynamic bootstrap seeds from GT instead of depending only on placeholder FreedomNet defaults
- GT now includes a lightweight host-side UDP bootstrap responder so VMware-backed ghostOS sessions can move from `bootstrapped=no` toward a real connected bootstrap state

## 0.1.18 - March 29, 2026

### Fixed

- opening `GT - GhostOS Terminal` now prefers attaching to an existing ghostOS runtime before doing any rebuild/prep work
- `enter ghostos --shell` now defaults to a headless runtime path instead of launching VMware GUI during normal terminal use
- VS Code terminal/profile entry now uses the stable headless shell flow again

## 0.1.17 - March 29, 2026

### Fixed

- `ghost p2p announce` now retries the command after an unexpected GhostTransport `HELLO` prelude instead of timing out on a recovered pipe session
- aligned route publication formatting and rebuilt the GT/runtime bundle after the local-only DHT publish fast path for non-bootstrapped sessions

## 0.1.16 - March 29, 2026

### Fixed

- packaged the latest GT shell/runtime fixes after the non-blocking P2P and MultiNode command path updates
- keeps the current stable Marketplace packaging flow while aligning the published extension version with the rebuilt `ghostterm_host`

## 0.1.15 - March 29, 2026

### Fixed

- packaged the current GT shell/runtime build as a fresh Marketplace release after the latest P2P command fixes
- `ghost p2p announce` and `ghost p2p bootstrap` now use the updated non-blocking driver path and longer GT command timeout handling

## 0.1.14 - March 29, 2026

### Fixed

- repackaged the same stable Marketplace-safe GT build as a fresh `0.1.14` release because `0.1.13` was already published and could no longer be replaced
- keeps the exact stable `0.1.13` operator behavior, including the non-forced `enter ghostos --shell` profile flow and the current P2P/runtime fixes

## 0.1.13 - March 29, 2026

### Fixed

- repackaged the stable GT release through the real cached `vsce` toolchain instead of manual archive rewriting, to restore a Marketplace-safe extension package
- keeps the same stable `0.1.10` operator behavior, including the non-forced `enter ghostos --shell` profile flow and the current P2P/runtime fixes

## 0.1.12 - March 29, 2026

### Fixed

- repackaged the stable `0.1.10` GT runtime and VS Code extension as a fresh `0.1.12` release without changing the validated operator flow
- keeps the stable `enter ghostos --shell` terminal profile behavior while retaining the current Wi-Fi, MultiNode, bundled-runtime, and P2P fixes

## 0.1.10 - March 29, 2026

### Added

- GT can now package and ship a bundled `ghostOS` runtime pack through `ghostterm_host.exe runtime package`, so non-developer operators do not need a full local repo checkout just to attach to a real guest runtime
- GT now exposes explicit `ghost p2p announce` and `ghost p2p bootstrap` flows, plus host-side `ghostos p2p address|stack|announce|bootstrap` commands for direct operator control over route publication and discovery bring-up

### Fixed

- `ghost p2p stack` no longer blocks on heavyweight NAT/bootstrap work during simple status inspection, so GT returns live kernel transport status instead of timing out
- `ghost p2p address` and `ghost p2p status` no longer trigger implicit route publication side effects during read-only inspection flows
- GT parsing for fields like `ssid` now respects token boundaries, so `ghost wifi details` no longer confuses `ssid` with `bssid`
- P2P contact connect/send flows now get longer GhostTransport time budgets for real route-preparation work instead of the short default request timeout
- GT status/doctor/runtime flows now distinguish between developer-repo mode and bundled-runtime mode instead of assuming every user has a writable local `mobile/` source tree
- GT VM preparation now falls back to a local writable VMX under `mobile\vm` if the canonical external `ghostOS.vmx` is unavailable or locked
- the VS Code GT terminal profile now returns to the more stable `enter ghostos --shell` flow instead of forcing `--headless --restart-vm` on every attach, while keeping the P2P/runtime fixes

## 0.1.9 - March 28, 2026

### Fixed

- the VS Code terminal profile now launches `GT - GhostOS Terminal` with a forced headless ghostOS VM restart so a fresh shell attaches to the newest kernel/runtime instead of a stale session
- GT host-side `enter ghostos --shell --headless --restart-vm` is now a supported flow for terminal-only operators who do not open VMware manually

## 0.1.8 - March 28, 2026

### Fixed

- packaged a new `GT - GhostOS Terminal` release alongside the latest kernel build after the P2P transport singleton construction fix in `ghostOS`
- aligned the shipped release with the current kernel-side P2P bring-up path so Marketplace and local VSIX installs pick up the newest runtime packaging

## 0.1.7 - March 28, 2026

### Fixed

- aligned the shipped GT release with the latest ghostOS kernel-side P2P/runtime path so Marketplace users can pick up the current build after the network-syscall validation fix in the Ring -1 gate
- refreshed the packaged release artifacts for the current Wi-Fi, MultiNode, and P2P inspection flow used by `GT - GhostOS Terminal`

## 0.1.6 - March 28, 2026

### Added

- `ghost multinodes` now exposes a kernel-backed viewer for connected peers, DHT-discovered nodes, and visible MultiNode count from the current runtime
- Marketplace documentation now includes the MultiNode network viewer command and usage notes

## 0.1.5 - March 28, 2026

### Added

- P2P contact flows in the store-facing documentation now describe the address-first path, where `ghost p2p add <alias> <wallet>` can rely on kernel-backed route discovery instead of requiring a manual endpoint
- GT now surfaces the announced route in `ghost p2p stack`, so operators can see whether their wallet route is being published automatically

### Fixed

- Marketplace README P2P examples no longer imply that `ip:port` is mandatory for every peer

## 0.1.4 - March 28, 2026

### Added

- `ghost wifi details` and `ghostos wifi details` now expose a full live network view from the running `ghostOS` kernel, including interface, IP, subnet, gateway, DNS, MTU, MAC, SSID, BSSID, security, signal, channel, and frequency
- Marketplace README now includes a current GT command reference for both host-side GT commands and in-shell `ghost` commands
- Marketplace README now documents the real GT verification flow for Wi-Fi inspection and kernel-backed P2P testing

### Fixed

- store-facing documentation is now aligned with the actual GT command surface instead of a partial subset

## 0.1.3 - March 27, 2026

### Added

- stronger GT runtime hardening across the Windows host path, including tighter GhostTransport pipe security and a more security-focused operator flow around the real ghostOS runtime

### Fixed

- GT-backed operator enrollment now persists its security-critical state through the sealed ghostOS profile instead of relying on runtime-only state
- passcode flows now reflect the hardened kernel-side verifier, lockout, and device-name persistence work that shipped with the latest GT runtime
- packaging for the next Marketplace update is now aligned with the current hardened GT/ghostOS integration state

## 0.1.2 - March 27, 2026

### Fixed

- Marketplace-installed builds now resolve the real local `ghostOS` repository from the current workspace or from the `ghostterminal.repoRoot` setting instead of assuming the extension install directory is the repo root
- `GT - GhostOS Terminal` now launches directly into `enter ghostos --shell --headless` instead of opening only a local GT host shell

## 0.1.1 - March 27, 2026

### Added

- contributed `GT - GhostOS Terminal` as a real VS Code Terminal Profile so it appears in the terminal profile picker alongside other shells
- activation wiring for `ghostterminal.terminalProfile`
- fallback terminal guidance if `ghostterm_host.exe` is missing on the machine

## 0.1.0 - March 27, 2026

Initial Marketplace-ready release of `GT - GhostOS Terminal`.

### Added

- Windows-native GT commands inside VS Code for mobile build, ISO preparation, VMware preparation, selfhost execution, serial follow, and ghostOS shell attach
- live ghostOS runtime queries through `ghostos status`, `ghostos ping`, `ghostos ui`, and `ghostos send`
- captured build diagnostics wired into the VS Code Problems panel
- `GhostBuild GBIR` explorer and GBIR summary virtual documents
- GhostOS-branded extension icon from `GT\gt.png`
- proprietary licensing and packaging metadata for controlled distribution
