dsh-trim-cot-leakage

Chain-of-Thought の漏えいを取り除く

Chain-of-Thought の漏えいとは、リポジトリではなく執筆セッションの視点で書かれた文章です。そのセッションでしか見られない成果物に言及したり、状態ではなく変更の経緯を語ったり、すでに離れたレビュアーに反論したりします。事実を述べる節を含む文章は、削除するだけでは解決しません。各節を HEAD 時点で成り立つように言い換えてから、その周囲の記録を削除してください。監査コードや制御フローの説明など、事実を述べる節を含まない文章は、そのまま削除します。必読の背景情報： このスキルが適用する完全な命題のルールは dsh-prose-standard にあります。コミット済み成果物への引用に関するアーカイブ済みの注記には、引用ルールの歴史的な根拠が記録されています。これはガイダンスであり、スクリプトではありません。

ひとつのテスト

疑わしい文章ごとに、次のように問いかけてください。セッション記録、PR スレッド、未コミットの草稿にアクセスできない HEAD 時点の読者が、すべての参照を特定し、すべての主張を検証できますか？ できない場合は、残す事実をリポジトリの視点から言い換え、それ以外を削除してください。できる場合は、どれほど過去の出来事のように聞こえても漏えいではありません。ただし、解決可能であることは、このスキルの基準を満たすにすぎません。README、ドキュメント、JSDoc などの現状を示す場所では、解決可能な変更の経緯も依然として変更の叙述であり、クラス 3 の定める場所へ移す必要があります。

分類

1. 終了した設計セッションへの引用 — (decision 7)、(audit C2)、design §4.7、plan §1.4、フェーズラベル（T4、W3、P-I）、「the design ledger」、「(B ruling)」。その決定にコミット済みの管理元がある場合は、名前とパスを示して引用してください。ない場合は、引用を削除し、事実を述べる節を単独で成り立つように言い換えてください。
2. スタックおよび PR の視点 — 「a later PR in this stack」、「this PR adds」、「the previous commit」。リリース済みの仕組みまたは拡張ポイントを記述してください。先送りする作業は TODO マーカーまたは課題への参照に移してください。
3. 変更の叙述とバージョン表記 — 「used to」、「no longer」、「the old X」、および過去の状態と対比する指示的な表記（「v1」、「this cut」、「today」、「now」）。現在の動作を記述してください。修正済みの回帰は、リポジトリの履歴（「以前は Y でした」）ではなく、現在形の反実仮想（「X がなければ Y が起きます」）で表してください。
4. レビューの進行に関する記述 — 「Rejected in review:」、「the reviewer confirmed」、草稿の版番号（「v5 of this note」）、ラウンドへの帰属。残す決定と根拠は、事実として記述してください。誰がいつ述べたかは削除してください。
5. レビュアーに向けた正当化 — 「the cast is safe — it simply…」、「this is correct because…」。コードの正しさを自ら弁護するコメントは、メンテナーではなくレビュアーに向けたものです。コードが安全であることを保証する不変条件を記述するか、コードから明らかな場合はコメントを削除してください。
6. 言い換えや導出の記録 — 制御フローの説明（「first we X, then we Y」）、テストの手順説明、自明な分岐の証明。削除してください。自明でない契約または不変条件だけを残してください。
7. 留保表現と計画の残り — 「probably fine for now」、「should be enough」、マーカーのない先送り。TODO／FIXME に昇格させるか、実際の制限を記述してください。留保表現は削除してください。
8. 執筆言語の混入 — 本文のほかの部分が英語なのに、翻訳されていない作業言語の断片（端、设计稿、---- 私有 ---- の区切り線）が含まれている場合、またはその逆が zh 対応版で起きている場合。翻訳するか、削除してください。

漏えいではないもの

人手を介さない引用チェックでは、長期間有効な参照が削除され、無効になった参照が残るという、両方向の問題が起きます。以下の保持ルールをそのまま適用してください。それぞれの例はこちらで確認できます。

• Issue への参照 — #1470、TODO(name):、「issue #N owns the follow-up」は HEAD で解決するため、README を含むあらゆる箇所に残してください。Agent Notes に移動しないでください。
• Agent Notes と事後分析にあるマージ済み PR および Issue の引用 — ドキュメント標準の変更経緯の記載方法に沿った、認められている根拠です。
• 抑制の理由 — oxlint-disable … -- reason、カバレッジ除外の理由、空の catch に関する説明は必須の文言です。理由に誤りがあれば修正し、削除してはいけません。
• 反実仮想の回帰テスト用ピン — 「X がなければ Y が起きる」、「単純な X なら……」。
• 測定済みの上限値 — 定数の根拠となる「（測定値：512 ネストで約 0.15 秒）」。根拠を示す「測定値」という語は不可欠です。
• 実行時の新旧状態 — 「新しい接続が受け付けを始める前に、古い接続の処理が完了する」は実行時のライフサイクルであり、変更履歴ではありません。
• ノートの変更経緯セクションにある過去の段階名 — 「最初の版では X を出荷した」は、その箇所であれば現在の状態と矛盾しません。「この版」のように、特定の時点を示す表現はどこでも禁止です。
• 設計上、リポジトリ外で解決する外部参照 — 標準のセクション（RFC 9110 §10.1.5）、Figma のフレーム名など。§ の禁止対象は、未コミットの内部ドラフトであり、外部標準や、§ 番号を管理するコミット済みドキュメントではありません。
• プロジェクトの語り口と文書ジャンルに沿った形式 — プロジェクトの語り口としての「私たち」、ノートの「検討した代替案」セクション。

ワークフロー

1. dsh-prose-standard に従って対象範囲と除外対象を定め、対象範囲を明示します。vendor/ と .agents/notes/archived/ には触れないでください。記録済みのフィクスチャーとスナップショットは派生物であり、文言の修正対象ではありません。新しい根拠が必要となる、承認済みの動作変更がある場合に限り、元となるソースまたはシナリオを変更して再生成してください。
2. まず読み取り専用で監査します。検索バッテリーを実行し（.agents/ も検索するため --hidden を指定します）、各検索結果を信頼する前に、既知の陽性例と紛らわしい陰性例を使って各プローブを調整し、その後、ヒットを一件ずつ意味に基づいて判断してください。検索バッテリーはあくまでプローブであり、定義そのものではありません。元の一括削除の各レビューラウンドで、バッテリーが見落とした事例が見つかったため、パターンを念頭に置かずに、対象範囲内で文言の多い箇所（モジュールの JSDoc、README、Agent Notes）も読み込んでください。
3. 各箇所の所有元を優先して修正します。生成されたカタログは、まずすべての利用箇所をたどり、元となる JSDoc またはジェネレーターテンプレートを修正してから、派生物をすべて再生成します。型同等性を保つフェンスは、元となる JSDoc を修正してから、二言語のページを両方とも再貼り付けします（verify-type-equiv がそれらの内容を固定します）。二言語の文言は、相手側を必要最小限で更新し、軽量な手順に沿って記録し直します。二言語のフェンスは、dsh-doc に従って、修正済みの逐語ブロックを両側にバイト単位で同一にコピーし、その後ペアを記録し直します。モデルまたはユーザーに表示される文字列は、dsh-prose-standard に従って扱い、所有元の動作を示す根拠がある場合のみ変更します。根拠がない場合は変更せず、保留として報告します。
4. 削除する前に、その箇所で述べられている命題を列挙し（prose-standard）、過剰修正の落とし穴を確認します。義務を推奨に変えてしまう、仮定を出荷済み機能に格上げする、正しい事実を削除する、または根拠の出所を落としてしまう修正は避けてください。
5. 検証します。バッテリーを再実行し、認められている保持対象、このスキル自体のディレクトリ、および所有元のノート内で引用されている根拠のみが残っていることを確認します。残った引用がすべて HEAD で解決することを確かめ、変更した箇所のゲートを実行します（ドキュメントには doc-sync、型同等性には verify-type-equiv、翻訳ペアの確認には verify-translation-pairing）。