clisbot 0.1.45-beta.1 → 0.1.45-beta.10

package/README.md

@@ -118,7 +118,7 @@ If you want to try first without persisting the token yet, just remove `--persis
 Next steps:
 
 - For security, DMs default to pairing.
-- Existing `0.1.43` configs upgrade directly to `0.1.45` automatically on first run. clisbot writes a backup first under `~/.clisbot/backups/`, then rewrites the config to the current shape.
+- Existing configs from any version before `0.1.45` update directly to `0.1.45` automatically on first run. clisbot writes a backup first under `~/.clisbot/backups/`, then rewrites the config to the current shape.
 - Shared Slack channels, Slack groups, Telegram groups, and Telegram topics are a separate gate: normal users need an explicit route such as `group:<id>` or `topic:<chatId>:<topicId>` before the bot will talk there. Legacy Slack `channel:<id>` input still works for compatibility.
 - After a shared surface is admitted, per-surface sender control comes from the bot's default shared rule `groups["*"]` plus any route-local `allowUsers` or `blockUsers`.
 - If the effective shared policy is `disabled`, the bot stays silent there for everyone, including owner/admin.
@@ -139,7 +139,7 @@ Need the step-by-step setup docs instead of the shortest path?
 
 - Telegram: [Telegram Bot Setup](docs/user-guide/telegram-setup.md)
 - Slack: [Slack App Setup](docs/user-guide/slack-setup.md)
-- Release notes: [CHANGELOG.md](CHANGELOG.md) and [docs/releases/](docs/releases/README.md)
+- Release history: [CHANGELOG.md](CHANGELOG.md), [release notes](docs/releases/README.md), [update guide](docs/updates/update-guide.md), [release guides](docs/updates/README.md), and [migration index](docs/migrations/index.md)
 - Slack app manifest template: [app-manifest.json](templates/slack/default/app-manifest.json)
 - Slack app manifest guide: [app-manifest-guide.md](templates/slack/default/app-manifest-guide.md)
 
@@ -152,18 +152,20 @@ What happens next:
 - fresh bootstrap only enables the channels you name explicitly
 - after the persisted first run, later restarts can use plain `clisbot start`
 
-## Big Upgrades In v0.1.39
+## Recent Release Highlights
 
-- Much better native Slack and Telegram rendering, so replies are easier to read and feel far less like pasted terminal output.
-- A much cleaner first-run path, with a clearer bot-first setup story and better setup docs.
-- Stronger pairing, auth, and safer shared-channel behavior by default.
-- More trustworthy long-running work, with better attach, detach, recovery, and operator visibility.
-- Real recurring automation with `/loop`.
+- `v0.1.45`: safer personal and team bots in real Slack and Telegram groups, automatic direct updates from older installs, more reliable scheduled loops, clearer sender and surface context, Telegram audio support, and stricter streaming/session isolation.
+- `v0.1.43`: more durable runtime recovery, clearer routed follow-up controls, more truthful tmux prompt submission checks, better queued-start notifications, and safer Slack thread attachment behavior.
+- `v0.1.39`: the first large release of the current bot-first shape, with native Slack and Telegram rendering, cleaner first-run setup, stronger pairing/auth defaults, better long-running run visibility, and recurring `/loop` automation.
+
+There are many more useful fixes and operator improvements in the full release notes, including config update safety, CLI help, setup docs, runner debugging, route policy behavior, and channel-specific polish.
 
 Read the full notes here:
 
 - [CHANGELOG.md](CHANGELOG.md)
 - [Release Notes Index](docs/releases/README.md)
+- [v0.1.45 Release Notes](docs/releases/v0.1.45.md)
+- [v0.1.43 Release Notes](docs/releases/v0.1.43.md)
 - [v0.1.39 Release Notes](docs/releases/v0.1.39.md)
 
 If you prefer Slack first:
@@ -191,11 +193,11 @@ bun run start --cli codex --bot-type personal --telegram-bot-token <your-telegra
 
 Repo-local `bun run start|stop|restart|status|logs|init|pairing` is pinned by `.env` to `CLISBOT_HOME=~/.clisbot-dev`, so local testing does not accidentally reuse your main `~/.clisbot` runtime.
 
-Upgrade note for existing installs:
+Update note for existing installs:
 
 - `v0.1.39` includes breaking changes in config shape and in the main CLI command surface.
-- If you already run an older install, ask Codex or Claude in this repo to update your current config before upgrading.
-- The upgrade itself is still simple:
+- If you already run an older install, ask Codex or Claude in this repo to update your current config before updating the package.
+- The package update itself is still simple:
 
 ```bash
 clisbot stop
@@ -318,7 +320,7 @@ If the quick start does not work, check these in order:
 trust_level = "trusted"
 ```
 
-- If that trust screen is still blocking, attach directly and continue from tmux with `tmux -S ~/.clisbot/state/clisbot.sock attach -t agent-default-main`.
+- If that trust screen is still blocking, inspect the live session name with `clisbot runner list`, then attach directly with `tmux -S ~/.clisbot/state/clisbot.sock attach -t <session-name>`.
 - If Gemini startup says it is waiting for manual authorization, authenticate Gemini directly first or provide a headless auth path such as `GEMINI_API_KEY` or Vertex AI credentials; `clisbot` now treats that screen as a startup blocker instead of a healthy ready session.
 - If Codex warns that `bubblewrap` is missing on Linux, install `bubblewrap` in the runtime environment.
 - If the bot does not answer, check `clisbot status` first. Healthy channels should show `connection=active`; if a channel stays `starting`, inspect `clisbot logs`.
@@ -337,13 +339,15 @@ Most users only need a small set of commands at first:
 
 - `clisbot start`: start the bot runtime and create the default first-run setup when needed.
 - `clisbot restart`: restart the runtime cleanly; use this first when the bot stops responding.
-- `clisbot stop`: stop the runtime cleanly before upgrades, config changes, or maintenance.
+- `clisbot stop`: stop the runtime cleanly before updates, config changes, or maintenance.
 - `clisbot stop --hard`: stop the runtime and kill all tmux runner sessions on the configured clisbot socket; use this when stale runner panes, old environment variables, or stuck sessions survive a normal restart.
 - `clisbot status`: check whether the runtime, channels, and active sessions look healthy.
 - `clisbot logs`: inspect recent runtime logs when startup, routing, or replies look wrong.
 - `clisbot runner list`: list the live tmux-backed runner sessions and see what is active.
 - `clisbot runner watch <session-name>`: live-watch one specific session when debugging a real run.
 - `clisbot runner watch --latest --lines 100`: jump straight into the most recently active session with enough context to debug a just-submitted message.
+- `clisbot queues list`: inspect pending durable queued prompts across the app.
+- `clisbot queues create --channel telegram --target group:-1001234567890 --topic-id 4335 --sender telegram:1276408333 <prompt>`: create one durable same-session queued prompt, capped by `control.queue.maxPendingItemsPerSession` (default `20`).
 
 Full operator command reference:
 
@@ -440,7 +444,7 @@ tmux is still the current stability boundary. One agent maps to one durable runn
 
 This repo also serves as a small example of an AI-native engineering workflow:
 
-- simple `AGENTS.md` and `CLAUDE.md`-style operating rules
+- simple `AGENTS.md`-style operating rules, with Claude and Gemini compatibility files able to symlink back to the same source
 - lessons-learned docs to capture repeated feedback and pitfalls
 - architecture docs used as a stable implementation contract
 - end-to-end validation expectations to close the feedback loop for AI agents

package/config/clisbot.json.template

@@ -324,7 +324,6 @@
             "socketPath": "~/.clisbot-dev/state/clisbot.sock"
           },
           "trustWorkspace": true,
-          "startupDelayMs": 3000,
           "startupRetryCount": 2,
           "startupRetryDelayMs": 1000,
           "promptSubmitDelayMs": 150,