peertable 0.3.3 → 0.3.5

package/skill/templates/member.md

@@ -4,27 +4,121 @@
 
 ## 作業ループ
 
+**作業を選ぶのも始めるのもあなたである。** 装置から仕事が降ってくることはないし、着手前に装置の許可を待つこともない（オーナー裁定 2026-08-09・改・裁定1）。Lattice が居る卓では、着手した後に装置が競合を見て介入してくることがある——それは次の「装置が介入してきた時」に従う。
+
 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. 実装する。インターフェースなど他タスクに影響する決定は、決めた時点で room 全員宛に一行で共有する
+4. 実装する。インターフェースなど他タスクに影響する決定は、決めた時点で影響を受けるメンバーを明示宛先にして一行で共有する。broadcastは無く、他のメンバーはroomログをpullで読む。**正しさの確認は実測だけが与える（決定66）**——着手していない工程の設計・契約・手順を思想で検証しない。次工程の起草は「着手できる最小限」で止め、実測で答えられる問いを議論で答えない。監査も対象に触れるもの（diff・実行・突合）だけが監査で、触れない予想は監査ではない
 5. 完了手順:
    - 証跡ファイル `evidence/{{PLAN_KEY}}/<task_id>.md` に「何を作り、どう確認したか」を書く（ディレクトリが無ければ作る。task_id は campaign を跨いで再利用されるので、平置きにすると前の campaign の証跡を上書きで消す）
    - 変更ファイルと証跡を `git add` して commit する（メッセージは日本語一行。対象ファイルを明示して他人の作業中変更を巻き込まない）
    - `.team/scripts/done.sh <task_id>` を実行する（evidence 記述子の生成と `lattice todo done` をやってくれる）
-6. room に完了を一行報告する。**その時「この点を見てほしい」を添える**——完了 task の監査は実装者以外の席が行い（決定60）、依頼が具体的なほど監査は速く深くなる
-7. **手が空いていて ready が無いなら、他の席の done を監査する。** 実装者以外なら誰でもよい。実物（diff・検証結果・ハーネス）を自分で走らせて所見を room へ出す——**報告を読むだけでは監査にならない**。親は所見を読んで受理を宣言するだけで、コードは読まない
-8. 1 へ戻る
+6. **ToDo の内側にリストを作らない。溜まったらグラフへ出す。** 実装中に「あれもやる」「これも要る」が
+   増えて、頭の中や作業メモに**チェックリストが生えてきたら、それは ToDo が1つでなくなった合図**である。
+   1つの ToDo の内側で消化せず、**A1..An ＋ 残余 A' へ分けてグラフ（工程正本）へ出す**。
+   - **装置は思考の中の暗黙 gate を検出できない**（宣言が動いて初めて `scope_expanded` に出る）。
+     だから**行動へ出る前の相はあなたが自分で捕まえる**しかない
+   - 分けるのは遅らせるためではない。**並列に取れるようになり、監査も受入も分かれて軽くなる**
+   - 判断はあなたがする。**装置は「宣言が N 回膨張した」「ここは合流点だ」までしか言わない**——
+     その膨張が上流の契約確定への追従なのか、自分の変更の後始末なのか、元から在った面の見落としなのか、
+     思いつきで盛った分なのかは、**あなたにしか分からない**（2026-08-09 実測: 1つの ToDo に前3種が同時に出た）
+7. room に完了を一行報告する。**その時「この点を見てほしい」を添える**——完了 task の監査は実装者以外の席が行い（決定60）、依頼が具体的なほど監査は速く深くなる
+8. **手が空いていて ready が無いなら、他の席の done を監査する。** 実装者以外なら誰でもよい。実物（diff・検証結果・ハーネス）を自分で走らせて所見を room へ出す——**報告を読むだけでは監査にならない**。親は所見を読んで受理を宣言するだけで、コードは読まない
+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）を正直に返す
+13. 1 へ戻る
+
+## effortを変更してほしい時
+
+作業を安全に中断できる状態にしてから、親だけへ`[effort変更依頼] <level>`を明示DMする。親が変更すると席は再起動し、会話contextは引き継がれない。再起動後は下の再着任手順でrole・工程正本・roomログから現在地を取り直す。自分でCLI設定を変えたり、broadcastで依頼したりしない。
+
+## Lattice の実行層へ自分の着手を載せる（pull 型・載っている卓だけ）
+
+**仕事は降ってこない。** 上のループどおり自分で選んで `todo start` した後、その着手を実行層へ持ち込むと、隔離 worktree という設備が使え、装置が他の着手済み ToDo との競合を見てくれる。**持ち込みは許可申請ではない**——装置は通す／通さないを決めるのではなく、競合した時だけ「留まれ」と言う。載っていない卓ではこの節は静かに眠る。
+
+```
+lattice run intake --run .lattice/runs/<run-id> --task <id>
+  → {worktree_path, base_sha, intervention: {state: none|hold, reason}}
+```
+
+**`lattice` は `"${LATTICE_CLI:-lattice}"` で叩く。** 席の env に `LATTICE_CLI` が入っている卓は、
+**PATH の install が古くて pull 系 command を持たない**（release 前の source tree を実測する卓）。
+そのまま `lattice` と打つと**手順どおりなのに command が無い**という形で詰まる。
+以下の例では `lattice` と書くが、実際は必ずこの形で叩くこと。
+
+**その run は誰が作るのか。** 装置が用意してくれるものではないし、setup も作らない——
+**卓が自分で作る設備**である。手順:
+
+0. `lattice run list --json` で **同じ plan の active な pull run**（`selection: "pull"`）を確認する
+   - **1件** → **それを共有する。** 席ごとに run を作らない
+   - **0件** → **room で生成担当を1席決めてから**作る（競争を起こさないのが安いので、先に決める）
+     ```
+     lattice run start --selection pull --id <plan>-<一意suffix> --plan <plan_key> --equipment detached-worktree
+     ```
+     **id に plan key だけの固定値を使わない。** `close` しても run directory は残り、
+     `run list` は closed を返さないので、**「無いのに `RUN_EXISTS` で作れない」**という
+     袋小路に入る（2026-08-09 実測）。時刻や通番の一意 suffix を付ける
+   - **`RUN_EXISTS` が返ったら** → **相手の run を推定しない。** 再度 `run list` して、
+     active があればそれを使い、無ければ**別の一意 id で明示的に作り直す**
+   - **複数件** → **止めて room で決める。** どれが正かは機械には決められない
+1. 作った席は **`run_ref` を room へ一行で共有する**（他の席はそれへ intake する）
+
+**これは設備の生成であって配車ではない。** run は intake の入れ物で、**中身（誰が何をやるか）は
+空のまま**である。作った席が他の席の仕事を決めたことにはならない。
+
+1. **`todo start` を先に済ませてから intake する。** 装置は Todo 正本の start event へ束縛するので、start していない task は intake できない。**逆順にしない。**
+2. **`intervention.state` を読む。** `none` なら worktree を使ってそのまま進める。`hold` なら**留まる**——他の着手済み task と競合しているという装置の判定である。理由（`reason`）を読み、room で調整するか、seam を切って解消する。**hold を無視して進めない。** 解消したかは `lattice run intake intervention --run <ref> --task <id>` で自分で読み直せる（bridge の `[介入]` 投稿を待たなくてよい。bridge は可視化であって通知の唯一経路ではない）
+3. **worktree を受け取ったら、自分の pid を装置へ渡す（attach）。** これをしないと、装置は競合時に「留まれ」と言うことはできても、実際に止めることができない（協調 hold のまま）。
+   ```
+   lattice run intake attach --run <ref> --task <id> --input <file>
+   ```
+   input は **`.team/seats/<あなたの名前>.json` を読んで `schema` を足すだけ**である（変換も再計算も要らない）。
+   ```json
+   {"schema":"lattice.pull_worker_attach_input.v1","name":…,"session":…,"pid":…,
+    "started_identity":…,"argv_digest":…,"recorded_at":…}
+   ```
+   **pid を自分で推定しない。** その file だけが正で、無ければ room で言う（黙って別の値を渡さない）。**他の席の seats file を読まない。**
+4. **intake は1本ずつ。** 前の intake が accepted / closed / released になるまで次を取らない。**席は1つの process なので、2本 intake すると片方の hold がもう片方を巻き込む**——制御の粒度が壊れる。
+5. **worktree の中だけを、絶対パスで触る。** `cd` しない・env を書き換えない・別 project へ移らない。席の room 接続と MCP 解決は cwd と env に乗っているので、動かすと卓から落ちる。git は `git -C <worktree> …`、編集は絶対パスで開く
+6. **commit してよい。禁止は `push` / `branch` / `merge` / `rebase` / `reset` / `stash` の6つ**（正は Lattice engine の `FORBIDDEN_OPERATIONS`）。worktree は `base_sha` の detached HEAD なので、そこへ積む commit は base の子孫のままで canonical branch を動かさない。逆に6つは HEAD を base の子孫から外すか、外部へ効果を出す操作なので、観測の前提か公開契約のどちらかを壊す
+7. **宣言境界の外へ書いても黙って弾かれない——観測に出る。** 書く必要があると分かった時点で room へ言う。隠して書いても diff で見えるだけである
+8. **検証は worktree の中で回す。** worktree は `base_sha` の clean checkout なので、gitignore 済みの資産（`node_modules` など）が**無い**。埋めに行く前に次を読むこと。
+   - **worktree の中で `npm install` してはいけない。** checkpoint 観測は `git status --ignored=matching` で撮る＝**gitignore 済みの書き込みも拾う**（gitignore 経由の scope 迂回を塞ぐ設計）。install した file はそのまま観測へ出て、diff entry 上限（256）を超えた時点で**観測そのものが失敗する**。自分の task の記録を自分で壊すことになる
+   - **依存は install しなくても解決する。** worktree は repo 配下（`<repo>/.lattice/runs/…/tree`）に切られるので、Node の bare specifier 解決が親ディレクトリを遡って canonical の `node_modules` に当たる（repo の外に置かれた木では当たらない）。これは現在の worktree 配置がもたらしている便益であって、どこでも成り立つ性質ではない
+   - **当たるのは canonical に入っている版である。** worktree の `package.json` が要求する版とは限らないので、**lockfile や依存を動かす task では、検証結果を「解決された版のずれ」ごと疑う**
+   - それでも回らない検証は、無理に回さず room で言う。**動かないからといって canonical tree で回さない**——それは測りたい木ではない
+9. **終わったら `todo done` を打ってから accept する。**
+   ```
+   # canonical repo の cwd から打つ。証跡は worktree にしか無いので絶対 path で渡す
+   cd <canonical repo>
+   PEERTABLE_PLAN={{PLAN_KEY}} .team/scripts/done.sh <id> --evidence-from <worktree>/evidence/{{PLAN_KEY}}/<id>.md
+   lattice run intake accept --run <ref> --task <id>
+   .team/scripts/done.sh --landing-run <ref>
+   ```
+   **`--evidence-from` を省いてはいけない。** 省くと canonical 側の証跡（無いか、別物）を hash する。
+   **canonical へ証跡を書き写して通すのも禁止**——「worktree の中だけを触る」契約を破りながら
+   green にする偽装になる。linked worktree は canonical と object DB を共有するので、
+   **worktree に commit した証跡は canonical から読める**（複製は要らない）。
+   装置が worktree の base→HEAD を独立に観測して受理する。**intake した席だけが attach / accept できる**（装置が actor で束縛している）ので、他の席に代わりに打ってもらうことはできない。
+   最後の landing-only 呼び出しは、accept 済み receipt が canonical default branch へ未着地なら
+   `未着地 N本`を出す。警告だけで処理は止めないが、`未push` と別の完了軸なので読み飛ばさない。
+
+**成果の正本はあなたの commit ではなく、Lattice が撮った observed diff である。** 受理されるのはその観測であって、commit そのものではない。
+
+**worktree は `run close` でも supervisor 終了でも畳まれない。** 畳むのは `run abandon` だけである（`removeScriptedWorktrees` の呼び出しはそこ1箇所）。**それでも「commit したから残る」と思わないこと**——worktree を消せば、その commit はどの参照からも辿れなくなり gc の対象になる。canonical への着地は run の外の別工程であり、`accept` も `run close` も着地の宣言ではない。着地状況は `lattice run landing --run <ref>` が receipt 単位で出す。
 
 ## 再着任（context が要約されたら）
 
-自分の context が要約された（＝会話の前半が手元に無い）と気づいたら、実装を続ける前に `.team/roles/member.md` と `.team/CLAUDE.md` を読み直して着任し直し、room へ `[再着任] <名前>` を一行投稿する。進行中 claim の状態は自分の記憶でなく**工程正本で取り直す**——`lattice todo status --json` の active に自分の task が居るかを確認し、`read_log` で自分の claim と完了報告を照合する。記憶と正本が食い違ったら、正本を正として食い違いを room で報告する。
+自分の context が要約された（＝会話の前半が手元に無い）と気づいたら、実装を続ける前に `.team/roles/member.md` と `.team/CLAUDE.md` を読み直して着任し直し、room へ `[再着任] <名前>` を一行投稿する。進行中の仕事は自分の記憶でなく**工程正本で取り直す**——`lattice todo status --json` の active（自分が start した task）と room の claim・完了報告を照合し、実行層へ載せていたなら `lattice run observe --run <ref>` の `intakes` で自分の intake と `intervention` を確認する。記憶と正本が食い違ったら、正本を正として食い違いを room で報告する。
 
 ## 注意
 
 - 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 が衝突したら、Lattice の start 記録（誰が in-progress か）を機械の事実として使う。**装置は claim の争いを裁定しない**——装置が見るのは着手済み task 同士の競合だけで、誰が取るかは卓が決める
 - **note が持つものを room の散文へ二重化しない**。設計メモ・タスク固有の経緯は `lattice todo note` に置き、room には決定と進捗だけを流す
 - room の新着通知が来たら read_unread で読む。返事が要るものには post で応える
 - **Codex 席の場合**: 起床は channels ではなく wakeup-bridge が担う。`room に新着あり（<誰> → <宛先>）。read_unread で読むこと。` が端末へ直接届くので、Claude 席と同じく read_unread で読む。**作業中でも割り込んで届く**（そのターンの中で読まれる）ので、届いたらその場で手を止めて読み、返事が要るなら post してから元の作業へ戻る。自分の発言では起きない