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. The same models scored 2/8 without the store and 8/8 with it.確定済みの設計判断は、store がなければセッション境界を 2/8 しか越えられない。store があれば、同じモデルで8/8を越えられる。

Setup: a notification API, mid-implementation, with 2 of 5 tasks done. The previous session had already settled three decisions. The algorithm is a sliding-window log. The team had rejected a fixed window, because it allows bursts across window boundaries. The backend is a Redis sorted set. The team had rejected an in-memory counter, because replicas don't share it. The 429 response shape is frozen, because client SDKs depend on it. The rate limit is 30 requests per minute. A fresh session gets the repo, plus exactly one instruction: "continue this." The bare condition sees only the repo. The harness condition also sees the store: the decisions, the task ledger, and the checkpoint. After each run, we inspected the code mechanically.

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

• Both bare models re-implemented the rejected design, reasoning "after consideration, fixed window." Bare×sonnet did this especially thoroughly: it built a venv and shipped 8 passing tests. A carefully tested implementation still surfaces the contradiction at review. That 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. But 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, such as proxy headers or retry-after precision. Harness×sonnet even caught a stale comment that contradicted the decisions, and it adjudicated the conflict 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, such as requirements.txt, remained visible to the bare condition too. That is why it still got Redis right.開示する限界：各セル 1 走行。fixture は合成であり、実プロジェクトより単純だ。ハーネス条件の注入文は banto の SessionStart 注入を簡略化したものだ。ハーネスなし条件にも requirements.txt などコード内の痕跡は見えていた。だから Redis は正解できた。

Project-specific knowledge comes from the store, or it doesn't come at all. The average score was 1.9 out of 8 without the store, and 7.9 out of 8 with it.プロジェクト固有の知識は、store 以外のどこからも出てこない。平均正答は、store なしが 1.9/8、store ありが7.9/8だった。

Subject: the store from a different project, one building a MoE inference and training engine for Apple Silicon. We asked 8 questions about measured values, design decisions, and the reasons behind discarded approaches. One 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 バッファ生成レベルで説明せよ」という問いだ。

This used partial-credit scoring by a provisional grader. Treat it as a reference value only. We have not yet run binary re-scoring, the R7 method, 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 the project-specific measured values as "unknown." This meant zero fabrication, which we count as honest. Only opus and fable partially reconstructed the mechanism from general knowledge, for example deriving from first principles that 8 blocks ÷ 32 threads gives 25% SIMD utilization.
• ハーネスなし条件では、全モデルが固有の実測値を「不明」と申告した。これは捏造ゼロを意味し、誠実な回答だと言える。opus と fable だけは、一般知識から機構を部分的に再構成した。例えば、8 ブロック ÷ 32 スレッド = SIMD 稼働 25% を第一原理から導出した。
• In the harness condition, 3 models scored full marks. In 3 of those cells, the model independently detected a contradiction between primary sources: an earlier document recorded the same figure as valid, while a later document determined it to be a fake benchmark. The model adjudicated the contradiction by chronology.
• ハーネス条件では、3 モデルが満点を取った。うち 3 セルでは、モデルが一次資料同士の矛盾を自力で検出した。同じ数値を有効と記録した先行文書と、それを偽ベンチと確定した後発文書が矛盾していたのだ。モデルはこの矛盾を時系列で裁定した。
• Haiku went from a bare score of 0 to a harness score of 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 answers by spending 3 to 6 times the input, mostly on cache reads. But cheap and unable to answer means nothing. Remember, this is partial-credit scoring, a 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. Only the store-equipped group got that right.コードの腕前では、もう差がつかない。差がつくのは「何を公開しないか」の判断だ。それを正しく判断できたのは store 群だけだった。

Task: write a CLI tool, in Python using only the standard library, that scans the real store (577 files across 9 buckets) and generates a static site. In the bare condition, the canonical structure spec is off-limits, so the model must infer structure from the raw files. In the harness condition, the model can also use the canonical structure reference (buckets, scope, and naming rules) plus the ledger. Scoring: a fresh scoring agent inspected the output mechanically, out of 10 points: 2 for execution, 2 for coverage, 2 for classification, 2 for the confidentiality boundary, 1 for metadata extraction, and 1 for links.

課題は、実 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, or ephemeral. Bare×sonnet didn't know this, and it published the plaintext of a security-review conversation in full. This caused no real harm, because it happened inside a test environment. In production, it would be an NDA or personal-data incident.
• 差が出たのは、境界の判断だった。ハーネス群は、正本の scope（共有・個人・一時）から「会話キャッシュは公開しない」という判断を導いた。ハーネスなし × sonnet はそれを知らず、セキュリティレビュー会話の平文を全公開した。検証環境内だったため実害はなかったが、実運用なら NDA 違反や個人情報事故になっていた。
• Tokens: bare×sonnet produced 37.5k output tokens; harness×sonnet produced 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 の出力は 37.5k、ハーネス × sonnet の出力は 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. We used the same model, sonnet, and the same 6 questions, comparing web-only against store-only.

題材は、web にも存在する最新モデルの情報、NVIDIA Nemotron-3 Ultra 550B だ。store には、26 日前に取得した research 文書がある。同一モデル（sonnet）・同一 6 問を使い、web のみと 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.5 times as much. The answer is fully contained in one 150-line file in the store. Web search, by contrast, pulls in a long model-card body on top of the search itself, and that inflates 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 it can go stale. The correct operating rule is to go to the web only for freshness-sensitive questions. That is exactly the ordering in banto's evidence-first rule.
• 副次的な発見もあった。回答の一部数値が、条件間で食い違っていた。公開ページが store 取得後に更新されていたためで、store は安いが古くなり得るということだ。鮮度が効く問いだけ web へ行く、これが正しい運用だ。banto の evidence-first ルールの順序と、まさに同じだ。

Neither result is painted red, because 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 of 8 settled decisions without the store, and 8 of 8 with it. Proprietary-knowledge accuracy went from 1.9 out of 8 to 7.9 out of 8. A weak model went from 0 to 7.5 out of 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, spending 3 to 6 times the input buys more than 4 times the correct-answer rate. But 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. Its lack of self-verification cannot be fixed by tooling. 実装は、構造の正本を渡せば sonnet で足りる。監査には別のモデルを使うべきだ。haiku は機械的検索に限定すべきだ。自己検証の欠如は、道具では治せない。