@cplieger/web-terminal-engine 3.9.0 → 3.10.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/jsr.json +1 -1
- package/package.json +1 -1
- package/src/status-stream.ts +23 -1
package/jsr.json
CHANGED
package/package.json
CHANGED
package/src/status-stream.ts
CHANGED
|
@@ -9,7 +9,7 @@ import { nextBackoffDelay } from "./reconnect.js";
|
|
|
9
9
|
|
|
10
10
|
/** SessionInfo is one session's wire shape: the JSON object the session REST
|
|
11
11
|
* API (GET/POST /api/sessions) returns per session. Mirrors the Go
|
|
12
|
-
* terminal.SessionInfo — the two are kept in lockstep by hand (single
|
|
12
|
+
* terminal.SessionInfo — the two are kept in lockstep by hand (single 8-field
|
|
13
13
|
* type; flip to wiregen if this surface grows).
|
|
14
14
|
*
|
|
15
15
|
* Three of the fields are title-shaped and they are not interchangeable:
|
|
@@ -46,6 +46,28 @@ export interface SessionInfo {
|
|
|
46
46
|
* empty means the session has no user-set name. */
|
|
47
47
|
readonly pinnedTitle?: string;
|
|
48
48
|
readonly createdAt: string;
|
|
49
|
+
/** the session's position in the display order every viewer of this server
|
|
50
|
+
* shares: 0-based, dense, and unique across the live set. Order is a property
|
|
51
|
+
* of the SESSION SET rather than of one browser, so two devices agree on the
|
|
52
|
+
* arrangement and a reorder made on one appears on the other. Set it with
|
|
53
|
+
* `PUT /api/sessions/order`, which takes every live id in the wanted order.
|
|
54
|
+
*
|
|
55
|
+
* Sort by this FIELD, not by the sequence sessions arrived in. The REST list
|
|
56
|
+
* and the status stream are both served in this order, but a consumer that
|
|
57
|
+
* merges them (subscribing before its bootstrap list resolves, which is how to
|
|
58
|
+
* avoid double-adopting a session) sees neither sequence intact.
|
|
59
|
+
*
|
|
60
|
+
* Absent from a server before 3.9.0, and from a status event carrying
|
|
61
|
+
* `removed` (the session has left the order). Treat absent as "this server has
|
|
62
|
+
* no shared order" and fall back to `createdAt`; do not read it as position 0,
|
|
63
|
+
* which belongs to a real session.
|
|
64
|
+
*
|
|
65
|
+
* One reorder arrives as one status event PER MOVED SESSION, so until you have
|
|
66
|
+
* applied a whole tick two sessions can hold the same position. Apply the tick,
|
|
67
|
+
* then sort. And never derive an order you WRITE BACK from a partly applied
|
|
68
|
+
* view: a list built from that hybrid still names the live set exactly, so the
|
|
69
|
+
* server accepts it and it becomes the arrangement every device sees. */
|
|
70
|
+
readonly order?: number;
|
|
49
71
|
/** true once the session has emitted a genuine activity signal — OSC 9;4
|
|
50
72
|
* progress (kiro-cli, Claude Code, …) or a classified OSC 9 notification.
|
|
51
73
|
* Sticky for the session's life. Consumers reveal the per-tab activity dot
|