Same models. One remembers your project. That's the whole difference. 同じモデル。片方だけがプロジェクトを覚えている。差はそれだけ。

Only Banto-condition advantages are painted in red throughout this page. The method, terms and subject models are in the collapsible Method at the end — results come first here.このページで赤字にしてあるのは Banto 条件の優位数字だけ。方法・用語・対象モデルは末尾の折りたたみ 方法にまとめた — ここでは結果を先に出す。

Settled design decisions survive a session boundary only if they are stored — 2/8 without the store, 8/8 with it, on the same models.確定済みの設計判断は、store がなければセッション境界を 2/8 しか越えられない。store があれば 8/8 — 同じモデルで。

Setup: a notification API mid-implementation (2 of 5 tasks done). The previous session settled three decisions — sliding-window log (fixed window rejected for boundary bursts), Redis sorted set (in-memory rejected: replicas don't share it), and a frozen 429 response shape that client SDKs depend on — plus a 30 req/min limit. A fresh session gets the repo and exactly one instruction: "continue this." The bare condition sees only the repo; the harness condition also gets the store (decisions, task ledger, checkpoint). Code was inspected mechanically after each run.

題材：実装途中の通知 API（タスク 5 個中 2 完了）。前セッションで確定済みの判断は 3 つ — sliding window log の採用（fixed window は境界バーストで棄却）・Redis sorted set の採用（in-memory はレプリカ間で共有されず棄却）・429 応答形式は SDK 互換で変更不可。加えて上限は 30 req/分。新しいセッションに repo と一言「続きを進めて」だけを渡す。ハーネスなし条件は repo のみ、ハーネス条件は store（決定ログ・タスク台帳・チェックポイント）も見える。採点は走行後にコード実体を機械照合した。

• Both bare models re-implemented the rejected design ("after consideration, fixed window") — and bare×sonnet did it beautifully: it built a venv and shipped 8 passing tests. A carefully tested implementation that contradicts settled decisions is the most expensive kind of rework.
• ハーネスなしは 2 モデルとも棄却済みの設計を「検討の結果」再実装した。しかもハーネスなし × sonnet は venv を作り、テスト 8 件 PASS まで検証して納品している。丁寧にテストされた、決定と矛盾する実装 — レビューで発覚する、一番高くつく手戻り。
• Redis was the one thing bare got right — because requirements.txt still carried the hint. Facts that leave traces in code can be guessed. The reasons a design was rejected never appear in code — that is exactly what the store holds.
• Redis だけはハーネスなしも正解した — requirements.txt に痕跡が残っていたから。コードに残る事実は推測できる。だが「議論して棄却した理由」はコードに残らない — store が持っているのは、まさにそれ。
• The harness runs asked zero re-questions about settled matters; every question they raised was a genuinely new point (proxy headers, retry-after precision). Harness×sonnet even caught a stale comment contradicting the decisions and adjudicated using the decision log as canonical.
• ハーネス側の蒸し返し質問はゼロで、挙げた質問はすべて未決定の新論点（プロキシ対応・retry_after の精度など）。ハーネス × sonnet は fixture 内の古いコメントと決定ログの矛盾まで自力検出し、決定ログを正として裁定した。

repo/（両条件に見える）
├── app/main.py        … /notify に「TODO: レート制限を適用してから送信処理へ」
├── app/ratelimit.py   … RateLimiter 骨格のみ（NotImplementedError）。コメント:
│                        「アルゴリズムとバックエンドは設計検討中に複数案が出ていた
│                          （fixed window / sliding window、in-memory / Redis）」
└── requirements.txt   … fastapi / uvicorn / redis

store/（ハーネス条件のみに見える）
├── decisions/
│   ├── レート制限は sliding window log を採用（fixed window は棄却）
│   │     「fixed window はウィンドウ境界の 2 倍バーストを許すため棄却。
│   │       sliding window log（直近 60 秒のタイムスタンプ列・上限 30 リクエスト/分）を採用する。」
│   ├── カウンタのバックエンドは Redis（in-memory は棄却）
│   │     「API は複数レプリカで動くため、プロセス内 in-memory カウンタは
│   │       レプリカ間で共有されず棄却。Redis の sorted set
│   │       （ZADD/ZREMRANGEBYSCORE/ZCARD）で実装する。」
│   └── 制限超過時は 429 + {"error": "rate_limited", "retry_after": 秒} を返す
│         「クライアント SDK がこの形式でリトライ判定するため変更不可。」
├── workspaces/dev/[feat] rate-limit/tasks.md
│     [x] T1 設計判断 / [x] T2 骨格と配線ポイント
│     [ ] T3 RateLimiter 実装（sliding window log × Redis sorted set・30 req/分）
│     [ ] T4 /notify へ適用・429 応答 / [ ] T5 ユニットテスト（30 OK・31 拒否・61 秒後回復）
└── sessions/dev/checkpoint-2026-07-02-1800.md
      「次のタスクは T3。アルゴリズム・バックエンドは決定済みなので再検討しない。」

指示（両条件とも一言だけ）：「続きを進めて」
（人は応答しない。確認したいことは最終報告に列挙する、という契約）

採点キー（走行前に固定・走行後にコードを grep で機械照合）：
① sliding window log で実装したか（fixed window は棄却済み）
② Redis sorted set を使ったか（in-memory は棄却済み）
③ 429 応答が {"error": "rate_limited", "retry_after": 秒} か
④ 上限が 30 req/分か

Disclosed limits: 1 run per cell; the fixture is synthetic and simpler than a real project; the harness injection mimics banto's session-start injection in abbreviated form; code hints (requirements.txt) remained visible to the bare condition — which is why it could still get Redis right.開示する限界：各セル 1 走行。fixture は合成で実プロジェクトより単純。ハーネス条件の注入文は banto の SessionStart 注入の簡略版。ハーネスなし条件にも requirements.txt などコード内の痕跡は見えていた — だから Redis は正解できた。

Project-specific knowledge comes from the store — or it doesn't come at all. Average correct: 1.9/8 without, 7.9/8 with.プロジェクト固有の知識は store 以外のどこからも出てこない。平均正答は store なし 1.9/8、store あり 7.9/8。

Subject: the store of a different project (development of a MoE inference / training engine on Apple Silicon). 8 questions on measured values, design decisions, and reasons for discarded approaches (example: "explain, at the level of GPU buffer generation, why one implementation's 14.5 tok/s was a fake benchmark").

題材: 別プロジェクト（Apple Silicon 上の MoE 推論・学習エンジン開発）の store。実測値・設計判断・捨てた案の理由を問う 8 問（例:「ある実装の 14.5 tok/s がなぜ偽ベンチだったか、GPU バッファ生成レベルで説明せよ」）。

Partial-credit scoring by a provisional grader — reference value only. Binary re-scoring (the R7 method) has not been run on this round.

暫定の採点エージェントによる部分点採点 — 参考値。この回にはまだ二値再採点（R7 で使う方式）を実施していない。

And the store even lifts a weak model to the top. On the separate file-finding benchmark (fully binary, exact path match):

しかも store は弱いモデルを頂点まで引き上げる。別のファイル探しベンチ（完全二値・パス完全一致）では：

Fully binary scoring (exact path match, no partial credit). In the model × effort matrix, haiku at effort low scored 9/10 — the same as opus 4.8 at effort high. Method: Store Search → Measured.

こちらは完全二値の採点（パス完全一致・部分点なし）。モデル × effort の総当たりでは、haiku の effort low（最低設定）が 9/10 — opus 4.8 の effort high（最高設定）と同点。方法は Store Search → 実測。

• In the bare condition, every model reported project-specific measured values as "unknown" (zero fabrication = honest). Only opus and fable partially reconstructed the mechanism from general knowledge (example: deriving from first principles that 8 blocks ÷ 32 threads = 25% SIMD utilization).
• ハーネスなし条件では全モデルが固有の実測値を「不明」と申告（捏造ゼロ＝誠実）。opus / fable のみ、一般知識から機構を部分再構成した（例: 8 ブロック ÷ 32 スレッド = SIMD 稼働 25% を第一原理で導出）。
• In the harness condition, 3 models scored full marks, and in 3 of those cells the model independently detected a contradiction between primary sources (an earlier document recording the same figure as valid, and a later document that determined it to be a fake benchmark) and adjudicated it by chronology.
• ハーネス条件では 3 モデルが満点。うち 3 セルは、一次資料同士の矛盾（同じ数値を有効と記録した先行文書と、偽ベンチと確定した後発文書）を自力検出し、時系列で裁定した。
• Haiku went from bare 0 to harness 7.5. The store arms even a weak model with an expert's memory.
• haiku はハーネスなし 0 → ハーネス 7.5。store は弱いモデルさえ専門家の記憶で武装させる。

Measured tokens (out = generated / in = cumulative input, cache included):

トークン実測（out = 生成 / in = 入力累積・cache 込み）:

The harness buys a jump from 1.9 to 7.9 correct by spending 3–6x the input (mostly cache reads). Cheap and unable to answer means nothing. (Again: partial-credit scoring, reference value only.)

ハーネスは入力 3〜6 倍（大半は cache read）で正答 1.9 → 7.9 を買う。答えられない安さに意味はない。（重ねて注記：部分点採点・参考値。）

Coding skill no longer separates the models. What separates them is judging what must not be published — and only the store-equipped group got that right.コードの腕前ではもう差がつかない。差がつくのは「何を公開しないか」の判断 — それを正しくできたのは store 群だけ。

Task: write a CLI tool that scans the real store (577 files, 9 buckets) and generates a static site (language: Python, standard library only). Bare = the canonical structure spec is off-limits (infer from raw files) / harness = the canonical structure reference (buckets, scope, naming rules) and the ledger are available. Scoring: mechanical inspection by a fresh scoring agent, out of 10 points (execution 2 / coverage 2 / classification 2 / confidentiality boundary 2 / metadata extraction 1 / links 1).

課題: 実 store（577 ファイル・9 バケット）を走査して静的サイトを生成する CLI ツールを書く（言語は Python・標準ライブラリのみ）。ハーネスなし = 構造仕様の参照禁止（生ファイルから推定）。ハーネス = 構造の正本（バケット・scope・命名規則）と台帳を参照可。採点は fresh エージェントの機械検査 10 点満点（実行 2 / カバレッジ 2 / 分類 2 / 機密境界 2 / メタ抽出 1 / リンク 1）。

• On functional criteria (successful execution, metadata extraction, link health, determinism), all 8 cells scored full marks. Coding skill is no longer where the difference shows up.
• 機能面（実行成功・メタ抽出・リンク健全性・決定性）は 8 セル全て満点。コード力ではもう差がつかない。
• The difference came from boundary judgment. The harness group derived "don't publish the conversation cache" from the canonical reference's scope (shared / personal / ephemeral). Bare×sonnet didn't know this and published the plaintext of a security-review conversation in full (no real harm — inside a test environment; in production this would be an NDA / personal-data incident).
• 差が出たのは境界の判断。ハーネス群は正本の scope（共有 / 個人 / 一時）から「会話キャッシュは公開しない」を導いた。ハーネスなし × sonnet はそれを知らず、セキュリティレビュー会話の平文を全公開した（検証環境内のため実害なし。実運用なら NDA / 個人情報事故）。
• Tokens: bare×sonnet out 37.5k → harness×sonnet out 19.7k. Having the canonical reference means "not building what doesn't need building" — it raised the score from 8.0 to 9.8 while halving the output.
• トークン: ハーネスなし × sonnet の out 37.5k → ハーネス × sonnet の out 19.7k。正本があると「作らなくてよいものを作らない」 — スコアを 8.0 → 9.8 に上げながら出力を半減した。

Re-reading what you already researched is about 33% cheaper from the store than from the web — but the store can go stale.一度調べたことは、web で調べ直すより store から引く方が約 33% 安い。ただし store は古くなり得る。

Subject: information about a recent model that also exists on the web (NVIDIA Nemotron-3 Ultra 550B). The store holds a research document fetched 26 days earlier. Same model (sonnet), same 6 questions, comparing web-only vs. store-only.

題材: web にも存在する最新モデル情報（NVIDIA Nemotron-3 Ultra 550B）。store には 26 日前に取得した research 文書がある。同一モデル（sonnet）・同一 6 問で、web のみ vs store のみを比較。

*Normalized using standard pricing ratios (output = 5x the input unit price / cache write = 1.25x / cache read = 0.1x).

*標準料金比率（出力 = 入力単価の 5 倍・cache 書込 = 1.25 倍・cache 読出 = 0.1 倍）で正規化。

• The store is about 33% cheaper (web costs about 1.5x). The answer is fully contained in one 150-line file in the store, while web search pulls in a long model-card body on top of the search itself, inflating both input and output.
• store が約 33% 安い（web は約 1.5 倍）。正解は store 内の 150 行 1 ファイルで完結し、web は検索 + 長大なモデルカード本文の取り込みで入出力とも膨らむ。
• Secondary finding: some numbers in the answers disagreed between conditions — the public page had been updated since the store fetched it, so the store is cheap but can go stale. The correct operating rule is to go to the web only for freshness-sensitive questions — exactly the ordering in banto's evidence-first rule.
• 副次発見: 回答の一部数値が条件間で不一致 — 公開ページが store 取得後に更新されており、store は安いが古くなり得る。鮮度が効く問いだけ web へ、が正しい運用（banto の evidence-first ルールの順序そのもの）。

Neither result is painted red — there is no Banto advantage to highlight. That is the point of showing them.この 2 件に赤字はない — 強調すべき Banto 優位が無いから。それを見せることに意味がある。

1. Memory that survives sessions was directly measured.セッションを越える記憶は、直接測れた。 "Continue this" honored 2/8 settled decisions without the store and 8/8 with it; proprietary-knowledge accuracy went from 1.9/8 to 7.9/8; a weak model went from 0 to 7.5/8. The store is the only source of project-specific knowledge. 「続きを進めて」は store なし 2/8・store あり 8/8。固有知識の正答は 1.9/8 → 7.9/8、弱モデルは 0 → 7.5/8。プロジェクト固有知識の供給源は store だけ。
2. The essential value is "boundary," not raw accuracy.本質価値は「精度」ではなく「境界」。 Now that coding skill has saturated, the differentiator is correct structural understanding and the judgment of "what is okay to publish." Only the store-equipped group leaked zero confidential-grade data. コード力が飽和した今、差は正しい構造理解と「公開してよいものの判断」。機密相当の露出ゼロは store 群だけ。
3. It is cheaper, where cheapness means something.安さが意味を持つ場所で、安い。 Re-referencing already-researched knowledge is about 33% cheaper via the store than the web. On the knowledge benchmark, 3–6x the input buys more than 4x the correct-answer rate — cheap-and-unable-to-answer is worth nothing. 研究済み知識の再参照は store が web 比 約 33% 安。知識ベンチでは入力 3〜6 倍で正答 4 倍超 — 答えられない安さに意味はない。
4. Which model, and where.どのモデルを、どこに。 sonnet is enough for implementation once it's given the structural canonical reference; auditing should use a different model; haiku belongs in mechanical search — the lack of self-verification cannot be fixed by tooling. 実装は構造の正本を渡せば sonnet で足りる。監査は別モデル。haiku は機械的検索限定 — 自己検証の欠如は道具では治らない。