peertable 0.3.8 → 0.3.9

package/README.ja.md

@@ -75,6 +75,8 @@ docker compose -f deploy/compose.yaml up -d
 
 ライブビューはメンバーごとに vendor / model / effort と**稼働状態**（作業中・待機・**承認待ち**（許可ダイアログで止まっている）・停止）を出す。作業中の席はアイコンが動き、完了宣言（`[done]` / `[完了]` / `受理:` 等）の瞬間に席の上へ印が浮く。状態変化は SSE で押し込むので、30秒の再取得を待たず観測周期（約8秒）で切り替わる。発言にはログ番号（`[123]`）が付き、ライブ新着はブロック単位で現れる。**点が付かない席は「誰も報告していない席」**——状態の送信は別プロセス（スキルが起こす）で、**書けない時は常駐せずに死ぬ**ので「起きているのに黙っている」状態は存在しない。
 
+観測先は**席自身が名乗る**（`observe: {tmux_socket, tmux_target}`）。席の起動スクリプトと、席の中で動く MCP クライアントの両方が自分の tmux socket / session を登録するので、**スキル以外の経路で立てた席（aiterm の素の pane など）もそのまま観測対象になる**。表示名から `peer-<名前>` を推測しないので、任意のセッション名で立てた席が消える問題は起きない。名乗っていない古い席だけが従来の推測へ落ちる。常駐は専用 tmux セッションが保持し、**起動側は「起こした」ではなく「最初の観測が届いた」ことを確かめてから成功を返す**（確かめられなければログ末尾を出して非ゼロで落ちる）。
+
 API: `GET /api/<room>/messages` / `members` / `summary`（約120バイト・`seq`・`last_ts`・`member_count`）/ `events`（SSE）、`POST /api/<room>/messages` / `members`。
 
 **2. メンバーを着席させる。** room の MCP 定義は**プロジェクト root の `.mcp.json`** に置く:

package/README.md

@@ -111,6 +111,8 @@ Open `http://localhost:8790` — every room gets a live web view (SSE). **The we
 
 The live view shows, per member: vendor / model / reasoning effort, 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>/summary` (≈120 bytes: `seq`, `last_ts`, `member_count`) · `GET /api/<room>/events` (SSE) · `POST /api/<room>/messages` · `POST /api/<room>/members`.
 
 **2. Seat a member session.** The room MCP definition must live in the **project-root `.mcp.json`**:

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "peertable",
-  "version": "0.3.8",
+  "version": "0.3.9",
   "description": "A round table of peer agents. No orchestrator at the head. Turn Claude Code sessions into a team of equal, long-lived peers.",
   "type": "module",
   "license": "MIT",

package/room/client.mjs

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

package/skill/SKILL.md

@@ -51,6 +51,7 @@ description: 任意プロジェクトに Peertable チーム（対等メンバ
    - ログは `.team/wakeup-bridge.log`。**0件でも0件と出す**ので、起こせているか・取りこぼしていないかはログを見れば分かる。再現ハーネスは `experiments/bridge-catchup-repro.mjs`
 
 6.5 **席の稼働状態ブリッジ（setup.sh が自動で起こす）**: 手順3の scaffold が `ensure-bridge.sh <project> seat-status` で起こすので、**AI が手で叩く段は無い**。観測先は member の `observe: {tmux_socket, tmux_target}` を優先し、無い既存memberだけ `peer-<名前>` へ後方互換で落とす。socket は明示env → aiterm POSIX既定 → 検証済み`/tmp/aiterm-*.sock`1本 → 既定パスの順で解決し、bashからは`tmux-socket.mjs`を呼ぶ。既に立っている席はclient再起動まで`observe`を自己申告しないため、`peer-`以外の席で記述子が要る時は席かclientを再起動する。WSLではbridgeが読む**WSL側**の版が正で、Windows側だけの更新では直らない。
+   - **`nohup` は使わない（決定74）。** `ensure-bridge.sh` が専用 tmux セッション `peertable-<bridge>-<room>` で常駐を保持する。tmux は**呼び出し元シェルの寿命に縛られない**——WSL の `wsl -e bash -lc` 経由だと `nohup` の子が呼び出し元と一緒に殺され、**初回1回だけ送信して死ぬ**（2026-08-11 実測。macOS では死なないので、この症状は WSL でしか出ない）。ensure は手渡された `PEERTABLE_TMUX_SOCKET` / `PEERTABLE_POST_TOKEN` / `PEERTABLE_URL` を command 側で明示して渡す——新 session が継ぐのは tmux *server* の環境で、呼び出し元 client の環境ではないため
    - **setup が起こし、teardown が止める（対称）。** 2026-08-10 までは「起こすかは卓の任意」で手で `nohup` する設計だったが、それが2つの失敗を招いたので変えた: 起こし忘れと、**トークンを持たないシェルで起こすこと**。後者は実害が出た——`~/.config/peertable.env` の `export` 欠落により、`source` した shell から起こした常駐がトークンを持たず、**4時間 HTTP 403 を撃ち続けた**。参加者一覧には点が1つも出ず、**「起こしていない」と見分けがつかなかった**
    - **書込トークンは起こす側の env に依存しない。** ブリッジ自身が `launch-seat.sh:25-27` と同じ規則で解決する（env が先・無ければ `~/.config/peertable.env` を読む。`export` の有無を問わない）。同じ規則を `run-bridge.mjs` も使う
    - **書けない常駐は生まれない。** 一度も書けていないまま送信が全件失敗したら `SEAT_STATUS_BRIDGE_WRITE_DENIED` で常駐に入らず死ぬ。一度書けた後の連続失敗は10回で `SEAT_STATUS_BRIDGE_UNREACHABLE`（wakeup-bridge と同じ本数・決定54）。**席がまだ立っていない tick は失敗に数えない**ので、setup 直後に起こしても死なない