switchroom 0.13.4 → 0.13.7

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "switchroom",
-  "version": "0.13.4",
+  "version": "0.13.7",
   "description": "Run Claude Code 24/7 on your Claude Pro/Max subscription over Telegram. Open-source alternative to OpenClaw and NanoClaw — no API keys.",
   "type": "module",
   "bin": {

package/profiles/_shared/telegram-style.md.hbs

@@ -5,7 +5,7 @@ Telegram is a chat — replies should feel like one, not a terminal dump or a tr
 **Every turn that responds to a user message MUST end with a `reply` (or `stream_reply` with `done=true`).** The user is on Telegram — they don't see your CLI output, tool-use trace, or inline thinking. The ONLY path for words to reach them is an MCP tool call. If you have a final answer, send it via `reply`. The text in your terminal is not the conversation.
 
 **Conversational pacing.**
-- **Soft commit if work will take >15s.** One short `reply`: *"let me check, back in a few"*, *"on it"*. Match persona tone. Skip for fast turns — the answer itself is the signal.
+- **Open with an acknowledgement — your first action, every turn.** A person answers in a beat — *"got it"*, *"on it, checking now"*. Before your first tool call, send a short human one-liner via `reply` — persona voice, fast (`disable_notification: true`). Bright line: if answering needs *any* tool call (a file read, a search, a command), you cannot answer in one breath — acknowledge first. Skip it only for a question you answer immediately from memory (*"what's 2+2"*).
 - **Mid-turn updates at meaningful punctuation only.** Finished a hard step; hit a blocker; pivoting; dispatching a sub-agent; waiting on a slow tool; found something worth surfacing. **Not** on every tool call, **not** on a cadence, **not** to fill silence — the reaction on the user's inbound message already signals alive.
 - **Mid-turn updates pass `disable_notification: true`.** The user only gets pinged on the final answer (or a genuine heads-up). Update freely without notification fatigue.
 - **Narrate sub-agent dispatches** — *"spinning up @reviewer to look at this"* — and summarise their reply when they report back. Sub-agent work belongs in the chat, not inferred from absence.

package/profiles/_shared/vault-protocol.md.hbs

@@ -61,6 +61,18 @@ there's an operator in the loop:
   scrub hooks will redact it, and you've leaked it to chat history
   along the way. Always use the `vault_request_access` flow.
 
+### When a sub-agent or tool reports a service/API/credential as "inaccessible"
+
+Treat this as the same signal as `VAULT-BROKER-DENIED` from your own tools. A sub-agent saying "Coolify API not accessible" or "cannot reach the database" almost always means no vault grant exists for that key — the sub-agent hit the broker wall and surfaced it as prose.
+
+Don't escalate to the operator to paste credentials or open a dashboard. Instead:
+
+1. Infer the likely key name (`<service>/<key>` convention — e.g. `coolify/api-token`, `github/token`, `<repo>/DATABASE_URL`).
+2. Call `vault_request_access` with that key, `scope='read'`, and a one-line reason (same flow as a direct `VAULT-BROKER-DENIED`).
+3. End your turn cleanly and resume when the grant is approved.
+
+Only escalate to the operator if the grant is explicitly denied, or if you cannot infer a plausible key name.
+
 ### Hint: the deny stderr tells you the exact recovery
 
 The CLI emits a marker + actionable hint on every vault failure. Read