@shardflux/cli 0.25.0 → 0.28.1

package/CHANGELOG.md

@@ -2,6 +2,158 @@
 
 ## Unreleased
 
+- The Shardflux app 0.9.2 (0.28.1+): `shard` installs and updates `@shardflux/desktop-darwin-arm64` / `-x64` and
+  `@shardflux/desktop-linux-x64` / `-arm64` 0.9.2 (Stop in ⌘1, organization choice at the first sign-in, Sign in after
+  signing out).
+
+- Return the coding-agent setup guide without loading the account command handlers.
+
+- Manual landing uses the result’s own ready computer or the persistent project reader, so deleting an unrelated thread does not interrupt it.
+
+- Check T3 presence directly during startup, avoiding unrelated desktop-app probes before every command.
+
+- Orchestrator inputs preserve long pastes, including their final instruction, without an application character cap. `shard orchestrator say` sends the full text to the API.
+
+- Land a finished conversation in its own repository's linked folder when a project holds several repositories.
+  Preserve the hub's default branch when it belongs to another repository.
+
+- Load only the selected command and skip optional setup modules when their local state is absent.
+
+
+- Load interactive command surfaces on demand, keeping help/version and simple commands fast while preserving command parsing, saved-work housekeeping, setup guards and install registration.
+
+- Codex Cloud admission (0.28.1+, SDK 0.30.1): a stopped startup/open reports its stored reason and recovery instruction immediately (`codex_admission_stopped`), instead of calling it pending or pointing only at connector status.
+
+- Stored-file recovery (0.28.1+): workspace views show when files are saved for recovery; resume restarts the workspace from those files.
+
+- `shard orchestrator say` (0.28.0+, SDK 0.30.0): every input waits its turn in order,
+  however many wait (no more 429), and one of your orchestrator's threads hears each input at once, all in parallel: a
+  follow-up reaches the thread of the request it is about (the input reads merged), the row you point at reaches the
+  thread of that row's input, and anything new gets a thread of its own. The help text says so.
+- Your inbox on every device (0.28.0+, SDK 0.30.0): `shard conversations archive <id...>` archives conversations from
+  your own inbox, `shard conversations unarchive <id...>` brings them back and `shard conversations seen <id...>` records
+  that you opened them now, the same in the Shardflux app and every client you use (`shard c archive|unarchive|seen`).
+  Each takes up to 200 ids in one request and prints `Archived <id>  <title>`, `Unarchived <id>  <title>` or
+  `Marked seen <id>  <title>` per conversation, and `Not found: <id>` on stderr for an id you cannot read; it exits 3
+  when none was found. `--json` prints the API's answer, `{data, skipped}`, the conversations with your `seen_at` and
+  `dismissed_at`. Only your view changes: the conversations, their agents and computers carry on. `shard conversations
+  get --json` and `list --json` carry the same `seen_at`, `dismissed_at` and `needs_you_reason`.
+- Restore an orchestrator input (0.28.0+, SDK 0.30.0): `shard orchestrator restore <input-id>` brings an input you
+  dismissed back into `shard orchestrator list` on every device and prints `Restored: <your words>` (`--json`:
+  `{input}`). Restoring an input that is not dismissed changes nothing.
+- Orchestrator answer media (0.28.0+, SDK 0.29.0): `shard orchestrator say --wait` prints a line for each picture,
+  video or file the answer shows, after its points: `  media: loss-curve.png (image, 1200×800, 84.0 KB)` (the size in
+  pixels once measured). `--json` adds the answer's `media`; `shard drive get <file.path> --sha256 <file.sha256>` reads
+  one.
+
+- Orchestrator report cards (0.28.0+, SDK 0.29.0): `shard orchestrator say --wait` prints an answer the orchestrator
+  wrote as a report as its verdict, then its points under their group headings, one line each:
+  `- Loss is down to 1.84: from 2.31 at step 5,000 (14:02)`, the time short and in this computer's local time; a point
+  written without a lead prints its words. Every point, source and follow-up prints whole, however long. An answer
+  written as facts prints its facts as before. `--json` adds the answer's `points`.
+
+- Board content at any length (0.28.0+, SDK 0.29.0): `shard task show` prints a task's title, its plan steps and each
+  report's title and outcome whole, however long the agent wrote them (the terminal wraps them); `shard task edit
+  --title` takes a title of any length.
+
+- Your brain (0.28.0+, SDK 0.29.0): `shard brain ls [prefix]` lists your brain's files (size, saved time, type and
+  path; `--all`, `--limit`, `--cursor`; `--json` adds `next_cursor` and the brain's `version`) and `shard brain get
+  <path>` writes a file's bytes to standard output, to a file with `-o`, or as `--json` (`--sha256` reads exactly that
+  version). Your brain is your archive in an organization, kept by your orchestrator: its published answers as
+  `reports/<YYYY-MM-DD>/<folder>/report.md` with their media, its own notes and files, and `index.md`. Signed in it is
+  your brain in the saved organization, your only one, or `--org <id|slug>`; with `SHARDFLUX_API_KEY`, the brain of the
+  person who created the key.
+- 0.28.0: shard files delete removes a file or, with --recursive, a directory through the files API; disk-full errors give cleanup guidance without a retry loop.
+- Hung checkpoint recovery: `guest_unresponsive` identifies a cold boot after bounded restore readiness failures. Retained files are kept; memory is not restored and processes restart. Conversation moves can use their last durable copy after a bounded source restore failure; the newer source disk stays kept under its retention policy.
+
+- A linked folder's start point (0.28.0+): when an agent links a folder of yours (a device's
+  `project_link`), the folder as it is now (its commit, uncommitted files as a snapshot on top) goes to the project hub
+  under `refs/shard/seed/link-<folder>`, and the link's result names that `commit` and the folder's `branch`. A task can
+  then name exactly where its work starts, and its agent starts there with no conversation of that folder yet. Linking
+  from the app or `shard projects link` copies nothing to the hub. An API without the fields takes the link without them.
+
+- Landing per repository (0.28.0+): a project holds every folder its people linked, so a task's result lands only in a
+  folder of the repository it was started from (its workers' `repo_remote`). When the project hub's default branch is
+  another repository's, the result lands in its own folder and the hub's default branch stays as it is; with no folder
+  of that repository on this computer it answers `land_unrelated`.
+
+- A result from another repository (0.28.0+): `shard task land` and `shard conversations land` answer `land_unrelated`
+  when the result has no history in common with the branch it lands in (it was started from another repository than
+  the one that branch holds, or two of its workers were), with what to do instead; nothing moves on the project hub or
+  in your folder. It was a Git error ("refusing to merge unrelated histories") that read as if trying again could help.
+
+- Auto land switch (0.28.0+): `shard settings --auto-land on|off` turns automatic landing on or off for every project
+  on this computer (on by default). Off, the live twin lands no conversation and new conversations start from your
+  HEAD; `shard task land` and `shard conversations land` still land on request. `shard settings` shows it and `--json`
+  adds `auto_land`. The Shardflux app reads the same switch to land finished board tasks with no click.
+
+- Message delivery (0.28.0+, SDK 0.29.0): `shard conversations send` reaches a working agent in its running turn
+  (Claude Code, Codex and Codex Cloud) and starts an idle one's next turn; its help says so instead of "next turn".
+  `--wait` waits up to 60 s and prints what happened: `Steered into the running turn.`, `Started the next turn.` or
+  `Not delivered yet.` (`Delivery not confirmed yet: …` when Codex Cloud has not confirmed it); `--json` adds
+  `delivery`. Without `--wait` the output stays `Message sent (<seq>).`
+
+- One Shardflux app (0.28.0+): `shard` installs and updates the one desktop app (menu bar or tray, onboarding,
+  launcher, conversations with their computers, device approvals, one Settings window) from
+  `@shardflux/desktop-darwin-arm64` / `-x64` 0.9.0 on macOS (replacing `@shardflux/menubar-darwin`) and from
+  `@shardflux/desktop-linux-x64` / `-arm64` 0.9.0 on Linux (replacing the GTK tray app), at the same places as before
+  (`~/Applications/Shardflux.app`, `~/.local/share/shardflux/desktop`). It keeps the menu bar app's bundle id,
+  executable and signature, so `shard menubar start|stop|status|--login` and the running app's own update work
+  unchanged, and its first start retires the apps it replaces, keeping where each agent's conversations open (the
+  places `agents targets --open-in` saved) and, on Linux, the tray app's settings. The Linux autostart entry starts it with `--background`
+  (tray icon only). The launcher shortcut lines read the app's own choice (`desktop-app.json`). `shard update` lists it
+  as "Shardflux app". Retired: the CGWindowList window probe used for menu bar apps before 0.3.2.
+  On Linux the running app is found by its executable (`/proc/<pid>/exe`): Electron rewrites its command line, so
+  `shard menubar start|stop|status` and the refresh no longer miss it; the library check probes the Electron
+  executable behind the app's launcher and names each library the computer is missing.
+- 0.27.0 includes the changes prepared as 0.26.0 (not released on its own): the entries marked 0.27.0 below.
+
+- Device registration (0.28.0+): isolate each project, back off transient failures and stop after eight attempts with
+  an actionable needs-attention message. A device id another sign-in registered (the API key `shard setup` replaced,
+  or another account) is replaced by a new one (at most once every 10 minutes), with one line in the helper's log, and every project
+  registers again at once, so your agents reach this computer without a restart. The old id is kept in
+  `device-id-history.json`.
+- Your agents on this computer (0.28.0+): `shard device approvals auto|read|ask` chooses how this computer answers
+  your own agents: `auto` runs everything they ask without asking, `read` runs folder listings and files copied to a
+  conversation and asks before anything else (commands, files saved here, ports, linking a folder), `ask` asks every
+  time. The first request asks for the choice (the Shardflux app's prompt; without the app, `shard` prints the two
+  commands once) and runs under the mode chosen. A teammate's request always asks. What ran without asking is listed
+  by `shard device approvals` (`--json`: `recent`) and the app's Settings. Approvals carry `choose_mode: true` while
+  nothing is chosen.
+- First prompts (0.28.0+): a Codex Cloud start queues its initial prompt while the executor prepares. Resuming an accepted start uses the same prompt key; an unconfirmed send keeps its created conversation.
+
+- Device helper (0.28.0+): a command your orchestrator asks your computer to run (a home conversation, so no folder of
+  it on this computer) asks you once with the exact command and folder ("Run on your Mac: sh -c tail -n 5 train.log ·
+  in ~/code/lm-train"), Allow once or Deny, and runs in your home folder or the ~/ folder it names. A request whose
+  conversation has no folder on this computer is refused with the reason instead of staying pending.
+- Filesystem recovery (0.28.0+): resume JSON/timing keeps `cold_boot_reason: guest_filesystem`; the existing note reports restarted processes. Ships with SDK 0.29.0.
+
+- Admission queue waits (0.28.0+, SDK 0.29.0): workspace opens retry `429 admission_queued` within the admission timeout with the same body/key, honor full `Retry-After`, and display `queued for admission; retrying in 2 s` while waiting.
+- 0.27.0: workspace disk caps report the admitted and acknowledged size. Completed disk grows refresh the disk grant; resize results retain the original request.
+
+
+- `shard orchestrator` (0.28.0+, SDK 0.29.0): your orchestrator agent from a terminal. `shard orchestrator say <words>`
+  sends your exact words (`--task`, `--report`, `--needs-you`, `--input`, `--conversation` point at a row) and prints
+  the input id and its place in line; every input is handled in parallel by its own thread. `--wait` follows it until
+  it is done, merged, failed or waiting and prints its curated result: the answer's headline and facts with their
+  sources and follow-ups, the tasks it created, the line it waits on (a question names its `shard needs-you answer
+  oq_…` command), or the input it was added to; exit 6 when it failed, 5 when `--timeout` (default 10m) passed first.
+  `shard orchestrator list [--all]` shows your inputs newest first, one line each; `shard orchestrator retry
+  <input-id>` sends a failed one again and `shard orchestrator dismiss <input-id>` takes one out of the list. Signed in
+  they reach your orchestrator; with `SHARDFLUX_API_KEY`, the orchestrator of the person who created the key. `--json`
+  prints `{input}` / `{inputs, cursor}`.
+- `shard needs-you` (0.28.0+, SDK 0.29.0) lists your orchestrator's questions (`oq_…`, answered with `--text`) and what
+  it asked your computer while it was offline (`dev_…`, "Waiting for your computer: list ~/code"; `shard needs-you
+  answer dev_… cancel` drops it).
+- Deprecated (0.27.0): `shard route` (POST /v1/router) and `shard ask` (POST /v1/questions); use the orchestrator
+  instead (`shard orchestrator say`). Each prints a one-line notice on stderr.
+
+- `shard agents models` (0.28.0+): the models each active account can use, as Claude and ChatGPT list them for that
+  account (asked server side the way Claude Code and Codex fill their pickers; never starts a computer): effort levels
+  with the default starred, the default model, and unavailable models with the provider's reason. `--account <ref>`,
+  `--provider`, `--all`, `--refresh`; `--json` prints the API answer. `--model` on `shard agents new` (and `shard ./`)
+  also takes a model id from that list (`claude-fable-5-1`, `gpt-5.6-terra`) next to the aliases.
+
 - Device requests reach the right computer (0.25.0+): the background helper tells the API which conversations are
   local to this computer (started or opened here), so their requests come here first, then to the computer you used
   last, never to whichever was seen last. A project link with a first task (`project_link` with `brief`) reads the
@@ -11,7 +163,8 @@
   what each working step does, next to the plain waiting line of a task that waits to start.
 - `shard transcribe <file>` (0.25.0+, SDK 0.28.0) prints what a recording says (WebM/Opus or PCM WAV from the file;
   raw PCM with `--format pcm16 --sample-rate`); `--words` adds each word's start and end, `--json` prints the
-  transcript.
+  transcript. Where cloud transcription is not on for the organization it says so in one line
+  (`cloud_transcription_off`) and exits 1 (0.28.0+, SDK 0.29.0).
 - Faster conversation starts (0.24.1): the project's dependency fingerprint is read from Git's own file list instead of walking the whole folder, so ignored and untracked trees beside the project (agent worktrees, build output) no longer hold a start on **Getting your project…**. A folder with 1.2 million such files took 32 s per start; it now takes 0.3 s, with the same fingerprint.
 - A folder without Git that `shard` makes a repository of (a first chat, `shard projects link`) starts with its files as
   the first commit (0.25.0+; `.gitignore` respected, large media stay untracked), so a conversation starts from the