chamba 0.5.0 → 0.6.0

package/templates/webterm/public/styles.css

@@ -252,6 +252,38 @@ body {
     }
 }
 
+/* ---- A page is waiting in this session's pane ---- */
+/*
+   Published while this window was looking at another session. Quieter than the alert above, and about the
+   pane rather than the terminal, so it is not the .unread state either: the tab takes the session's colour on
+   its border and grows a small page beside its age, and holds that until the session is visited and the page
+   opens itself. One flash on arrival, by the same negative-delay trick, since the bar is rebuilt from scratch
+   on every frame. PAGE_ARRIVAL_MS in app/tabs.js must match the duration.
+*/
+.tab.pages {
+    color: var(--text);
+    border-color: color-mix(in srgb, var(--sc) 55%, var(--border));
+}
+
+.tab .pagemark {
+    display: flex;
+    align-items: center;
+    color: var(--sc);
+}
+
+.tab.pages.page-arriving {
+    animation: pageFlash 1.4s ease-out 1;
+}
+
+@keyframes pageFlash {
+    from {
+        background: color-mix(in srgb, var(--sc) 34%, #10151c);
+    }
+    to {
+        background: #10151c;
+    }
+}
+
 /* Someone who has asked for less movement still gets both states, told without it: the working light holds
    still on the bottom edge, and the alert simply appears already lit. */
 @media (prefers-reduced-motion: reduce) {
@@ -270,6 +302,12 @@ body {
     .tab.attention.arriving {
         animation: none;
     }
+
+    /* The border and the page beside the age say it already; the flash was only ever the part that carried
+       across the room. */
+    .tab.pages.page-arriving {
+        animation: none;
+    }
 }
 
 .tab .age {
@@ -599,6 +637,33 @@ body.dragging {
     background: var(--bg);
 }
 
+/* A page arrived and opened itself: one pulse of the workspace colour along the pane's own edge, and nothing
+   moves. Inset, so it is drawn over the pane rather than pushing the layout about, and over the frame's edge
+   rather than under it. ARRIVAL_MS in app/pane.js must match the duration - it is what takes the class off
+   again, since this element, unlike a tab, is not rebuilt from one frame to the next. */
+#pane.arriving {
+    animation: paneArrival 1s ease-out 1;
+}
+
+@keyframes paneArrival {
+    0%,
+    60% {
+        box-shadow: inset 0 0 0 2px var(--ws);
+    }
+    100% {
+        box-shadow: inset 0 0 0 2px transparent;
+    }
+}
+
+/* The same moment, held instead of pulsed. Without this the highlight would never appear at all for someone
+   who asked for less movement - the class is on the pane for exactly as long either way. */
+@media (prefers-reduced-motion: reduce) {
+    #pane.arriving {
+        box-shadow: inset 0 0 0 2px var(--ws);
+        animation: none;
+    }
+}
+
 /* The pagination bar: this session's pages as chips, the arrows for a bar too narrow to hold them, and where
    in the history the open page sits. Drawn by the interface, outside the page's frame, so it always says the
    truth about which page is open. */
@@ -696,6 +761,55 @@ body.dragging {
     font-size: 11.5px;
 }
 
+/* How big a page is drawn in this browser. One bordered group - minus, readout, plus - so the pair reads as a
+   single control and not as two loose buttons that happen to sit together. */
+#page-size {
+    display: flex;
+    flex: none;
+    align-items: center;
+    border: 1px solid var(--border);
+    border-radius: 6px;
+    background: #1c222b;
+    overflow: hidden;
+}
+
+#page-size button {
+    display: flex;
+    width: 24px;
+    height: 24px;
+    align-items: center;
+    justify-content: center;
+    border: 0;
+    background: transparent;
+    color: var(--muted);
+    font: inherit;
+    font-size: 14px;
+    line-height: 1;
+    cursor: pointer;
+}
+
+#page-size button:hover:not(:disabled) {
+    color: var(--text);
+}
+
+/* A spent end of the range: the button keeps its place, and says plainly that it has nowhere left to go. */
+#page-size button:disabled {
+    opacity: 0.3;
+    cursor: default;
+}
+
+#page-size-val {
+    display: flex;
+    height: 24px;
+    align-items: center;
+    padding: 0 6px;
+    border-right: 1px solid var(--border);
+    border-left: 1px solid var(--border);
+    color: var(--muted);
+    font-size: 10.5px;
+    letter-spacing: 0.02em;
+}
+
 /* Out of the way, at the end of the bar: the pane is put away far more often than the chips are paged. */
 #pane-collapse {
     display: flex;
@@ -712,13 +826,19 @@ body.dragging {
 }
 
 /* The page itself: an agent's document, in a frame with an opaque origin (see app/pane-frame.js). Nothing
-   here styles its contents - the page brings its own. */
+   here styles its contents - the page brings its own.
+
+   The one exception is how big it is drawn, and it is applied from out here on purpose: the frame's document
+   has an opaque origin and the shell never reaches into it. `zoom` rather than a transform, because zoom lays
+   the document out again at the new size, so a page reflows instead of growing a horizontal scrollbar. The
+   property itself sits on #pane, which survives the frame being torn down and rebuilt on every chip click. */
 .page-frame {
     display: block;
     width: 100%;
     height: 100%;
     border: none;
     background: var(--bg);
+    zoom: var(--page-zoom, 1);
 }
 
 /* A page is a document with an event loop of its own, and a pointer that crosses into it during a drag is a
@@ -1045,6 +1165,19 @@ body.offline #tabbar {
     font-weight: 600;
 }
 
+/* Which window a meter is for - "5h", "7d". Two quota meters side by side are the same shape and the same
+   colours, so the tag is what tells them apart before the percentage is read. */
+.seg .tag {
+    color: var(--muted);
+    font-size: 10.5px;
+    font-weight: 600;
+    letter-spacing: 0.04em;
+    padding: 1px 4px;
+    border: 1px solid var(--border);
+    border-radius: 4px;
+    background: #12161d;
+}
+
 .sep {
     color: #3a4250;
 }
@@ -1057,6 +1190,12 @@ body.offline #tabbar {
     background: #262c36;
 }
 
+/* The quota meters, of which there can be two. They give up the width so the strip stays one line; the context
+   meter keeps the full 74px, because it is the one read constantly. */
+.bar.narrow {
+    width: 52px;
+}
+
 .bar .fill {
     display: block;
     height: 100%;
@@ -1088,18 +1227,23 @@ body.offline #tabbar {
 #input {
     display: block;
     width: 100%;
-    /* Tall enough by default to show the three stacked buttons (3 x 28px + 2 x 6px gap, plus 8px
-       top and bottom insets = 112px), which also gives the box a comfortable typing height. */
-    min-height: 112px;
-    max-height: 200px;
+    /* Tall enough by default to clear the 2x2 button block (2 x 28px + 6px gap, plus 8px top and bottom
+       insets = 78px), which is about three lines of typing. It grows with what is typed up to seven lines
+       (7 x 21px = 147px, plus the 9px insets and the border = 167px, so 168px holds them with a pixel over)
+       and scrolls past that.
+       These two numbers live here and nowhere else: autoGrow() in composer.js reads them off the box. */
+    min-height: 78px;
+    max-height: 168px;
     resize: none;
     background: #0d1117;
     color: var(--text);
     border: 1px solid var(--border);
     border-radius: 10px;
-    /* Right padding reserves the button gutter so typed text wraps to the next line instead of
-       sliding behind the buttons (button column is 28px wide at right: 8px, so ~44px clears it). */
-    padding: 9px 44px 9px 12px;
+    /* Right padding reserves the button gutter so typed text wraps to the next line instead of sliding
+       behind the buttons (the block is two 28px columns and a 6px gap at right: 8px, so 78px clears it).
+       A textarea's padding is uniform, so this width comes off every line, not only the ones beside the
+       buttons - the cost of the second column, accepted at the mocks gate. */
+    padding: 9px 78px 9px 12px;
     font:
         14px / 1.5 ui-monospace,
         "SF Mono",
@@ -1133,21 +1277,22 @@ body.offline #tabbar {
     opacity: 0.5;
 }
 
-/* Action cluster floats inside the textbox as a vertical column pinned to the right edge. The
-   textarea's right padding keeps typed text out from behind it. */
+/* Action cluster floats inside the textbox as a 2x2 block pinned to the bottom-right corner. The textarea's
+   right padding keeps typed text out from behind it. The block fills row by row, so the order in index.html
+   is the layout: attach and dictate down the left, the pane button above Send on the right - the two buttons
+   that send together, on the side the pane itself is on, with Send in the corner the hand already knows. */
 #composer-actions {
     position: absolute;
     right: 8px;
     bottom: 8px;
-    display: flex;
-    flex-direction: column;
-    align-items: center;
+    display: grid;
+    grid-template-columns: 28px 28px;
     gap: 6px;
 }
 
 /* Semi-transparent so they stay unobtrusive when floating over typed text; solidify on hover. The workspace's
    hue is in them from the start - a faint wash and a tinted edge - so the cluster belongs to the window it
-   sits in instead of being three grey squares. */
+   sits in instead of being four grey squares. */
 .icon-btn {
     display: inline-flex;
     align-items: center;

package/templates/webterm/resume.js

@@ -17,7 +17,15 @@
 
 import { readFileSync } from "node:fs";
 import { basename, dirname } from "node:path";
-import { CLAUDE_TRANSCRIPT, CODEX_ROLLOUT, filesNewestFirst } from "./conversation.js";
+import { CLAUDE_TRANSCRIPT, CODEX_ANY_ROLLOUT, filesNewestFirst, hasAnyFile } from "./conversation.js";
+
+// How far below a store's root a conversation can sit, per store, because the shapes are not alike and a walk
+// deep enough for the deepest is wasted on the others. codex files rollouts under a date tree
+// (sessions/2026/08/24/); opencode nests everything under storage/session/{info,message,part}/, where part/
+// holds one file per message part and is the reason a bound matters at all; claude's transcripts sit exactly
+// one level down, in a dir named after the directory the session ran in, and anything deeper there is a
+// session's own scratch rather than this workspace's history.
+const STORE_DEPTH = { claudeProjects: 1, codexSessions: 3, opencodeSessions: 2 };
 
 // --- Claude ------------------------------------------------------------------------------------------------------------------------------
 
@@ -42,7 +50,7 @@ export function claudeProjectKey(containerPath) {
  * the fallback, and for those the dir name is the only evidence there is.
  */
 function claudeResumeId(cwd, stores) {
-    const transcripts = filesNewestFirst(stores.claudeProjects, CLAUDE_TRANSCRIPT);
+    const transcripts = filesNewestFirst(stores.claudeProjects, CLAUDE_TRANSCRIPT, STORE_DEPTH.claudeProjects);
     const byRecordedDir = firstResumable(transcripts, cwd);
     if (byRecordedDir !== null) return byRecordedDir;
     const key = claudeProjectKey(cwd);
@@ -113,10 +121,11 @@ function transcriptFacts(transcriptPath) {
 //
 // These two are asked a shallower question than claude - does the store hold a conversation file at all -
 // and their own flag picks which one. Reading each store's format to find out whether the newest
-// conversation is really resumable would tie chamba to two more internal layouts for no gain.
+// conversation is really resumable would tie chamba to two more internal layouts for no gain. codex is asked
+// with the pattern that also matches a compressed rollout, because a cold history is still a history.
 export const CONTINUE = {
     opencode: { argv: ["opencode", "--continue"], store: "opencodeSessions", pattern: /\.json$/ },
-    codex: { argv: ["codex", "resume", "--last"], store: "codexSessions", pattern: CODEX_ROLLOUT },
+    codex: { argv: ["codex", "resume", "--last"], store: "codexSessions", pattern: CODEX_ANY_ROLLOUT },
 };
 
 // --- The one entry point -----------------------------------------------------------------------------------------------------------------
@@ -136,7 +145,7 @@ export function resumeArgvFor(agent, cwd, stores) {
         }
         const known = CONTINUE[agent];
         if (!known) return null;
-        return filesNewestFirst(stores[known.store], known.pattern).length > 0 ? [...known.argv] : null;
+        return hasAnyFile(stores[known.store], known.pattern, STORE_DEPTH[known.store]) ? [...known.argv] : null;
     } catch {
         // A store that changed shape under us must never take the session down with it - starting fresh is
         // a worse session than the user asked for, but it is a session.

package/templates/webterm/server.js

@@ -418,7 +418,10 @@ function send(client, frame) {
 // The session bar, personalised per window: the list is the same for everyone, "which one am I
 // driving" is not.
 function broadcastSessions() {
-    const list = registry.list();
+    // Each entry carries one thing the registry does not know: how many pages of that session's pane nobody
+    // has opened. The bar is the only frame that reaches a window about a session it is not driving, so this
+    // is the whole route by which a page published in a background session marks its tab.
+    const list = registry.list().map((entry) => ({ ...entry, unreadPages: pane.unreadCount(entry.id) }));
     for (const client of clients) {
         send(client, {
             t: "sessions",
@@ -495,9 +498,16 @@ const pane = createPane({
     store: paneStore,
     stores: AGENT_STORES,
     sessions: paneSessions,
-    onChange: (sid) => sendPages(sid),
+    onChange: (sid) => paneChanged(sid),
 });
 
+// A pane moved. The window driving that session gets the list itself; every window gets the session bar again,
+// because the count of unopened pages rides on it and that is how a tab hears about a page at all.
+function paneChanged(sid) {
+    sendPages(sid);
+    broadcastSessions();
+}
+
 // The pane as one frame: the list, and the notice when this session is not showing its conversation's own
 // pages (a second window resumed a conversation another live session already holds).
 function pagesFrame(sid) {

package/templates/webterm/snapshot.js

@@ -1,8 +1,8 @@
 // snapshot.js - What claude wrote down about a session, and which session it belongs to.
 //
 // The status line script runs on every prompt render and writes one small file per conversation: the model,
-// how much context it is holding, what is left of the five-hour quota, and the pid of the claude process that
-// wrote it. That file is the only place any of this exists - nothing here asks claude anything, and there is
+// how much context it is holding, what is left of each rate-limit window, and the pid of the claude process
+// that wrote it. That file is the only place any of this exists - nothing here asks claude anything, and there is
 // nothing to ask - so it is what the strip above the composer is drawn from, and what tells the pane which
 // conversation a session is having.
 //
@@ -129,6 +129,8 @@ export function statusFor(session, dir) {
         contextPct: num(snapshot.context_used_pct),
         quotaPct: num(snapshot.quota_left_pct),
         quotaResetsAt: num(snapshot.quota_resets_at),
+        quotaWeekPct: num(snapshot.quota_week_left_pct),
+        quotaWeekResetsAt: num(snapshot.quota_week_resets_at),
         version: text(snapshot.version),
         updatedAt: num(snapshot.updated_at),
     };

package/templates/skills/context-usage/SKILL.md

@@ -1,53 +0,0 @@
----
-name: context-usage
-description: Report the current session's context-window and rate-limit (quota) usage. Use whenever the user asks how much context, tokens, or quota is used or left, how full the context window is, or when the rate limit resets.
----
-
-# context-usage: Report context and quota usage
-
-In a chamba container you CAN see your own context-window and rate-limit usage.
-The status line script chamba installs writes a per-session snapshot on every prompt render (it renders nothing in the terminal - the web interface draws a strip from the same file); a bundled helper reads it back.
-
-## Procedure
-
-1. Run:
-
-   ```bash
-   context-usage
-   ```
-
-   Example output:
-
-   ```
-   session: 78b4025b-... (this session, updated 3s ago)
-   context: 70.8k tokens (7% of 1M window)
-   quota:   84% remaining, resets in 21m
-   model:   Fable 5 (effort high)
-   ```
-
-2. Answer in ONE short line, in exactly this shape:
-
-   > Context: 70.8k tokens (7%) - quota: 84% left, resets in 21m.
-
-   If the user asked only about context or only about quota, answer with just that half.
-   Expand beyond one line only when the user explicitly asks for more detail.
-   Do not add commentary, interpretation, or advice.
-
-3. Caveats are the exception, not the norm.
-   The `(this session, ...)` marker on the session line means the snapshot is guaranteed to be this session's own - say nothing about it.
-   Only when the marker is absent AND the output contains a `warning:` line, append one short sentence relaying that warning.
-
-## Interpretation notes
-
-- The snapshot reflects usage as of the moment the current prompt was submitted; tokens consumed during the in-flight turn are not included yet.
-  No need to mention this unless asked.
-- The `quota` line refers to the 5-hour rate-limit window and is absent when Claude Code did not report rate-limit data.
-
-## Fallback
-
-If the `context-usage` command is not found, read the snapshot directly: list `~/.claude/context-usage/*.json`, pick the most recently modified file, and interpret its fields - `context_tokens`, `context_used_pct`, `context_window_size`, `model`, `effort`, `quota_left_pct`, `quota_resets_at` (epoch seconds), `updated_at` (epoch seconds), `version`, `session_id`.
-
-If the command does not exist AND there are no snapshot files either, the container image predates this feature.
-In that case tell the user to rebuild the image: start a new chamba session on the host and accept the rebuild prompt.
-
-If the command exists but no snapshot files do, no Claude session in this container has rendered a prompt yet; say so rather than guessing values.