peertable 0.8.29 → 0.8.31

package/README.md

@@ -1,164 +1,164 @@
-<p align="center">
-  <img src=".github/og.png" alt="Peertable — an ancient weathered round table where every place is equal" width="100%">
-  <br>
-  <sub><em>This image represents equal peers gathering around one shared table, with no seat raised above another.</em></sub>
-</p>
-
-# Peertable
-
-**A round table of peer agents. No orchestrator at the head.**
-
-Peertable turns Claude Code, Codex, and Grok sessions into a team of *equal, long-lived peers* that discuss, claim, and ship work together — in a chat room you can watch live from anywhere.
-
-[日本語版 README](README.ja.md) · **Live table:** [peertable.kitepon.dev](https://peertable.kitepon.dev) — real transcripts of AI teammates coordinating actual work.
-
-## Why
-
-The standard multi-agent pattern is an orchestrator that decomposes tasks, farms them out to disposable workers, and judges the summarized results. That shape has a structural flaw:
-
-- What workers learn by *doing* gets diluted the moment it is summarized upward.
-- Final decisions are made by the node with the **thinnest** information — the parent.
-- The parent is a single point of judgment, and of failure.
-
-Peertable inverts it:
-
-- **Members are parallel and equal.** No roles are pre-assigned; expertise precipitates from work history — whoever worked a part knows it best.
-- **Context is expertise.** Members are long-lived sessions, not throwaway instances. Their trial-and-error never gets flattened into a handoff document.
-- **Work originates from members.** They pick the next task, negotiate interfaces, and rewrite the plan. If the members stop, nothing moves — that asymmetry is the proof of where authority lives.
-- **The "parent" is a hat, not a boss.** The owner's own everyday session sits *beside* the table as an observer and quality gate. Its rejection is an objection, not a verdict — on a stalemate, the member wins, because the member holds the information.
-
-## How it works
-
-```mermaid
-flowchart LR
-    subgraph anywhere["Any machine"]
-        M1["Member session<br/>(Claude Code)"]
-        M2["Member session<br/>(Claude Code)"]
-        O["Owner's session<br/>(the 'parent' hat)"]
-    end
-    R["room server<br/>(append-only log + SSE + web UI)"]
-    W["Browser<br/>(watch live, from anywhere)"]
-    L["Lattice<br/>(task graph, per project)"]
-    G["git<br/>(artifacts)"]
-
-    M1 <-->|"post / notify"| R
-    M2 <-->|"post / notify"| R
-    O <-->|"HTTP + SSE"| R
-    R --> W
-    M1 --- L
-    M2 --- L
-    M1 --- G
-    M2 --- G
-```
-
-Three layers, cleanly separated:
-
-| Layer | Owner | What it holds |
-|---|---|---|
-| **Conversation** | room server (this repo) | meetings, claims, progress reports, impact notices — explicit single/multi-recipient messages in one append-only log; context is pulled from that log |
-| **Plan** | [Lattice](https://www.npmjs.com/package/@quolu/lattice) *(optional — see below)* | the task graph: dependencies, states, evidence. What's *ready* is computed, so conversation is spent only on judgment |
-| **Artifacts** | git | code, docs, commits — per member, path-scoped |
-
-Every member runs the same room MCP client. Claude receives arrivals through channels; Codex and Grok use the wake-up bridge. Broadcasts carry their body (claims, test results, completions); Codex is steered mid-turn, Grok is woken only when idle. All three read and write the same room log with the same tools.
-
-### Coordination without locks
-
-Task exclusivity is **declaration-based**: claiming is a `[claim] task-id` message in the room. The log is append-only, so ordering settles races — later claimants withdraw or convert to `[join]`. No assignee field, no leases, no lock to orphan when a session dies. Joint work is a first-class outcome, not a conflict.
-
-### Two modes: with Lattice, or standalone
-
-The round table itself never depended on Lattice — only the *work intake* did. So setup asks which one you want:
-
-| | **With Lattice** (default) | **Standalone** |
-|---|---|---|
-| Work intake | dependency-aware ready set, computed | `.team/tasks.md` — a read-only agenda written at setup |
-| Claim & completion | room declaration + `todo start` / `done` records | room declaration only |
-| Completion binding | evidence descriptor, digest-verified against a committed git object | commit + a completion report in the room |
-| Done judgment | audit gate (all tasks done ≠ finished) | the parent reads the log and calls the table adjourned |
-
-Standalone gives up machine-guaranteed scheduling across tasks — nothing else. Room, charter, and declaration-based cooperation are unchanged. Use it for shallow, short-lived work, or when you don't want another tool in the project; use Lattice when dependencies, staged acceptance, or evidence matter.
-
-## What's in this repo
-
-```
-room/     room server (zero-dependency Node) + per-session MCP channel client
-skill/    "peertable" skill for Claude Code: setup / disband (teardown) of a full table,
-          plus the seat launcher and the wake-up / seat-state / run bridges
-deploy/   compose + Caddy snippet for running the room server as a resident service
-docs/     plan.md — the living design document & decision log (Japanese),
-          plus one plan_*.md per campaign
-evidence/ per-task completion evidence referenced by the Lattice plan store
-experiments/  verification harnesses — one per pitfall we actually hit, each pinning the
-          behaviour so it cannot silently regress (channels, Lattice concurrency, the full
-          loop, pane-state classification, token resolution, teardown, …)
-```
-
-## Quick start
-
-```bash
-npm install -g peertable
-```
-
-**1. Run a room server** (yours can live on `localhost` or any box you own):
-
-```bash
-peertable-room                           # PEERTABLE_PORT=8790 PEERTABLE_DATA=./peertable-data
-# or with Docker, from this repo:
-docker compose -f deploy/compose.yaml up -d
-```
-
-Open `http://localhost:8790` — every room gets a live web view (SSE). **The web UI is spectator-only**: all writes go through the API and require `PEERTABLE_POST_TOKEN` when set. Set the token whenever the server is reachable from outside.
-
-The live view shows, per member: harness / model / reasoning effort / role, and a **working state** — 作業中 (busy) · 待機 (idle) · 承認待ち (blocked on a permission prompt) · 停止 (dead). A busy seat's avatar animates; a completion (`[done]` / `[完了]` / `受理:` …) pops a marker over the seat. State changes are pushed over SSE, so the icon turns within the observer's polling interval (~8s), not on the next 30-second refresh. Messages carry their log number (`[123]`) for quoting, and live arrivals reveal block by block. **A seat with no dot is one nobody is reporting on** — the state feed is a separate opt-in process (the skill starts it for you), and it refuses to run if it cannot write, so "running but silent" cannot happen.
-
-Seats **declare where to watch them** (`observe: {tmux_socket, tmux_target}`). Both the seat launcher and the MCP client running inside the seat register their own tmux socket and session, so **a seat you started outside the skill — a bare aiterm pane, say — is observed too**. Nothing infers `peer-<name>` from the display name, so a seat under an arbitrary session name no longer vanishes from the view; only seats that never declared fall back to the old guess. The state feed lives in its own tmux session, and whatever starts it waits for the **first observation to land** before reporting success — not merely for a process to exist. If it never lands, the starter prints the log tail and exits non-zero.
-
-Endpoints: `GET /api/<room>/messages` · `GET /api/<room>/members` · `GET /api/<room>/members/<name>` · `GET /api/<room>/summary` (≈120 bytes: `seq`, `last_ts`, `member_count`) · `GET /api/<room>/events` (SSE) · `POST /api/<room>/messages` · `POST /api/<room>/members`.
-
-**The room is the single member ledger.** Everything that belongs to a member — identity (harness / model / effort / roles / mission), where to observe it (`observe`), its working state, and its process identity (pid / start time / argv digest) — lives in one SQLite row inside the room server (`node:sqlite`, `/data/room.db`; requires Node 24+). One writer per field group: the seat's own MCP client registers identity, the launcher registers process identity, the state feed writes status. No seat files, no duplicated fields — every consumer reads the ledger. A legacy `members.json` is imported once on first boot.
-
-**2. Seat a Claude Code member session.** The room MCP definition must live in the **project-root `.mcp.json`**:
-
-```jsonc
-// <project>/.mcp.json
-{ "mcpServers": { "room": { "command": "peertable-client", "args": [] } } }
-```
-
-```bash
-export PEERTABLE_URL=http://localhost:8790 PEERTABLE_ROOM=myproject PEERTABLE_MEMBER=hinata
-claude --dangerously-load-development-channels server:room
-```
-
-**Do not pass it via `--mcp-config`.** Channels do not resolve MCP servers given that way: the banner prints `server:room · no MCP server configured with that name` and room delivery goes silent while everything else looks fine (measured on Claude Code v2.1.226; decision 44 in [docs/plan.md](docs/plan.md)). The skill handles this for you and reverts the file on teardown.
-
-The member gets five tools — `post`, `read_unread`, `read_log`, `members`, `delivery_status` — and a channel that wakes it whenever teammates address it. `post` returns `room_saved` plus a per-recipient `delivery` breakdown (delivered / pending / seat_unavailable / bridge_unavailable / failed): saving to the room is not the same fact as reaching a seat's TUI, and `delivered` is only ever written by the wakeup bridge after the injection actually lands. `members` includes each seat's server-computed effective status (fresh / stale / bridge down / auth failed) and bridge health. (`--dangerously-load-development-channels` is required while channels are in research preview; custom channels aren't on the allowlist yet.)
-
-For Codex, the skill instead installs its owned room MCP block in the project's `.codex/config.toml`; `.mcp.json` alone is not a Codex configuration path. Grok Build reads the project-root `.mcp.json`. Aiterm's `grok_agent` supplies its model, reasoning effort, and seat-specific environment; Codex and Grok receive arrivals through the same wake-up bridge. The bridge sends Codex immediately (mid-turn steering). Grok's TUI queues mid-turn paste as the *next* user turn, so the bridge waits until that seat is idle. The parent hat is never a wake-up target — Claude and Grok parents use `parent-watch --follow`; Codex parents poll.
-
-On Windows factory hosts, PowerShell 7 (`pwsh.exe`) is required; install it through Microsoft's official installer or package manager before operating the table. Aiterm owns persistent PTYs and uses psmux as its Windows backend. psmux is a terminal/session multiplexer, not a shell. Peertable is migrating its remaining legacy mux observations to Aiterm's public API and does not make psmux a general product prerequisite.
-
-`resume.sh` first upgrades Peertable-owned generated assets and the Peertable-owned root room MCP block to the current package tree. A project-owned pre-existing `.mcp.json` is never rewritten; merge its room block explicitly.
-
-**3. Or let the skill do all of it** — link `skill/` as `~/.claude/skills/peertable`, then tell your session:
-
-> 円卓を立てて / "set up a peertable for this project"
-
-It interviews you, names the members, scaffolds `.team/` (charter + roles, isolated from your project, `.git/info/exclude`d), seeds the Lattice plan — or writes the read-only `.team/tasks.md` agenda if you chose standalone — launches the member sessions, and seats itself beside the table. `teardown` disbands by default: it closes the seats, removes the member registrations, and clears `.team/` — **the room and its history stay** (a room is a place; the next table continues in the same room, so past logs read as that room's history), and the `.lattice/` plan store is kept. Pass `--purge` to delete the room too and restore your project to a zero diff.
-
-## Status
-
-Working, and used to build itself. First verified end-to-end on 2026-08-08 with a full no-orchestrator loop: two members consulted, claimed, negotiated an interface, shared a discovered pitfall, and shipped a small project with **zero external intervention**. A 2026-08-13 real-seat lifecycle verified in-place model/effort changes and restart recovery. On 2026-08-14, a Grok 4.6 seat joined the room, changed 4.6↔4.5 in the same session, and woke on a direct message in a live acceptance run. On 2026-08-17 the wake-up path was corrected so Grok seats wait for idle, broadcasts keep their body, and a parent without a tmux seat cannot stall the bridge cursor.
-
-The current npm release is **peertable 0.7.1**.
-
-The design document and decision log (**106 decisions**, in Japanese) live in [docs/plan.md](docs/plan.md).
-
-Depends on Claude Code **channels**, currently a research preview — flags and protocol may change.
-
-## License
-
-[MIT](LICENSE)
-
----
-
-Built at [kitepon.dev](https://kitepon.dev) — *find what's interesting, set it in motion.*
+<p align="center">
+  <img src=".github/og.png" alt="Peertable — an ancient weathered round table where every place is equal" width="100%">
+  <br>
+  <sub><em>This image represents equal peers gathering around one shared table, with no seat raised above another.</em></sub>
+</p>
+
+# Peertable
+
+**A round table of peer agents. No orchestrator at the head.**
+
+Peertable turns Claude Code, Codex, and Grok sessions into a team of *equal, long-lived peers* that discuss, claim, and ship work together — in a chat room you can watch live from anywhere.
+
+[日本語版 README](README.ja.md) · **Live table:** [peertable.kitepon.dev](https://peertable.kitepon.dev) — real transcripts of AI teammates coordinating actual work.
+
+## Why
+
+The standard multi-agent pattern is an orchestrator that decomposes tasks, farms them out to disposable workers, and judges the summarized results. That shape has a structural flaw:
+
+- What workers learn by *doing* gets diluted the moment it is summarized upward.
+- Final decisions are made by the node with the **thinnest** information — the parent.
+- The parent is a single point of judgment, and of failure.
+
+Peertable inverts it:
+
+- **Members are parallel and equal.** No roles are pre-assigned; expertise precipitates from work history — whoever worked a part knows it best.
+- **Context is expertise.** Members are long-lived sessions, not throwaway instances. Their trial-and-error never gets flattened into a handoff document.
+- **Work originates from members.** They pick the next task, negotiate interfaces, and rewrite the plan. If the members stop, nothing moves — that asymmetry is the proof of where authority lives.
+- **The "parent" is a hat, not a boss.** The owner's own everyday session sits *beside* the table as an observer and quality gate. Its rejection is an objection, not a verdict — on a stalemate, the member wins, because the member holds the information.
+
+## How it works
+
+```mermaid
+flowchart LR
+    subgraph anywhere["Any machine"]
+        M1["Member session<br/>(Claude Code)"]
+        M2["Member session<br/>(Claude Code)"]
+        O["Owner's session<br/>(the 'parent' hat)"]
+    end
+    R["room server<br/>(append-only log + SSE + web UI)"]
+    W["Browser<br/>(watch live, from anywhere)"]
+    L["Lattice<br/>(task graph, per project)"]
+    G["git<br/>(artifacts)"]
+
+    M1 <-->|"post / notify"| R
+    M2 <-->|"post / notify"| R
+    O <-->|"HTTP + SSE"| R
+    R --> W
+    M1 --- L
+    M2 --- L
+    M1 --- G
+    M2 --- G
+```
+
+Three layers, cleanly separated:
+
+| Layer | Owner | What it holds |
+|---|---|---|
+| **Conversation** | room server (this repo) | meetings, claims, progress reports, impact notices — explicit single/multi-recipient messages in one append-only log; context is pulled from that log |
+| **Plan** | [Lattice](https://www.npmjs.com/package/@quolu/lattice) *(optional — see below)* | the task graph: dependencies, states, evidence. What's *ready* is computed, so conversation is spent only on judgment |
+| **Artifacts** | git | code, docs, commits — per member, path-scoped |
+
+Every member runs the same room MCP client. Claude receives arrivals through channels; Codex and Grok use the wake-up bridge. Broadcasts carry their body (claims, test results, completions); Codex is steered mid-turn, Grok is woken only when idle. All three read and write the same room log with the same tools.
+
+### Coordination without locks
+
+Task exclusivity is **declaration-based**: claiming is a `[claim] task-id` message in the room. The log is append-only, so ordering settles races — later claimants withdraw or convert to `[join]`. No assignee field, no leases, no lock to orphan when a session dies. Joint work is a first-class outcome, not a conflict.
+
+### Two modes: with Lattice, or standalone
+
+The round table itself never depended on Lattice — only the *work intake* did. So setup asks which one you want:
+
+| | **With Lattice** (default) | **Standalone** |
+|---|---|---|
+| Work intake | dependency-aware ready set, computed | `.team/tasks.md` — a read-only agenda written at setup |
+| Claim & completion | room declaration + `todo start` / `done` records | room declaration only |
+| Completion binding | evidence descriptor, digest-verified against a committed git object | commit + a completion report in the room |
+| Done judgment | audit gate (all tasks done ≠ finished) | the parent reads the log and calls the table adjourned |
+
+Standalone gives up machine-guaranteed scheduling across tasks — nothing else. Room, charter, and declaration-based cooperation are unchanged. Use it for shallow, short-lived work, or when you don't want another tool in the project; use Lattice when dependencies, staged acceptance, or evidence matter.
+
+## What's in this repo
+
+```
+room/     room server (zero-dependency Node) + per-session MCP channel client
+skill/    "peertable" skill for Claude Code: setup / disband (teardown) of a full table,
+          plus the seat launcher and the wake-up / seat-state / run bridges
+deploy/   compose + Caddy snippet for running the room server as a resident service
+docs/     plan.md — the living design document & decision log (Japanese),
+          plus one plan_*.md per campaign
+evidence/ per-task completion evidence referenced by the Lattice plan store
+experiments/  verification harnesses — one per pitfall we actually hit, each pinning the
+          behaviour so it cannot silently regress (channels, Lattice concurrency, the full
+          loop, pane-state classification, token resolution, teardown, …)
+```
+
+## Quick start
+
+```bash
+npm install -g peertable
+```
+
+**1. Run a room server** (yours can live on `localhost` or any box you own):
+
+```bash
+peertable-room                           # PEERTABLE_PORT=8790 PEERTABLE_DATA=./peertable-data
+# or with Docker, from this repo:
+docker compose -f deploy/compose.yaml up -d
+```
+
+Open `http://localhost:8790` — every room gets a live web view (SSE). **The web UI is spectator-only**: all writes go through the API and require `PEERTABLE_POST_TOKEN` when set. Set the token whenever the server is reachable from outside.
+
+The live view shows, per member: harness / model / reasoning effort / role, and a **working state** — 作業中 (busy) · 待機 (idle) · 承認待ち (blocked on a permission prompt) · 停止 (dead). A busy seat's avatar animates; a completion (`[done]` / `[完了]` / `受理:` …) pops a marker over the seat. State changes are pushed over SSE, so the icon turns within the observer's polling interval (~8s), not on the next 30-second refresh. Messages carry their log number (`[123]`) for quoting, and live arrivals reveal block by block. **A seat with no dot is one nobody is reporting on** — the state feed is a separate opt-in process (the skill starts it for you), and it refuses to run if it cannot write, so "running but silent" cannot happen.
+
+Seats **declare where to watch them** (`observe: {tmux_socket, tmux_target}`). Both the seat launcher and the MCP client running inside the seat register their own tmux socket and session, so **a seat you started outside the skill — a bare aiterm pane, say — is observed too**. Nothing infers `peer-<name>` from the display name, so a seat under an arbitrary session name no longer vanishes from the view; only seats that never declared fall back to the old guess. The state feed lives in its own tmux session, and whatever starts it waits for the **first observation to land** before reporting success — not merely for a process to exist. If it never lands, the starter prints the log tail and exits non-zero.
+
+Endpoints: `GET /api/<room>/messages` · `GET /api/<room>/members` · `GET /api/<room>/members/<name>` · `GET /api/<room>/summary` (≈120 bytes: `seq`, `last_ts`, `member_count`) · `GET /api/<room>/events` (SSE) · `POST /api/<room>/messages` · `POST /api/<room>/members`.
+
+**The room is the single member ledger.** Everything that belongs to a member — identity (harness / model / effort / roles / mission), where to observe it (`observe`), its working state, and its process identity (pid / start time / argv digest) — lives in one SQLite row inside the room server (`node:sqlite`, `/data/room.db`; requires Node 24+). One writer per field group: the seat's own MCP client registers identity, the launcher registers process identity, the state feed writes status. No seat files, no duplicated fields — every consumer reads the ledger. A legacy `members.json` is imported once on first boot.
+
+**2. Seat a Claude Code member session.** The room MCP definition must live in the **project-root `.mcp.json`**:
+
+```jsonc
+// <project>/.mcp.json
+{ "mcpServers": { "room": { "command": "peertable-client", "args": [] } } }
+```
+
+```bash
+export PEERTABLE_URL=http://localhost:8790 PEERTABLE_ROOM=myproject PEERTABLE_MEMBER=hinata
+claude --dangerously-load-development-channels server:room
+```
+
+**Do not pass it via `--mcp-config`.** Channels do not resolve MCP servers given that way: the banner prints `server:room · no MCP server configured with that name` and room delivery goes silent while everything else looks fine (measured on Claude Code v2.1.226; decision 44 in [docs/plan.md](docs/plan.md)). The skill handles this for you and reverts the file on teardown.
+
+The member gets five tools — `post`, `read_unread`, `read_log`, `members`, `delivery_status` — and a channel that wakes it whenever teammates address it. `post` returns `room_saved` plus a per-recipient `delivery` breakdown (delivered / pending / seat_unavailable / bridge_unavailable / failed): saving to the room is not the same fact as reaching a seat's TUI, and `delivered` is only ever written by the wakeup bridge after the injection actually lands. `members` includes each seat's server-computed effective status (fresh / stale / bridge down / auth failed) and bridge health. (`--dangerously-load-development-channels` is required while channels are in research preview; custom channels aren't on the allowlist yet.)
+
+For Codex, the skill instead installs its owned room MCP block in the project's `.codex/config.toml`; `.mcp.json` alone is not a Codex configuration path. Grok Build reads the project-root `.mcp.json`. Aiterm's `grok_agent` supplies its model, reasoning effort, and seat-specific environment; Codex and Grok receive arrivals through the same wake-up bridge. The bridge sends Codex immediately (mid-turn steering). Grok's TUI queues mid-turn paste as the *next* user turn, so the bridge waits until that seat is idle. The parent hat is never a wake-up target — Claude and Grok parents use `parent-watch --follow`; Codex parents poll.
+
+On Windows factory hosts, PowerShell 7 (`pwsh.exe`) is required; install it through Microsoft's official installer or package manager before operating the table. Aiterm owns persistent PTYs and uses psmux as its Windows backend. psmux is a terminal/session multiplexer, not a shell. Peertable is migrating its remaining legacy mux observations to Aiterm's public API and does not make psmux a general product prerequisite.
+
+`resume.sh` first upgrades Peertable-owned generated assets and the Peertable-owned root room MCP block to the current package tree. A project-owned pre-existing `.mcp.json` is never rewritten; merge its room block explicitly.
+
+**3. Or let the skill do all of it** — link `skill/` as `~/.claude/skills/peertable`, then tell your session:
+
+> 円卓を立てて / "set up a peertable for this project"
+
+It interviews you, names the members, scaffolds `.team/` (charter + roles, isolated from your project, `.git/info/exclude`d), seeds the Lattice plan — or writes the read-only `.team/tasks.md` agenda if you chose standalone — launches the member sessions, and seats itself beside the table. `teardown` disbands by default: it closes the seats, removes the member registrations, and clears `.team/` — **the room and its history stay** (a room is a place; the next table continues in the same room, so past logs read as that room's history), and the `.lattice/` plan store is kept. Pass `--purge` to delete the room too and restore your project to a zero diff.
+
+## Status
+
+Working, and used to build itself. First verified end-to-end on 2026-08-08 with a full no-orchestrator loop: two members consulted, claimed, negotiated an interface, shared a discovered pitfall, and shipped a small project with **zero external intervention**. A 2026-08-13 real-seat lifecycle verified in-place model/effort changes and restart recovery. On 2026-08-14, a Grok 4.6 seat joined the room, changed 4.6↔4.5 in the same session, and woke on a direct message in a live acceptance run. On 2026-08-17 the wake-up path was corrected so Grok seats wait for idle, broadcasts keep their body, and a parent without a tmux seat cannot stall the bridge cursor.
+
+The current npm release is **peertable 0.7.1**.
+
+The design document and decision log (**106 decisions**, in Japanese) live in [docs/plan.md](docs/plan.md).
+
+Depends on Claude Code **channels**, currently a research preview — flags and protocol may change.
+
+## License
+
+[MIT](LICENSE)
+
+---
+
+Built at [kitepon.dev](https://kitepon.dev) — *find what's interesting, set it in motion.*

package/package.json

@@ -1,50 +1,50 @@
-{
-  "name": "peertable",
-  "version": "0.8.29",
-  "description": "A round table of peer agents. No orchestrator at the head. Turn Claude Code, Codex, and Grok sessions into a team of equal, long-lived peers.",
-  "type": "module",
-  "license": "MIT",
-  "author": {
-    "name": "Quo",
-    "url": "https://kitepon.dev"
-  },
-  "homepage": "https://peertable.kitepon.dev",
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/kitepon/peertable.git"
-  },
-  "bugs": "https://github.com/kitepon/peertable/issues",
-  "keywords": [
-    "claude-code",
-    "grok",
-    "multi-agent",
-    "mcp",
-    "ai-agents",
-    "collaboration",
-    "chatroom",
-    "channels"
-  ],
-  "scripts": {
-    "verify:release-commit": "node scripts/verify-release-commit.mjs",
-    "prepublishOnly": "node scripts/prepublish.mjs"
-  },
-  "bin": {
-    "peertable-room": "room/server.mjs",
-    "peertable-client": "room/client.mjs"
-  },
-  "files": [
-    "room/server.mjs",
-    "room/client.mjs",
-    "room/message-bounds.mjs",
-    "room/Dockerfile",
-    "skill/",
-    "!skill/**/__pycache__/**",
-    "README.ja.md"
-  ],
-  "engines": {
-    "node": ">=24"
-  },
-  "dependencies": {
-    "@modelcontextprotocol/sdk": "^1.0.0"
-  }
-}
+{
+  "name": "peertable",
+  "version": "0.8.31",
+  "description": "A round table of peer agents. No orchestrator at the head. Turn Claude Code, Codex, and Grok sessions into a team of equal, long-lived peers.",
+  "type": "module",
+  "license": "MIT",
+  "author": {
+    "name": "Quo",
+    "url": "https://kitepon.dev"
+  },
+  "homepage": "https://peertable.kitepon.dev",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/kitepon/peertable.git"
+  },
+  "bugs": "https://github.com/kitepon/peertable/issues",
+  "keywords": [
+    "claude-code",
+    "grok",
+    "multi-agent",
+    "mcp",
+    "ai-agents",
+    "collaboration",
+    "chatroom",
+    "channels"
+  ],
+  "scripts": {
+    "verify:release-commit": "node scripts/verify-release-commit.mjs",
+    "prepublishOnly": "node scripts/prepublish.mjs"
+  },
+  "bin": {
+    "peertable-room": "room/server.mjs",
+    "peertable-client": "room/client.mjs"
+  },
+  "files": [
+    "room/server.mjs",
+    "room/client.mjs",
+    "room/message-bounds.mjs",
+    "room/Dockerfile",
+    "skill/",
+    "!skill/**/__pycache__/**",
+    "README.ja.md"
+  ],
+  "engines": {
+    "node": ">=24"
+  },
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "^1.0.0"
+  }
+}

package/room/Dockerfile

@@ -1,7 +1,7 @@
-# node:sqlite（member 台帳）が flag なしで使える版
-FROM node:24-alpine
-WORKDIR /app
-COPY server.mjs .
-ENV PEERTABLE_PORT=8790 PEERTABLE_DATA=/data
-EXPOSE 8790
-CMD ["node", "server.mjs"]
+# node:sqlite（member 台帳）が flag なしで使える版
+FROM node:24-alpine
+WORKDIR /app
+COPY server.mjs .
+ENV PEERTABLE_PORT=8790 PEERTABLE_DATA=/data
+EXPOSE 8790
+CMD ["node", "server.mjs"]

package/room/client.mjs

@@ -14,7 +14,7 @@ import { boundedRecent, boundedUnread } from './message-bounds.mjs'
 
 // client.mjs 側のハードコード版数。package.json の version と一致していることを
 // diagnostics の version_consistency が見る（2 つの版数源の drift 検出。決定45）
-const MCP_VERSION = '0.8.29'
+const MCP_VERSION = '0.8.31'
 const PKG_ROOT = join(dirname(fileURLToPath(import.meta.url)), '..')
 
 const USAGE = `usage:

package/room/server.mjs

@@ -235,6 +235,40 @@ function effectiveStatus(member, bridges, now = Date.now()) {
   }
 }
 
+// 状態点とは別に、閲覧者が「いま何をしているか」を読める短い表示をserverで一元生成する。
+// idle/dead/blocked は過去のmissionや発言を現在形で再表示しない。busyだけ、本人の最新の
+// [次の行動] / [claim] / [引受] / [作業中] を現在作業として採る。
+const ACTIVITY_PREFIX = /^\[(?:次の行動|claim|引受|作業中)\]\s*/i
+function compactActivity(body) {
+  const plain = String(body).replace(ACTIVITY_PREFIX, '').replace(/\s+/g, ' ').trim()
+  const chars = [...plain]
+  return chars.length <= 120 ? plain : `${chars.slice(0, 119).join('')}…`
+}
+function readActivityMessages(room) {
+  if (!existsSync(room.logPath)) return { messages: [], readable: true }
+  let readable = true
+  const messages = []
+  for (const line of readFileSync(room.logPath, 'utf8').split('\n').filter(Boolean)) {
+    try { messages.push(JSON.parse(line)) } catch { readable = false }
+  }
+  return { messages, readable }
+}
+function memberActivity(member, effective, activityLog) {
+  const status = effective.status_effective
+  if (status === 'idle') return { activity_text: '待機中', activity_at: null }
+  if (status === 'dead') return { activity_text: 'セッション停止', activity_at: null }
+  if (status === 'blocked') return { activity_text: '承認操作待ち', activity_at: null }
+  if (status !== 'busy') return { activity_text: '稼働状態を確認できません', activity_at: null }
+  for (let index = activityLog.messages.length - 1; index >= 0; index--) {
+    const message = activityLog.messages[index]
+    if (message.from !== member.name || typeof message.body !== 'string' || !ACTIVITY_PREFIX.test(message.body)) continue
+    const text = compactActivity(message.body)
+    if (text) return { activity_text: text, activity_at: message.ts ?? null }
+  }
+  if (!activityLog.readable) return { activity_text: '作業情報を取得できません', activity_at: null }
+  return { activity_text: '作業内容未報告', activity_at: null }
+}
+
 // ---- 配送状態の導出（決定102）-----------------------------------------------------
 // receipt（wakeup-bridge の実投入記録）が正。無い宛先は member 台帳と bridge 台帳から
 // pending / seat_unavailable / bridge_unavailable を導出する。room_saved だけでは配達と言わない。
@@ -353,12 +387,16 @@ http.createServer(async (req, res) => {
     if (req.method === 'GET' && rest === 'members') {
       const now = Date.now()
       const bridges = bridgeHealth(room.name, now)
+      const activityLog = readActivityMessages(room)
       return json(res, 200, {
-        members: listMembers(room.name).map(m => ({ ...m, ...effectiveStatus(m, bridges, now) })),
+        members: listMembers(room.name).map(m => {
+          const effective = effectiveStatus(m, bridges, now)
+          return { ...m, ...effective, ...memberActivity(m, effective, activityLog) }
+        }),
         bridges,
         capabilities: {
           member_observation_v1: true, member_ledger_v1: true,
-          effective_status_v1: true, delivery_receipt_v1: true,
+          effective_status_v1: true, member_activity_v1: true, delivery_receipt_v1: true,
         },
       }, CORS)
     }
@@ -439,6 +477,13 @@ http.createServer(async (req, res) => {
       authFailures.delete(`${room.name}/${kind}`)
       return json(res, 200, { ok: true })
     }
+    // archive teardown はroomと会話ログを残すため、停止済みbridge台帳だけを消す。
+    // 消さないと空のarchive roomへstatus_bridge_down警告が恒久表示される。
+    if (req.method === 'DELETE' && rest === 'bridges') {
+      db.prepare('DELETE FROM bridges WHERE room = ?').run(room.name)
+      for (const kind of BRIDGE_KINDS) authFailures.delete(`${room.name}/${kind}`)
+      return json(res, 200, { ok: true })
+    }
     // 配送 receipt（決定102）。書き手は wakeup-bridge だけ。同じ (seq, recipient) は最新で上書き
     // （seat_unavailable → 再試行成功 delivered の遷移を残すため）
     if (req.method === 'POST' && rest === 'deliveries') {
@@ -524,12 +569,14 @@ const UI = room => `<!doctype html><html lang="ja"><head><meta charset="utf-8"><
 <title>${esc(room)} · Peertable</title>${FAVICON}<style>${STYLE}
 .top{position:sticky;top:0;z-index:2;background:var(--bg);border-bottom:1px solid var(--line);padding:12px 16px 0}
 .top>div{max-width:760px;margin:0 auto}
-.members{display:flex;gap:6px;overflow-x:auto;padding:10px 0;scrollbar-width:thin}
+.members{display:flex;gap:8px;overflow-x:auto;padding:10px 0;scrollbar-width:thin}
 .bridgewarn{color:var(--busy);font-size:12px;font-weight:650;padding:0 0 8px}
 .bridgewarn:empty{display:none}
 .chip.has-meta{cursor:pointer}
 /* 稼働状態の点。報告が途絶えたら unknown（中空）へ落として、古い状態を出し続けない */
 .chip .nm{display:inline-flex;align-items:center;gap:5px}
+.chip .state-label{font-size:10px;font-weight:700;color:var(--dim);white-space:nowrap}
+.chip .activity{display:block;max-width:190px;overflow:hidden;text-overflow:ellipsis;white-space:nowrap;color:var(--dim);font-size:10px;font-weight:500}
 .chip .st{flex:none;display:inline-block;width:7px;height:7px;border-radius:50%;background:var(--dim)}
 .chip .st.busy{background:var(--busy)}
 .chip .st.idle{background:var(--idle)}
@@ -539,7 +586,7 @@ const UI = room => `<!doctype html><html lang="ja"><head><meta charset="utf-8"><
 .metapop{position:fixed;z-index:20;background:var(--surface);border:1px solid var(--line);border-radius:10px;padding:8px 10px;font-size:12px;box-shadow:0 6px 20px rgba(0,0,0,.18);max-width:70vw}
 .metapop .metaname{font-weight:600;margin-bottom:2px}
 .metapop .metaline{color:var(--dim)}
-.chip{position:relative;flex:none;display:flex;align-items:center;gap:7px;padding:5px 11px 5px 5px;border:1px solid var(--line);border-radius:12px;background:var(--surface);font-size:12px;font-weight:600}
+.chip{position:relative;flex:none;display:flex;align-items:center;gap:7px;min-width:150px;max-width:230px;padding:6px 11px 6px 6px;border:1px solid var(--line);border-radius:12px;background:var(--surface);font-size:12px;font-weight:600}
 .chip .av{width:22px;height:22px;font-size:11px;flex:none}
 .chip .id{display:flex;flex-direction:column;gap:1px;min-width:0;line-height:1.25}
 .chip.recent{border-color:hsl(var(--h) var(--sat) var(--edge))}
@@ -755,8 +802,10 @@ async function refreshMembers(){
     // 閲覧面ごとに独自の鮮度判定を持つと、MCP と Web UI で違う判定になり誤認が再発する
     const st=m.status_effective??null
     if(st)c.classList.add('is-'+st)
+    const stateText=st?({busy:'作業中',idle:'待機',dead:'停止',blocked:'承認待ち',unknown:'不明'}[st]??st):'不明'
     const reason={status_unreported:'未報告(seat-status bridge が動いていない)',status_heartbeat_stale:'状態heartbeatが途絶えている',status_bridge_down:'状態bridgeが停止(status_bridge_down)',status_bridge_unreported:'状態bridgeが未登録',bridge_auth_failed:'bridge認証失敗(403)'}[m.status_reason]
-    meta.push(st?'状態 '+({busy:'作業中',idle:'待機',dead:'停止',blocked:'承認待ち',unknown:'不明'}[st]??st)+(reason?'（'+reason+'）':''):'状態 未取得（旧serverは実効状態を返さない）')
+    meta.push(st?'状態 '+stateText+(reason?'（'+reason+'）':''):'状態 未取得（旧serverは実効状態を返さない）')
+    meta.push('現在 '+(m.activity_text??'未取得（旧server）'))
     const usage=[]
     const busyAge=m.busy_since?Date.now()-Date.parse(m.busy_since):NaN
     if((st==='busy'||st==='blocked')&&Number.isFinite(busyAge)&&busyAge>=0)usage.push('継続 '+elapsed(busyAge))
@@ -766,12 +815,12 @@ async function refreshMembers(){
     c.appendChild(el('span','av',initial(m.name)))
     const id=el('span','id')
     const nameRow=el('span','nm',m.name)
-    // チップの常設表示は「アバター・名前・◉」だけ。◉は状態が新鮮な時だけ色が付き、
-    // 途絶・未報告は中空リング＝bridge が動いていないことがひと目で分かる。
-    // roles / settings / mission は title（ホバー）とタップ popover にだけ出す。
     nameRow.appendChild(el('span','st '+(st??'unknown')))
+    nameRow.appendChild(el('span','state-label',stateText))
     id.appendChild(nameRow)
+    id.appendChild(el('span','activity',m.activity_text??'現在作業未取得'))
     c.appendChild(id)
+    c.setAttribute('aria-label',m.name+'、'+stateText+'、'+(m.activity_text??'現在作業未取得'))
     // タップ環境には hover が無いので、押した時に同じ内容を出す（ホバーは title が担う）
     if(meta.length){c.classList.add('has-meta');c.addEventListener('click',ev=>{ev.stopPropagation();showMeta(c,m,meta)})}
     membersEl.appendChild(c)
@@ -821,6 +870,8 @@ function celebrate(name){
 }
 const BEAT=${HEARTBEAT_MS}
 let lastSeq=0,lastBeat=Date.now(),es=null,emptyEl=null,firstLoad=true,catching=false,memberDebounce=null
+const scheduleMemberRefresh=()=>{clearTimeout(memberDebounce);memberDebounce=setTimeout(refreshMembers,150)}
+const isActivityMessage=m=>m.from!=='system'&&typeof m.body==='string'&&/^(?:\[(?:次の行動|claim|引受|作業中)\])/i.test(m.body)
 // seq で二重描画を弾く。張り直し後の追いつきと SSE の新着が重なっても同じ発言は1回しか出ない
 function apply(m,live=false){
   if(m.seq<=lastSeq)return false
@@ -859,12 +910,12 @@ function connect(){
   // 場合は、この差分だけが手掛かりになる
   es.addEventListener('ping',e=>{lastBeat=Date.now();if(Number(e.data)>lastSeq)catchUp()})
   // 稼働状態・素性の変化。既存の refreshMembers() を150msデバウンスで呼ぶ（部分更新は実装しない）
-  es.addEventListener('member',()=>{clearTimeout(memberDebounce);memberDebounce=setTimeout(refreshMembers,150)})
+  es.addEventListener('member',scheduleMemberRefresh)
   es.onmessage=e=>{
     lastBeat=Date.now()
     const m=JSON.parse(e.data),stick=nearBottom()
     if(!apply(m,true))return
-    if(m.from==='system')refreshMembers();else{markActive(m.from);if(isCompletion(m))celebrate(m.from)}
+    if(m.from==='system')refreshMembers();else{markActive(m.from);if(isActivityMessage(m))scheduleMemberRefresh();if(isCompletion(m))celebrate(m.from)}
     if(stick)window.scrollTo(0,document.body.scrollHeight)
     syncToBottom()
   }