peertable 0.3.6 → 0.3.8

package/skill/scripts/wakeup-bridge.mjs

@@ -12,9 +12,10 @@
 // 送った文言はそのターンの中で読まれ、指示どおりに動いた（steering が効く）。したがって
 // idle 待ちの経路は持たない——待ちを入れると、混んでいる席ほど起床が遅れる。
 import { execFile } from 'node:child_process'
-import { existsSync, readFileSync, unlinkSync, writeFileSync } from 'node:fs'
+import { existsSync, readFileSync, renameSync, unlinkSync, writeFileSync } from 'node:fs'
 import { join } from 'node:path'
 import { promisify } from 'node:util'
+import { resolveSeatObservation, resolveTmuxSocket } from './seat-usage.mjs'
 
 const run = promisify(execFile)
 const [proj, ...rest] = process.argv.slice(2)
@@ -24,7 +25,8 @@ if (!proj || rest.length === 0) {
 }
 
 const record = join(proj, '.team', 'wakeup-bridge.json')
-const sock = process.env.PEERTABLE_TMUX_SOCKET ?? `${process.env.TMPDIR}claude-tmux-sockets/claude.sock`
+const socketResult = resolveTmuxSocket(process.env)
+const sock = socketResult.socket
 const alive = pid => { try { process.kill(pid, 0); return true } catch { return false } }
 const sleep = ms => new Promise(r => setTimeout(r, ms))
 const log = line => console.log(`[${new Date().toISOString()}] ${line}`)
@@ -63,6 +65,28 @@ process.on('SIGINT', cleanup)
 
 // 席ごとに未配達を溜めて、2秒ごとにまとめて1回起こす（連投で席を何度も起こさない）
 const pending = new Map(seats.map(s => [s, []]))
+let members = new Map()
+async function refreshMembers() {
+  try {
+    const res = await fetch(`${url}/api/${encodeURIComponent(room)}/members`)
+    if (!res.ok) throw new Error(`members ${res.status}`)
+    const body = await res.json()
+    members = new Map(body.members.map(member => [member.name, member]))
+    return true
+  } catch (error) {
+    // 記述子の更新が読めないことは起床停止の理由にしない。直前の map を保ち、
+    // 未登録席は wake() の legacy target へ戻す。縮退を必ずログに残す。
+    log(`member 記述子を更新できないので直前の観測先で続ける: ${error.message}`)
+    return false
+  }
+}
+await refreshMembers()
+function markReady() {
+  const next = { ...JSON.parse(readFileSync(record, 'utf8')), ready_at: new Date().toISOString() }
+  const temp = `${record}.tmp`
+  writeFileSync(temp, JSON.stringify(next) + '\n')
+  renameSync(temp, record)
+}
 
 async function wake(seat, msgs) {
   const last = msgs[msgs.length - 1]
@@ -71,9 +95,14 @@ async function wake(seat, msgs) {
     ? `room に新着あり（${last.from} → ${audience}）。read_unread で読むこと。`
     : `room に新着 ${msgs.length} 件（最新: ${last.from} → ${audience}）。read_unread で読むこと。`
   try {
-    await run('tmux', ['-S', sock, 'send-keys', '-t', `peer-${seat}`, text])
+    // bridge 起動後の着席も次の配達で取り直す。初回だけの snapshot にすると
+    // 新席を「member 不明」として永久に起こせず、旧 peer- 互換より後退する。
+    await refreshMembers()
+    const observation = resolveSeatObservation(members.get(seat) ?? { name: seat }, sock)
+    if (observation === null) throw new Error(`観測記述子も既定 socket も無い: ${seat}`)
+    await run('tmux', ['-S', observation.socket, 'send-keys', '-t', observation.target, text])
     await sleep(400)
-    await run('tmux', ['-S', sock, 'send-keys', '-t', `peer-${seat}`, 'Enter'])
+    await run('tmux', ['-S', observation.socket, 'send-keys', '-t', observation.target, 'Enter'])
     log(`起こした: ${seat} ← ${msgs.length} 件（最新 seq ${last.seq}）`)
   } catch (error) {
     // 席が畳まれていれば tmux が落ちる。黙って飲まず、毎回出す（何件落としたかも出す）
@@ -172,6 +201,7 @@ for (;;) {
       if (!res.ok) throw new Error(`events ${res.status}`)
       failures = 0
       log('SSE 接続')
+      markReady()
       await catchUp('再接続')
       let buf = ''
       for await (const chunk of res.body) {

package/skill/templates/member-standalone.md

@@ -8,7 +8,7 @@
 
 1. `.team/tasks.md` で議題を見る。`read_log` で既存の claim と完了報告を照合し、まだ誰も持っていないものを選ぶ
 2. 憲章の手順で`read_log`から先行claimを確認し、roomに`[claim] <タスク>`を記録する。起こす必要のある相手だけを宛先へ入れ、記録だけなら自分宛でよい。**`[claim]` は独立した1発言で出す**——完了報告や他タスクの話と同じ発言に畳まない。宣言としては有効でも、後から機械的に追えなくなり、監査が「宣言が無い」と誤読する（2026-08-08 実測）。単独モードでは room ログが唯一の正本なので、より効く
-3. 実装する。インターフェースなど他タスクに影響する決定は、影響を受けるメンバーを明示宛先にして一行で共有する
+3. 実装する。インターフェースなど他タスクに影響する決定は、影響を受けるメンバーを明示宛先にして一行で共有する。宛先は**その内容で今すぐ動く必要がある相手だけ**——同報・返答不要の情報共有目的で複数人を並べない（決定71）
 4. 完了手順:
    - 何を作り、どう確認したかを自分で確かめる（テスト・実行・実測。「たぶん動く」で閉じない）
    - 変更ファイルを `git add` して commit する（メッセージは日本語一行。対象ファイルを明示して他人の作業中変更を巻き込まない）
@@ -25,6 +25,7 @@
 
 ## 注意
 
+- **DM宛先は最小化する（決定71）**: 親宛DMは①done報告・監査受理要請、②オーナー承認gateに関わる物件、③親・オーナーにしか解けないblocker・裁定依頼（`[effort変更依頼]`はこれに該当）の3種だけ。進捗・調整・意見の共有は親宛DMにしない。席同士のDMも、その内容で**今すぐ動く必要がある相手だけ**へ送る——同報・返答不要の情報共有目的の複数宛先は禁止。宛先を選ぶ基準は「この宛先は受け取って何をする？」に答えられるかで、答えられない宛先は外す。記録目的はroomログ（全員pull可読）で足りる
 - 誰が何を持っているかを機械に問い合わせられない卓である。claim と完了の宣言を落とした瞬間に重複作業になるので、宣言を省かない
 - room の新着通知が来たら read_unread で読む。返事が要るものには post で応える
 - **Codex 席の場合**: 起床は channels ではなく wakeup-bridge が担う。`room に新着あり（<誰> → <宛先>）。read_unread で読むこと。` が端末へ直接届くので、Claude 席と同じく read_unread で読む。**作業中でも割り込んで届く**（そのターンの中で読まれる）ので、届いたらその場で手を止めて読み、返事が要るなら post してから元の作業へ戻る。自分の発言では起きない

package/skill/templates/member.md

@@ -9,7 +9,7 @@
 1. `lattice todo status --json` で ready なタスクを見る。{{CLAIM_SCOPE}}
 2. 憲章の手順で room に claim を宣言する。**`[claim]` は独立した1発言で出す**——完了報告や他タスクの話と同じ発言に畳まない。宣言としては有効でも、後から機械的に追えなくなり、監査が「宣言が無い」と誤読する（2026-08-08 実測）
 3. `lattice todo start --plan {{PLAN_KEY}} --task <id>` で着手を記録する。**誰も着手しておらず ready が2件以上ある frontier の先頭を取る時だけ `--parallel-frontier` が必須**（無いと `PARALLEL_DISPATCH_REQUIRED / parallel_frontier_requires_declaration` で弾かれる）。ready が1件だけ、または既に誰かが着手している frontier へ後から乗る時は素の start でよい
-4. 実装する。インターフェースなど他タスクに影響する決定は、決めた時点で影響を受けるメンバーを明示宛先にして一行で共有する。broadcastは無く、他のメンバーはroomログをpullで読む。**正しさの確認は実測だけが与える（決定66）**——着手していない工程の設計・契約・手順を思想で検証しない。次工程の起草は「着手できる最小限」で止め、実測で答えられる問いを議論で答えない。監査も対象に触れるもの（diff・実行・突合）だけが監査で、触れない予想は監査ではない
+4. 実装する。インターフェースなど他タスクに影響する決定は、決めた時点で影響を受けるメンバーを明示宛先にして一行で共有する。宛先は**その内容で今すぐ動く必要がある相手だけ**——同報・返答不要の情報共有目的で複数人を並べない（決定71）。broadcastは無く、他のメンバーはroomログをpullで読む。**正しさの確認は実測だけが与える（決定66）**——着手していない工程の設計・契約・手順を思想で検証しない。次工程の起草は「着手できる最小限」で止め、実測で答えられる問いを議論で答えない。監査も対象に触れるもの（diff・実行・突合）だけが監査で、触れない予想は監査ではない
 5. 完了手順:
    - 証跡ファイル `evidence/{{PLAN_KEY}}/<task_id>.md` に「何を作り、どう確認したか」を書く（ディレクトリが無ければ作る。task_id は campaign を跨いで再利用されるので、平置きにすると前の campaign の証跡を上書きで消す）
    - 変更ファイルと証跡を `git add` して commit する（メッセージは日本語一行。対象ファイルを明示して他人の作業中変更を巻き込まない）
@@ -28,7 +28,7 @@
 9. **監査findingに採れるのは欠陥だけ（決定65）。** 受入をblockできるfindingは「実際に再現するエラー・受入条件の不成立・明白な論理破綻・具体的な安全事故経路」だけ。**「安全装置を増やした方がいい」「この構成の方が便利」といった思想・改善提案はfindingではない**——申し送り（`todo note`・課題帳）へ自分で記録して受入はそのまま通し、**実装者に返信・対応の義務を生まない**。思想を1つ1つのToDoの監査結果へ混ぜると開発は永遠に終わらない（オーナー裁定 2026-08-09）。欠陥か思想かの線引きは**あなたの判断**で行う——機械的な形式基準は置かない（基準で縛ると本物の指摘まで形式で弾かれる）。再現手順を添えると監査は速く強くなるが、それは義務ではなく技法である
 10. **監査の重さは2段で使い分け、閉じるのは欠陥の枯渇で決める（決定64）。** 通常のToDoは軽く: 実装者以外の席が対象diff・受入条件・focused testを確認して閉じる。複数席・独立fixture再現・反証という**重い構造は、Wave/Phaseの受入gateと契約クリティカル面（認可・lease・公開契約・データ破壊経路）だけ**。**終了条件は巡数ではない**——欠陥（決定65資格）が出た巡の次は何巡目でも正当で、欠陥の出なかった巡で閉じる。何席・何巡は自分の判断（数の上限で縛らない）。迷ったら軽い方——全ToDoを重くすると卓全体が止まる（2026-08-09実測）
 11. **監査は文脈近接の独立1席（決定67）。** 監査を依頼する時は、**同じ工程・関連ToDoを担当した席**（文脈を既に持つ席）から**1席だけ**選ぶ。無関係の席へ依頼しない（契約・経緯の冷間読み込みでトークンを焼く）。独立の要件は「実装者本人でない」ことだけで、文脈近接と両立する。**自分が依頼されていない監査へ自発参加しない・他席の監査結果へ追認を送らない**。2席目（別レンズ）を付けてよいのは決定64の重い面（契約クリティカル・Wave/Phase gate）だけで、付ける側が理由1行を添える
-12. **claimできるToDoが無いなら仕事を発明しない（決定68）。** 依頼されていない監査・他席への状況照会・正典の自主レビューを暇つぶしに始めない（空いた時間は成果ではなくコスト）。「[待機] <名前>」を親宛DMで1行宣言して黙る。縮退の打診が来たらWIP棚卸し（claim中ToDo・未commit変更・未報告結果・残process/一時fixture）を正直に返す
+12. **claimできるToDoが無いなら仕事を発明しない（決定68）。** 依頼されていない監査・他席への状況照会・正典の自主レビューを暇つぶしに始めない（空いた時間は成果ではなくコスト）。**roomへ**「[待機] <名前>」を1行宣言して黙る（親宛DMにしない——決定71。親は決定68の運用側どおりroomログをpullして席数を判断しており、DMで起こす必要はない）。縮退の打診が来たらWIP棚卸し（claim中ToDo・未commit変更・未報告結果・残process/一時fixture）を正直に返す
 13. 1 へ戻る
 
 ## effortを変更してほしい時
@@ -116,6 +116,7 @@ lattice run intake --run .lattice/runs/<run-id> --task <id>
 
 ## 注意
 
+- **DM宛先は最小化する（決定71）**: 親宛DMは①done報告・監査受理要請、②オーナー承認gateに関わる物件、③親・オーナーにしか解けないblocker・裁定依頼（`[effort変更依頼]`はこれに該当）の3種だけ。進捗・調整・意見の共有や待機宣言は親宛DMにしない。席同士のDMも、その内容で**今すぐ動く必要がある相手だけ**へ送る——同報・返答不要の情報共有目的の複数宛先は禁止。宛先を選ぶ基準は「この宛先は受け取って何をする？」に答えられるかで、答えられない宛先は外す。記録目的はroomログ（全員pull可読）で足りる
 - Lattice の書き込みが `STORE_WRITE_CONFLICT` 等で弾かれたら、1〜2 秒待って同じコマンドを再実行する（同時書込の正常な負け方であり、壊れてはいない）
 - `--parallel-frontier` を付けた start が `parallel_frontier_not_applicable` で弾かれたら、それは**その task がもう `next_ready` に居ない**（他人が着手済み・依存で塞がった）という意味である。フラグの不具合ではないので付け外しで粘らず、`lattice todo status --json` と room ログで claim 状況を確認し直す
 - claim が衝突したら、Lattice の start 記録（誰が in-progress か）を機械の事実として使う。**装置は claim の争いを裁定しない**——装置が見るのは着手済み task 同士の競合だけで、誰が取るかは卓が決める