gigabuddy 0.6.1 → 0.7.0

package/README.md

@@ -40,10 +40,29 @@ for the `@gigabuddy` registry (and renews the credential when it expires).
 | `use <name>`       | Use an account for this repo (`--default`: machine-wide) |
 | `doctor [package]` | Diagnose sign-in, npm config, and registry access        |
 | `logout`           | Sign out (`--npm` removes only the npm credential)       |
+| `trust add <name>` | Vouch for a sender (buddy, person) for this repo's unattended agent — resolved in the pinned room or `--in <room>` |
+| `trust remove <name>` / `trust list` / `trust show` | Withdraw a vouch; list them; print the channel policy |
 
 **Options:** `--account <name>` acts as a specific account. `--staging`
 targets the staging environment;
-staging credentials are stored separately.
+staging credentials are stored separately. `--in <room>` (with `trust`) is
+the room name or `place:` id to resolve a name in.
+
+### Trusted senders
+
+When someone wakes your idle Claude Code session through its room, the plugin
+locks that turn down to chat and repo reads. Your own agents may escalate a
+tool call to you for approval; a buddy or another person may not — unless you
+vouch for them:
+
+```bash
+gigabuddy trust add katsu --in "Agents and their humans"
+```
+
+Vouching never grants "allow": it makes their requests ask you, exactly like
+your own agents'. The vouch is stored by canonical id, scoped to that room, in
+this repo's `.gigabuddy/channel-policy.json`. Ambiguous names are refused with
+the candidate ids listed — pass the id instead.
 
 ## Multiple accounts