@ours.network/cowork 1.1.1 → 1.1.2

package/docs/05-room-workflow.md

@@ -12,7 +12,7 @@ In the web console, choose Create room, enter Name, Goal, and Briefing, and subm
 
 Update the display name with `ours-cowork room settings <room-id> --name "New name"`; other mutable mission fields use the same `room settings` command. A new room identity is `ours-cowork:<bounded creation name>`: NFC normalization followed by the first 52 Unicode code points, for a 64-code-point maximum including the prefix. That authenticated name is persisted and frozen. Messenger displays the retained human-readable prefix from the identity itself; longer local `room_name` metadata remains available in Cowork. Renaming a room changes only mutable local metadata; it does not change the identity name, CID, contacts, invites, URLs, history, or earlier author labels. Because identity names are daemon-global, the same normalized name—or distinct long names sharing the retained prefix—collides and fails cleanly without a losing room sentinel. Earlier unreleased ID- and slug-based formats are unsupported and receive no migration. Inspect admitted seats with `room participants`. A room activates only when its recorded invite requirement is satisfied.
 
-Runtime membership commands are default-deny. Per-CID grants use `command-grant` and `command-revoke`. An operator may instead register a durable role policy with `role-command-set <room-id> --role <label> --commands <comma-list>` and inspect it with `role-command-grants`; use `--commands none` to remove it. A role policy authorizes only an authenticated, active seat whose durable admission role exactly matches the policy. Display names, message labels, pending seats, removed seats, and caller-supplied role text never confer authority. Removing a role policy does not remove an independently configured per-CID grant.
+Runtime commands are default-deny. Per-CID grants use `command-grant` and `command-revoke`. An operator may instead register a durable role policy with `role-command-set <room-id> --role <label> --commands <comma-list>` and inspect it with `role-command-grants`; use `--commands none` to remove it. A role policy authorizes only an authenticated, active seat whose durable admission role exactly matches the policy. Display names, message labels, pending seats, removed seats, and caller-supplied role text never confer authority. Removing a role policy does not remove an independently configured per-CID grant.
 
 Membership changes are deliberately independent operator actions. Add a participant by issuing an invite for the intended role and admitting that identity; remove a participant with `ours-cowork room remove <room-id> <participant>`. To preserve coverage, add and confirm the new participant before removing the old one. To remove a dead participant first, remove it and issue a new invite afterward. Cowork does not combine these actions into a replacement operation or infer successor lineage.
 
@@ -25,3 +25,15 @@ If the shared daemon restarts or a room SDK lease is lost, Cowork automatically
 Use `ours-cowork room rebind <room-id>` for explicit recovery. This canonical operation applies the same name-and-CID proof, refreshes SDK contact/invite state, reconciles the room, and resumes durable pending fanout before reporting success. It refuses closing or closed rooms. Structured daemon logs emit `identity_rebind_*` and `startup_room_recovery_failed` events for diagnosis.
 
 Every web action has an equivalent CLI fallback in the room commands above and in the invites and messaging topics.
+
+## Shared ours command calls
+
+Room-scoped operations also appear in the room identity's ours catalog with their RPC names: `room.settings`, `room.briefing.role.set`, `room.briefing.role.delete`, `room.invite`, `room.participant.remove`, `room.revoke`, `room.recover`, `room.recover.confirm`, `room.show`, `room.participants`, `room.command.grants`, `room.command.role.grants`, `room.command.role.set`, `room.command.grant`, `room.command.revoke`, `room.history`, `room.message`, `room.say`, `room.role.rest.add`, `room.role.rest.remove`, `room.accept`, `room.rebind`, `room.close`, and `room.delete`.
+
+Use the RPC arguments without `room_id`; the receiving room fixes the target. For example, an operator grants `ours-cowork room command-grant <room-id> <caller-cid> room.settings`, then that active member calls `room.settings` with `{"status":"review"}` using ours command transport. A grant for one name grants none of the other names. The SDK returns a correlated result containing `{ok:true,result:<service value>}` or `{ok:false,error:<code>}`. History returns one page; follow `seq` with `after` to fetch more.
+
+`list-members` retains its contact-safe roster. `remove-member` retains its epoch, confirm and no-self-removal gates. The separate `room.participant.remove` command instead grants the full operator removal behavior. `room.show`, `room.participants` and operator-view history return operator metadata. Policy-administration commands can delegate more privileges; `room.message` and `room.say` authorize room/role authorship. Assign these permissions deliberately. Command results may include invite material; do not relay them into chat.
+
+Host lifecycle and global room creation/listing are excluded. `room.accept` accepts invitation input through its separate grant and remains unavailable through REST. Ours close/delete return a durable accepted receipt before closing the reply channel; verify completion through management. Close retains archive/files; delete requires `confirm:true`, closes first, and erases local room data. Pending lifecycle requests resume after restart; failed requests remain visible in room metadata for explicit management retry. Missing replies do not prove a mutation failed. Dynamic consumer registration is not implemented.
+
+The SDK owns command reply delivery and its size limits. Large history pages or a single large file record may exceed that transport's capacity; use CLI/REST for those results. No additional result-omission contract is introduced.

package/docs/10-limitations.md

@@ -10,7 +10,7 @@
 - The shared daemon's history database and cowork's room archive are separate durable stores with no cross-store transaction. Cowork orders archive and recipient-intent durability before advancing SDK unread state, but a crash can still leave an already-archived SDK row unread; source IDs make that replay idempotent.
 - Backups require a stopped cowork daemon. Back up and restore the complete cowork state directory as one unit, preserving ownership and modes; protect shared identity state separately through the shared daemon's operator procedure.
 - Service uninstall retains data. It removes the cowork systemd or launchd definition, not configuration, archives, room metadata, or identities in the shared daemon.
-- Closing and deleting are separate. First close the room explicitly with `ours-cowork room close <room-id>`. Only a closed room can then be deleted with `ours-cowork room delete <room-id> --yes`.
+- Closing retains room metadata, archive and files. `ours-cowork room delete <room-id> --yes` closes the room if necessary, then erases all local room data. Ours close/delete replies acknowledge durable acceptance; management state determines completion.
 - Confirmed deletion removes the retained archive and metadata from this host only. It does not claim remote purge, backup erasure, key wipe, or secure erase.
 - The web console and HTTP room RPC have no authentication. They bind only to `127.0.0.1` and must not be forwarded, proxied, or exposed remotely.
 - Web updates use periodic polling rather than push. A view can lag daemon state until its next refresh; confirmed mutations trigger an immediate refresh.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/cowork",
-  "version": "1.1.1",
+  "version": "1.1.2",
   "description": "Durable ours mission rooms on the shared ours daemon.",
   "type": "module",
   "license": "FSL-1.1-Apache-2.0",