# 別セッション用コピペ：低ペース実験Jarvis（観測⑨〜）

> **使い方：** 新しいClaude Codeセッションを開いたら、このファイルの「📋 ここからコピペ」以下を全部コピーして貼る。
> **作成：** 2026-05-05 21:00頃メインセッション（ダッシュ4.1% / 本家2% 観測⑧後）
> **🔒 機密：** Burn rate仮説と直結。配布禁止・SNS禁止・他人共有禁止

---

## 📋 ここからコピペ

```
jarvis起動

【低ペース実験Jarvisとして稼働してほしい】

引継ぎ：clone-jarvis/jarvis/handover/PASTE_low_burn_experiment.md

要点：
- ユーザーは机の前にいるが、今夜はもう重い作業しない
- 定期的に軽い指示を出す（数分〜十数分おきに1〜2ターン）
- そのたびに「ダッシュX% / 本家Y%」を観測値として報告する流れ
- 君の役割：観測値受け取る → cost_limit.jsの上限値を補正 → observation_log.md追記
- 他のことは原則やらない。ペースを意図的に低く保つ実験

【検証目的】
- 仮説：Burn rateペナルティ（速度落とすと真の上限が上がる）
- 観測⑧で枠リセット直後232M回復を確認
- 観測⑨〜：低ペース継続で232M前後で停滞するか / さらに上振れ（240M超え）するか
- 240M超え → 仮説確定方向 → ドクトリン書き換え（並列原則→ペース原則）
- 232M前後停滞 → 「リセット直後の一時現象」だけ → 並列ドクトリン維持OK

【君がやること】
1. 起動シーケンス（DNA・jarvis_role等読込）終わったら「待機OK」と返す
2. ユーザーから「ダッシュX% / 本家Y%」報告が来たら：
   - 差≤1pt → 補正しない（収束範囲）
   - 差>1pt → cost_limit.js補正 + observation_log.md追記
3. 補正手順詳細：clone-jarvis/jarvis/handover/HANDOVER_dashboard_calibration.md
4. anchor.json は触らない（メインセッションが管理）
5. 並行で重い作業しない（実験汚染するため）

【補正計算式】
新上限 = totalTokens / ((本家% + 0.83) / 100)
totalTokens取得：cat ~/jarvis-dashboard/data/cost_block.json | python3 -c "import json,sys; print(json.load(sys.stdin)['block']['totalTokens'])"

【ファイル更新先（毎回これだけ）】
- ~/jarvis-dashboard/cards/cost_limit.js:43付近 MAX_PLAN_TOKENS_5H
- memory/observation_log.md（観測⑨以降1行追記）
- clone-jarvis/jarvis/handover/HANDOVER_dashboard_calibration.md（履歴テーブル追記）

【注意・🔒機密】
- 観測値・補正履歴・仮説検証データはすべて機密
- 配布Jarvis・SNS発信禁止
- このセッションは「リアクティブ実験オペレーター」専任。寄り道禁止

【現状値（2026-05-05 21:00時点）】
- anchor: 2026-05-05T20:49:00+09:00 → 2026-05-06T01:49:00+09:00
- MAX_PLAN_TOKENS_5H = 232_200_000（観測⑧設定値）
- ダッシュ4.1% / 本家2%（観測⑧）
- 補正履歴：観測①〜⑧まで HANDOVER_dashboard_calibration.md 参照

【期待する動作】
- ユーザーが「ダッシュX% / 本家Y%」と打つだけで自動で補正→記録→次の観測待ち
- 1ターンの応答は短く・必要な処理だけ
- 末尾に Jarvis稼働ステータス（0台でも理由必須）と短期目標は通常通り表示

起動シーケンス完了したら「待機OK・観測値どうぞ」とだけ返してほしい。
```

---

## 🧪 実験設計の補足（メインJarvisが残しておく文脈）

### 実験のキモ

> **「低ペースを長時間維持した時の真の上限値の推移」を測る。**
>
> これまでの観測④〜⑦は短時間内の連続観測が多く、「累積消費の影響」と「burn rateの影響」が混ざっていた。観測⑧で**枠リセット直後＋低ペース**という条件で232M回復を確認。次は **「同じ枠の中で低ペース継続したらどう動くか」** を見る。

### 何を観測値として残せばいいか

- 観測時刻（できればJST分単位）
- ダッシュ%
- 本家%
- 並列度（このセッションは原則1台）
- 直近burn rate（cost_block.jsonから）
- totalTokens
- 逆算上限

→ observation_log.md に1行追加するだけでOK。フォーマット既存。

### 想定パターン3種

| パターン | 予想動作 | 仮説への意味 |
|---|---|---|
| **A. 232M前後で安定** | 低ペースでも上限は変わらない・リセット時の上振れだけ一時的 | burn rate依存は弱い・並列ドクトリン維持 |
| **B. 240〜260M超えて伸びる** | 低ペース継続で上限が拡張される | 仮説確定方向・ドクトリン書き換え |
| **C. 232Mから下がっていく** | 何らかの累積要因が後から効いてくる | 別仮説必要・要再設計 |

### 並行で他のことをやらない理由

burn rateを実験変数として扱うので、メインセッションや他Jarvisが同時に重い作業をすると **実験条件が汚染される**。観測⑧の232.2Mも「メインセッションが補正タスクだけやっていた」という前提がついてる。実験中は **このセッション以外は静かにする**。

### メインセッション（このセッション）はもう実験に参加しない

このメインセッションは観測⑧時点で既にtokenを使い込んでる（jsonl読み・anchor機構実装等）。新規セッションの方がjsonlのフレッシュエントリが少なく観測精度が高い。だから別セッション切る。

---

*作成：2026-05-05 メインJarvis（観測⑧直後）*
*目的：観測⑨〜の実験運用を別セッションに切り分けてburn rate仮説を確度高く検証する*