@fidacy/openclaw-plugin 0.5.10 → 0.6.1

package/CHANGELOG.md

@@ -1,5 +1,37 @@
 # Changelog
 
+## 0.6.1
+
+### Patch Changes
+
+- Declaring one system no longer locks the agent out of every other one.
+
+  Found by installing the published 0.8.0 from npm and using it: declaring only the CRM immediately blocked `gmail` and `hubspot` too. Strict whitelist semantics say everything off the list falls, but "these are my systems" reads, to the person writing it, as the list of systems they want governed — not an exhaustive inventory of everything the agent touches. Someone trying Fidacy would declare one system, watch their agent break everywhere else, and uninstall before understanding why.
+
+  The default now governs what you declared. Full lockdown is one word away: `"unknownDestinations": "block"` refuses anything heading somewhere you never listed. The strong property is still there, it just stopped being a trap and became a decision you make knowingly.
+
+  The declared system is governed exactly as before either way.
+
+## 0.6.0
+
+### Minor Changes
+
+- The firewall stops governing only the verb and starts governing the destination, which is the axis an agent cannot rename.
+
+  **Why this exists.** Verified against the published binary: with all eight action classes blocked, `mcp__pipedrive__deals_export`, `mcp__pipedrive__update_person`, `curl api.pipedrive.com` and a WebFetch to the same host all went through. A verb list is infinite and always behind; an agent that wants to export your CRM only has to call the tool something else. But no action can avoid having a destination: every access has a host, an MCP server or a path. The destination is a short list you write once, and a destination you never declared no longer passes in silence. Same polarity the payment firewall always had: never "block the bad payees", always "only these".
+
+  **What you can now say.** "My agent reads Pipedrive, but never exports or modifies anything, and never touches a system I did not declare." Three lines of config, enforced offline, and both the allow and the refusal are signed.
+
+  **`ask`, the mode that keeps the firewall from being bureaucracy.** Without it there are only two extremes, and a tool that only blocks gets switched off so the agent can work. An unusual action now neither passes nor stalls the agent: it is refused immediately with a message that says it is a pending question, not a verdict, and approving it lets the retry through.
+
+  **Three bugs found and fixed while building this**, each caught by a test before it reached anyone:
+
+  - The normalisation written to prevent evasion was creating it: collapsing separators everywhere turned `rm -rf` into `rm .rf` and destroyed the flag.
+  - `classifyAction` only lowercased, so `mcp__gmail__email_send` never matched the `email.send` pattern because of one separator, and `verb_with_underscore` is how every MCP server names a tool. A class in `ask` was letting through the exact action it governs.
+  - Normalising the patterns trimmed `'rm '` into `'rm'`, which then matched `crm`, `form` and `confirm`. `hubspot.crm.export` was being classified as deleting files, and a false positive that blocks innocent work is the fastest route to being uninstalled.
+
+  **The first-run config now writes itself out in full.** It only ever contained the `mandate` block, so nobody discovered that `systems` and `actionClasses` exist: the whole destination axis was built and invisible. `systems` starts empty and `actionClasses` start in `log`, so nothing changes for an existing agent until you tighten it.
+
 ## 0.5.10
 
 ### Patch Changes