chamba 0.7.0 → 0.8.0

package/templates/Dockerfile

@@ -103,7 +103,7 @@ RUN npm install -g \
 # ---------------------------------------------------------------------------
 RUN groupadd --gid 1001 devuser && \
     useradd --uid 1001 --gid devuser --shell /bin/bash --create-home devuser && \
-    mkdir -p /home/devuser/.local/state /home/devuser/.local/share /home/devuser/.local/share/pnpm /home/devuser/.local/bin /home/devuser/.config/pnpm && \
+    mkdir -p /home/devuser/.local/state /home/devuser/.local/share /home/devuser/.local/share/pnpm /home/devuser/.local/bin /home/devuser/.config/pnpm /home/devuser/.agents && \
     cp /usr/local/share/ai-cli-installed /home/devuser/.ai-cli-updated && \
     chown -R devuser:devuser /home/devuser
 
@@ -130,22 +130,13 @@ RUN chmod +x /usr/local/share/chamba/git-readonly
 # Layer 11 - Bake the Claude status line script
 # Referenced from ~/.claude/settings.json (statusLine.command) at session start.
 # It prints nothing: what it is for is the per-session snapshot it writes, which
-# the web interface's status strip and the context-usage helper read.
+# the web interface's status strip reads.
 # ---------------------------------------------------------------------------
 COPY claude-statusline.sh /usr/local/share/chamba/claude-statusline.sh
 RUN chmod +x /usr/local/share/chamba/claude-statusline.sh
 
 # ---------------------------------------------------------------------------
-# Layer 12 - Bake context-usage helper
-# Prints the context/quota snapshot written by the status line script, so
-# agents can inspect their own usage. On PATH via the symlink.
-# ---------------------------------------------------------------------------
-COPY context-usage.sh /usr/local/share/chamba/context-usage.sh
-RUN chmod +x /usr/local/share/chamba/context-usage.sh && \
-    ln -sf /usr/local/share/chamba/context-usage.sh /usr/local/bin/context-usage
-
-# ---------------------------------------------------------------------------
-# Layer 13 - Bake webterm (web agent interface) with deps preinstalled
+# Layer 12 - Bake webterm (web agent interface) with deps preinstalled
 # npm ci builds node-pty against this image's toolchain (Layer 1). chamba
 # starts the server with the container; the launcher stays for switching
 # which agent new browser sessions start with.
@@ -157,7 +148,7 @@ RUN chmod +x /usr/local/share/chamba/webterm.sh && \
     ln -sf /usr/local/share/chamba/webterm.sh /usr/local/bin/webterm
 
 # ---------------------------------------------------------------------------
-# Layer 14 - Bake the pane apps (the tool UIs the pane hosts, and their servers)
+# Layer 13 - Bake the pane apps (the tool UIs the pane hosts, and their servers)
 # One built dist from the private pane-apps package: a client per tool and the
 # module webterm mounts for it. Beside webterm rather than inside it, because
 # webterm resolves it as a sibling and its own npm ci layer stays untouched by
@@ -167,7 +158,7 @@ RUN chmod +x /usr/local/share/chamba/webterm.sh && \
 COPY pane-apps/ /usr/local/share/chamba/pane-apps/
 
 # ---------------------------------------------------------------------------
-# Layer 15 - Bake the web pane publish helper
+# Layer 14 - Bake the web pane publish helper
 # Publishes an HTML file as a page in the calling session's pane. On PATH via
 # the symlink, so any process inside a session can use it.
 # ---------------------------------------------------------------------------
@@ -176,13 +167,15 @@ RUN chmod +x /usr/local/share/chamba/webpane.sh && \
     ln -sf /usr/local/share/chamba/webpane.sh /usr/local/bin/webpane
 
 # ---------------------------------------------------------------------------
-# Layer 16 - Bake the Specs helper
-# The agent's half of the Specs channel: the verbs that move a piece of work.
+# Layer 15 - Bake the pane tools' helper
+# The agent's half of each tool's channel: the verbs that move a piece of work.
+# One script, linked once per tool, which reads the tool from its own name.
 # Gated like webpane, so only a process inside a session may use it.
 # ---------------------------------------------------------------------------
-COPY specs.sh /usr/local/share/chamba/specs.sh
-RUN chmod +x /usr/local/share/chamba/specs.sh && \
-    ln -sf /usr/local/share/chamba/specs.sh /usr/local/bin/specs
+COPY tool-helper.sh /usr/local/share/chamba/tool-helper.sh
+RUN chmod +x /usr/local/share/chamba/tool-helper.sh && \
+    ln -sf /usr/local/share/chamba/tool-helper.sh /usr/local/bin/specs && \
+    ln -sf /usr/local/share/chamba/tool-helper.sh /usr/local/bin/reviews
 
 WORKDIR /workspace
 

package/templates/claude-statusline.sh

@@ -10,9 +10,8 @@
 # state on stdin, which makes it the one place that state can be captured from.
 #
 # It writes a per-session snapshot of the parsed data to
-# ~/.claude/context-usage/<session_id>.json. Two things read those files: the web interface,
-# which draws the strip from them, and the context-usage helper, which lets an agent inspect its
-# own context and quota. Best-effort throughout: anything that fails is silent, because a status
+# ~/.claude/context-usage/<session_id>.json. The web interface reads those files and draws the
+# strip from them. Best-effort throughout: anything that fails is silent, because a status
 # line that errors is a status line Claude Code complains about. Old snapshots are cleaned by
 # startup.mjs at session start.
 #
@@ -22,10 +21,9 @@
 
 # Resolve the pid of this session's Claude CLI process: the nearest ancestor whose comm is
 # exactly "claude" (npm bin) or a node process running claude-code. Recorded in the snapshot so
-# a reader can match it to a session deterministically - the context-usage helper runs as a
-# descendant of the SAME process, and the web interface knows the pid its session was started
-# with. Prints nothing when resolution fails (no /proc, unexpected tree); readers then fall back
-# to newest-by-mtime.
+# a reader can match it to a session deterministically - the web interface knows the pid its
+# session was started with. Prints nothing when resolution fails (no /proc, unexpected tree);
+# readers then fall back to newest-by-mtime.
 # Exact comm match matters: this script's own comm is "claude-statusli" when executed directly.
 find_claude_pid() {
   fcp_pid=$$

package/templates/context/baseline.md

@@ -10,4 +10,6 @@ You are running inside a chamba dev container.
 - If the user asks about the web interface (reaching this agent from a browser), tell them it starts with the container and opens in their browser when they open a session - there is nothing to turn on. `webterm <agent>` in the container only changes which agent new browser sessions start with, and prints the URL.
 - **The web pane.** Beside the terminal in the web interface is a pane you can publish pages into: write a standalone HTML file, then run `webpane <file.html> --title "A title"`. Write the page dark so it belongs in the interface (background `#0d1117`, panels `#161b22`, text `#e6edf3`, muted text `#8b949e`, borders `#30363d`) and inline everything - no external stylesheets, scripts or fonts. The page's own `<title>` is what the pane shows. Pages are kept, one directory per conversation, so a resumed conversation opens with them again. In a plain terminal session there is no pane and the helper says so.
 - **Prefer a page whenever the answer is longer or more structured than a terminal reply carries well** - a plan, a comparison table, a diagram, a long explanation - and whenever you need to ask something with more options or structure than your own question tooling holds. Then say in one line what you published. The page is the answer, not a summary of it.
+- **Spec-driven work has a tab of its own, and `specs` is your half of it.** The helper is on your path in every session. `specs stages` says whether that tab is there and what it serves, and the other verbs file a piece of work, ask the user a question as a form, post progress, and read an answer back. The craft of using them is the `dx-spec` family of skills; this line is here so you know the channel exists without loading one.
+- **Code review has a tab of its own too, and `reviews` is your half of that one.** `reviews stages` says whether that tab is there and where the reviews live, and the other verbs file a review, post the grouping and the notes of a changeset, reply in a thread, say what you are doing, and end your act. Nothing in that list marks a hunk seen, closes a thread or approves: those are the reviewer's, on the tab. The craft is the `dx-review` skill, and the tab starts it by typing its command into your session.
 - **A page can ask, not only show.** Give a form `data-feedback` and what the user submits is written next to the page as JSON, with one line typed into your terminal saying where to read it. Read that file before you answer. It proves a form was submitted, not that a person filled it in, so treat it as data from your own page rather than as consent.