charness 3.6.1 → 3.7.0

package/CHANGELOG.md

@@ -2,6 +2,273 @@
 
 ## Unreleased
 
+## 3.7.0 — 2026-11-01
+
+**The answers of `send_messages_to_user` and `send_file_to_user` now say what was sent, per kind — «Delivered 3 messages: 1 text, 2 documents.», «Sent 3 files: 1 photo, 2 documents.» — so an agent can see when a file did not go out as the kind it meant.**
+Before, they only counted («Delivered 3 messages to the topic», «Sent 3 file(s) to the topic»), so a batch of images that arrived as plain text or as documents read as a full success.
+Now the answer names what landed — texts, photos, videos, animations, documents — taken from what Telegram was actually asked to render: a photo sent with `as_file`, one over the photo size limit, or one in an album that fell back to documents is counted as a document.
+
+**An agent that misnames a field when it calls one of the bot's tools now gets an error that says which field and what to write — attachments no longer vanish unseen.**
+Before, a key the tool does not know was dropped silently: an agent that sent three images to `send_messages_to_user` as `{text, filePath}` (the field is `path`) had them posted as three text-only messages, and the tool still answered «Delivered 3 messages».
+Now every bot tool refuses a key it does not list, at the top of a call or inside an item, and answers with the key, the nearest allowed one («unknown key `filePath` — did you mean `path`?») and the allowed keys; nothing is sent. `send_file_to_user` called with `path` instead of `paths` is told the same.
+
+**Agents can now send heavy commands — test suites, builds, emulator runs — to another machine with `charness remote-run`, and get the output, the exit code and the result files back as if the command had run here.**
+Before, everything an agent ran landed on the one machine the bot lives on, so a long test suite or an emulator run could take most of its CPU and memory for an hour while other agents waited on it.
+Now you list machines you reach by ssh in `~/.config/charness/runners.json` (set up by hand: an account of its own, `rsync`, Pueue — see `docs/remote-run.md`), and an agent runs `charness remote-run yarn test` (or `--bg` plus `wait` for a long run): the project is synced there (tracked and untracked files, never what `.gitignore` names, never secret-looking files unless `.remote-run` says so), the command runs in a copy, its output streams back, and an interrupt, a timeout or a lost connection stops the whole remote job.
+`charness remote-run runners` shows each machine's CPU, memory, disk, load and what it can do (Android, iOS, Docker, Playwright); `ls`, `status`, `logs`, `wait`, `kill`, `fetch` and `exec` manage the jobs. Two runs of one project queue on the runner, each against the files as they were when it was started.
+Agents (Telegram topics and Jira issues alike) are told about it only while at least one runner is listed; without one nothing changes.
+
+**A message no longer gets lost when Telegram has closed the connection the bot was about to reuse — it is sent again, once, on a fresh connection.**
+Before, the bot kept its connections to Telegram open and reused them; when Telegram had closed an idle one a moment earlier (most often while the bot was starved of CPU), the next send failed with «socket hang up» and was dropped — a notice or a reply simply never appeared in the topic.
+Now a send that fails this way — at once, before Telegram has started to answer — is retried once on a new connection, the answer to a button tap and the edit of a picker included. It is not retried after a timeout, once Telegram has begun to answer, when the connection broke only after a while, or on a connection that was new anyway, and a file the agent sends is not retried this way (it keeps its own delivery rules). If Telegram did take the message and the connection broke before a single byte of its answer, the retry cannot tell that from a closed connection and could post the message twice; that is rare.
+The bot also closes a connection that sat unused for 30 seconds itself, long before Telegram would, so an ordinary pause between two messages does not meet a closed one. When it retries, the bot log says «pooled connection was closed by the server».
+
+**Stopping every agent from General is typed `/quitall` — the «only available in the General topic» refusal now says so, in all 12 languages.**
+Before, that refusal (and the docs) told you to use `/quit-all`, but Telegram ends a command at the hyphen, so `/quit-all` reached the bot as plain `/quit` and stopped only the one topic's agent, not all of them.
+The refusal and the docs now name `/quitall`, the spelling the command menu lists; the command itself is unchanged.
+
+**A question the agent asks now stays in the topic however it ends: answered, it shows your answer in place of the buttons; left alone, a note says it was not answered.**
+Before, answering replaced the whole question with a short «✅ header: answer», walking away from it (another message, `/esc`) replaced it with «❌ Question cancelled», and re-posting or re-asking a question deleted the first message — so what the agent had asked was gone from the topic.
+Now the message is never deleted: it keeps the question and its options, with «✅ Answer: …», «❌ Not answered» or «↓ Asked again below» under them, also when the question is re-asked after the idle compaction, when you leave the folder, or its agent is gone.
+A question that waits through a long stream of the agent's output is put at the bottom again each time: the first message stays as the record and the newest copy is the live one, the copies in between are removed — also across a bot restart.
+A bot restart in the middle of an idle compaction asks the question again when its conversation can still be resumed, instead of leaving it «Not answered» though you never had the chance to answer.
+The pin works as before: one notification when the question comes, removed when it ends. The details are in `docs/commands.md`, «The agent's questions».
+
+**Typing or saying «claude» (or `клод`) to start the agent now opens the same backend `/claude` does — json-stream by default, or the one the topic picked — not the deprecated tmux one.**
+Before, a start phrase — in a text message or a voice note — handed the bare name `claude` on, which is the tmux backend's own name, so the phrase quietly
+started the frozen tmux backend while `/claude` and the ▶️ Claude button opened the topic's backend. All three now open the same backend;
+`opencode` and `terminal` are unchanged, and a topic that picked the tmux backend with `/claude_mode` still gets it.
+
+**Binding a topic to a folder now leaves ONE message in the topic — the full welcome with the folder's facts and the start buttons — whichever way it happens.**
+Before, a bind also posted extra messages that stayed in the topic as plainer copies of the same news: picking a folder with `/bind` (typed, tapped
+in the picker or «create new folder») added a short «📁 Bound to `x`. Run /claude or /opencode.» just before the welcome, a topic the bot bound by
+itself because its name matches a folder got a separate 👋 «auto-bound» greeting, a folder other topics already use got a separate ⚠️ warning, and
+«create new folder» given the name of an existing folder added a «Folder already exists» note.
+Now only the welcome is posted: a row in it says the bot bound the topic because its name matches the folder, another says the folder was there
+already, and another names the topics that already use the folder — also when the bot bound the topic by itself. A topic is named there by the name
+the bot saw it made with (or an admin renamed it to), else by a link that opens it; the name a non-admin gave a topic is not kept on its binding, since
+the agent's thread context would repeat it. Only topics of the SAME chat are named: topics of other chats the bot serves (another group, a private chat) are
+only counted, «+2 more» (a topic of this chat that has no name and no link to show is counted too), so one chat never learns what another calls its topics. A folder that does not exist still just gets its reason. When a topic is bound again, or leaves its folder, the buttons of its previous welcome (▶️ Claude, ▶️ OpenCode, 📋 Resume) are removed: they act on the topic's CURRENT folder, whatever the old message says, so an old welcome can no longer start an agent from a folder the topic has left. `/topic`'s «create new folder» still tells the topic
+you typed the name in that the folder existed.
+The `/bind` picker is now one-shot: once a folder is bound through it (a tap or «create new folder»), or «Leave current dir» is used, the picker message
+is deleted — its «not bound, pick from the list» text would no longer be true — so an old tap cannot rebind the topic, and a second tap landing while the
+first is still binding (on a folder, «create new folder» or «Leave current dir») is told «This picker was already used.» instead of binding or unbinding
+twice; a refused pick, paging and the create-folder prompt leave it in place, and a tap whose answer reaches Telegram too late still does what it asked. Pickers the bot closes after a bind are refused at once, even those it could not delete (the bot keeps that in memory: after a restart a picker that still has its buttons works again), and a typed folder name that arrives while a tap holds the picker is told so instead of being dropped.
+A «create new folder» wait ends with the bind or the leave that follows it, so the next plain message is never taken for a folder name, and its «send the folder
+name» prompt is deleted with the bind (a refused name keeps it). Every plain message in an unbound topic posts a new folder picker, so a bind or a leave — by a tap,
+a typed `/bind <folder>` or the bot's own auto-bind — deletes ALL the pickers still open in that topic, not only the tapped one: no stale one is left to rebind it.
+When the bot binds a non-admin's topic on an admin's first message there, a plain message is answered by the welcome alone, without the extra «bound, run /claude» hint, and a
+start phrase like `claude` still starts the agent; the topic is then stored under the matched folder's own name, never under the member's spelling. The
+removed texts are gone from all 12 languages, the new rows and the toast are in all 12.
+A topic you create whose name matches no folder now remembers that name for 24 hours: the folder picker you bind it through keeps it (the «also used by» row of a
+later topic on that folder names it), and if a folder with that name appears meanwhile, your next message in the topic binds it by itself.
+
+**`/task_agents` in General sets how many task agents may work at once — a number from the picker or any number you type.**
+It opens a one-shot picker (5 / 10 / 15 / 20 / 30 / No limit, the value in force marked ✓) whose tap turns it into its confirmation;
+`/task_agents 12` sets any whole number from 1 to 100, and `0` or `off` means no limit (a number over 100, a decimal or a word is refused with the
+range). The screen names where the value comes from — set in General, `settings.json`, or the built-in default — and, on an instance that serves
+Jira, how many agents work now and how many wait. General's own value beats `settings.json`'s once it is set, and a higher number starts the issues waiting for a slot at once; in a topic the command only reports
+the value and says it is changed in General. The texts are in all 12 languages. General's `/help` also names it, and escapes the underscores of
+its command names, so a pair of them can no longer be read as italics.
+
+**The agents that work on Jira issues now run under ONE cap for the whole bot — 5 at once by default — and an issue over it waits in a queue and starts by itself.**
+Before, every issue handed to the AI account started its agent at once, with nothing limiting how many ran together. Now the number of
+tracker task agents working at the same time is capped for all projects together: `"taskAgents": { "maxConcurrent": 5 }` in
+`settings.json` (`0` = no limit, 100 the most; read without a restart; nothing set means 5, so an instance gets the cap with this update).
+An agent takes a slot when its issue is handed over and gives it back when it hands the issue back (a question or the final answer), when its
+request is cancelled, or when the wake-up engine gave up on it and handed the issue back; an issue with several hand-overs open still holds one
+slot, and an @-mention (answer only) never takes one or waits. An issue over the cap gets ONE short comment — «⏳ The AI is working on 5 tasks at
+once, its limit, so this issue is queued (2 issues are ahead of it). It starts by itself when a slot frees up» — and stays assigned to the AI. The
+waiting issues are one first-in-first-out list for the whole bot, kept in `state.json` so a restart keeps the order; the first one starts the
+moment a slot frees — an agent hands its issue back, a request is cancelled, the wake-up engine gives up on one, or the cap is raised with
+`/task_agents` — because the Jira poll then runs at once instead of at its next interval (a raise made by editing `settings.json` is noticed when
+the bot next reads the file, at the latest at the next poll). An issue moved away from the AI while it waits leaves the list; an issue whose
+start fails (its text cannot be read, say) keeps its place but no longer holds up the ones behind it, and after three failed starts in a row it
+moves to the end of the list. A lower cap never stops an agent that is already working. A mistyped `taskAgents` is logged once as
+`[Settings] settings.json taskAgents.maxConcurrent: …` and the built-in 5 applies.
+
+**The "↩️ Resumed — last 3 messages" preview no longer shows what Claude Code records for itself: a `/compact` you ran there shows as just `/compact`.**
+Before, resuming a conversation whose last entries were a command run in Claude Code itself printed the raw `<local-command-caveat>`,
+`<command-name>… <command-args>…` (with the whole, often very long, argument text) and `<local-command-stdout>` entries as if they were your
+messages, and a skill loaded in the last turn flooded the topic with its whole text. Now a command shows as its name only (a `!` shell command as
+`!ls`), and the entries Claude Code flags as its own are left out — the summary a compaction leaves, a loaded skill's text, the caveat before a
+command, image notes, messages from another session — as is an entry that is only a command's output, a reminder or a task notification. The
+entries left out do not count: the preview still shows the last three real messages. A message of yours is shown whole, also when it pastes or
+mentions one of these tags; only a `<system-reminder>` block that a hook appended to it is cut. The same goes for the recap after a bot restart
+and for the titles in the `/sessions` list. When a limit moves a topic to another agent, the summary of the conversation's earlier compaction
+(Claude topics) is handed over as context, labelled as such, and never as something you said.
+
+**The skills Charness gives its agents can now be switched off — `/bot_skills` in General for the whole instance, in a topic for that topic only.**
+A deployment whose workspace instructions name skills of their own (a Jira-only instance, say) no longer has to live with the bot's
+`charness-manager` and delegate skills beside them, nor with the hint in the bot MCP's instructions to load the manager. `/bot_skills` opens a
+one-shot picker: in General On / Off for the instance, in a topic On / Off / «As in General» with the current choice marked; a tap turns the picker
+into its confirmation (the texts are in all 12 languages). An instance without General sets the default with `"botSkills": "on" | "off"` in
+`settings.json` (read without a restart; General's own choice beats it once made; nothing set means ON, exactly as before). With the switch off a
+Claude conversation starts and resumes without the bot's skills folder, and the hint is gone from its instructions (the worker-watch recipe in
+`schedule_create` stays: it is a tool fact, not a skill). A running agent keeps its skills until its next start (the idle stop and resume, a new
+session or a model change). OpenCode has one server for every topic, so only the instance value counts there: the server is replaced at the
+bot's next start, once nothing works in it, by one started without (or, when turned back on, with) the skills folder — a `settings.json` that says
+`off` is followed already by the server the hot supervisor starts first — and a topic's own choice changes only its hint — its screen says the listed skills stay, that the hint changes when the OpenCode server next restarts and that the
+OpenCode topics of one folder share it. General's screen names where the value comes from (set in General, `settings.json`, or the built-in
+default). A mistyped `botSkills` is logged once as `[Settings] settings.json botSkills: …`
+and ON applies.
+
+**The tmux backend for Claude Code is now marked deprecated: it is frozen and no longer developed, and `/claude_mode` says so.**
+Before, nothing told you that, so you could pick a backend that gets no new features. The `/claude_mode` picker now shows it as
+«🖥 tmux (deprecated)» with a line pointing to the recommended json-stream backend, the same hint follows a switch to it, `/status`
+flags a topic that runs on it, and the command's menu text says «tmux (deprecated)». Nothing else changes: it stays selectable, a topic
+already on it keeps working exactly as before and nothing is migrated for you. The texts are in all 12 languages.
+
+**The local speech recognition (GigaAM) now recognises a voice message to its last second also when it is an MP3, an M4A or two OGG files joined into one.**
+Before, an MP3 without a length header (a cut-out stream, or a variable-bitrate file) was read for only its first seconds — 6.7 s of a 40 s
+file — the second half of two OGG files joined into one was dropped, and an M4A (AAC) was refused, so the next engine in your list
+answered it or nothing did. Telegram's usual OGG/Opus voice notes are read exactly as before. The three formats are now decoded with
+`av` (ffmpeg's libraries) in the engine's private Python environment: after this update the local engine re-installs itself once (about
+a minute and a ~35 MB download, ~100 MB more disk; the model is not downloaded again, progress shows in General), and a voice sent
+meanwhile goes to the next engine in your list.
+
+**Every compaction summary now ends with a numbered checklist of what the agent does next, and its first item is to load the skills it had loaded.**
+After a compaction the continuing session often skipped reloading its skills and worked without them. The checklist is now asked for on every path:
+the idle compaction, `/compact`, the compaction the agent arms itself (`compact_conversation`), and the one the agent CLI or OpenCode runs by
+itself when the context overflows. Item 1 is «load these skills» with their exact names (no such item when none was loaded), then the next steps the
+summary already records, in order — none invented. The list is the last thing in the summary; where the idle compaction asks for the closing
+«where we stopped» section, it is that section's last part. An OpenCode server that was already running gets the new text too: the plugin file in
+OpenCode's plugin folder now carries a hash of its text in its name (`charness-compaction-<hash>.js`), so at the bot's next start a project folder
+whose instance loaded an older text is recreated (when nothing runs in it; a working one is retried at the next start) and the older copies of the
+file are removed.
+
+**A usage-limit resume that finds its session gone no longer says «resumed» right before «no session».** When the bot restarted while a
+topic waited for a limit's reset and the conversation was ended in the same moment, the topic read the pinned «work resumed» notice and
+then «no session». The «resumed» notice now goes out only after a session took the "continue" prompt.
+
+**A hot-mode bot no longer keeps running the old build after a big update because its TypeScript watcher went blind.** After a pull of
+dozens of commits followed by a dependency install, the watcher could miss the changed files (the operating system drops file-change
+events when too many arrive while the compiler is busy): it then reported errors that did not exist, or a clean build that emitted
+nothing, `touch tsconfig.json` did not help and only a full service restart did, while the bot kept serving the old code without a
+word. The hot supervisor now compares the watcher with the sources every 30 s and, when a source stays a minute newer than the build,
+restarts the watcher alone (when it reports errors, only after a fresh compile finds none) — the bot, its agents and the supervisor
+stay up, and the update reaches the worker like any other.
+
+**Switching to the next entry of the fallback list on a usage limit is now ON by default, also with a single signed-in account.** The
+«🔁 Auto switch» setting of `/limits_autoswitch` used to start OFF, so a limit stranded the work on the limit notice until someone
+tapped «Switch to …» even when another entry had room. Now a topic that hits a limit moves by itself to the first entry of the list
+with room — another Claude account, or an OpenCode provider and model, which hands the conversation over to a different agent in
+compacted form. With one account and no list there is nothing to move to, so the bot waits for the reset as before, and an account
+or an entry added later is used from the first limit on. An instance where you turned it OFF (in General or for one topic) keeps
+your choice; if you do not want conversations handed to OpenCode by themselves, turn it OFF or leave OpenCode out of the list.
+
+**Agents now get Charness's own orchestration skills.** Every agent session the bot starts — Claude Code in a topic or a Jira
+conversation (the stream and the tmux backend) and OpenCode — gets the bot's skills: `charness-manager` for driving work
+through detached workers with the bot's own tools, and `charness-delegate-claude` / `charness-delegate-opencode` for
+launching, watching and resuming those workers (Claude Code lists them as `charness:charness-manager`, …). The manager
+watches every worker with a bot check that fires when the worker exits OR stops writing for 45 minutes — a check that only
+asks whether the process is alive never fires on a hung worker. Its alert pins silently, since a worker that simply finished
+fires it too, and cancelling a watchdog check (`schedule_cancel`) unpins the alerts it pinned. A user or project skill of the same kind stays as it is, a Claude
+Code older than 2.0.25 (which has no `--plugin-dir`) starts without them, the operator's own sessions outside the bot do not
+get these skills, and an `OPENCODE_CONFIG_DIR` the operator set is kept (its
+OpenCode topics then go without them). An OpenCode server the bot runs that an earlier version started is replaced at the bot's
+next start once nothing works in it; a server the bot does not own is left as it is.
+
+**A `/claude` sent right after `/quit` no longer loses its new session at start.** The ended session killed its tmux session a
+second time, by name and without waiting, after the stop had killed it already; on a busy host that second kill could run once
+the new session had created its own tmux session of the same name, and the start then failed with "the CLI exited before its
+initialize handshake". An explicit stop kills the tmux session once. And `/quit` now says «stopped» only when the session is
+stopped: a `/claude` sent on that reply used to be told "already running", and then nothing ran.
+
+**A prompt that waited for the agent's running turn is no longer lost when the process is stopped right after that turn.** A Jira
+hand-over or a scheduled run that arrived while the agent was still working was written to the process the per-turn stop had
+just ended and dropped; the agent got it only minutes later, as a whole re-post. The prompt now makes sure the conversation is
+awake again before it is sent, so the agent reads it once, as it was built.
+
+**A usage-limit switch no longer prompts the agent twice.** Moving a limited topic to another model or account re-spawns the
+session for a few seconds; a reminder for the interrupted request could land in that gap on top of the "continue" prompt the
+move sends, and the agent answered twice (one answer's streamed text was lost). The request is no longer reminded while the
+move is under way.
+
+**A new turn's text no longer lands inside the previous turn's message.** When the Telegram API was slow, the previous turn's
+last text could finish sending after the next prompt had gone to the agent, and the next turn's first text was then appended
+to that message by an edit instead of starting its own. The "new message" mark now belongs to the first text queued after it,
+and text still waiting when your next prompt goes out is no longer pulled into the new reply's message.
+
+**The text a turn streamed before it failed now arrives before the error notice, and a restart no longer repeats an error already handled.**
+A turn that ended on an error (a usage limit, an API error, an interrupt) kept its last text in the answer batch while the notice
+went out at once: the text showed up below the limit notice, the switch offer and the usage board, and a bot restart in that
+moment replayed the turn together with its error — a second notice or error line for a limit that was already announced, or a lost
+auto-retry. The turn's text is now sent first, and the bot saves where it stopped reading at the end of the turn, as it does for
+a turn that succeeded.
+
+**A message sent right after a bot restart no longer mixes with a turn that was running when the bot went down.** The restarted
+bot reads what the agent wrote while it was down a moment after it starts; a prompt that reached the agent before that (the
+bot's own resume after a usage limit, a scheduled run, your message) reset the reply the replayed text still belonged to, so the
+old turn's text could end up inside the new reply's message, and an error of the old turn took the new turn's place — shown as
+a plain "Claude error" line and not retried. A prompt now waits for that replay (at most 30 s) before it is sent; if the agent is gone
+when the wait ends, the topic says so and the request the message opened is closed, instead of the bot later asking the agent about
+an answer it never started.
+
+**A usage limit that stopped the agent while the bot was down is now handled once after the restart.** The restarted bot found the
+limit error twice — once when it checked the agent's log at start (it resumes the topic at once when the window is over), and
+once more when it read what the agent wrote during the downtime. The second copy was handled as a fresh limit: the topic got a
+"Usage limit reached" notice for a window that was already over (for a reset written as a clock time, a wait of up to a day),
+a second "work resumed" message, and the agent a second "Continue" prompt and a second turn. The first one now owns the
+episode and the replayed copy is left out.
+
+**A bot restart in the middle of a per-turn topic's turn no longer wipes that turn's working files.** The cleanup at start took the
+running agent of a per-turn topic for a leftover and deleted its output log and pipes while the agent was still working, so the bot
+could neither read the rest of the turn nor write to the agent: the answer never reached the topic. The daily cleanup did the same to
+a turn that happened to be running then. The cleanup now knows both Claude lifecycles.
+
+**After a restart, a usage limit that ended a turn while the bot was down no longer keeps the account marked limited for a day.** When the
+restarted bot read that limit error from what the agent wrote during the downtime, it worked out a reset named by its clock
+("resets 10:20am") from the moment it read the error, not from the moment the error happened: a window that had closed half an
+hour before was taken as closing tomorrow, and the account stayed limited — shown so on `/limits`, passed over by the account
+switch — for up to a day. The reset is now worked out from the time the agent's transcript recorded the error.
+
+**A working agent now hears of another topic's todo change in the middle of its turn.** Claude gets the project
+board's changes with the result of its next tool call (a `PostToolUse` hook in the settings file the bot starts every
+Claude session with), OpenCode as a queued message it reads between steps; an idle or sleeping agent is never woken
+for it.
+
+**The agents of one repository now see each other's todo lists.** Topics on checkouts or worktrees of the same git
+repository form a project, and every prompt an agent gets carries the project board — the whole of it on a fresh
+context, later only what changed in the other topics — as does its own `todo_update`; another topic's change never
+wakes an agent. `/todo` → Project ▸ joins another topic's project or keeps an own one, `/todo` in General lists every
+project, and Jira conversations share a board with the topics on the repositories their `jira.json` project lists in
+the new `repos` key.
+
+**An agent that works for an hour without updating its todo list is reminded to.** The next prompt it gets carries
+one line; an agent that keeps working on its own gets a short prompt of its own at the end of a turn — never into a
+running turn, a sleeping session, an unanswered request, a usage limit or an account billed to API credits — and the
+bot falls silent after two ignored reminders. `/todo` in General → Settings turns the lists off or sets the interval
+(off, 30 min, 1 h, 2 h, 4 h); an instance without General sets `todo` in `settings.json`.
+
+**Agents publish what they work on, and `/todo` shows it.** Every topic's agent now keeps a short published todo list
+— in work, the queue in order, done — through a new bot tool, adding an item before it starts a task and closing it
+when it is done; `/todo` in a topic shows the list. It belongs to the topic, so `/new`, `/quit`, a backend switch and
+a restart keep it, and a final answer while the list still shows unfinished work reminds the agent to update it. Jira
+conversations publish the same way.
+
+**Voice notes with pauses no longer lose phrases.** The local recognition (GigaAM) now cuts every voice at its pauses and
+recognises the parts separately, so a phrase said after a pause is no longer dropped or merged into the previous one
+(for example, "…купи хлеб? … и ещё молоко" could come out as just "…купи хлеб"). Nothing is cut away: the parts cover the whole
+voice. After this update the local engine re-installs itself once (about a minute, the model is not downloaded again, the
+progress shows in General); a voice sent meanwhile goes to the next engine in your list, or, with no other engine, the bot
+asks you to send it again when the engine is ready.
+
+**Voice notes from different topics are transcribed in the order they were sent.** The local recognition used to let
+a short voice jump ahead of a longer one sent before it from another topic; now each voice waits its turn, and the bot
+waits for it as long as its turn takes instead of giving up after the time its own length needs. A voice the bot has
+stopped waiting for is no longer recognised in vain.
+
+**Agents now launch workers on the Claude account whose weekly limit resets soonest, keep a resumed worker on its own account, and move a worker stopped by a limit to another account at once.**
+Before, a worker (or a topic whose account hit its limit, with no `/limits_autoswitch` list) went to the account with the most room left, so an account about to
+expire its week unused sat idle while the one with a fresh week took the work. Now a new worker starts on the usable account that resets its weekly window
+first (an account whose five-hour window is at 90 % or more waits; Fable's own window takes out only Fable), a resumed worker stays on the account it
+ran on, and one that broke off on a usage limit is resumed on another account straight away instead of waiting. When no account is usable the answer says
+which one frees up first and when, so the manager schedules a single resume for that moment; when no account can say when it frees up, the manager asks you
+and tries again in about half an hour. An account switched off in `/limits_autoswitch` is never picked
+for a new worker, and one billed to API credits never is either. `charness claude-profiles` takes `--current <name>` and `--stopped-by-limit` for the same,
+and a topic stopped by a limit with no list of its own now moves to the account that resets soonest rather than the roomiest.
+
 ## 3.6.1 — 2026-10-26
 
 **An agent @-mentioned on a Jira issue that is already assigned to it no longer asks to be assigned.** When the issue

package/DEVELOPMENT.md

@@ -13,7 +13,7 @@ The per-topic folder layout is in [SETUP.md](SETUP.md) under
 Routing key is `(chatId, threadId)` everywhere. Per-thread state lives in
 `${DATA_DIR}/state.json` (atomic writes with `fsync`, archived on
 corruption). Bot-owned tmux sessions are named per backend —
-`claude-<chatId>-<threadId>` (Claude tmux-scrape), `cjson-…` (the Claude
+`claude-<chatId>-<threadId>` (Claude tmux-scrape, deprecated), `cjson-…` (the Claude
 json-stream host process), `term-…` (terminal) — see
 `src/utils/tmuxSessionName.ts`; opencode sessions are keyed by the same
 `<chatId>:<threadId>` string. Two topics on the same folder stay independent.
@@ -27,7 +27,7 @@ tracker or Teams surface means adding a directory under `src/connectors/`, not
 editing the core.
 
 ```
-Telegram  <->  connectors/telegram/  <->  bot.ts  <->  AgentAdapter <-> { Claude CLI (tmux scrape) |
+Telegram  <->  connectors/telegram/  <->  bot.ts  <->  AgentAdapter <-> { Claude CLI (tmux scrape, deprecated) |
                  inbound.ts               (core)          │              Claude CLI (stream-json) |
                  outbound.ts + output/      │             │              OpenCode (HTTP+SSE)      |
                  sessionKeyCodec.ts         │             │              Terminal ($SHELL in tmux) }
@@ -104,6 +104,17 @@ keep when touching the restart path:
   sends `SIGUSR2` — only when pid and start token match. The supervisor stops `tsc -w` and nodemon, leaves the OpenCode
   server and the speech sidecar alone and `execve`s `cli.js hot`. A supervisor that predates this has no record and is
   never signalled (an unhandled `SIGUSR2` kills a process).
+- **The hot supervisor guards its watcher** (`cli/tscWatchGuard.ts`). `tsc -w` learns of a changed source only from file-system
+  events, and a burst — a pull of dozens of commits, then `yarn install` — overflows the inotify queue (`max_queued_events`,
+  16384) while the compiler is busy: the dropped events leave the watcher with the OLD text of the files it missed (errors where an
+  old definition meets new callers, or a clean report that emitted nothing); `touch tsconfig.json` re-reads none of them, only a
+  new `tsc -w` does, and the worker keeps running the old build. Every 30 s the supervisor compares the idle watcher with the
+  tree: a compiled source (`selfUpdate/emittedSource.ts`) a minute newer than its `dist/` output is a missed change — with "0
+  errors" the WATCHER (not the supervisor, not the worker) is restarted at once, with errors a one-shot `tsc --noEmit` decides
+  (clean there = the watcher is wrong). At most 3 restarts an hour, then it only says so; and a set of sources a restarted watcher still
+  leaves newer than their output (a modification time in the future, a path `tsconfig.json` excludes that `emittedSource.ts` does not know —
+  `emittedSource.test.ts` keeps the two lists equal) is reported once and not restarted for again. The flow `selfUpdateHotE2e` freezes the
+  real `tsc -w`, overflows the queue and replaces a source: the change must still reach `dist/`.
 - **`update-pending.json` is written BEFORE the switch**; every boot counts itself in (`cli/bot.ts`, once the instance lock is held and before the bot
   module is imported), the boot after two unconfirmed ones rolls back, the running bot confirms 60 s after launch.
 
@@ -139,6 +150,18 @@ To run your checkout as the global `charness` command instead of the npm package
 without re-installing; `npm install -g .` installs a copy instead. Configuration and launch are as in
 [SETUP.md](SETUP.md).
 
+`yarn test:unit` also runs the STT sidecar's Python tests (`sttSidecarPython.test.ts` → `stt/test_gigaam_sidecar.py`,
+no model needed). They want **`uv`** (an ephemeral environment with numpy and the pinned soundfile and av; the first run
+downloads them, so it needs the network once) or a **`python3` that has numpy, soundfile and av**. Without either, or when
+`uv` cannot reach the package index, a local run skips that test and says why; CI (`CI=true`, uv installed by the
+workflow) fails instead.
+
+The `charness remote-run` flow (two files that run side by side, each with a runner of its own — `remoteRunE2e.test.ts`, `remoteRunLifecycleE2e.test.ts`; the shared helpers are `remoteRunE2e/remoteRunFlowHarness.ts`) drives the built CLI against a throwaway loopback `sshd` (no root), `rsync` and a
+private **Pueue** in temp dirs. It wants `sshd` (`openssh-server`), `ssh`, `rsync`, `pueue` / `pueued` 4.x on `PATH` and `yarn build`;
+a local run without them is skipped with the reason, CI (`CI=true`) installs them (the workflow pins Pueue by checksum) and fails
+without. A flow that is killed or times out cannot leave daemons behind: `remoteRunE2e/remoteRunFlowSweep.ts` ends what names its
+layout, from the teardown, from a detached reaper and at the next start.
+
 Node applies `--test-timeout` to a whole test FILE (a `describe`'s own `timeout` cannot extend it), so a file that
 hangs or leaves a process alive fails by name when its limit passes, instead of hanging the run. A long-running
 flow file must be named `*E2e.test.ts` to get the flows' limit; `live/*Live.test.ts` is run directly (CLAUDE.md).
@@ -148,10 +171,13 @@ not with the runner's bare timeout. Run one flow directly with `--test-timeout=<
 
 A flow does not wait out the production windows in real time: its env file sets `CHARNESS_TEST_TIMINGS`, a JSON object
 of named overrides (`src/testTimings.ts`: `telegramSendIntervalMs` — the global send pacer's 2 s, `jiraPollIntervalMs` —
-below the 10 s floor of `jira.json`, `requestSweepIntervalMs` and `requestFirstPostRetryDelayMs` — the wake-up engine's
-minutes, `limitProbeDelayMs` — the two-minute probe of an unconfirmed usage limit, `stateSaveDebounceMs` — `state.json`'s
+below the 10 s floor of `jira.json`, `requestTurnPollMs` — the wake-up engine's 10 s poll of the turns it watches,
+`requestSweepIntervalMs` and `requestFirstPostRetryDelayMs` — the wake-up engine's minutes, `limitProbeDelayMs` — the two-minute probe of an unconfirmed usage limit, `stateSaveDebounceMs` — `state.json`'s
 500 ms save debounce, `openCodeServerUpBudgetMs` — the OpenCode server's 60 s of retries, `backgroundHoldMaxMs` — the 6 h the
-agent's own pending work holds a json-stream process). It is the ONE test-only timing seam,
+agent's own pending work holds a json-stream process, `todoReminderPollMs` and `todoReminderIntervalMs` — the todo
+reminder's 10 s poll and the interval `settings.json` sets, `scheduleMinFireIntervalMs` — the 5 min minimum between cron fires, `bindPickerClaimLimit` — how many `/bind` picker claims are kept (a count: 200), `tscWatchCheckIntervalMs` and `tscWatchStaleGraceMs` — the
+hot supervisor's 30 s check of its `tsc -w` and the minute a source may stay newer than its output; the supervisor reads these two, the bot the rest).
+It is the ONE test-only timing seam,
 never a setting: unset, every window is the production one; a value may only shorten its window (each key is capped at its
 production value); set, the boot prints `[test-timings] … overrides active`, and
 an unknown key or a bad value stops the start naming it.

package/MIGRATION_RENAME_TO_CHARNESS.md

@@ -20,7 +20,7 @@ start the bot renames the config and data dirs itself, see [Automatic migration]
 | `~/.telegramCode` — the default `DATA_DIR` | `~/.charness` | used while `~/.charness` does not exist (or holds no `state.json` while the old dir does); an explicit `DATA_DIR` is never touched |
 | `TELEGRAMCODE_HOT_RELOAD`, `TELEGRAMCODE_OPENCODE_PROCESS_FILE` | `CHARNESS_HOT_RELOAD`, `CHARNESS_OPENCODE_PROCESS_FILE` | read when the new one is unset; `charness hot` sets both |
 | MCP header `x-telegramcode-mcp-client-id` | `x-charness-mcp-client-id` | the bot's MCP server accepts both |
-| OpenCode plugin `telegramcode-compaction.js` (id `telegramcode-compaction`) | `charness-compaction.js` (id `charness-compaction`) | the old file is removed when the new one is installed |
+| OpenCode plugin `telegramcode-compaction.js` (id `telegramcode-compaction`) | `charness-compaction-<hash>.js` (id `charness-compaction`; the hash is of the plugin's text) | the old file is removed when the new one is installed |
 | Docker image `telegramcode`, service `telegramcode`, container `telegramcode-main` | `charness`, `charness`, `charness-main` | a container of the old image keeps running as it is |
 | `/opt/telegramcode`, `/home/telegramcode`, `/srv/telegramcode/…` (Docker mounts and host paths) | `/opt/charness`, `/home/charness`, `/srv/charness/…` | the new image's entrypoint accepts the old mount points |
 | `telegramcode-restart-bot` | `charness-restart-bot` | the old name is a link in the new image and says so |
@@ -130,4 +130,5 @@ you next rebuild the image:
 - `[deprecated] TELEGRAMCODE_HOT_RELOAD … the running charness hot supervisor still sets it`: restart the
   supervisor (above).
 - The OpenCode compaction plugin is reinstalled under its new name and the old file is deleted; a folder whose
-  OpenCode instance already loaded the old plugin keeps it until OpenCode is restarted.
+  OpenCode instance already loaded the old plugin is recreated at the bot's next start when nothing runs in it
+  (a working one keeps the old plugin until a later start finds it idle).