docs(release): give every release the same written notes

.github/release-notes/v0.1.0.md

@@ -0,0 +1,70 @@
+# Vectis 0.1.0
+
+**The first release of Vectis: disposable GitHub Actions runners on your own Apple Silicon Mac. Each job runs in a fresh ARM64 virtual machine, with a just-in-time runner that Vectis removes together with the VM when the work is done. You control it from a native Mac app, a CLI or an MCP server, and you can control other Macs remotely.**
+
+## Highlights
+
+### One job, one disposable VM
+
+- Every job starts in a fresh VM cloned from a prepared environment. The runner accepts one job, then Vectis removes the VM and runner registration so later jobs start clean.
+- Automatic runners are opt-in for each repository connection. Vectis watches for matching queued jobs and checks that work is still queued before allocating a VM. The default concurrency limit is five runners and can be configured from one to sixteen. Actual capacity depends on the CPU and memory assigned to environments; at most two macOS VMs run at once.
+- You can also start a runner manually. Vectis reports runner operation status separately from the GitHub job result, so completed cleanup is not mistaken for a passing workflow.
+
+### Ubuntu, macOS and Windows environments
+
+- **Ubuntu 24.04 ARM64:** downloads and verifies a pinned Ubuntu image, then prepares Git, Docker, SSH and the official runner's required dependencies.
+- **macOS 26 ARM64:** downloads and verifies Apple's restore image, installs it into a local guest bundle and guides you through guest setup and SSH verification.
+- **Windows 11 ARM64:** installation is available as an experimental path using media you provide.
+
+Choose CPU, memory, virtual disk size, image directory and VM storage location for each environment. Setup operations are durable and can resume after interruptions.
+
+### Connect GitHub and schedule work
+
+Pair a Mac with your Vectis account through browser approval. Link and verify a GitHub account, install the Vectis GitHub App for the repository owner, then connect a repository to an environment. Each connection provides a `runs-on` label such as `vectis-ubuntu`.
+
+- Automatic scheduling starts disabled and can be enabled per connection. Vectis receives GitHub job events and can scan GitHub for missed queued or running jobs.
+- If a successful run leaves its original job queued, Vectis makes a bounded number of additional attempts. Failed, cancelled or interrupted runs are not retried automatically.
+- Connect and disconnect repository bindings, inspect recent GitHub job states and refresh missing or stale job records.
+- Organization repository administrator access is verified before privileged operations.
+- Outside contributors need maintainer approval before public-repository jobs are admitted. Fork approval and workflow review stay with GitHub maintainers.
+
+### Review ARM workflow migrations
+
+Preview one workflow file or analyze workflows in a connected repository. Vectis proposes supported ARM64 label changes and reports jobs that need human review. It does not assume x64 jobs will work on ARM64.
+
+After Vectis observes a successful job on the same repository binding and environment revision, it can open a regular pull request containing only changed workflow files. Review and merge it through GitHub as usual; Vectis never merges it. Dynamic expressions, complex matrices, reusable workflows and privileged event patterns may need manual review.
+
+### Control Vectis from the app, CLI or MCP
+
+The native Mac app, `vectis` CLI and `vectis-mcp` server use the same typed command contract.
+
+- The app manages environments, repositories, runner operations, activities, diagnostics and settings. Its background service continues working when the window closes.
+- The CLI returns structured JSON, stable error codes and actionable next steps.
+- MCP lets agents inspect capabilities, issue the same commands, read operation state and wait for results.
+- The release also includes a Vectis agent skill and Claude Code plugin.
+
+### Control other Macs remotely
+
+Connect multiple Macs to one account and use the app, CLI or MCP to control an authorized host. Browser approval verifies each controller; access expires after 90 days and can be revoked. Hosts collect remote commands over an outbound connection, so they do not need an inbound port. Commands for an unavailable remote host do not fall back to running locally.
+
+### Safe recovery after interruptions
+
+The local service stores operations in SQLite and uses caller-provided keys to make command retries idempotent. Accepted, running, action-required and completed states remain distinct. Setup downloads can resume. After a service or host interruption, Vectis reconciles VM state only after it has evidence that the process exited. It stops only processes it started and tracks, and cleanup removes the owned VM and runner registration.
+
+### Security boundaries
+
+- Build work runs on your Mac. The Vectis cloud coordinates account identity, GitHub access and remote commands; it does not run workflow code. VM disks and build files stay on the host, while GitHub receives logs, artifacts and caches that workflows upload.
+- Guest VMs receive no host folders, Docker socket, GitHub App private key or general host credentials. A guest receives only the single-use runner registration needed for its job.
+- Each Mac maintains an outbound connection and does not expose an inbound service port.
+
+## Updating
+
+This is the first release, so install it: the app comes as a signed and notarized installer, and it includes an option to install matching `vectis` CLI and `vectis-mcp` launchers. Afterwards the app has an update path that waits for active work to finish. Then prepare an environment, pair the Mac with your Vectis account through browser approval, link GitHub and connect a repository.
+
+## Compatibility
+
+The app, CLI and service ship together. For macOS guests, complete guest setup locally and install Apple's Command Line Tools or Xcode in the guest; Xcode is not installed automatically. Project-specific runtimes and tools on Ubuntu guests are installed by workflow steps or containers.
+
+## Platform requirements and limitations
+
+Apple Silicon Mac with macOS 15 or later; Intel Macs are not supported. Ubuntu 24.04 ARM64 and macOS 26 ARM64 guests are supported. Windows 11 ARM64 is experimental and needs your own Windows and VirtIO media, a valid Windows license, and a separately installed QEMU build with the Vectis TPM patch, firmware and software TPM. All guests are ARM64, so workflows that require x86-64 binaries or x64 runner labels do not run unchanged.

.github/release-notes/v0.1.1.md

@@ -0,0 +1,49 @@
+# Vectis 0.1.1
+
+**A reliability release. Runners start reliably in parallel, failed runners are retried, and jobs that wait for approval run once approved. An idle Mac also costs the cloud far less.**
+
+## Highlights
+
+### Parallel runners start reliably
+
+With several automatic runners, two jobs could start virtual machines within milliseconds of each other. The second start failed because the first, still booting, was treated as an interrupted VM that needed inspection. The affected GitHub jobs then waited until GitHub cancelled them.
+
+- A booting VM is now tracked as Starting. Admission counts the CPU and memory of starting VMs, so concurrent starts cannot over-commit the Mac.
+- A genuinely interrupted VM still blocks new VMs, and runner capacity now reports no free slots while one exists, so the cloud stops handing out runners that cannot start.
+- The app shows these VMs as Starting.
+
+### Failed runners are retried
+
+A runner that failed before GitHub gave it a job was never retried, so the job kept waiting. Vectis now retries it after a minute, within the existing limit of three attempts per job. Cancelled, unfinished and action-required attempts are still not retried.
+
+### Jobs that wait for approval now run
+
+Jobs gated by an environment approval report the GitHub status `waiting`, and GitHub also uses `requested` and `pending`. Vectis rejected these, so such jobs were never picked up after approval.
+
+- They are now stored as Waiting and get a runner as soon as GitHub queues them. The app shows them as Waiting.
+- A runner that finds its job still waiting ends as cancelled without booting a VM.
+- A person's cancellation of an unchanged job stays final.
+
+### A much quieter idle Mac
+
+One idle Mac used enough Convex database bandwidth to exhaust a free plan within a week. Heartbeats now write liveness and runner capacity to a separate table instead of rewriting the machine record, job scan times no longer rewrite repository bindings, and the app asks the cloud for a small change marker instead of the full job list, fetching the list only when something reads it. In our measurements an idle machine's database traffic dropped by more than 90 percent. Scheduling behavior is unchanged.
+
+### Diagnostics when a runner loses its guest
+
+When the guest connection is lost or the runner process exits unsuccessfully, Vectis now collects evidence before stopping the VM and keeps it on the failed operation: the runner's last output or the SSH error, the host's network view of the VM and, if the guest still answers, uptime, memory, the kernel log tail and the runner log tail. The text is capped at 16 KiB and scrubbed of the runner configuration. The app shows it in the activity details, and the CLI and MCP include it in the operation result. Windows guests report only uptime and the runner log, which is untested.
+
+### Security
+
+Dependencies `undici` and `devalue` moved past their patched versions, which closes the open Dependabot alerts.
+
+## Updating
+
+Installed apps find this release within four hours, and the update waits for active work to finish. Updating from 0.1.0 is automatic. Nothing needs to be prepared again.
+
+## Compatibility
+
+The cloud backend is already deployed and stays compatible with 0.1.0 apps. A 0.1.0 app cannot decode a job list that contains a Waiting job, so update the app on every Mac to see those jobs. The app, CLI and service ship together.
+
+## Platform requirements and limitations
+
+Apple Silicon Mac with macOS 15 or later. Ubuntu 24.04 ARM64 and macOS 26 ARM64 guests are supported; Windows 11 ARM64 is experimental. All guests are ARM64, so workflows that require x86-64 binaries do not run unchanged.

.github/release-notes/v0.2.0.md

@@ -0,0 +1,78 @@
+# Vectis 0.2.0
+
+**Read job logs, see why a repository is not ready, decide who can start runners on your Mac, and rerun, cancel or dispatch GitHub runs from every surface. Linux guests can run x86_64 tools through Rosetta, Windows guests are kept off your local network, and runners that hang or lose their job clean up after themselves.**
+
+## Highlights
+
+### Job logs on every surface
+
+Read a GitHub job's log from the desktop, `vectis job logs <job-id> --binding <id> [--follow]`, or the MCP tool `vectis_job_logs`. Logs are fetched on demand with a byte cursor, so following a running job only transfers new output. The desktop opens a log panel under each job with follow, wrap and copy.
+
+### Readiness checks with the next step
+
+`vectis repository readiness`, the MCP tool `vectis_readiness` and the desktop's connect dialog check everything a repository needs, one item at a time: cloud connection, linked GitHub account, App installation, administrator access, fork approval policy, environment and connection. Each problem carries a code and the next step, and the desktop jumps to the place where you fix it. `vectis doctor` reports coded checks for the host runtime too. A new onboarding checklist on the Overview walks a fresh Mac from environment to first job.
+
+### Decide who can start runners on your Mac
+
+Each repository connection now has an access policy: anyone who can run workflows, or only listed GitHub users, and automatic or manually approved capacity. Jobs from other actors never get a runner, and jobs that need approval wait in **Needs you** until you approve them. Because GitHub can hand a runner a different queued job than the one it was started for, a job-started hook inside the guest checks the assigned job against the policy before any step runs, and stops the runner if it does not match.
+
+### Rerun, cancel and dispatch
+
+`vectis run rerun-failed`, `vectis run cancel` and `vectis workflow dispatch`, their MCP commands, and the job menu in the desktop control GitHub runs directly. Every request is idempotent: Vectis records it before contacting GitHub, never resends a request whose outcome is unknown, and reports such outcomes as unconfirmed instead of guessing.
+
+### x86_64 Linux tools through Rosetta
+
+Opt in per Linux environment with `vectis environment configure <id> --x64 rosetta`. The guest then runs x86_64 binaries and `docker run --platform linux/amd64` images through Apple's Rosetta, shared read-only into the guest. The runner stays ARM64 and keeps its labels, so workflows choose this explicitly.
+
+### Network egress for Windows guests
+
+Windows guests are limited to the internet by default: connections to the Mac, its local network, loopback and link-local addresses are refused, while DNS and internet traffic work. Linux and macOS guests report their egress as not enforced on every surface, because Apple Virtualization's NAT cannot restrict it yet.
+
+### Runners that clean up after themselves
+
+- A runner requested for a job that no longer needs it is released after 10 minutes of inactivity, reported as `runner_idle`.
+- An automatic runner request that a Mac never picks up expires after 2 minutes if the Mac went offline, or 10 minutes if it stayed online, so another connected Mac can take the job.
+- When GitHub still holds a runner on a job that died, cleanup is retried automatically for up to 30 minutes instead of waiting for a manual reconcile.
+- A request that lost its cloud lease can now be reconciled after its VM is confirmed stopped.
+- A job the access policy refused ends as `runner_assignment_rejected`, not as a plain cancellation.
+
+### See what is happening
+
+- Jobs show the runner's stage next to their GitHub status: preparing, registering, waiting for a job, cleaning up, released.
+- The desktop sends a macOS notification when Vectis needs you or work fails, even while its window is hidden. Clicking it opens the activity. Turn it off in Settings.
+- A failed GitHub job now shows an error toast, even when its runner finished cleanly.
+
+### Workflow migration
+
+Migration rewrites only the `runs-on` values it moves, byte for byte, and keeps comments and formatting. The desktop shows which jobs move to Vectis, which stay, and why, instead of two plain file previews.
+
+### Security
+
+- Account linking and host isolation were hardened: each Linux instance has its own SSH host key, private fork policies are checked before a runner is registered, and Windows guests run with network isolation.
+- Credentials are redacted from logs, operation details and stored diagnostics, including Windows bootstrap diagnostics.
+- `@modelcontextprotocol/sdk` and `sharp` were updated.
+
+### Fixes
+
+- Exit evidence is kept when VM file cleanup fails, so an instance can still be reconciled.
+- Windows bootstrap failures keep their diagnostics.
+- Jobs that GitHub reports with runner `0` are recognized as unassigned again.
+- Jobs inherit the guest's normal umask, so files they create are no longer private to the runner user.
+- A removed environment's ID can be prepared again.
+- Requesting a runner for a job GitHub does not know reports `job_not_found`.
+
+## Updating
+
+Installed apps find this release within four hours, and the update waits for active work to finish. Before you rely on it:
+
+- **Prepare Linux environments again.** Each Linux instance now gets its own SSH host key. Images prepared with 0.1.x report `action_required` until they are prepared again. To keep the environment ID, its `vectis-<id>` runner label and existing repository connections, remove the old environment and prepare the new image under the same ID. Removing an environment keeps its image files on disk.
+- **Approve the GitHub App's Actions write permission** to use run control. Until then, rerun, cancel and dispatch report `github_app_permission_required`. Everything else works without it.
+- **Windows: rebuild QEMU with both Vectis patches.** Windows guests now start only with a QEMU build that supports network isolation (`native/qemu/patches/0002-isolate-vectis-user-network.patch`). Existing Windows base images do not need reinstalling.
+
+## Compatibility
+
+The cloud backend is deployed and stays compatible with 0.1.x apps. Run control, job logs and readiness need 0.2.0 on the Mac. The app, CLI and service ship together.
+
+## Platform requirements and limitations
+
+Apple Silicon Mac with macOS 15 or later. Ubuntu 24.04 ARM64 and macOS 26 ARM64 guests are supported; Windows 11 ARM64 is experimental. Guests are ARM64; Linux guests can run x86_64 tools through Rosetta when you opt in. Network egress is enforced only for Windows guests.