@gotcos/glasses-server 6.36.1 → 6.36.3

package/CHANGELOG.md

@@ -2219,6 +2219,57 @@ unsaved capture, and makes batch status stop lying about finished work.
 
 # Changelog
 
+## [6.36.3] - 2026-08-17
+
+### The seeded query was being crowded out by the steps
+
+Caught by probing the live stream after shipping 6.36.2, before Miles tested it: a
+real session seeded 8 events -- 6 tool calls, one prose, one status -- and **no
+prompt**. The seed took "the last 7 events of any kind", and in a busy run the
+user's question is twenty or thirty steps back, so the activity you opened the page
+to watch is exactly what pushed the query off it. The one case the feature exists
+for was the one case it failed.
+
+The newest prompt in the read window is now emitted FIRST and unconditionally,
+outside the step budget. Measured on this Mac's largest transcript (87.2 MB): the
+last 256 KiB holds 133 records including 3 user turns, so the window reaches a query
+comfortably. The client pins rather than lists it, so it costs nothing in the
+scrolling window.
+
+## [6.36.2] - 2026-08-17
+
+### The live view stops being a blank slate
+
+Three changes, all from Miles watching a real session on hardware.
+
+- **The user's query is now an event.** A `user` record used to be dropped whole,
+  on the reasoning that "the prompt came from this device" -- true of a Continue
+  turn and false of the case that matters most, a session running in a Mac window
+  where that record is the question Miles typed there and the glasses have never
+  seen it. Dropping it is why the lens said WORKING and gave no clue what it was
+  working ON. Tool results stay dropped; harness wrappers
+  (`<system-reminder>`, `<cos-alarms>`, the memory and bulletin blocks) are
+  stripped, because on the lens they would read as the user's own words.
+  New `prompt` kind: additive to a closed set, and safe by construction since the
+  client validates `kind` against its own table and ignores what it does not know.
+
+- **A shell command is summarised instead of sent raw.** `bash ses...` and
+  `bash s...` on the lens were a command reduced to two characters. Two causes
+  compounding, and this is one of them: the leading `cd <path>` (identical on
+  every command in a repo), heredoc BODIES, and output plumbing (`2>&1`, pipes
+  into `head`/`sed`) are now dropped, keeping the verb and its arguments -- what
+  you would look for reading over someone's shoulder.
+
+- **The stream seeds from history on connect.** The tail starts at the file's
+  current size, so opening a session that was already working showed an EMPTY page
+  that filled one line at a time. It now reads backward a bounded 256 KiB, drops
+  the leading fragment (an arbitrary offset lands mid-record), and replays the last
+  7 steps -- exactly the client's live window, so the seed fills the screen once
+  without pushing live events out of the view it exists to prime. Never fatal: a
+  session whose history cannot be read still streams, it just starts empty.
+
+Needs COS Glasses 6.8.374 to render any of it.
+
 ## [6.36.1] - 2026-08-17
 
 ### A reply keeps its line structure

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gotcos/glasses-server",
-  "version": "6.36.1",
+  "version": "6.36.3",
   "description": "COS Glasses \u2014 self-hosted AI heads-up-display server for Even G2 smart glasses, powered by Claude Code, Codex, or Cursor Agent CLI",
   "type": "module",
   "bin": {

package/server/lib/session-stream-events.ts

@@ -25,6 +25,14 @@ export type SessionStreamState = 'working' | 'idle' | 'done'
 
 export type SessionStreamDraft =
   | { kind: 'tool'; verb: SessionStreamVerb; target: string; detail: string }
+  // The user's own words for the turn being worked on. Miles: "we should see the query
+  // that the user has versus it just being a blank slate where it says working. That
+  // way, the user at least knows what the agent is actively working on."
+  //
+  // ADDITIVE TO A CLOSED SET, AND SAFE BY CONSTRUCTION: the client validates `kind`
+  // against its own table and ignores anything it does not know, so a build that
+  // predates this renders exactly as it did before rather than breaking.
+  | { kind: 'prompt'; text: string }
   | { kind: 'prose'; text: string }
   | { kind: 'status'; state: SessionStreamState }
   | { kind: 'heartbeat' }
@@ -52,6 +60,16 @@ export const TARGET_MAX_CHARS = 80
 /** `+14 -2`, `120 lines`. Anything longer is not a detail. */
 export const DETAIL_MAX_CHARS = 40
 
+/**
+ * The user's query, in characters.
+ *
+ * 160 rather than the 80 a target gets: this is the one line that says WHAT IS BEING
+ * WORKED ON, so it earns more than a tool name does. The client clips it to the two
+ * lens lines it can spare, which at 62 columns is ~120 visible; the extra 40 is
+ * headroom so the client rather than the server decides where to cut.
+ */
+export const PROMPT_MAX_CHARS = 160
+
 /**
  * Marker appended when a value was cut.
  *
@@ -124,6 +142,53 @@ function countLines(value: unknown): number {
   return value.split('\n').length
 }
 
+/**
+ * The part of a shell command worth 40 columns.
+ *
+ * WHAT WENT WRONG ON HARDWARE. Miles's 9:20 screenshot showed `bash ses...` and
+ * `bash s...` -- a shell command reduced to two characters. Two causes compounding:
+ * the raw command was sent whole, and the CLIENT then treated it as a PATH and kept
+ * only the text after the last `/`. So `cd /Users/.../cos-glasses-app && grep -n x
+ * src/lib/session-stream-trail.ts` arrived, got split on its final slash, and rendered
+ * as the tail of a filename. The client fix is necessary; this is the other half.
+ *
+ * WHAT IT DROPS, in order of how much noise it removes:
+ *  - a leading `cd <path>` and its separator. Every command in this repo starts with
+ *    one and it is the same directory every time: pure cost, zero information.
+ *  - heredoc BODIES. A `<<'PY' ... PY` block is often hundreds of lines, and none of
+ *    them is the command; the marker is kept so it is clear a script ran inline.
+ *  - `2>&1`, pipes into output plumbing (`head`, `tail`, `sed`, `tr`, `cut`) and
+ *    redirections, which are how you read a command rather than what it does.
+ *
+ * WHAT IT KEEPS: the first real verb and its arguments, which is what you would look
+ * for on a monitor over someone's shoulder.
+ */
+export function commandSummary(command: string): string {
+  let text = command.replace(/\r/g, '')
+
+  // Heredoc body out, marker kept: `python3 - <<'PY' ...body... PY` -> `python3 - <<PY`
+  text = text.replace(/<<-?\s*'?"?([A-Za-z_][A-Za-z0-9_]*)'?"?[\s\S]*?^\1\s*$/gm, '<<$1')
+  text = text.replace(/<<-?\s*'?"?([A-Za-z_][A-Za-z0-9_]*)'?"?[\s\S]*$/m, '<<$1')
+
+  text = text.replace(/[\r\n\t]+/g, ' ').replace(/\s{2,}/g, ' ').trim()
+
+  // Leading `cd <path>` plus its separator, however the command chained it. Repeated
+  // because a command can open with more than one.
+  for (let i = 0; i < 3; i++) {
+    const next = text.replace(/^cd\s+(?:"[^"]*"|'[^']*'|\S+)\s*(?:&&|;|\|\||\n)?\s*/, '')
+    if (next === text) break
+    text = next
+  }
+
+  // Output plumbing off the end. The command is what ran, not how it was read.
+  text = text.replace(/\s*2>&1\s*/g, ' ')
+  text = text.replace(/\s*\|\s*(?:head|tail|sed|tr|cut|wc|sort|uniq|grep -o|cat)\b[^|]*/g, '')
+  text = text.replace(/\s*>\s*\/dev\/null(?:\s*2>&1)?/g, '')
+
+  const flat = text.replace(/\s{2,}/g, ' ').trim()
+  return flat.length > 0 ? flat : command.trim()
+}
+
 /**
  * What this tool acted ON.
  *
@@ -142,7 +207,9 @@ export function targetForTool(name: unknown, input: unknown): string {
 
   if (lower === 'bash' || lower === 'shell' || lower === 'exec' || lower === 'exec_command') {
     const command = args.command ?? args.cmd
-    if (typeof command === 'string' && command.length > 0) return oneLine(command, TARGET_MAX_CHARS)
+    if (typeof command === 'string' && command.length > 0) {
+      return oneLine(commandSummary(command), TARGET_MAX_CHARS)
+    }
   }
 
   for (const key of ['pattern', 'query', 'skill', 'description', 'subject', 'prompt']) {
@@ -233,6 +300,41 @@ function draftsFromContentBlocks(message: Record<string, unknown>): SessionStrea
   return out
 }
 
+/**
+ * The user's query out of a user record, or nothing.
+ *
+ * WHAT IS DELIBERATELY NOT A PROMPT:
+ *  - a `tool_result` block. The call was announced when it was made.
+ *  - a harness-injected wrapper. `<system-reminder>`, `<local-command-stdout>`,
+ *    `<command-name>` and the memory/bulletin blocks arrive as user turns and are not
+ *    anything a person asked. Showing one on the lens would be worse than showing
+ *    nothing, because it reads as the user's own words.
+ *  - an empty string after cleaning.
+ */
+export function promptDrafts(message: Record<string, unknown>): SessionStreamDraft[] {
+  const content = message.content
+  const blocks = Array.isArray(content)
+    ? content
+    : typeof content === 'string' ? [{ type: 'text', text: content }] : []
+
+  const parts: string[] = []
+  for (const raw of blocks) {
+    const block = asRecord(raw)
+    if (!block) continue
+    if (block.type === 'tool_result') return []
+    if (block.type !== 'text' && block.type !== undefined) continue
+    if (typeof block.text === 'string') parts.push(block.text)
+  }
+
+  let text = parts.join(' ')
+  // Wrapper blocks out, whole. A partial strip would leave the tag names on the lens.
+  text = text.replace(/<(system-reminder|relevant-memories|cache-health|daily-bulletin|cos-alarms|device-handoff|now|memory-stored|local-command-stdout|local-command-stderr|command-name|command-message|command-args)>[\s\S]*?<\/\1>/g, ' ')
+  const flat = oneLine(text, PROMPT_MAX_CHARS)
+  // A record whose ONLY content was a wrapper leaves nothing worth a line.
+  if (!flat || /^</.test(flat)) return []
+  return [{ kind: 'prompt', text: flat }]
+}
+
 function draftsFromClaudeRecord(record: Record<string, unknown>): SessionStreamDraft[] {
   const type = typeof record.type === 'string' ? record.type : ''
 
@@ -241,9 +343,19 @@ function draftsFromClaudeRecord(record: Record<string, unknown>): SessionStreamD
   if (type === 'system' && record.subtype === 'init') return [{ kind: 'status', state: 'working' }]
   if (type === 'result') return [{ kind: 'status', state: 'done' }]
 
-  // A user row is a tool RESULT or the prompt we just sent. Neither is news: the tool
-  // call was already announced, and the prompt came from this device.
-  if (type === 'user') return []
+  // A user row is EITHER a tool result or the query being worked on.
+  //
+  // This used to drop both, on the reasoning that "the prompt came from this device".
+  // That is true of a Continue turn and FALSE of the case that matters most: a session
+  // running in a Mac window, where the user row is the question Miles typed there and
+  // the glasses have never seen it. Dropping it is what made the live view a blank
+  // slate that said WORKING and nothing else.
+  //
+  // Tool results stay dropped -- the call was already announced.
+  if (type === 'user') {
+    const message = asRecord(record.message)
+    return message ? promptDrafts(message) : []
+  }
 
   const role = typeof record.role === 'string' ? record.role : ''
   if (type !== 'assistant' && role !== 'assistant') return []

package/server/lib/session-transcript-watcher.ts

@@ -172,6 +172,60 @@ async function readRangeAt(path: string, offset: number, length: number): Promis
   }
 }
 
+/**
+ * The last complete records before a byte offset, for the OPEN-time seed.
+ *
+ * WHY THIS EXISTS. The tail starts at the file's current size, so opening a session
+ * that is already working showed an EMPTY page that filled one line at a time. Miles,
+ * on hardware: "the live session pulling is a little lackluster." You walk up to the
+ * desk and the monitor is blank. The history is right there in the file; the tailer was
+ * simply choosing not to read it.
+ *
+ * READS BACKWARD, BOUNDED. `maxBytes` off the end, never the whole file -- the whole
+ * point of the forward-cursor design is that an 81 MB transcript is never re-read.
+ *
+ * DROPS THE FIRST FRAGMENT. A read from an arbitrary offset lands MID-RECORD, so the
+ * bytes before the first newline are the tail of a record whose start we never saw.
+ * Emitting that fragment would put a half-parsed line on the lens; it is discarded,
+ * which is why this returns "the last COMPLETE records".
+ *
+ * Returns [] on any read failure. A seed is a nicety; a session must still stream when
+ * its history cannot be read.
+ */
+export async function readTranscriptSeedLines(
+  path: string,
+  endOffset: number,
+  maxBytes = SEED_MAX_BYTES,
+): Promise<string[]> {
+  const end = Math.max(0, endOffset)
+  if (end === 0) return []
+  const length = Math.min(end, Math.max(0, maxBytes))
+  const start = end - length
+  const chunk = await readRangeAt(path, start, length)
+  if (chunk === null || chunk.length === 0) return []
+
+  let buf = chunk
+  if (start > 0) {
+    // Mid-record start: everything up to and including the first newline belongs to a
+    // record we did not see the beginning of.
+    const first = buf.indexOf(0x0a)
+    if (first < 0) return []
+    buf = buf.subarray(first + 1)
+  }
+  const last = buf.lastIndexOf(0x0a)
+  if (last < 0) return []
+  return buf.subarray(0, last).toString('utf8').split('\n').filter(line => line.length > 0)
+}
+
+/**
+ * Bytes read backward for a seed.
+ *
+ * 256 KiB against a measured p90 record of 1,627 bytes is on the order of a hundred
+ * records -- far more than the seven the lens can show, and small enough that the read
+ * is one syscall on a page open rather than anything the user waits for.
+ */
+export const SEED_MAX_BYTES = 256 * 1024
+
 export function createTranscriptTailer(options: TranscriptTailerOptions): TranscriptTailer {
   const now = options.now ?? (() => Date.now())
   const publish = options.publish ?? ((key, draft) => { publishSessionStream(key, draft) })

package/server/routes/agent-session-stream.ts

@@ -65,7 +65,12 @@ import {
   subscribeSessionStream,
   type PublishedSessionEvent,
 } from '../lib/session-stream-bus.js'
-import { acquireTranscriptWatcher, transcriptWatcherDegraded } from '../lib/session-transcript-watcher.js'
+import {
+  acquireTranscriptWatcher,
+  transcriptWatcherDegraded,
+  readTranscriptSeedLines,
+} from '../lib/session-transcript-watcher.js'
+import { draftsFromLine } from '../lib/session-stream-events.js'
 import type { SessionStreamState } from '../lib/session-stream-events.js'
 
 export const agentSessionStreamRouter = Router()
@@ -108,6 +113,15 @@ export async function openingState(
   }
 }
 
+/**
+ * Seeded events written on connect.
+ *
+ * EXACTLY THE LIVE WINDOW. `SESSION_TRAIL_LIVE_LINES` on the client is 7, measured
+ * against the 220px body; seeding more would scroll the newest events out of the view
+ * the seed exists to fill, and seeding fewer would leave the screen half empty.
+ */
+export const SEED_EVENTS = 7
+
 agentSessionStreamRouter.get('/agent-sessions/:provider/:sessionId/stream', async (req, res) => {
   res.set('Cache-Control', 'private, no-store')
 
@@ -228,6 +242,56 @@ agentSessionStreamRouter.get('/agent-sessions/:provider/:sessionId/stream', asyn
   // The contract's "emit a status immediately" -- written before any queued event so
   // the client's first frame is always a state, never a bare tool line.
   write({ kind: 'status', state, at: Date.now() })
+  // THE SEED. The last few steps of what already happened, before anything live.
+  //
+  // Without it, opening a session that is already working shows an empty page that
+  // fills one line at a time, which is what Miles reported from hardware. The screen
+  // should look like a monitor you just walked up to, not one that was switched on.
+  //
+  // BOUNDED TO WHAT THE LENS CAN SHOW. `SEED_EVENTS` is the live window, so the seed
+  // fills the screen once and no more: a hundred replayed events would push the live
+  // ones off the top of the very view they are meant to prime.
+  //
+  // ORDERED BEFORE `deliver = write`, so a live record landing during the read is
+  // queued in `pending` and written AFTER the seed rather than being overtaken by it.
+  //
+  // NEVER FATAL. A session whose history cannot be read still streams; it just starts
+  // empty, exactly as it did before this existed.
+  if (path !== null && startOffset > 0) {
+    try {
+      const lines = await readTranscriptSeedLines(path, startOffset)
+      const drafts = lines.flatMap(line => draftsFromLine(provider, line))
+      // Status drafts are dropped from the seed: they describe the state at some past
+      // moment and the opening status above is the CURRENT one. Replaying an old
+      // `done` after it would tell the client the live session had finished.
+      // THE QUERY IS SEEDED SEPARATELY, AND ALWAYS.
+      //
+      // Taking "the last 7 events" and hoping the prompt is among them does not work,
+      // and a live probe against a real session proved it: 8 seeded events, 6 tools and
+      // one prose, and NO prompt -- because in a busy run the user's question is twenty
+      // or thirty steps back and gets pushed out of the window by the very activity you
+      // opened the page to watch. That is the exact case the query exists for.
+      //
+      // So the newest prompt in the whole read window is emitted FIRST, unconditionally,
+      // and the step budget is spent entirely on steps. The client pins it rather than
+      // listing it, so it costs nothing in the scrolling window.
+      const lastPrompt = [...drafts].reverse().find(d => d.kind === 'prompt')
+      if (lastPrompt) write({ ...lastPrompt, at: Date.now() })
+
+      const steps = drafts.filter(d => d.kind === 'tool' || d.kind === 'prose')
+      for (const draft of steps.slice(-SEED_EVENTS)) {
+        // NOT tagged as seeded. A replayed step is a step that really happened, and a
+        // second rendering style for it would be a distinction without a use. The one
+        // consequence is that the client's "N ago" clock starts at open rather than at
+        // the record's real time; it self-corrects on the first live event.
+        write({ ...draft, at: Date.now() })
+      }
+    } catch {
+      /* a seed is a nicety; the live tail is the contract */
+    }
+  }
+  if (closed) return
+
   // Then anything published while the headers were being prepared, in order, before
   // the listener starts writing straight through. All three steps are synchronous, so
   // no event can interleave and arrive out of order.