[SnowCheetos]

vKore's first architecture was built around HostLink, a host-guest channel that never reached Kore's main: MicroPerceptron/kore#722, MicroPerceptron/kore#909 and MicroPerceptron/kore#933 were closed, and MicroPerceptron/kore#1015 is stale. A Kore release could not speak to that half of vKore, and the Kore crates it pinned by commit had drifted from any Kore that exists. This PR retires that half and rebuilds vKore on what Kore actually offers a host:

• an ISO, and the QEMU topology Kore's own production gate boots;
• the console markers Kore prints as it boots;
• QMP;
• DagFS volumes, through Kore's own engine, exported by libkore.

Kore reaches vKore through one dependency: kore-host from libkore (MicroPerceptron/libkore#31, pinned at 3aac3b5, which exports Kore's main at 7074bda2). Nothing of Kore is copied here.

What vKore does now

• Machines (vkore machine create|run|changes|apply): boots an ISO on Kore's gate topology with the host's QEMU probed rather than assumed, follows the boot by Kore's own markers (kernel, services, shell, ready, degraded, failed), and stops it with the power button. With Kore's main from 7074bda2 (MicroPerceptron/kore#1475) the stop is graceful, 0.35 s after the press. Older Kore under QEMU never hears the button, so vKore ends QEMU after --grace.
• Volumes (vkore volume DISK info|ls|tree|cat|get|put|rm|format|shots): a machine's disk, an image, or a block device. Reads, previews (from a file's head, never decoding pixels), exports and installs go through Kore's all-or-nothing publication. Exports never go through a symlink, never over a file unasked, and are published only once synced. The folder an export is sent to is created if it does not exist.
• Screenshots: vKore creates pictures/screenshots before each boot, since Kore's capture app saves only into an existing folder. It lists and exports captures with their record (build, time, mode, region, uptime and any other kore: keys). Kore writes a capture seconds after PrintScreen and a stop does not wait for it, so the documented round trip waits 15 s.
• The desktop (vkore-ui): Volumes and Machines, in-process, Iced over Axiom.
  • Shaping is confined to the bundled faces, so a host-installed JetBrains Mono can no longer blank the window.
  • Text from a guest or the host is escaped where a face cannot draw it, and controls, direction overrides and invisible characters are shown.
  • Starting a machine releases its disk from the browser and reopens it when the machine stops.
• Removed: the HostLink endpoint and inference registry, the harness and its API, vkore-workspace, vkore-hostlink-ab, the launchers and gate scripts. The policy, package and add-on crates stay, with no guest path until a channel exists; MIGRATION.md says how one comes back (through Kore and libkore, never ahead of them).

Commits:

• 5e39761: the rebuild.
• 2d24e0f: docs (README, docs/compatibility.md, docs/desktop.md, MIGRATION.md, AGENTS.md).
• 820d7fd: docs on why stops are graceful with the PM1 fix and were not before.
• 82a035c: an export creates the folder it is sent to, once it has something to copy. shots reports refusals instead of taking them for an empty folder.
• d8a8848: pin libkore 3aac3b5 (Kore main 7074bda2), verified on that commit's ISO, and the capture timing a graceful stop exposes.
• 07e10f5: in the desktop, a hovered row no longer wears the selection's border, the volume root's breadcrumb has one slash, and counts agree with their nouns (also in the CLI).
• ea6ab0d: README, the desktop on a physical Kore disk.

Verification

Linux x86_64 container, QEMU 8.2.2 TCG, at 07e10f5:

• cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings and cargo test --workspace (119 tests) pass. The desktop's tests include headless page renders: no text refusals, and the shared kernels drawing a page pixel-identical to the scalar reference. The QMP client has tests for late replies, mid-line timeouts and line bounds.
• The opt-in boot test passes on a production ISO built from Kore 7074bda2 and on a production v0.40.0 ISO.
• The 7074bda2 ISO: vkore machine run boots to ready (19/19 services, 45/45 apps), presses PrintScreen, and stops gracefully. vkore volume @NAME shots --get copies the capture out with its record, byte-identical to the volume's copy. With --stop-after 5 or 7 the capture was lost; with 10 or 30 it was saved.
• The v0.40.0 ISO: the same run to ready (44/44 apps), with the capture copied out. The stop ends QEMU after the grace period.
• An older disk that v0.40.0 formatted, booted by the 7074bda2 ISO: ready, with both builds' captures on the volume.
• A GPT disk on a loop device (Kore user and system partitions): an install through the partition node, and exports through the partition and whole-disk nodes byte-identical to the source. Nothing outside the user partition changed. With another partition on the same disk mounted, as on a dual-boot machine, writes go through the user partition's node. Naming a partition that does not hold the volume is refused, and the refusal names the one that does.
• The desktop under Xvfb: browsed, previewed and saved a capture byte-identical, and started, followed and stopped the machine.

On a physical machine with Kore and Ubuntu on one NVMe disk, booted into Ubuntu (run by the maintainer): the desktop opened Kore's user volume through the disk's node. It previewed a 2880×1800 capture's record and saved it out.

Not verified

KVM or HVF acceleration, writing to a physical disk, macOS, AMD hosts.

Notes

• The desktop depends on Axiom, which is not public yet (.cargo/config.toml fetches it with Git credentials). Every other crate builds from public sources.
• Kore's graceful shutdown does not wait for a capture still being written, and Kore prints no console line when one is saved. So --screenshot cannot wait for the save; the docs give a measured wait instead. A console marker for a saved capture, in Kore, would let it wait exactly.
• Reading a Kore disk from the host needs read access to the whole disk's node, and writing needs read-write on it and on the volume's partition. Today that means root, or ACLs on those nodes. Device access through udisks2 is a follow-up.
• This supersedes the HostLink direction of the open Real Kore multi-chat, workspace authority, and runtime diagnostics #39.

---

🤖 Generated with Claude Code

https://claude.ai/code/session_01ACHC7gzaAcosxJUPe73SWh

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.

[SnowCheetos]

copilot-pull-request-reviewer, this PR's only check, failed without reviewing anything: its session ended with HTTP 402, "You have exceeded your monthly quota". That is the organization's Copilot review quota, not this change. The same error stopped the reviewer on MicroPerceptron/kore#1475 and MicroPerceptron/libkore#31. A re-run won't pass until the quota resets or is raised.

This repository has no CI workflows, so the gates were run locally on this branch: cargo fmt --all -- --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test --workspace, and the opt-in boot test with a real Kore ISO. Adding a workflow that runs those on every PR would be a separate change. The desktop's Axiom dependency is not public yet, so that workflow would need a credential for it, or would have to build without vkore-ui.

---

Generated by Claude Code