sliccy 6.116.1 → 6.116.3

package/README.md

@@ -177,7 +177,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. The iPhone/iPad follower shows the same read-only scoop view.
+- **Cone** — the main agent you interact with. It holds the broad context, owns the overall workflow, and delegates work. You can run several at once: the left rail's action row offers **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. A Cherry embed — SLICC as a garnish inside someone else's page — mirrors the cones its leader has but never offers to create or drop one.
 - **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?