@stratusagent/agents 0.12.0 → 0.12.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@stratusagent/agents",
-  "version": "0.12.0",
+  "version": "0.12.2",
   "type": "module",
   "main": "./dist/index.js",
   "types": "./dist/index.d.ts",
@@ -18,7 +18,7 @@
     "node": ">=22.13 <23 || >=23.4"
   },
   "dependencies": {
-    "@stratusagent/core": "0.12.0"
+    "@stratusagent/core": "0.12.2"
   },
   "devDependencies": {
     "@types/node": "^24.6.0",

package/skills/stratus/SKILL.md

@@ -58,7 +58,7 @@ A project-local `stratus.config.json` ships inside repositories, so it is **untr
 
 When a setting "isn't taking", these say why:
 
-- `stratus doctor` shows what `stratus run` and `stratus chat` would use, and which file or variable decided each value.
+- `stratus doctor` shows what `stratus run` and `stratus chat` would use, and which file or variable decided each value. When a daemon is running it also asks it what it warned about at start, and says when the config has changed since then (a restart applies it).
 - `stratus agents` shows what each agent on the roster runs on.
 - `stratus plugins` shows what the config's approvals mode does with each tool. `stratus serve --approvals` overrides that mode. A daemon in `remote` logs an `approvals: remote` line at startup, so a `stratus logs` with no such line since the last start means `headless`.
 
@@ -114,12 +114,12 @@ When a stored key "isn't found", check in this order:
 - `stratus setup` → Plugins installs, enables, and asks for settings like roots in one step.
 - Enabled is not granted: your soul's `tools:` must also cover a plugin's tools. `stratus plugins` walks the whole chain for each tool (installed, enabled, granted to which agents, and what approvals do with a call), so it answers "why can't you use X" in one command.
 - **Risk.** Every tool is `safe`, `gated`, or `dangerous`. The daemon runs `safe` tools unattended, among them `memory.*`, `skill.read`, `credential.request`, `agent.delegate`, `schedule.list`, `schedule.cancel`, and `fs.read`, `fs.list`, and `fs.search`. Gated tools include:
-  - `web.fetch`, `fs.write`, `shell.run`, `browser.*`, and `mcp.*`;
+  - `web.fetch`, `fs.write`, `fs.move`, `shell.run`, `browser.*`, and `mcp.*`;
   - `schedule.every`, `schedule.at`, `message.send`, and `message.read` (which reads a channel your Slack app is in, never a DM, and labels what it returns `external`);
   - every third-party tool, `web.search` included.
   - What happens to a gated call depends on the approvals mode. Under `headless` (the default) it is refused. Under `remote` the people in `approvals.slackApprovers` are asked in Slack (or through the control API's `/approvals`) with **Allow once**, **Always allow**, and **Deny**. Under `remote` with nobody to ask, it is refused too.
-  - Either way, what was already approved still runs unattended. For `shell.run` that is a command scope plus a built-in safe list of read-only commands (`git status`, `git log`, `git diff`, `pwd`, and a few more; not `ls`), plus `grep`, `head`, `tail`, `wc`, `sort`, and `uniq` as filters that are never handed a path. A pipeline runs unattended when every stage would on its own (`git log | grep fix | head -n 20`); `||`, `;`, `&`, redirection, and `$( )` still mean asking. For `browser.act` and `web.fetch` it is an approved site (a `web.fetch` redirect to another site is reported as `redirectedTo`, not followed), and for other gated tools a standing grant.
-  - The exception is `approvals.externalContent: "gate"`, set for every agent or per agent under `approvals.agents.<id>`. Once your conversation has read external content (`web.fetch`, `browser.*`, `web.search`, or an `mcp.*` tool), no grant applies for the rest of it: every gated call is asked or, headless, refused, and **Always allow** is not offered. `safe` tools, the built-in read-only commands, and a schedule's pre-authorized destination still run. Your next conversation starts with its grants again.
+  - Either way, what was already approved still runs unattended. For `shell.run` that is a command scope plus a short built-in safe list (`pwd`, `whoami`, and `uname`; not `ls`, and no `git` command, not even `git status`, since git runs programs a repository names), plus `grep`, `head`, `tail`, `wc`, `sort`, and `uniq` as filters that are never handed a path. **Always allow** on a git command keeps that scope. A pipeline runs unattended when every stage would on its own (with a `git log` scope approved, `git log | grep fix | head -n 20`); `||`, `;`, `&`, redirection, and `$( )` still mean asking. For `browser.act` and `web.fetch` it is an approved site (a `web.fetch` redirect to another site is reported as `redirectedTo`, not followed), and for other gated tools a standing grant.
+  - The exception is `approvals.externalContent: "gate"`, set for every agent or per agent under `approvals.agents.<id>`. Once your conversation has read external content (`web.fetch`, `browser.*`, `web.search`, or an `mcp.*` tool), no grant applies for the rest of it: every gated call is asked or, headless, refused, and **Always allow** is not offered. `safe` tools, the built-in safe list (`pwd`, `whoami`, `uname`, and the stdin filters), and a schedule's pre-authorized destination still run. Your next conversation starts with its grants again.
   - **Always allow** writes one of those to `agents/<id>/whitelist.json`, except for a tool that names a destination, such as `message.send`, where it lasts for the conversation. A `dangerous` call is never offered it.
   - `stratus grants <id>` lists the grants, and `stratus grants revoke <id> --tool|--scope|--origin` takes one back. There is no command to add one: a headless daemon asks nobody, so it never creates a grant, and a call nobody has approved yet needs `remote` mode first.
 
@@ -142,7 +142,7 @@ When a stored key "isn't found", check in this order:
 - With several agents in one thread, an untagged reply goes to whoever spoke last. Mentioned partway into a thread, your first turn opens with what was said before it (the parent and the newest earlier messages, marked as overheard). Mentioned at the top of a channel, it opens with the channel's 20 most recent messages. Both need the Slack app's history scopes. Without them you hear the thread from the mention onward only. A stranger or another bot among those earlier messages lowers the conversation's trust as if they had spoken to you.
 - **Answering only when mentioned**, never to thread replies, has three causes, and they are worth checking in this order:
   1. `listens: mentions` in your soul.
-  2. Another agent spoke last in that thread.
+  2. Another agent spoke last in that thread. That includes an agent on another daemon or machine, and any other app's bot that posted there.
   3. The app is missing the history scopes (`channels:history`, `groups:history`, `mpim:history`) and their `message.*` events, which means adding them and reinstalling the app.
 
   Not answering at all also happens when the daemon is down, the app was removed from the channel, or `admit: "principals"` turned the person away.