sliccy 6.93.0 → 6.94.1

package/README.md

@@ -75,7 +75,7 @@ SLICC is for you if:
 - **Add visual and file context directly in chat.** Drop images or files onto the workspace, or use the paperclip button. Dropped `.skill` archives still install into `/workspace/skills`.
 - **Inspect experimental features from the avatar menu.** When centrally managed flags enable the surface for the current runtime, click your avatar and choose **Experimental features…** to open its standalone dialog. The dialog may honestly be empty: `experimental-settings` controls its availability but is not itself user-toggleable.
 - **Steer a running turn instead of waiting for it.** In the chat composer, `Enter` sends — including from a hardware keyboard in the native iOS follower — and queues behind whatever the cone is already doing; `Shift+Enter` inserts a newline. `Ctrl+Enter` (`Cmd+Enter` on macOS) steers: the message is injected as soon as the current step finishes, so you can redirect the agent mid-turn.
-- **Boot full x86 virtual machines in the browser.** `v86 start` runs real operating systems (Alpine, FreeDOS, KolibriOS, ...) on the wasm-based [v86](https://github.com/copy/v86) emulator, entirely client-side. The agent drives the guest from the shell — type, click, screenshot, stream the screen live, save/restore state — and `-net <model>,relay=fetch` gives the guest HTTP access through SLICC's fetch proxy. Install with `ipk add v86`.
+- **Boot full x86 virtual machines in the browser.** `v86 start` runs real operating systems (Alpine, FreeDOS, KolibriOS, ...) on the wasm-based [v86](https://github.com/copy/v86) emulator, entirely client-side. The agent drives the guest from the shell — type, click, screenshot, stream the screen live, save/restore state — and `-net <model>,relay=fetch` gives the guest HTTP access through SLICC's fetch proxy. Install with `ipk add -g v86`.
 - **Delegate parallel work to scoops.** Split tasks into isolated sub-agents with their own sandboxes and context, then let the main agent coordinate the results.
 - **Turn one-off wins into reusable workflows.** Package behavior as skills, build interactive sprinkles, and react to external events with webhooks and cron-driven licks.
 - **Mount your local file system.** By default, SLICC is confined to your browser. But you can ask it to mount folders from your local file system, so it can read and write from there. Mount into an empty path such as `/mnt/myproject` so you do not hide existing skills or scripts. Picker mounts ask again after a page reload; for folders you always want available, map them in the launcher's mount table (`npx slicc --mount=~/Projects/foo:/mnt/foo`, or Settings → Mounts in Sliccstart.app) and they are mounted automatically on every launch, with no picker or permission prompt — see [Auto-mounted host folders](docs/mounts.md#auto-mounted-host-folders-the-mount-table).
@@ -174,7 +174,7 @@ SLICC shares one core across every runtime ("float"). The browser is not just wh
 
 Once the product makes sense, the ice-cream language is easier to enjoy: it maps to real architecture, not just mascot energy.
 
-- **Cone** — the main agent you interact with. It holds the broad context, owns the overall workflow, and delegates work. Experimental: with the **Multiple cones** flag on (Settings → Experimental), the left rail's action row gains **New cone** (name it; your current chat stays where it is) and **Drop cone** (its chat goes to the Freezer without memory extraction, together with its scoops; the last cone can never be dropped). Cones switch from the tab strip — all cones first, then the scoops of the one you are in. Each cone keeps its own conversation and its own model: the model picker changes the cone you are looking at, switching cones switches the model back, a new cone starts on the model of the cone you created it from, and a scoop keeps the model its cone had when it was spawned. **New chat** / **New chat, fast** / **Discard** archive and clear the cone you are looking at. There is one Freezer for all cones; a thawed chat says which cone it came from. Licks and the first-run welcome stay with the original cone. Each extra cone also gets its own workspace (`/cones/<folder>/workspace`) and memory file, so cones do not overwrite each other's files or interleave each other's memory — what a cone learns is remembered for that cone; `/shared`, `/tmp` and installed skills stay common. **You never talk to a scoop directly**: opening one from the tab strip shows its transcript with no composer — you watch it work, and everything it needs from you (a sudo request, an approval, a nudge when it goes idle) appears in the chat of the cone that owns it. The cone is where you answer, and `feed_scoop` from the cone is the only way to send a scoop input.
+- **Cone** — the main agent you interact with. It holds the broad context, owns the overall workflow, and delegates work. Experimental: with the **Multiple cones** flag on (Settings → Experimental), the left rail's action row gains **New cone** (name it; your current chat stays where it is) and **Drop cone** (its chat goes to the Freezer without memory extraction, together with its scoops; the last cone can never be dropped). Cones switch from the tab strip — all cones first, then the scoops of the one you are in. Each cone keeps its own conversation and its own model: the model picker changes the cone you are looking at, switching cones switches the model back, a new cone starts on the model of the cone you created it from, and a scoop keeps the model its cone had when it was spawned. **New chat** / **New chat, fast** / **Discard** archive and clear the cone you are looking at. There is one Freezer for all cones; a thawed chat says which cone it came from. Licks and the first-run welcome stay with the original cone. Each extra cone also gets its own workspace (`/cones/<folder>/workspace`) and memory file, so cones do not overwrite each other's files or interleave each other's memory — what a cone learns is remembered for that cone; `/shared`, `/tmp` and installed skills stay common. **You never talk to a scoop directly**: opening one from the tab strip shows its transcript with no composer — you watch it work, and everything it needs from you (a sudo request, an approval, a nudge when it goes idle) appears in the chat of the cone that owns it. The cone is where you answer, and `feed_scoop` from the cone is the only way to send a scoop input. The iPhone/iPad follower shows the same read-only scoop view.
 - **Scoops** — isolated sub-agents with their own filesystem sandbox, shell, and conversation history.
 - **Licks** — external events that wake an agent up: webhooks, cron jobs, and other signals from the outside world.
 - **Floats** — normal engineers would call it runtimes, but would normal engineers have come up with this?