peertable 0.6.1 → 0.7.1

package/README.md

@@ -1,160 +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 four tools — `post`, `read_unread`, `read_log`, `members` — and a channel that wakes it whenever teammates address it. (`--dangerously-load-development-channels` is required while channels are in research preview; custom channels aren't on the allowlist yet.)
-
+<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.
 
-**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.4.16**.
-
-The design document and decision log (**91 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.*
+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,49 +1,49 @@
-{
-  "name": "peertable",
-  "version": "0.6.1",
-  "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/Dockerfile",
-    "skill/",
-    "!skill/**/__pycache__/**",
-    "README.ja.md"
-  ],
-  "engines": {
-    "node": ">=24"
-  },
-  "dependencies": {
-    "@modelcontextprotocol/sdk": "^1.0.0"
-  }
-}
+{
+  "name": "peertable",
+  "version": "0.7.1",
+  "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/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

@@ -13,7 +13,7 @@ import { findModelsDoc, resolveSeatIdentity } from '../skill/scripts/resolve-sea
 
 // client.mjs 側のハードコード版数。package.json の version と一致していることを
 // diagnostics の version_consistency が見る（2 つの版数源の drift 検出。決定45）
-const MCP_VERSION = '0.6.1'
+const MCP_VERSION = '0.7.1'
 const PKG_ROOT = join(dirname(fileURLToPath(import.meta.url)), '..')
 
 const USAGE = `usage:
@@ -73,6 +73,7 @@ const mcp = new Server(
       'メンバー一覧の名前・役割・設定・使命を見て連携せよ。members と read_unread 先頭に同じ欄がある。' +
       '<channel source="room"> の通知は「新着あり」の合図であり、本文は read_unread ツールで読む。' +
       '発言は post ツールを使う。to: "all" はroom全体、メンバー名はDM、配列は複数人宛である。' +
+      'post 応答の room_saved は room 保存だけの事実で、配達成功ではない。相手に届いた前提で進む前に delivery が delivered であることを確認せよ。' +
       `次にやる仕事があるターンを終える直前に post(to: "${ME}", message: "[次の行動] ...") を1回送れ。` +
       'この自己DMは席の TUI へ次ターンの入力として入る。仕事があるのに出さないと席は止まる。' +
       '手番が無く待機に入るときは自己DMを出すな。親へ [待機] を一度だけ送り沈黙せよ。空の終了通知は使うな。',
@@ -105,11 +106,24 @@ mcp.setRequestHandler(ListToolsRequestSchema, async () => ({
     },
     { name: 'read_unread', description: 'room全体宛と自分宛の未読メッセージを読む。読んだ位置は記憶される', inputSchema: { type: 'object', properties: {} } },
     { name: 'read_log', description: 'room ログの直近 count 件を読む（既定 50。全宛先を含む）', inputSchema: { type: 'object', properties: { count: { type: 'number' } } } },
-    { name: 'members', description: 'room に居るメンバーの一覧（名前・役割・設定・使命）', inputSchema: { type: 'object', properties: {} } },
+    { name: 'members', description: 'room に居るメンバーの一覧（名前・役割・設定・使命・実効稼働状態）と bridge 健全性。状態が unknown の席と bridge 障害はここで分かる', inputSchema: { type: 'object', properties: {} } },
+    { name: 'delivery_status', description: '発言 seq の宛先別配達状態を照会する。delivered / pending / seat_unavailable / bridge_unavailable / failed。room_saved は配達成功ではない', inputSchema: { type: 'object', properties: { seq: { type: 'number' } }, required: ['seq'] } },
   ],
 }))
 
 const fmt = m => `[${m.seq}] ${m.from} → ${Array.isArray(m.to_names) ? m.to_names.join(', ') : m.to} (${m.ts}): ${m.body}`
+const elapsedText = ms => {
+  if (!Number.isFinite(ms)) return null
+  const min = Math.floor(ms / 60000)
+  return min < 1 ? `${Math.floor(ms / 1000)}s前` : min >= 60 ? `${Math.floor(min / 60)}h${min % 60}m前` : `${min}m前`
+}
+// 実効稼働状態は server 生成の欄だけを読む（決定101）。MCP 側で鮮度判定を持たない
+const statusText = (m) => {
+  if (m.status_effective === undefined) return '状態=不明(旧server・実効状態なし)'
+  const age = elapsedText(m.status_age_ms)
+  if (m.status_reason === 'fresh') return `状態=${m.status_effective}（最終報告 ${age}）`
+  return `状態=${m.status_effective}（理由=${m.status_reason}${age ? `・最終報告 ${age}` : '・報告なし'}）`
+}
 const memberLine = (m) => {
   const rolesText = Array.isArray(m.roles) && m.roles.length ? m.roles.join('・') : ''
   const settingsText = [m.model, m.effort].filter(Boolean).join('×')
@@ -117,12 +131,28 @@ const memberLine = (m) => {
   if (rolesText) parts.push(`役割=${rolesText}`)
   if (settingsText) parts.push(`設定=${settingsText}`)
   if (m.mission) parts.push(`使命=${m.mission}`)
+  parts.push(statusText(m))
   return parts.join(' ')
 }
+const bridgeText = (bridges) => {
+  if (!bridges) return '⚠ bridge健全性: 不明（旧serverはbridge台帳を持たない）'
+  const label = { seat_status: '稼働状態bridge', wakeup: '配達bridge' }
+  const lines = ['seat_status', 'wakeup'].map((kind) => {
+    const state = bridges[kind]?.state ?? 'unknown'
+    return `${label[kind]}=${state}`
+  })
+  const broken = ['seat_status', 'wakeup'].some(k => bridges[k]?.state !== 'up')
+  return `${broken ? '⚠ ' : ''}bridge: ${lines.join(' / ')}`
+}
 const rosterText = async () => {
-  const { members } = await (await fetch(api('members'))).json()
-  if (!members?.length) return '席: （まだ誰も居ない）'
-  return `席: ${members.map(memberLine).join(' / ')}`
+  const { members, bridges } = await (await fetch(api('members'))).json()
+  if (!members?.length) return `席: （まだ誰も居ない）\n${bridgeText(bridges)}`
+  return `席: ${members.map(memberLine).join(' / ')}\n${bridgeText(bridges)}`
+}
+const deliveryText = (delivery) => {
+  const entries = Object.entries(delivery ?? {})
+  if (!entries.length) return 'delivery: （TUI配達対象の宛先なし）'
+  return `delivery: ${entries.map(([name, d]) => `${name}=${d.state}${d.reason ? `(${d.reason})` : ''}`).join(' / ')}`
 }
 
 mcp.setRequestHandler(CallToolRequestSchema, async req => {
@@ -134,7 +164,15 @@ mcp.setRequestHandler(CallToolRequestSchema, async req => {
       if (!r.ok) return { isError: true, ...text(`送信失敗: ${JSON.stringify(msg)}`) }
       // cursor は触らない。自分の発言は relevant で除外されるので進める必要が無く、
       // ここで進めると post より前に届いた未読を読まないまま既読にしてしまう（0.2.1 で修正）
-      return text(`sent [${msg.seq}]`)
+      // 保存と配達は別の事実（決定102）。sent の一語で両者を混ぜず、宛先別の配達状態を返す
+      if (msg.room_saved !== true) return text(`sent [${msg.seq}]（旧server: 配達状態は取得できない。room保存を配達成功と扱うな）`)
+      return text(`room_saved [${msg.seq}]（room保存のみ。配達成功ではない）\n${deliveryText(msg.delivery)}\n配達の確定は delivery_status ツール（seq=${msg.seq}）で delivered を確認すること`)
+    }
+    case 'delivery_status': {
+      const r = await fetch(api(`deliveries?seq=${Number(args.seq)}`))
+      const body = await r.json()
+      if (!r.ok) return { isError: true, ...text(`照会失敗: ${JSON.stringify(body)}`) }
+      return text(`seq ${body.seq}: room_saved=${body.room_saved}\n${deliveryText(body.delivery)}`)
     }
     case 'read_unread': {
       const { messages } = await (await fetch(api(`messages?since=${cursor}`))).json()
@@ -148,8 +186,8 @@ mcp.setRequestHandler(CallToolRequestSchema, async req => {
       return text(messages.slice(-(args.count ?? 50)).map(fmt).join('\n') || '（ログなし）')
     }
     case 'members': {
-      const { members } = await (await fetch(api('members'))).json()
-      return text(members.map(memberLine).join('\n') || '（誰も居ない）')
+      const { members, bridges } = await (await fetch(api('members'))).json()
+      return text(`${members.map(memberLine).join('\n') || '（誰も居ない）'}\n${bridgeText(bridges)}`)
     }
     default:
       throw new Error(`unknown tool: ${req.params.name}`)
@@ -345,6 +383,10 @@ async function runDiagnostics(asJson) {
       'scripts/parent-watch-logic.mjs',
       'scripts/seat-credential.mjs',
       'scripts/ensure-room-mcp.mjs',
+      // 既存卓の現行tree同期とteardownのblock単位所有。resume／teardownから呼ぶため一体で必須
+      'scripts/room-mcp-config.mjs',
+      'scripts/upgrade-team-assets.sh',
+      'scripts/remove-managed-room-mcp.mjs',
       'scripts/bridge-record-live.mjs',
       'scripts/leave-seat.sh',
       'scripts/change-seat.sh',
@@ -357,6 +399,9 @@ async function runDiagnostics(asJson) {
       'scripts/wakeup-bridge.mjs',
       'scripts/wakeup-delivery.mjs',
       'scripts/seat-status-bridge.mjs',
+      // 円卓開始ゲートと既存 room の正規 resume 入口（決定104・105）。欠けると親の依頼確定と再稼働が手作業へ戻る
+      'scripts/kickoff-gate.mjs',
+      'scripts/resume.sh',
       // teardown の archive（＝解散・既定）が呼ぶ。欠けるとログの写しが取れない
       'scripts/archive-room-log.py',
       'templates/gen-plan.mjs',