@intentic/machine 1.344.0 → 1.346.0

package/README.md

@@ -108,8 +108,12 @@ flowchart LR
   sandbox's, in this environment or another of this PC's (see [What folder sync owns](#what-folder-sync-owns)), and a
   set-up-again that would change where a paired sandbox's folder syncs. It is **copy-first** unless
   its owner opted into two-way: see [Copy-first projects](#copy-first-projects).
-  Attaching the same folder again keeps its session and the watcher's pause and outage records, so an automatic pause
-  still resumes when its reason ends. The host's enrollment and transport settings are refreshed.
+  Setting the same folder up again keeps its session and every fact that holds its sync (see
+  [File sync runs or holds still by one rule](#file-sync-runs-or-holds-still-by-one-rule)). A project folder also takes
+  its agents' landed work by itself (`deliver: "auto"`, see [Delivering landed work](#delivering-landed-work)), and is
+  refused where it is a whole disk, a home folder or one holding it, or the system's own (`folderRefusal` in
+  [`sync/folders.ts`](src/sync/folders.ts), as the desktop app refuses them). `setup` wakes the resident watcher
+  (`sync/wake.ts`) once it has recorded the pairing, so the session is made at once rather than at the next poll.
 - **Through Docker** ([`sync/endpoint.ts`](src/sync/endpoint.ts)): with `setup --transport auto`, the default, a
   project's sandbox is reached through this machine's own Docker engine when the container `ic` named after the
   pairing URL's slug is running there with that URL as its `SANDBOX_PUBLIC_URL`. Anything else stays on ssh: a hosted
@@ -124,10 +128,10 @@ flowchart LR
   - (2026-10-05) The transport is no longer decided once: the container is asked after on every prepare and every
     minute (`checkContainers` in [`sync/gone-watch.ts`](src/sync/gone-watch.ts)). A stopped container, or an engine that
     does not answer, changes nothing. A container the engine no longer holds is looked up in ic: still listed (a swap
-    moving it) changes nothing; in ic's trash pauses the folder's sync with that reason. When the sandbox still answers
-    at its address, whether ic holds it nowhere or cannot say, it lives elsewhere now and the pairing moves onto ssh
-    (paused instead without an enrollment to ride); in neither and silent, the sandbox is gone (below); otherwise its
-    sync is paused until the container is back.
+    moving it) changes nothing; in ic's trash holds the folder's sync still (`containerAway: "trashed"`). When the
+    sandbox still answers at its address, whether ic holds it nowhere or cannot say, it lives elsewhere now and the
+    pairing moves onto ssh (held instead without an enrollment to ride); in neither and silent, the sandbox is gone
+    (below); otherwise its sync holds still until the container is back (`containerAway: "missing"`).
 
   (2026-10-01) Measured on Docker Desktop from Windows and from WSL: a session was up in 2–4 s, against up to 90 s
   through the tunnel. Bind-mounting the folder into the container was rejected: a land or an agent's `rm -rf` would
@@ -141,10 +145,11 @@ flowchart LR
   (`settlesFirst` in [`sync/mutagen.ts`](src/sync/mutagen.ts) says why for each). Every session and forward is created
   with three Mutagen labels, `intentic-owner=<machineId>-<environment>`, `intentic-sandbox=<sanitized id>` and
   `intentic-kind=sync|state|forward`; see [What folder sync owns](#what-folder-sync-owns).
-- **This computer's own sandbox takes folders** (see [Folders attached to this computer's sandbox](#folders-attached-to-this-computers-sandbox)):
-  `sync setup --projects-host` enrolls it with no folder of its own, and each folder the owner opens attaches to it as
-  `/work/<name>` (`sync attach`), copy-first, with the land of a conversation written back into it by itself
-  (`deliverProject`).
+- **Each folder has a sandbox of its own** (`sync setup --project`, see [Copy-first projects](#copy-first-projects)):
+  copied one way into its `/work/<name>`, with the land of a conversation written back into it by itself
+  (`deliverProject`, see [Delivering landed work](#delivering-landed-work)). _(2026-10-21) Folders used to attach to one
+  sandbox per computer (`sync setup --projects-host`, `sync attach`); that went, see
+  [One sandbox per computer, retired](#one-sandbox-per-computer-retired)._
 - **What file sync costs this device is cycles, and the sandbox's side decides how many.** Mutagen's agent in the
   sandbox has no recursive watcher, and both sessions force it to poll (`--watch-mode-<side> force-poll`): every 2 s
   for the workspace, which is how late an agent's edit reaches the folder, and every 60 s for the state backup, which
@@ -170,21 +175,25 @@ flowchart LR
   host key the enrollment carries when it carries one (a sandbox reads its sshd's public key off its history volume and
   answers with it, `SyncEnrollmentAnswerSchema` in the contract), else with nothing, so `accept-new` records the key
   the sandbox presents now, as it does for an older sandbox. Outside an enrollment a changed key is still refused. A sandbox whose ports poll has failed for ten
-  minutes has its forwards taken off localhost, and they come back with its first answer; after an hour its sessions
-  are paused, an hour counted from `unreachableSince` in `sync.json` (2026-10-05: it was counted in memory, so an agent
-  restarted more often than hourly never paused a dead sandbox's sessions). A sandbox that no longer exists is another
+  minutes has its forwards taken off localhost, and they come back with its first answer; after an hour its sync holds
+  still, an hour counted from `unreachableSince` in `sync.json` (2026-10-05: it was counted in memory, so an agent
+  restarted more often than hourly never held a dead sandbox's sessions). A sandbox that no longer exists is another
   matter: see [Sandboxes that are gone](#sandboxes-that-are-gone). `sync uninstall` ends every session and forward of
   this agent's and stops its Mutagen daemon, which serves this agent alone (below), starting it first if it was down so
-  every session is really ended; the synced folders keep their files. `sync uninstall --folders` (what the desktop app's
-  uninstaller runs) unpairs only the pairings that sync a folder here: mirror-only pairings and the projects host keep
-  their ports and their enrollments.
+  every session is really ended; the synced folders keep their files. It runs the agent's own Mutagen in `bin/` and
+  downloads none: without that copy the session steps are skipped (2026-10-18). `sync uninstall --folders` (what the desktop app's
+  uninstaller runs) unpairs only the pairings that sync a folder here: mirror-only pairings keep their ports and their
+  enrollments.
 - Symbolic links travel only where the device can create them ([`sync/symlinks.ts`](src/sync/symlinks.ts)). A
   Windows PC without Developer Mode refuses every link, and Mutagen would try again on every cycle, so its sessions
   use `--symlink-mode ignore`. Turning Developer Mode on brings them back at the agent's next start.
 - **Which computer this is** ([`machine-id.ts`](src/machine-id.ts)): a `machineId` minted once at install and kept
-  in `~/.intentic/machine/machine-id`, sent in the connect-time facts, the sync report and the sync enrollment. The
-  Windows side hands its own to the agent it starts in each distro, so every OS install of one PC answers with one id;
-  a sandbox joins enrollments, sync enrollments and device rows on it, never on a hostname.
+  in `~/.intentic/machine/machine-id`, sent in the connect-time facts, the sync report, the sync enrollment and the
+  device enrollment (`device setup` sends it with the environment when it redeems the pairing). The Windows side hands
+  its own to the agent it starts in each distro, so every OS install of one PC answers with one id; a sandbox joins
+  enrollments, sync enrollments and device rows on it, never on a hostname. (2026-10-20: `device setup` used to redeem
+  with no body, so the sandbox learned the id only once the agent connected, and the PC showed as two machine cards
+  until then.)
 - The features a device advertises (`set-shape`, `reshape-later`, `rollback-to`, `background-prepare`) are read off
   the `ic` under it, from that `ic`'s own help (`ic sandbox shape --set` for the first two, `ic sandbox rollback --to`
   for the third, `ic sandbox prepare --auto` for the fourth), rather than listed beside the code. The agent's own two,
@@ -356,97 +365,35 @@ folded where the platform folds it). With `--json` each prints exactly one JSON
   back included. Copy-first then carries the restored files to the sandbox, as it does any edit here, so the agent's
   versions they replace are gone from there too.
 - One bring-back, restore or delivery runs per folder at a time (`restore/<pairing key>/.operation.pid`, a pid of this
-  boot, checked alive). A pause an operation made and never lifted (the process killed in between) is recorded in
-  `restore/<pairing key>/.paused`, and the next command about that folder resumes the session.
-
-### Folders attached to this computer's sandbox
-
-Each computer has one always-available local sandbox, and any number of folders attach to it, each as `/work/<name>`.
-A folder used to get a project sandbox of its own (`sync setup --project`, above), which still works.
-
-**The projects host.** `intentic-machine sync setup --url <sandboxUrl> --pair <token> --projects-host` (with
-`--transport` and `--sandbox-id` as for any setup) enrolls the machine sandbox exactly as a setup does, and records a
-folderless pairing: `{ sandboxUrl, sandboxId, mode: "sync", syncToken, projectsHost: true, transport?, container? }`.
-It has no Mutagen session, no git bridge and no state backup. It holds the sandbox's sync token, and it is the one
-pairing that mirrors the sandbox's ports to localhost. It reaches the sandbox through Docker when the sandbox's
-container runs on this machine's engine, so its forwards ride `docker://` too. Refused:
-
-- `--projects-host` with `--dir`, `--remote-dir` or `--project`.
-- Turning a sandbox that syncs a folder into the projects host, and the other way round. Unpair first.
-- An enrollment that comes back ports-only.
-
-Enrolling again rotates the sandbox's one token per machine key, so the new token is written into every pairing of that
-sandbox (`withPairing` in [`sync/config.ts`](src/sync/config.ts)).
-
-**Attaching and detaching.** Both are local: no enrollment, no network. With `--json` each prints exactly one JSON
-object, `{ "ok": false, "error": "<sentence>" }` and exit code 1 on failure, as the copy-first commands do.
-
-| Command | Success output |
-|---|---|
-| `sync attach --sandbox-url <url> --dir <folder> --name <name>` | `{ "ok": true, "pairing": "<sandboxId>~<name>", "remoteDir": "/work/<name>", "folder": "<folder as given, absolute>" }` |
-| `sync detach --dir <folder>` | `{ "ok": true, "pairing": "<key>", "folder": "<folder>" }` |
-
-- `attach` finds the projects host whose URL has the same host as `--sandbox-url`. Without one it answers "this
-  computer's sandbox is not set up for folders yet".
-- It refuses:
-  - a name `isProjectDirName` refuses (the sandbox's reserved names included);
-  - a folder that is not there;
-  - a whole disk, the home folder or one holding it, `/var/home` or a whole home in it, and the system's folders (on
-    Windows, on whichever drive), as the desktop app does ([`folderRefusal`](src/sync/folders.ts)). (2026-10-06) A WSL
-    distro's folder named from Windows (`\\wsl.localhost\<distro>\…`, `\\wsl$\…`) is held to the distro's rules: its
-    `/home`, a whole home in it, `/root`, a mounted disk (`/mnt/c`) and its system's folders;
-  - a folder that is, holds or sits inside any other pairing's, this environment's or (2026-10-05) another environment
-    of this PC's ([`sync/siblings.ts`](src/sync/siblings.ts), as `setup` does);
-  - a name already attached for another folder.
-- It records `{ key: "<sandboxId>~<name>", sandboxId, sandboxUrl, syncToken (the host's), mode: "sync", localDir,
-  remoteDir: "/work/<name>", project: true, direction: "to-sandbox", deliver: "auto", transport?, container? }`.
-  Docker is preferred, as for the host. Attaching the same folder under the same name again keeps the direction its
-  owner chose. `localDir` is the folder as given, made absolute, as `setup` records one; links are resolved only to
-  compare folders (2026-10-05: the desktop app finds its folder in `status --json` by the path it passed, and on Fedora
-  Atomic `/home` is itself a link to `/var/home`, so a link-resolved path would never be found).
-- It returns once the pairing is recorded and the resident agent is running. The agent creates the session on its next
-  pass, and `status --json` lists the folder with its `localDir`, `remoteDir`, `deliver` and `mutagenStatus`.
-  `mutagenStatus` is absent until the session exists, then Mutagen's own words: `connecting-beta`, `scanning`,
-  `reconciling`, `staging-beta`, `transitioning`, `saving` while the first copy runs, and `watching` once a whole cycle
-  has finished. Read the first `watching` as "first copy done": later edits pass through the same words again.
-- `detach` removes the pairing first, so the agent recreates nothing, then ends its session and drops its listing record.
-  Its restore points stay. A folder with a sandbox of its own is refused, with the `sync uninstall` that unpairs it.
-- `changes`, `bring-back`, `restore-points`, `restore` and `direction` work on an attached folder as on any project, by
-  `--dir`.
-
-**A pairing key.** Every pairing is filed under `pairingKey` = `key ?? sandboxId`. Every pairing made before folders could
-attach has no `key`, so its key is its sandbox id and nothing of it moves: its session names, its restore points, its
-listing record, its lock. The key names what is a folder's own: the `upsertPairing`/`removePairing`/`set*` writes, the
-Mutagen session (`sessionName`), `restore/<key>/` with its lock and pause marker, and `hashes/<key>.json`. The sandbox
-id still names what is the sandbox's: the enrollment and its token, the ssh alias and tunnel (one block per sandbox),
-the container, the forwards, the swap pause, the report's `sandboxId`. `sync.json` is refused whole for:
-
-- two pairings under one key;
-- an attached key that is not `<sandboxId>~<name>` for its `/work/<name>`;
-- a projects host with a folder, remote dir, project flag or key.
-
-`--sandbox` (pause, resume, mirror, autoheal, uninstall) selects every pairing of the sandbox it names.
-
-**One poll, one mirror, one report per sandbox** ([`sync/mirror.ts`](src/sync/mirror.ts)):
-
-- The sandbox's own pairing polls its ports; with no host, the first folder attached to it does. The poll is also how the
-  sandbox's liveness and a revoked enrollment are noticed. Every other folder follows that answer
-  (`followSandbox`): paused after an hour of no answer, resumed on the first. A folder never mirrors a port, whatever
-  `mirrorOff` says. It carries the sandbox's switch only so the report says the same of it.
-- A revoked enrollment drops every pairing of the sandbox, since they share its token.
-- The report goes to each sandbox once (`reportCarriers`), and `scopedReport` carries all of its pairings, host and
-  folders, each with `remoteDir`, `projectsHost` and `deliver`: the daemon keeps one report per machine.
-- **A folder's first copy waits for its report** (`readyToPrepare`). The daemon makes `/work/<name>` a repository of its
-  own once a report names it. So a folder whose session does not exist yet gets one only after a report naming it was
-  taken, tried again each pass otherwise. A daemon with no report route (404) is not waited for.
-
-(2026-10-05) An attached folder's session is `intentic-<sandbox>--<name>-<8 hex of sha256(name)>`. A sanitized id never
-holds `--`, so the name can be no sandbox's session nor its `-state` backup (a folder called `state` included). The hash
-keeps `my.app` and `my_app` apart, which sanitize alike. Letting every folder poll was rejected: ten folders would cost
-the daemon eleven polls every five seconds, and three rejected polls counted per sandbox would revoke after one tick.
-
-**Delivering landed work** ([`sync/project/project-delivery.ts`](src/sync/project/project-delivery.ts)). When a conversation's work
-lands in `/work/<name>`, the daemon calls `deliverProject` on the device link (`ProjectDeliverySchema` in the contract),
+  boot, checked alive). Its pause is a hold like any other (`transferSince`, below): recorded on the pairing before
+  the session is paused and lifted as the operation lets go, so the watcher's pass keeps the session paused while it
+  writes. (2026-10-21: recorded nowhere, it read as a pause nothing explained, and the next pass resumed the session in
+  the middle of the write.) A pause an operation made and never lifted (the process killed in between) is recorded in
+  `restore/<pairing key>/.paused`, and the next command about that folder resumes the session; the watcher lets go of
+  its hold by itself once the folder's lock names no live process.
+
+### One sandbox per computer, retired
+
+(2026-10-21) Each computer used to have one always-available sandbox that every folder attached to as `/work/<name>`:
+`sync setup --projects-host` enrolled it with no folder of its own, and `sync attach` / `sync detach` filed each
+folder under a key of its own (`<sandboxId>~<name>`), polled and reported once per sandbox and announced to the daemon
+before its first copy. The owner retired it: a central sandbox for everything was the wrong shape, and each folder now
+gets a sandbox of its own, made for it (`sync setup --project`, [Copy-first projects](#copy-first-projects)), which
+takes landed work by itself. So there is one pairing per sandbox again, filed under its sandbox id, and `sync.json` is
+refused whole for two pairings of one sandbox, as before.
+
+A `sync.json` an older agent wrote is never refused for what that design left in it. Reading leaves out its folderless
+pairing (`projectsHost: true`) and every attached folder (`key`), so nothing syncs them; the watcher's start writes
+the file without them and says each in one line (`retireLegacyPairings` in [`sync/config.ts`](src/sync/config.ts)),
+and the orphan sweep ends their Mutagen sessions and forwards. Nothing is deleted on either side: each folder keeps its
+files, and that sandbox keeps its copies and its agents' history, carrying on as an ordinary sandbox. The sync scripts
+refuse `SYNC_PROJECTS_HOST` from a desktop app older than this, rather than reading it as a folder for that
+sandbox's whole `/work`.
+
+### Delivering landed work
+
+([`sync/project/project-delivery.ts`](src/sync/project/project-delivery.ts)) When a conversation's work lands in a
+project sandbox's `/work/<name>`, the daemon calls `deliverProject` on the device link (`ProjectDeliverySchema` in the contract),
 and this agent writes the change into the folder. It is a procedure of the link, not an MCP tool, so no agent can call
 it, and it sits behind no switch of the grant: the folder's own `deliver: "auto"` is the permission. It is logged and
 appended to the audit file like every call.
@@ -506,11 +453,11 @@ Two witnesses can say a sandbox is gone ([`sync/gone.ts`](src/sync/gone.ts)); ab
 What follows is the same for both ([`sync/gone-watch.ts`](src/sync/gone-watch.ts)):
 
 - **Marked.** Every pairing of the sandbox gets `goneSince` (first heard), `goneCheckedAt` and `goneBy` (`edge` or
-  `local`) in `sync.json`. Its sessions are paused with the watcher's own marker, `fileSyncPausedFor: "gone"`; a pause
-  somebody else made is left alone. Its ports come off localhost, its tunnel listener closes, no report is posted to
-  it, nothing is created for it, and its folders do nothing more. One line says so, with the day it will be retired.
-- **Asked again** at most hourly (one ports poll), whatever the outcome. An answer clears all three fields, lifts the
-  pause, and the next pass puts the ports back. A sandbox ic listed again (restored from its trash) is cleared at once
+  `local`) in `sync.json`, which is what holds its file sync still. Its ports come off localhost, its tunnel listener
+  closes, no report is posted to it, nothing is created for it, and its folders do nothing more. One line says so, with
+  the day it will be retired.
+- **Asked again** at most hourly (one ports poll), whatever the outcome. An answer clears all three fields, which lets
+  its sync go, and the next pass puts the ports back. A sandbox ic listed again (restored from its trash) is cleared at once
   when ic was the witness; the edge's word is withdrawn only by the sandbox answering.
 - **Retired** once seven days (the trash window) have passed since it was first said to be gone, on a verdict asked
   within the last hour, so an agent that was off for a week asks once first. Retiring ([`sync/retire.ts`](src/sync/retire.ts))
@@ -561,11 +508,16 @@ whose it is.
   environment the watcher (and `sync uninstall`) moves off the old directory
   ([`sync/mutagen-move.ts`](src/sync/mutagen-move.ts)): each of this agent's sync sessions there is carried, not made
   again. It is paused, its state files (`sessions/<id>` and `archives/<id>`, the last state both sides agreed on) are
-  copied into the new directory, it is terminated in the old one, and this agent's daemon, started again, loads it and
-  resumes what was running. Made again from nothing, a two-way session would bring back what one side deleted while it
+  copied into the new directory, it is terminated in the old one, and this agent's daemon, started again, loads it. A
+  session that was paused there is the owner's pause (`ownerPausedAt`), and the watcher's next pass resumes the rest.
+  _(2026-10-20)_ Which sessions were paused is written down at the move's first look (`mutagen-move-paused.json`, gone
+  once the move is recorded done) and declared before the move pauses anything; a later try reads that record, not a
+  listing in which the move's own pauses look like the owner's. Declared after the terminate instead, a move cut short
+  in between left nothing saying whose the pauses were, and its retry declared every session the owner's, so folders
+  nobody paused stayed paused. Made again from nothing, a two-way session would bring back what one side deleted while it
   could not sync and read a one-sided edit as a conflict; nothing could be flushed first, since the move runs before the
   transport is up. Forwards are terminated and made again. A session that cannot be carried is terminated and made again
-  by the watcher, paused if it was (`mutagen-moved.json` holds the names until then). The old daemon is stopped only
+  by the watcher, paused if it was, since its pause was declared the same way. The old daemon is stopped only
   when nothing else is left in it or the move started it; one of another Mutagen version is stopped and started with
   this agent's copy for the move, then started again with the owner's own Mutagen where one is on PATH. Mutagen's own
   sign-in registration is removed only where it starts this agent's copy.
@@ -594,11 +546,10 @@ whose it is.
   up to a week. A clone the bridge started, or one already shallow, takes the sandbox's shallow boundary
   (`--update-shallow`), so a shallow sandbox repo no longer leaves a whole refused pack behind on every pass. Leftovers
   older than an hour from an earlier agent are cleared once per process. Holds are in `status` and the report.
-- **A nearly full drive pauses folder sync** (2026-10-18, [`sync/low-disk.ts`](src/sync/low-disk.ts)). Every pass
-  measures the drive holding each folder whose session writes there (not a copy-first project, which only sends).
-  Under 2% of the drive, clamped to 5–20 GiB, the pairing's sessions and git bridge pause (`fileSyncLowDisk`); they
-  resume once the floor and 2 GiB more are free. While paused, no other pause's lifting resumes them, and the pause is
-  put back once a minute in case one did. `status` and the device card say why, with the numbers.
+- **A nearly full drive holds folder sync still** (2026-10-18, [`sync/low-disk.ts`](src/sync/low-disk.ts)). Every
+  pass measures the drive holding each folder whose session writes there (not a copy-first project, which only sends).
+  Under 2% of the drive, clamped to 5–20 GiB, the pairing's sync and git bridge hold still (`lowDisk`); they carry on
+  once the floor and 2 GiB more are free. `status` and the device card say why, with the numbers.
 - **Keys and enrollments per environment.** A newly made key is commented `<hostname>-<environment>`, so the sandbox
   files a new enrollment under that name. An existing key keeps its comment (a sandbox older than this agent would read
   a changed comment on the same key as a second machine holding sync); the sandbox tells existing ones apart by machine
@@ -606,7 +557,7 @@ whose it is.
 - **Tunnel ports per environment.** Under WSL's mirrored networking a distro's loopback is the Windows side's, so both
   sides pairing one sandbox derived one port twice. A distro now derives its ports in 20000-23999 from its name and the
   sandbox id; every native environment keeps 24000-27999 exactly as before, so nothing outside WSL moves.
-- **One folder, one sync, across the PC.** `setup` and `attach` read the other environments' `sync.json` (from the
+- **One folder, one sync, across the PC.** `setup` reads the other environments' `sync.json` (from the
   Windows side each supervised distro's through `wsl.exe -d <distro> cat`; from a distro the Windows side's beside its
   agent) and compare after one spelling: `C:\code\app` and `/mnt/c/code/app` are `drive:c/code/app`, and
   `\\wsl.localhost\Ubuntu\home\ada\app` and Ubuntu's `/home/ada/app` are `wsl:ubuntu/home/ada/app`. An overlap is refused
@@ -641,12 +592,33 @@ whose it is.
   each side's sandboxes to that side, a sandbox made from WSL had nobody backing it up, preparing its update or tidying
   after it, so each environment now runs them for its own. Both back off from a slug that keeps failing, as auto-prepare does, and each has its switch
   beside the update ones (`intentic-machine updates --backups off`, `--tidy off`).
-- **File sync holds still while its sandbox is swapped here** ([`sync/swap-pause.ts`](src/sync/swap-pause.ts)). A
+- **File sync holds still while its sandbox is swapped here** ([`sync/holds.ts`](src/sync/holds.ts) `holdsSync`). A
   pairing's local slug is the first label of its sandbox's public hostname (what ic names a sandbox with one) or the
-  id in it (what ic names one from its connect token), so the mapping is exact. Its sessions are paused through the
-  cutover and the first quarter hour of probation, and past that while the sandbox does not answer, then resumed; a
-  pause somebody made is left alone. Only this environment's records count: a distro syncing a sandbox the Windows side
-  swaps is not paused.
+  id in it (what ic names one from its connect token), so the mapping is exact. Its sync holds still through the
+  cutover and the first quarter hour after the cutover began, and past that while ic still watches the swap and the
+  sandbox does not answer. The quarter hour is measured from the pairing's own `swapSince`, the cutover's start as ic
+  recorded it, so it lasts after ic lets its record of the swap go. (2026-10-20: a swap with no probation, such as the dev
+  loop, leaves no record seconds after its cutover, and a hold read off the record alone let go after about thirty
+  seconds. Giving ic's record a longer life was rejected: the hold is the agent's fact, and ic's record answers whether a
+  swap is going on.) A later swap of the same sandbox starts the quarter hour again. Only this environment's records
+  count: a distro syncing a sandbox the Windows side swaps is not held.
+- **File sync runs or holds still by one rule** (2026-10-20, [`sync/holds.ts`](src/sync/holds.ts)). Eight facts on a
+  pairing hold its sync still: the owner's `sync pause` (`ownerPausedAt`), the sandbox said to be gone (`goneSince`),
+  its container away or in ic's trash (`containerAway`), a swap (`swapSince`), an hour without an answer
+  (`unreachableSince`), a nearly full drive (`lowDisk`), and a bring-back, restore or delivery writing into the folder
+  (`transferSince`, 2026-10-21; that operation also pauses its session itself, at once, before it writes). Each is kept
+  by the one rule that observes it, and none of
+  them touches Mutagen. Every pass, after the rules have run, `holdSessions` reads every session in one listing and
+  makes Mutagen agree: what runs while anything holds it is paused, and what is paused while nothing does is resumed,
+  one session per call and read back (`resumeSessions`), tried again each pass until Mutagen took it. A session is made
+  paused while its pairing is held. `sync resume` lifts the owner's pause alone and says what else still holds it; the
+  report carries the holds as `heldBy`, so a page offers Resume only for the owner's pause. Before this, each reason
+  paused and resumed Mutagen itself behind a marker of its own (`fileSyncAutoPaused`, `fileSyncSwapPaused`,
+  `fileSyncPausedFor`, `fileSyncLowDisk`, translated on read into the facts above), set only when it found the session
+  running, and a person's pause had no record at all. A marker cleared before the resume took (fair-moth, 2026-10-19),
+  one a reattach dropped (swift-cedar, 2026-10-17), or a pause another reason found in place left sync paused with
+  nothing to lift it, or lifted one somebody still meant. The first pass of this build takes every paused session no
+  fact explains as the owner's, once (`sync-owner-pauses-adopted`).
 - (2026-10-15) **Nothing downloaded replaces a binary until the release vouches for it**
   ([`release-verify.ts`](src/release/release-verify.ts)). Before an upgrade runs the new agent (and the Windows launcher
   beside it), before ic is put in place ([`tools/ic-binary.ts`](src/device/tools/ic-binary.ts)), and before setup
@@ -766,10 +738,19 @@ The keeper now puts an unneeded sandbox to sleep and wakes it when somebody open
 - **Wake.** The platform never calls a machine. A browser that finds the sandbox asleep asks the platform to wake it,
   and this agent's wake round asks the platform for such requests (`ic sandbox wakes --json --source agent`, one request
   for every sleeper on this side, each under its own report key), starting each one asked for through `ic sandbox
-  start`. It asks every fifteen seconds while anything sleeps, and every five minutes otherwise, to catch a sleep made
-  by hand. It runs whatever the keeper's switch says, so a sandbox asleep when the keeper was switched off still wakes.
+  start`. While anything sleeps the ask is held (2026-10-19): `--wait 25` has the platform answer the moment somebody
+  asks for a wake, or after 25 s, and the next ask follows at once, so a wake no longer waits up to fifteen seconds for
+  the next poll. An ic or a platform from before the held ask is asked every fifteen seconds as before; an ic that
+  refuses the flag (clap's exit 2, no JSON) is asked again at once without it, and plainly for an hour. With nothing
+  asleep it asks every five minutes, to catch a sleep made by hand. It runs whatever the keeper's switch says, so a
+  sandbox asleep when the keeper was switched off still wakes.
   The desktop app on the same computer runs the same command the moment its workspace page has asked
   (`--source app`, the app's `sandbox_wakes.rs`), so a sandbox opened there need not wait for this round.
+- **The link comes back with it** (2026-10-19). A sleep leaves this agent's link to the sandbox on its dial ladder,
+  which after twenty failures rests a quarter of an hour between tries: on rog a sandbox woken at 16:48 had its device
+  tools back at 17:12. Each start is acted on as ic prints it, and every link naming the slug is dialled at once and put
+  back on the ladder's first rung (peer-dial's `retryNow`); so is a sandbox somebody else woke, once ic counts nothing
+  asleep or the keeper's next listing shows it running.
 - **The setting** is this environment's `sandboxSleepMinutes` in `machine.json`: absent means 30, `0` means never. Set
   it with `intentic-machine sandbox sleep-after <minutes|off>` and read it with `sleep-after status`. One sandbox can
   be kept awake from its own editor instead (Overview, "Sleep when unused", settings `sleepWhenUnused`, 2026-10-18):
@@ -869,16 +850,28 @@ version, file time) and the `IC_*`/`INTENTIC_*` variables in the agent's environ
 
 ### The keyring
 
-[intentic-keyring](../keyring) is a process of its own beside this agent (2026-10-16): the agent installs it, keeps
-it running and relays to it, and holds no vault key and no value. `intentic-machine keyring setup` puts the
-`intentic-keyring` asset of this agent's own release into `bin/` (checked against the release's signed `SHA256SUMS`, as
-the launcher is; a from-source agent copies `_devices/keyring/dist-bin`'s build instead), makes `intentic-askpass` a
-hard link beside it, registers a login entry of its own (`keyring`, `IntenticKeyring` on Windows, running
-`intentic-keyring serve`), starts it, and sets up the vault with a passphrase typed twice without echo (or once on
-stdin with `--passphrase-stdin`), plus Windows Hello where there is one unless `--no-hello`. Nothing in the agent's
-own upgrade, its `bin/` sweep or its rollback touches the keyring's files: it moves to a new release only through
-`keyring upgrade`, which downloads and checks the new binary, asks the running keyring (which asks the person), and only
-then swaps it, keeping `.previous` and putting it back if the new one does not answer.
+[intentic-keyring](../keyring), the vault behind Passwords, is a process of its own beside this agent (2026-10-16):
+the agent installs it, keeps it running and relays to it, and holds no vault key and no value. Since 2026-10-19 it has
+one mode, the protected service: the vault is held by a system account of its own (`LOCAL SERVICE` from a startup task
+on Windows, the `intentic-keyring` user from the systemd unit `intentic-keyring@<uid>` on Linux), and what starts at
+sign-in is its session helper. `intentic-machine keyring setup` puts the `intentic-keyring` asset of this agent's own
+release into `bin/` (checked against the release's signed `SHA256SUMS`, as the launcher is; a from-source agent copies
+`_devices/keyring/dist-bin`'s build instead), makes `intentic-askpass` a hard link beside it, asks for an
+administrator's yes once (UAC on Windows, `pkexec` on Linux) to run `intentic-keyring service install`, registers the
+helper's login entry (`keyring`, `IntenticKeyring` on Windows, running `intentic-keyring session`), starts it, and sets
+up the vault: it generates a recovery key (six groups of five Crockford base32 characters, 150 bits), sends it as the
+setup op's `passphrase`, and prints it once; it is never stored. Windows Hello is enrolled through the helper unless
+`--no-hello`; on Linux the daily unlock is a polkit yes. Without the administrator's yes setup stops with `declined`
+and "Passwords needs an administrator's approval once…", having changed nothing; on macOS, or a Linux without
+systemd, polkit or setfacl, it stops with `unavailable` before installing anything. A computer still on the per-user
+keyring from before (`intentic-keyring serve`, retired) is moved by `setup` or `upgrade`: the old keyring is stopped,
+`service install` carries `~/.intentic/keyring/vault.json` and its files into the service's folder, and the login entry
+becomes the helper's. Its old passphrase still opens it where the recovery key would.
+
+Nothing in the agent's own upgrade, its `bin/` sweep or its rollback touches the keyring's files: it moves to a new
+release only through `keyring upgrade`, which downloads and checks the new binary, asks the running keyring (which asks
+the person), and only then swaps it, keeping `.previous` and putting it back if the new one does not answer; the new
+binary's `service install` then runs as an administrator, so the service's own copy follows.
 
 - **Relayed for the sandbox** ([`keyring/relay.ts`](src/keyring/relay.ts)): the contract's `keyring*` procedures go
   to the keyring's pipe and back, with the sandbox named from the link the call came in on (`shares`, `copies`) and an
@@ -890,12 +883,9 @@ then swaps it, keeping `.previous` and putting it back if the new one does not a
   1.5 s, the answer kept for 30 s ([`keyring/feature.ts`](src/keyring/feature.ts)).
 - **Marked**: what `run_command` and `app_start` start carries `INTENTIC_AGENT_COMMAND=1`, for the keyring's record
   and prompts. A hint, not a boundary: the agent's command can unset it.
-- **Hardened** (Windows, `keyring harden`): the plain keyring is stopped and its login entry removed first, so the
-  vault the service takes is the last one written; then one UAC prompt runs `intentic-keyring service install`, which
-  moves the vault under the startup task that runs the keyring as `LOCAL SERVICE` (the keyring's README says how), and
-  the login entry becomes `intentic-keyring session`. Hardened mode is read from the marker the install writes for this
-  user (`%ProgramData%\Intentic\Keyring\<SID>.hardened`). `keyring upgrade` on a hardened keyring also runs the new
-  binary's `service install`, elevated, so the service's own copy follows.
+- **Installed** is read from the marker `service install` writes for this user, which every user may read:
+  `%ProgramData%\Intentic\Keyring\<SID>.hardened` on Windows (named from when the service was an optional "hardened
+  mode"), `/var/lib/intentic-keyring/<uid>.installed` on Linux ([`keyring/service.ts`](src/keyring/service.ts)).
 - `status` and `doctor` show one keyring row (not installed, not running, not set up, locked or unlocked), and
   `status --json` and `doctor --json` carry it as `keyring: { installed, running, setUp, locked?, unlockedUntil?, version? }`.
 
@@ -906,8 +896,8 @@ it reaches the pipe.
 
 | Command | Success output |
 |---|---|
-| `keyring setup [--passphrase-stdin] [--no-hello]` | `{ "ok": true, "path", "askpass": { "installed", "path"? }, "autostart", "setUp": true, "alreadySetUp", "state"? }` |
-| `keyring status` | `{ "ok": true, "installed", "running", "setUp", "state"?, "askpass": { "installed", "path"? }, "hardened" }` |
+| `keyring setup [--no-hello]` | `{ "ok": true, "path", "askpass": { "installed", "path"? }, "autostart", "setUp": true, "alreadySetUp", "recoveryKey"?, "state"? }` (`recoveryKey` only when this run made the vault) |
+| `keyring status` | `{ "ok": true, "installed", "running", "setUp", "state"?, "askpass": { "installed", "path"? }, "support": { "canSetUp", "why"?, "hello", "platform" } }` |
 | `keyring unlock [--minutes N]` / `keyring lock` | `{ "ok": true, "unlockedUntil" }` / `{ "ok": true }` |
 | `keyring list` | `{ "ok": true, "entries": [EntryInfo], "backends" }` |
 | `keyring add NAME [--stdin] [rules] [--backend B --ref R [--field F] [--attribute A]] [--replace]` | `{ "ok": true, "name" }` |
@@ -919,8 +909,7 @@ it reaches the pipe.
 | `keyring askpass install\|uninstall\|status` | `{ "ok": true, "installed", "path"?, "variables", "file"?, "profile"? }` |
 | `keyring sync status` | `{ "ok": true, "sync": { "key", "peers", "revision" } }` |
 | `keyring upgrade` | `{ "ok": true, "upgraded", "from", "to" }` |
-| `keyring harden` (Windows) | `{ "ok": true, "service": "IntenticKeyring", "autostart" }` |
-| `keyring uninstall` | `{ "ok": true, "removed", "vault", "hardened" }` |
+| `keyring uninstall` | `{ "ok": true, "removed", "vault", "service" }` |
 
 The rule flags are `--kind password|text`, `--program P`, `--package P`, `--host H`, `--askpass M` (each repeatable;
 on `edit` a list flag replaces the whole list, and a lone `""` empties it), `--username U`, `--remember-minutes N`, and
@@ -928,17 +917,59 @@ on `edit` a list flag replaces the whole list, and a lone `""` empties it), `--u
 value. `askpass install` sets `SSH_ASKPASS`, `SSH_ASKPASS_REQUIRE=prefer`, `SUDO_ASKPASS` and `GIT_ASKPASS` for the
 user: through `[Environment]::SetEnvironmentVariable` on Windows, and on Linux and macOS in
 `~/.config/environment.d/intentic-askpass.conf`, printing the `export` lines a shell profile needs. `keyring
-uninstall` keeps the vault in `~/.intentic/keyring`.
+uninstall` removes the service (an administrator's yes) and puts the vault back in `~/.intentic/keyring`, where it
+stays; set up again, the same recovery key opens it.
+
+### Uninstall
+
+`intentic-machine uninstall [--purge] [--delete-data]` ([`src/uninstall/`](src/uninstall/)). `ic uninstall` is the one
+orchestrator of a whole-device uninstall and runs `--purge` here; the agent's own command is the same removal for a
+person who runs it alone, and either way it never downloads anything.
+
+- **No flag**: every sandbox link, every sync pairing and the login entry go, as they always have. The agent goes even
+  from a device that hosts sandboxes; on Windows it keeps running while WSL distros are attached, to keep them running.
+- **`--purge`**: everything of the agent leaves this environment, in this order:
+  1. On Windows, each WSL distro in `machine.json` is purged through its own agent (`wsl.exe`, five minutes at most
+     each; an agent older than `--purge` takes the plain uninstall, and the warning says how to finish), and the list
+     is emptied, so nothing is left for the Windows side's agent to keep running for.
+  2. On Linux and macOS the binary is renamed to `bin/intentic-machine.uninstalling` before anything stops the agent.
+     The Windows side restarts a stopped distro agent a second later through a script that exits 64 when the binary is
+     missing, and then drops that distro from its list, so a purged distro does not come back.
+  3. The programs sandboxes started with `app_start` are stopped, from every sandbox's `runs/<sandbox>/apps.json`.
+  4. The plain uninstall runs (links, pairings, the login entry). Mutagen is the agent's own copy in `bin/` or none: a
+     missing copy skips the session steps instead of downloading one.
+  5. Windows' start before sign-in is removed (Windows asks for permission), and the resident agent is stopped with its
+     login entry whatever it still served.
+  6. The agent's Mutagen daemon is stopped and the ssh include removed, in case the sync step stopped early.
+  7. The keyring goes with askpass (`keyring uninstall`). Its protected service needs an administrator's yes. If it is
+     declined, the service stays, and so do `bin/` and the PATH entry, so the purge can be run again to finish it.
+  8. What the agents before this one left goes: the `intentic-host` and `intentic-sync-mirror` login entries,
+     `~/.intentic/host` and `~/.intentic/sync`, their `~/.local/bin` links, and the `intentic-link-watch` timer.
+  9. The PATH entry goes: `bin` out of the per-user PATH on Windows (`removeFromWindowsPathValue`, written back under
+     the value's own kind), and the `~/.local/bin/intentic-machine` link where it points into `bin`.
+  10. Lingering is turned off only where the agent turned it on. local-agent writes `linger-enabled` beside the agent's
+      log the one time `loginctl enable-linger` changes it from off to on. Lingering the user had already stays.
+  11. The files go: `~/.intentic/machine` and `~/.intentic/keyring` except the person's data, then each folder once
+      empty, and `~/.intentic` once nothing is left in it. Everything else under `~/.intentic` is ic's and is never
+      touched. On Windows the running agent is moved to `%TEMP%` first, and a hidden PowerShell removes what was still
+      in use once this process has exited.
+- **The data that stays** without `--delete-data`: the keyring's `vault.json`, `keys.json` and `audit.jsonl*`;
+  `machine/restore`; `machine/audit.jsonl*`; and in `machine/trash` the folders `trash_file` made for files a sandbox
+  moved aside on this device (named for the moment alone; the upkeep's own trash entries go). The narration says what
+  stayed and why.
+- **`--delete-data`** implies `--purge` and removes the data too.
+- A step that does not finish is a warning with the command that finishes it by hand (`fix:` on its own line), and the
+  verdict counts them. The run fails, exit 1, only when the agent is still running or its files could not be removed.
 
 ## Key files
 
 - [src/commands.ts](src/commands.ts) — the CLI: `device`, `sync`, `keyring`, `sandbox`, `run`, `status`, `doctor`, `upgrade`, `updates`, `uninstall`.
+- [src/uninstall/purge.ts](src/uninstall/purge.ts) — `uninstall --purge`: the steps in `steps.ts`, the distros in `distros.ts`, the files in `sweep.ts`, every decision pure in `plan.ts`.
 - [src/resident/resident.ts](src/resident/resident.ts) — the resident process that holds links, pairings and WSL distros; `supervision.ts` beside it starts and stops it through whatever restarts this environment's agent.
 - [src/device/mcp.ts](src/device/mcp.ts) — every tool a sandbox can call on this device.
 - [src/device/policy.ts](src/device/policy.ts) — scope checks and the file-root boundary.
 - [src/sync/endpoint.ts](src/sync/endpoint.ts) — how a pairing reaches its sandbox: the tunnelled sshd (`tunnel.ts`), or Docker for a project on this machine.
-- [src/sync/attach-commands.ts](src/sync/attach-commands.ts) — `sync attach` and `sync detach`, folders on this computer's own sandbox.
-- [src/sync/project/project-delivery.ts](src/sync/project/project-delivery.ts) — landed work written into an attached folder (`deliverProject`).
+- [src/sync/project/project-delivery.ts](src/sync/project/project-delivery.ts) — landed work written into a project folder (`deliverProject`).
 - [src/sync/gone.ts](src/sync/gone.ts) — when a paired sandbox counts as gone; `gone-watch.ts` acts on it, `retire.ts` retires its pairings, `forget-command.ts` is `sync forget`.
 - [src/environments/machine.ts](src/environments/machine.ts) — the Windows root and its WSL children.
 - [src/upkeep/manifest.ts](src/upkeep/manifest.ts) — what the device upkeep finds and puts right; `reconcile.ts` runs it.

package/dist/autostart/autostart.d.ts

@@ -1,5 +1,4 @@
 import type { AutostartSpec } from "@intentic/local-agent";
 export declare const MACHINE_AUTOSTART: AutostartSpec;
 export declare const KEYRING_AUTOSTART: AutostartSpec;
-export declare const KEYRING_SESSION_AUTOSTART: AutostartSpec;
 //# sourceMappingURL=autostart.d.ts.map

package/dist/autostart/autostart.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"autostart.d.ts","sourceRoot":"","sources":["../../src/autostart/autostart.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,uBAAuB,CAAC;AAM3D,eAAO,MAAM,iBAAiB,EAAE,aAc/B,CAAC;AAOF,eAAO,MAAM,iBAAiB,EAAE,aAW/B,CAAC;AAIF,eAAO,MAAM,yBAAyB,EAAE,aAKvC,CAAC"}
+{"version":3,"file":"autostart.d.ts","sourceRoot":"","sources":["../../src/autostart/autostart.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,aAAa,EAAE,MAAM,uBAAuB,CAAC;AAM3D,eAAO,MAAM,iBAAiB,EAAE,aAc/B,CAAC;AASF,eAAO,MAAM,iBAAiB,EAAE,aAW/B,CAAC"}

package/dist/autostart/autostart.js

@@ -16,18 +16,12 @@ const keyringLog = keyringPaths().log;
 export const KEYRING_AUTOSTART = {
     id: "keyring",
     windowsRunValue: "IntenticKeyring",
-    desktopName: "Intentic Keyring",
-    desktopComment: "The password vault on this computer: types and hands over secrets for your intentic sandboxes, at your word",
+    desktopName: "Intentic Passwords",
+    desktopComment: "Passwords on this computer: its prompts and typing on this desktop, for the protected service that holds the vault",
     logPath: keyringLog,
     launchAgent: { label: "dev.intentic.keyring" },
-    detachedArgs: ["serve"],
-    foregroundArgs: ["serve"],
-    failureNote: (reason) => `Couldn't register the keyring to start at login (${reason}); it runs until this computer restarts, and \`intentic-machine keyring setup\` starts it again. Its log is ${keyringLog}.`,
-};
-export const KEYRING_SESSION_AUTOSTART = {
-    ...KEYRING_AUTOSTART,
-    desktopComment: "The intentic keyring's prompts and typing on this desktop, for the IntenticKeyring service that holds the vault",
     detachedArgs: ["session"],
     foregroundArgs: ["session"],
+    failureNote: (reason) => `Couldn't register Passwords to start at login (${reason}); it runs until this computer restarts, and \`intentic-machine keyring setup\` starts it again. Its log is ${keyringLog}.`,
 };
 //# sourceMappingURL=autostart.js.map

package/dist/autostart/autostart.js.map

@@ -1 +1 @@
-{"version":3,"file":"autostart.js","sourceRoot":"","sources":["../../src/autostart/autostart.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,MAAM,mBAAmB,CAAC;AAEjD,OAAO,EAAE,UAAU,EAAE,MAAM,cAAc,CAAC;AAK1C,MAAM,CAAC,MAAM,iBAAiB,GAAkB;IAC5C,EAAE,EAAE,kBAAkB;IACtB,eAAe,EAAE,iBAAiB;IAClC,WAAW,EAAE,wBAAwB;IACrC,cAAc,EAAE,yFAAyF;IAEzG,OAAO,EAAE,UAAU;IACnB,WAAW,EAAE,EAAE,KAAK,EAAE,sBAAsB,EAAE;IAC9C,YAAY,EAAE,CAAC,KAAK,CAAC;IACrB,cAAc,EAAE,CAAC,KAAK,EAAE,cAAc,CAAC;IAEvC,gBAAgB,EAAE,CAAC,KAAK,EAAE,cAAc,EAAE,kBAAkB,CAAC;IAC7D,WAAW,EAAE,CAAC,MAAM,EAAE,EAAE,CACpB,4DAA4D,MAAM,iGAAiG,UAAU,GAAG;CACvL,CAAC;AAKF,MAAM,UAAU,GAAG,YAAY,EAAE,CAAC,GAAG,CAAC;AAEtC,MAAM,CAAC,MAAM,iBAAiB,GAAkB;IAC5C,EAAE,EAAE,SAAS;IACb,eAAe,EAAE,iBAAiB;IAClC,WAAW,EAAE,kBAAkB;IAC/B,cAAc,EAAE,6GAA6G;IAC7H,OAAO,EAAE,UAAU;IACnB,WAAW,EAAE,EAAE,KAAK,EAAE,sBAAsB,EAAE;IAC9C,YAAY,EAAE,CAAC,OAAO,CAAC;IACvB,cAAc,EAAE,CAAC,OAAO,CAAC;IACzB,WAAW,EAAE,CAAC,MAAM,EAAE,EAAE,CACpB,oDAAoD,MAAM,+GAA+G,UAAU,GAAG;CAC7L,CAAC;AAIF,MAAM,CAAC,MAAM,yBAAyB,GAAkB;IACpD,GAAG,iBAAiB;IACpB,cAAc,EAAE,iHAAiH;IACjI,YAAY,EAAE,CAAC,SAAS,CAAC;IACzB,cAAc,EAAE,CAAC,SAAS,CAAC;CAC9B,CAAC"}
+{"version":3,"file":"autostart.js","sourceRoot":"","sources":["../../src/autostart/autostart.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,YAAY,EAAE,MAAM,mBAAmB,CAAC;AAEjD,OAAO,EAAE,UAAU,EAAE,MAAM,cAAc,CAAC;AAK1C,MAAM,CAAC,MAAM,iBAAiB,GAAkB;IAC5C,EAAE,EAAE,kBAAkB;IACtB,eAAe,EAAE,iBAAiB;IAClC,WAAW,EAAE,wBAAwB;IACrC,cAAc,EAAE,yFAAyF;IAEzG,OAAO,EAAE,UAAU;IACnB,WAAW,EAAE,EAAE,KAAK,EAAE,sBAAsB,EAAE;IAC9C,YAAY,EAAE,CAAC,KAAK,CAAC;IACrB,cAAc,EAAE,CAAC,KAAK,EAAE,cAAc,CAAC;IAEvC,gBAAgB,EAAE,CAAC,KAAK,EAAE,cAAc,EAAE,kBAAkB,CAAC;IAC7D,WAAW,EAAE,CAAC,MAAM,EAAE,EAAE,CACpB,4DAA4D,MAAM,iGAAiG,UAAU,GAAG;CACvL,CAAC;AAOF,MAAM,UAAU,GAAG,YAAY,EAAE,CAAC,GAAG,CAAC;AAEtC,MAAM,CAAC,MAAM,iBAAiB,GAAkB;IAC5C,EAAE,EAAE,SAAS;IACb,eAAe,EAAE,iBAAiB;IAClC,WAAW,EAAE,oBAAoB;IACjC,cAAc,EAAE,oHAAoH;IACpI,OAAO,EAAE,UAAU;IACnB,WAAW,EAAE,EAAE,KAAK,EAAE,sBAAsB,EAAE;IAC9C,YAAY,EAAE,CAAC,SAAS,CAAC;IACzB,cAAc,EAAE,CAAC,SAAS,CAAC;IAC3B,WAAW,EAAE,CAAC,MAAM,EAAE,EAAE,CACpB,kDAAkD,MAAM,+GAA+G,UAAU,GAAG;CAC3L,CAAC"}

package/dist/commands.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"commands.d.ts","sourceRoot":"","sources":["../src/commands.ts"],"names":[],"mappings":"AACA,OAAO,EAAiB,KAAK,cAAc,EAAE,MAAM,eAAe,CAAC;AA0JnE,eAAO,MAAM,QAAQ,kDA4BnB,CAAC"}
+{"version":3,"file":"commands.d.ts","sourceRoot":"","sources":["../src/commands.ts"],"names":[],"mappings":"AACA,OAAO,EAAiB,KAAK,cAAc,EAAE,MAAM,eAAe,CAAC;AAsInE,eAAO,MAAM,QAAQ,kDA4BnB,CAAC"}