@ours.network/cowork 0.3.0 → 0.3.2

package/docs/05-room-workflow.md

@@ -3,14 +3,14 @@
 Create a room and inspect its host-owned identity:
 
 ```sh
-ours-cowork room create --goal "Ship the fix" --briefing "Review evidence first"
+ours-cowork room create --name "Release bridge" --goal "Ship the fix" --briefing "Review evidence first"
 ours-cowork room list
 ours-cowork room show <room-id>
 ```
 
-In the web console, choose Create room, enter Goal and Briefing, and submit once. The created room is selected automatically and its Invite panel opens. Add invitation requirements one at a time; the UI does not combine room creation and invites into a fabricated atomic operation.
+In the web console, choose Create room, enter Name, Goal, and Briefing, and submit once. Names are trimmed and Unicode NFC-normalized, must contain 1–64 Unicode characters, and cannot contain Unicode control or format characters. Duplicate names are allowed. The created room is selected automatically and its Invite panel opens. Add invitation requirements one at a time; the UI does not combine room creation and invites into a fabricated atomic operation.
 
-Update mutable mission fields with `room settings`. Inspect admitted seats with `room participants`. A room activates only when its recorded invite requirements are satisfied. Roles are display labels; participant identity CIDs, not roles, are authorization keys.
+Update the display name with `ours-cowork room settings <room-id> --name "New name"`; other mutable mission fields use the same `room settings` command. The display name is persisted as `room_name`, while the opaque `room_id` remains the stable routing, URL, storage, and identity-correlation key. The underlying room identity is not renamed. Existing unnamed rooms receive the deterministic display name `Room <first 8 room_id characters>` when loaded. Inspect admitted seats with `room participants`. A room activates only when its recorded invite requirements are satisfied. Roles are display labels; participant identity CIDs, not roles, are authorization keys.
 
 Close with `ours-cowork room close <room-id>`. Close is forward-only and removes live room packet state while retaining the local archive. Archive deletion is a separate explicit operation described in the limitations topic.
 

package/docs/07-messaging-history.md

@@ -17,8 +17,16 @@ ours-cowork room history <room-id>
 ours-cowork room history <room-id> --after 40 --limit 20
 ```
 
-Participant messages are accepted only from durable seats in an active room. History records include messages and the durable relay intent/result trail used for restart recovery.
+Daemon history responses are capped at 3 MiB of JSON so one 2 MiB file record (about 2.8 MiB after base64 expansion) remains retrievable without allowing an unbounded management response. A page may therefore contain fewer records than `--limit` even when more records exist. Continue from the last returned `seq` with `--after`; only an empty page means end of history. The CLI follows these byte-short pages automatically and still prints up to the requested record limit.
 
-The web console projects participant and room-authored messages plus the briefing into Communication. Relay, recovery, close, and failure records are excluded from chat and shown in Events; Archive retains the complete ordered record stream. Messages appear only after the authoritative history refresh observes them.
+Participant messages and files are accepted only from durable seats in an active room. A file is opaque binary data: cowork neither interprets its MIME metadata nor executes its contents. Its filename must be a path-free name of at most 255 UTF-8 bytes (not `.`, `..`, or a name containing `/`, `\\`, or NUL); MIME metadata may be empty and is limited to 255 UTF-8 bytes. Zero-byte files are valid. The maximum file size is 2 MiB (2,097,152 bytes), and a larger file is rejected explicitly.
+
+Before consuming an incoming file from packet state, cowork durably archives its exact bytes as canonical base64 together with size and SHA-256, then durably creates every per-recipient relay intent. Each other active seat receives two core-protocol items: a signed `room_file` metadata envelope and a binary file containing the original bytes. Core receives bytes, never a local filesystem path, so there is no staging-file or path-permission dependency. A seat removed after fan-out is skipped terminally without receiving metadata or bytes. A crash can redrive an unfinished recipient from the archived bytes; an already terminal recipient is not retried.
+
+In an anonymous room, signed file metadata identifies the author only by participant ID and alias. The operator archive still retains the real author and exact file bytes. The participant-facing history projection currently contains messages only; file records remain visible in the complete operator Archive/CLI history, while recipients retrieve file bytes through their ordinary ours file inbox.
+
+History records include messages, files, and the durable relay intent/result trail used for restart recovery.
+
+The web console projects participant and room-authored messages plus the briefing into Communication. Relay, file, recovery, close, and failure records are excluded from chat and shown in Events; Archive retains the complete ordered record stream, including archived file bytes. Messages appear only after the authoritative history refresh observes them.
 
 Version one polls rather than receiving pushed updates: the room list refreshes every five seconds, while the selected room, participants, and history refresh every two seconds. Polling pauses in a hidden tab, coalesces overlap, and refreshes after confirmed mutations. CLI history remains the fallback when a browser is unavailable.

package/docs/10-limitations.md

@@ -1,6 +1,8 @@
 # Limitations
 
-- The retained archive is plaintext on this host. Filesystem ownership and `0700`/`0600` modes limit local access, but the archive is not encrypted at rest by ours-cowork.
+- The retained archive is plaintext on this host, including exact participant file bytes encoded as base64. Filesystem ownership and `0700`/`0600` modes limit local access, but the archive is not encrypted at rest by ours-cowork.
+- Files are opaque bytes. Cowork records MIME as untrusted metadata and does not inspect content, scan for malware, execute it, or infer safety from the filename or MIME value. Recipients must apply their own content policy.
+- Files are limited to 2 MiB (2,097,152 bytes). Larger files are rejected loudly because the pinned core cannot provide the same retained, unacknowledged delivery and archive-redrive guarantee for them. There is no chunking or local path staging in this release.
 - Invite secrets exist only for the process lifetime that minted them and in the receipt returned to the operator. Durable room metadata stores descriptors, not invite blobs. A prior one-time or public secret is not reconstructable; a durable invite marked as needing replacement requires explicit recovery to mint a new secret.
 - Relay recovery is at-least-once. A crash after transport acceptance but before the durable result can retry a send, so participants may observe duplicates. The system does not provide exactly once relay semantics.
 - The host records transport acceptance and failures; it does not observe delivery, reading, or remote processing. A successful operator command must not be interpreted as participant receipt.

package/docs/11-web-console.md

@@ -12,13 +12,15 @@ The console and HTTP room RPC have no authentication. They bind only to `127.0.0
 
 ## Room setup
 
-1. Choose Create room and enter the Goal and Briefing.
+1. Choose Create room and enter the friendly Name, Goal, and Briefing. The name is shown in the room list, workspace header, and room details.
 2. Submit once. The new room is selected and its Invite panel opens.
 3. Add one invitation requirement at a time. Choose one-time or public mode and set the minimum acceptances for a public invite.
 4. Copy every invite from its blocking receipt before choosing Done. The secret is shown once and is not retained in browser storage, the URL, logs, or durable room metadata.
 
 The room activates after its durable invitation requirements are satisfied. Participants shows admitted identities and their invite roles.
 
+Friendly names are trimmed and Unicode NFC-normalized, must contain 1–64 Unicode characters, and cannot contain Unicode control or format characters. Duplicate names are allowed. Change a name in Room settings. The browser continues to route by the opaque room ID; renaming does not change the URL, storage key, or underlying room identity. Existing unnamed rooms appear as `Room <first 8 room_id characters>`.
+
 ## Communication and records
 
 Communication is the human-readable chat: room and participant messages plus the mission briefing. Messages are not inserted optimistically; a sent message appears after the daemon's ordered history includes it. Events contains relay, recovery, close, and failure details. Archive contains the complete sequence-numbered stream and can show earlier loaded rows.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ours.network/cowork",
-  "version": "0.3.0",
+  "version": "0.3.2",
   "description": "Standalone daemon for durable ours mission rooms.",
   "type": "module",
   "license": "FSL-1.1-Apache-2.0",