byollm 0.1.0 → 0.1.2

package/README.md

@@ -1,111 +1,11 @@
-> **`alpha.15` is a breaking wire change, and it breaks daemons and relays —
-> not app authors.** If you call `app.enqueue(...)` and read results, nothing
-> in your code changes. If you run a daemon or an upstream, every package must
-> move together: a mixed pair refuses on both sides, because both ends parse
-> `.strict()`.
+<!-- release-note 0.1.1 -->
+> **`0.1.2` is documentation only — nothing to upgrade.** `PROTOCOL_VERSION`
+> is still `2`, so a 0.1.0 party and a 0.1.1 party talk to each other in both
+> directions. No dependency, schema, wire field or on-disk shape moved.
 >
-> What moved, all of it reconciling the frozen `byollm_009` with its code:
-> `JobStub` gains `site` (the site's identity key id) and loses
-> `audienceAllow`; `ResultRequest` gains `leaseId`; `HeartbeatResponse` loses
-> `leases`, which nothing read; `WireErrorCode` gains `not-ready`,
-> `clock-skew` and `forbidden`, and `403` is `forbidden` rather than
-> `unauthorized`. `RESULT_PROVENANCE` is superseded by
-> `PROVENANCE_NAMES_DEVICE`. See `byollm_009` Amendment A.>
-> **`alpha.16` is a breaking wire change — daemons and relays again, not app
-> authors.** `app.enqueue(...)` and reading results are unchanged. All five
-> packages move together: both ends parse `.strict()`, so a mixed pair
-> refuses.
->
-> What moved, all of it Tier 2 of `cloud_008`: `model`, `backendClass` and
-> `durationMs` come off `ResultRequest` and are sealed **inside** the result
-> envelope as `SealedOutcome = { outcome, ran }` — so a daemon can no longer
-> declare a model it did not sign, and a relay carries neither.
-> `HeartbeatResponse` loses `leases` (nothing read it) and now reports real
-> cancellations instead of an empty list. `WireErrorCode` gains `forbidden`
-> for 403, leaving `unauthorized` at exactly 401. The relay gained a
-> site-plane `cancel` endpoint, honours `stub.deadlineAt`, honours
-> `stub.audience`, and remembers a refusal.>
-> **`alpha.17` is additive** — no wire change. It exports `ReleaseReason`,
-> which `RoutingStore.releaseLeases` names and the package did not export, so
-> the interface was unimplementable outside this repo.>
-> **`alpha.18` is a breaking wire change — daemons and relays, not app
-> authors.** `app.enqueue(...)` and reading results are unchanged. All five
-> packages move together.
->
-> The **bearer token is gone**: off `PairPollResponse`, off the runner row,
-> off the daemon's pairings file, out of the adapter's schema. It was minted,
-> hashed and stored on two disks and never sent, looked up or compared —
-> `REQUESTS_SIGNED_NOT_BEARER` was enforced by signatures the whole time. If
-> you run the Supabase adapter, apply
-> `20260819000000_drop_runner_token.sql`; `byollm_approve_pairing` now takes
-> one argument. A pairings file written by an older daemon still loads.
->
-> `model`, `backendClass` and `durationMs` moved **inside** the sealed result
-> (`SealedOutcome = { outcome, ran }`), so a daemon cannot declare a model it
-> did not sign and a relay carries none of them. Writing a `RoutingStore`?
-> `releaseLeases` takes an optional `reason` and `complete` requires
-> `leaseId`, and **an implementation that ignores either still typechecks** —
-> run the store contract tests.>
-> **`alpha.19` is additive on the wire and a behaviour change in every
-> store.** `ResultResponse` gains an optional `duplicate`. Nothing is removed,
-> so an older daemon keeps working — but the *order* two rules are checked in
-> has changed, and a `RoutingStore` implementation must change with it.
->
-> `complete` now checks **terminal state before holder**, scoped to the device
-> that finished the job: a replay from that device is answered `duplicate:
-> true` with a 2xx, and anyone else gets exactly the refusal they would get
-> for a job that is not terminal. Previously `RESULT_IDEMPOTENT` held only
-> because the lease is nulled on success, so the holder check tripped first —
-> deleting the idempotency branch failed no test. Run the store contract
-> tests; the compiler cannot see this.
->
-> **`alpha.3` is a breaking change.** A config naming `openai-http` with a
-> remote base URL and an offer scope wider than `private` is narrowed to `private`
-> until you acknowledge the spend and set a daily ceiling:
-> `byollm offer <backend> public --cap <cents>`. Local base URLs are
-> unaffected. `byollm backends` shows the cost class per route.
-
-<!-- release-note 0.1.0-alpha.21 -->
-> [!NOTE]
-> **`0.1.0-alpha.20` is not a complete release — do not pin it.** Four
-> packages published and `@byollm/server` did not: a Sigstore
-> transparency-log 409 on its provenance attestation. The workflow's
-> "already published" guard correctly refuses to resume a partial publish,
-> so `0.1.0-alpha.21` is that release, whole.
->
-> If you run the Supabase adapter, `alpha.21` needs
-> `20260819010000_completed_by_lease_id.sql`: alpha.19 shipped §3.6's
-> ordering without the column it stores the grant in.
-
-<!-- release-note 0.1.0-alpha.40 -->
-**`byollm start` — stop keeping a terminal open.** The daemon can now run
-under your computer's own supervisor and restart itself if it stops: a launchd
-agent on macOS, a `systemd --user` unit on Linux, a logon task on Windows. All
-user-level — no root, no system directories, and `byollm stop` takes it
-away. `byollm status` gained a line saying whether it is actually supervised
-right now, including the state that matters most: installed but not running,
-which looks fine from an app's dashboard and serves nothing.
-
-If you are running via `npx`, install properly first (`npm install -g
-byollm@latest`) — `install` refuses to supervise a copy in npx's cache, because
-npm deletes that directory and the service would fail at some later boot.
-
-<!-- release-note 0.1.0-alpha.41 -->
-**`onNoRunner` takes a string.** Your fallback answer is your own value, not
-wire data, and handing back a whole result record for it was ceremony — the
-README's own example got the shape wrong, which is how this was found.
-
-```ts
-const { outcome, fallback } = await job.result({
-  onNoRunner: () => runOnHostedModel(transcript),
-});
-```
-
-Whatever you return, `result()` labels it `fallback: true` — the stamp is
-applied by the wait, not taken from you, so an answer that did not run on
-somebody's device cannot be reported as though it did (`FALLBACK_LABELED`).
-Both delivery channels do it, polling and Supabase Realtime. Records still
-work; they just get labelled too.
+> This README used to open with a stack of release notes instead of with the
+> package. The history moved to `docs/release-notes/` and `CHANGELOG.md`,
+> where none of it was lost. Full note: `docs/release-notes/0.1.1.md`.
 
 # `byollm`
 
@@ -193,6 +93,14 @@ for one. It defaults to 2 GB. **It does not know how big your models are**, so
 set it to fit your largest. It does not apply to services whose compute happens
 somewhere else — a hosted model reached through a local port loads nothing here.
 
+`autoUpdate` (default `false`) lets the daemon install new versions when it is
+offered one. Offers are taken only from `updateAuthority` — the reference hub,
+`https://hub.byollm.cloud`, when you leave it out — and never from any other
+site you paired with, never from a direct-mode pairing, and never for an older
+version. Every update is checked against its npm provenance before it runs and
+rolled back if it fails; [`docs/security.md` §7a](https://github.com/oftomorrowinc/byollm/blob/main/docs/security.md#7a-updates)
+says exactly what is checked.
+
 You do not have to write any of this by hand. `byollm services manage` asks
 what this machine has and writes the file for you, and it is safe to re-run:
 it shows what is already there.
@@ -246,35 +154,46 @@ The meter is the product, and it gets the same care as the loop.
 
 ```bash
 byollm status         # what's connected, what's running, what you've done for others
-byollm sites          # which sites this device serves, and which are waiting on you
-byollm approve <site> # say yes to a site that asked
+byollm sites          # which sites this device serves, and which keys it still holds
 byollm log            # every prompt that has ever run here
 byollm log --full     # the whole text, not the first line
-byollm stop           # stop claiming work — the off switch, always yours
+byollm stop           # stop running in the background — the off switch, always yours
 byollm start          # and bring it back
+byollm forget <url>   # drop a pairing entirely
 ```
 
-### A site cannot add itself
+### Which sites this device serves is decided in your dashboard
 
 Pairing is with an *app* — a hub, a relay, your own server — and one pairing
 can cover several sites. Which sites arrives on the heartbeat, from the same
 party that routes the work.
 
-So a site that turns up after pairing **waits**. It is listed by
-`byollm sites` with its fingerprint, nothing is claimed for it, and it starts
-being served the moment you run `byollm approve <site>`. Compare the
-fingerprint against what the site itself shows you before you do.
-
-The reason is narrow and worth stating: the daemon pins each site's keys so
-that the party routing a job cannot choose which key signed it. If that party
-could also *add* a site, it could generate a keypair, announce it, sign its
-own work with it, and every pin check downstream would pass — because the
-list they check against is the thing it wrote. Approving is the one step it
-cannot perform for you.
-
-A key that moves under a site you already approved is refused rather than
-replaced, for the life of the pairing — including when the site leaves the
-list and comes back. Rotation is an explicit path, not a silent swap.
+A site that turns up after pairing is **pinned and served** from that
+heartbeat on. Nothing on this machine asks you first: `byollm approve` is
+gone (it exits with a tombstone saying so), and which sites reach your device
+is decided in the app's dashboard, where the person changing it is signed in
+and can see what they are changing.
+
+What you get instead is a notice. The first time a new site's work runs here,
+the daemon says `now serving <site>, enabled from your dashboard` with the
+site's fingerprint — on screen in `byollm run`, in `~/.byollm/service.log`
+when it runs in the background — so a change made at the app is never silent
+at the machine. `byollm sites` lists every site this device serves and
+every key it still holds, with fingerprints, for comparing against what the
+site itself shows you.
+
+What the daemon still refuses, whatever the app says: a key that moves under
+a site id it has already pinned, for the life of the pairing — including when
+the site leaves the list and comes back (rotation is an explicit, signed path,
+not a silent swap); and any job that does not carry a grant signed by the
+control-plane key this device pinned when it paired. A party that can add a
+site to your heartbeat still cannot sign work for it.
+
+The trade is stated plainly in the spec (byollm_016, Amendment K): an app or
+control plane that is compromised can point your device at a site you never
+chose. Spend caps bound what that costs, the notice makes it visible, and the
+levers are yours: `byollm stop` stops all work, `byollm forget <url>` drops
+the pairing.
 
 Every prompt is appended to `~/.byollm/ingress.log` **before** it executes, so
 a job that wedges the computer still leaves a record of what it was. The file is

package/dist/bin.js

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 import {
   main
-} from "./chunk-FUKJDD7M.js";
+} from "./chunk-K7QYAF7V.js";
 
 // src/bin.ts
 process.exitCode = await main(process.argv.slice(2));