sliccy 6.135.0 → 6.135.2

package/README.md

@@ -83,6 +83,7 @@ SLICC is for you if:
 - **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. Tear one down with `umount /mnt/myproject` (or the longer `mount unmount /mnt/myproject`). 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).
+- **Recover from concurrent file edits.** When an edit invalidates a browser file snapshot, SLICC attempts the read up to three times. Persistent read errors are still reported.
 - **Mount remote storage as if it were local.** Beyond local folders, `mount --source` bridges S3 buckets, S3-compatible services like Cloudflare R2 and MinIO, and Adobe authoring content — both da.live repositories and Helix 6 sites on the AEM Source Bus — into the same VFS surface. Reads use TTL+ETag caching with conditional revalidation; writes use ETag-conditional PUTs that surface concurrent-edit conflicts as `EBUSY`. Credentials live server-side (`~/.slicc/secrets.env` in CLI, `chrome.storage.local` in the extension via the **Extension options** page) and never reach the agent. After setup: `mount --source s3://my-bucket --profile r2 /mnt/r2`, `mount --source da://my-org/my-repo /mnt/da`, or `mount --source aem://my-org/my-site /mnt/aem`. A `da://` source checks the site config first and re-routes to the Source Bus when the site has been upgraded to Helix 6, rather than quietly mounting a store that no longer holds its content. See [docs/mounts.md](docs/mounts.md) for the full guide.
 
 ## Getting started
@@ -168,7 +169,7 @@ On macOS, launching a terminal follower from Sliccstart also exposes its managed
 
 SLICC shares one core across every runtime ("float"). The browser is not just where you view the product — it is where the agent runtime lives.
 
-- **Browser-first runtime:** the agent loop, virtual filesystem, shell, UI, and tools run client-side.
+- **Browser-first runtime:** the agent loop, virtual filesystem, shell, UI, and tools run client-side. Startup bounds parallel file reads to support large local filesystems.
 - **Thin server where needed:** the CLI path mainly exists to launch Chrome, proxy CDP, and bridge the few things browsers cannot do alone. The Chrome extension is even thinner — UI and agent engine load from the hosted leader tab.
 - **One model across floats:** CLI / standalone, thin Chrome extension, Electron, Cherry (embedded follower in third-party pages), hosted-leader / cloud (`@slicc/cloud-core` over an e2b sandbox), and the native macOS / iOS surfaces (`Sliccstart`, `slicc-server`, `SliccFollower`) all reuse the same underlying system.
 - **Cone + scoops delegation:** the main agent orchestrates; sub-agents execute in isolated sandboxes and report back.