mrZhangTianye/training-plan-skill

Playwise Training Plan

長期的な健康を前提として、総合トレーニングによって全面的な身体能力を構築し、生活の課題やさまざまなスポーツに参加する能力を向上させます。「六角形の戦士」は長期的な方向性であり、複数の能力の同時向上を可能にし、また段階的に一部の能力を重点的に発展させ、他の能力を維持することをも認めます。機能的トレーニングは一般的な身体能力の構築と補強を担います。適正体重と体組成は長期観察の結果であり、トレーニングはこれを支援します。

このシステムが対象とする人

対象とする人：トレーニングを長期的な健康と生活能力と捉える人。複数の種目（筋力＋ラン＋スイム＋球技）を同時に楽しみ、どの種目も競技会に向けて準備していない人。目標は、何でも少しずつ楽しみ、怪我をせず、日常生活の身体的要求に対応できること。能力の幅を追求し、単一の競技成績は追わない。

対象としない人——説明しても行わない場合、明確に範囲外であることを指摘します：

タイプ	特徴
競技会に向けて準備している人	マラソン、トライアスロン、ボート、大会——テーパリング、競技特化のピーキング、周期変動が必要
専門特化したトレーニングを行う人	競技会準備、テーパリング、競技特化のピーキング、種目に応じた周期変動が必要。ランニング頻度／水泳頻度自体は判断基準にはなりません：週4-6回のランニング、週3-4回の水泳も、トレーニング歴と総量に基づけば総合トレーニングの一部となり得ます
成績向上を目指す人	目標が順位、ペース、記録達成
臨床診断・治療が必要な人	診断、画像診断の読影、リハビリテーション処方

一言判断基準：「特定の競技会のためにトレーニングを調整しますか？」と尋ね、「はい」と答えた場合は対象外です。

なぜこの線引きをするのか：本システムの骨格は「総合能力＋競技会準備なし＋長期的健康」であり、上限は12週間、テーパリングは行わず、競技特化のピーキングも行わず、疲労に基づいて負荷を減らすのであって周期化変動は行いません。専門特化のニーズは、この3本の柱全てを覆すことになります——無理に適用すれば、どちらも中途半端になります。このようなニーズに直面した場合、範囲外であることを伝え、「割引版」の専門計画を提供してはいけません。

デフォルトでは、ユーザーは指示されたトレーニングを正常に完了できるものと想定します。スキルは、十分な刺激、明確な負荷量、事前設定された漸進的負荷、および回復可能な組み合わせを提供し、通常通りトレーニングを進めるユーザーが目標の能力向上への道筋を得られるようにします。「状況に応じて調整」という言葉で今回の提案を代替してはならず、確認結果の記入を効果の保証とみなしてはいけません。

計画内に選択肢を残さない：トレーニングセッション内のエクササイズ、セット数とレップ数、負荷選択方法、回復、ローテーションはすべて明確にすべきです。同等のエクササイズを保持する場合は、ローテーション順序を固定します。不明な実測負荷については、捏造せず、目標努力度と最初のセットの選択方法に基づいて実行可能な処方を開示します。納品前に、実行者がその場で二者択一を迫られるような処方の空欄を排除します。

これは独立して使用可能なトレーニングシステムです。通常のスケジュール作成には、パッケージ内の原則、決定ルール、エクササイズアセットを使用します。納品物とトレーニングセッション表には、外部の著者、教材、論文、引用番号、または元のファイルパスを表示しません。

スキルと個人コンテンツの境界——3つの領域はそれぞれ役割を担い、相互に侵入してはいけません：

• スキル（本パッケージ）：再利用可能なメソッド、エクササイズライブラリとそのdefault_dose、プログラミングと負荷量戦略、検証とレンダリングスクリプト、出力形式。特定の個人の利用可能時間、過去の重量、器具や負荷量の好みを記述してはいけません。ライブラリ内の推奨重量は一般的なデフォルト値であり、特定の人物への処方ではありません。
• 計画ファイル（plan.jsonなど）：この個人、この周期に関する事実——利用可能時間、プールの長さ、目標と開始点、段階的計画、今回の負荷量と参照重量。
• ユーザーの履歴記録：ユーザーが実際に完了した重量と反応（TR）。形式例 TR 36kg×8（合成例、実際の記録ではありません） は、この文書のために新たに構築されたダミーデータです。実際の計画では、本人の有効な記録と実際の日付を使用しなければなりません。

納品パイプラインは本パッケージに含めない：計画をNotion／飛書／何らかのリポジトリに落とすスクリプト、リポジトリIDとページID、および「ある人が手作業で表を修正する習慣」などの操作履歴は、すべてユーザーのプライベートな部分に属し、本スキルに記述してはいけません——これらは特定の個人のアカウントとページ構造に結びついており、別の人が取得しても動作しません。本パッケージは「レンダリング原稿／エクスポートファイル」までとします。どうしても必要な場合は、ユーザー自身のツールディレクトリに置き、scripts/、references/には入れず、また「オプションツール」としてパッケージ内に残すことも避けます。汎用化する際には、この層はその場で削除し、別の場所に移動してはいけません。

スケジュール作成時に時間、器具、負荷の選択に衝突が生じた場合は、ユーザーの条件に戻って計算し、個人の制約をスキルのルールとして記述してはいけません。また、スキルの汎用デフォルト値をユーザーの実際のデータの代わりに使用してはいけません。

メインフロー：計画を優先し、フィードバックがあれば調整

計画を立てることが本スキルの主タスクであり、運動判断はユーザーが問題を報告した場合にのみ開始されます。

1. まず計画を立てる：開始点と既知の条件に基づき、一度に各週の負荷量、強度、休息、および通常の漸進的負荷を明確に記述します。
2. フィードバックがない場合：事前に設定された経路に従って進みます——毎週「異常なし、残留疲労なし、安定」の確認を求めず、デフォルトの完了を記録された実際の完了とみなしてはいけません。デフォルトの正常完了は、スケジュール作成上の仮定に過ぎません。
3. フィードバックを受け取った場合：完了困難、不快感、または条件の変化が発生した場合にのみ、まだ実行されていない部分を調整し、履歴は保持します。

負荷増加（重量増加、セット数増加、距離増加、セット間休憩短縮、頻度増加、次のフェーズへの進行）は、依然として負荷増加ゲートを通過します——ゲートは受動的に阻止します：問題が報告されなければ阻止せず、報告されれば阻止します。これは「毎週状態を報告しなければ次に進めない」という意味ではありません。

操作フロー

1. 新規作成、展開、適合、修正、または説明のいずれかを判断します。既存の目標、条件、構造を再利用します。
2. 新規作成と適合時には、以下の5つのドキュメントを必ず読んでください：情報収集、トレーニング哲学、設計原則、プログラミング、処方と漸進的負荷。怪我、疼痛、手術歴、または動作制限が関係する場合は、まず制限下でのトレーニングを読んでからスケジュールを立ててください——問題が発生してから参照するのではありません。
3. トレーニング内容に応じて機能的筋力セッションまたはランニング・スイムセッション構造を読みます。能力、領域、動作ファミリー、個別項目の4層からなるエクササイズライブラリに沿って、エクササイズとトレーニングユニットから実行可能なアセットを選択し、選択と効果に従ってエクササイズの貢献を確認します。完全な機能セッションは、特定部位のローリング、ストレッチ、コレクション、アクティベーション、その場での動作準備、移動スキル、特異的スピード／ジャンプ／メディシンボール、筋力トレーニングにおける爆発力とコア、筋力複合、およびエネルギー代謝（爆発的な動作の力－速度曲線区分とウエイトリフティング派生の負荷帯については力－速度曲線とウエイトリフティング派生を参照）を具体化します。リハビリ支援とコレクションに従って支援タスクをこれらのセクションに配置し、独立した週末セッションは低コストのストレッチとリラクゼーションに使用します。種目の分担、フェーズ、または時間の都合によりアレンジする場合は、具体的な代替と負荷判断を提供し、削除したセクションを完了したと称してはいけません。技術的なエクササイズは既に習得しているバージョンを選択します。低い技術的基盤の準備は、正常完了の仮定の下で明確かつ制御可能な処方を開示できますが、既に習得しているという観察結果を捏造してはいけません。候補となる曖昧な名称をそのまま処方として使用してはならず、エクササイズの指導や診断・治療コースを生成してもいけません。
4. 具体的な負荷量、強度、回復、実行の要点、終了条件を提示し、各週の漸進的負荷を事前に計画します。正常完了した場合は、既定の経路に従って進行します。ログ、追加テスト、または毎回の証明は、進行の条件とはしません。フィードバックを受信した場合、または条件が変化した場合は、変更ロジックを読み、必要最小限の範囲を修正し、完了した履歴は保持します。時間の変化が複数の種目に関わる場合は、その中の複数種目の取捨選択に従います：まず推奨と代替案を提示し、コストを明確にして、ユーザーが方向性を決定し、その後再スケジュールします。ユーザーに代わって種目を削ってはいけません。また、ユーザー自身が削り方を決めるのを待ってはいけません。削減の順序は時間が足りない場合の減らし方を参照：日付の入れ替え → セッション数の削減 → 負荷量の削減。時間を節約する場合、負荷量の削減のみ許され、密度や強度を上げてはいけません。
5. データ構造に従って計画を保存し、自己検証基準に従って、目標刺激、開始点、漸進的負荷、種目の取捨選択、実際の時間、階層の一貫性をチェックします。その後、scripts/validate_plan.pyを実行します。エラーはまず修正し、具体的な審査事項には適切な対応が必要であり、「通過」とだけ書いてはいけません。出力仕様に従ってレンダリングまたはエクスポートします。修正時にはscripts/compare_plans.pyを実行し、実際の差異と影響を保持します。

設計制約

• 最長12週間。サポートされる計画の長さは、12／9／8／6／4／3週のみです。それ以外（例：10、11、13週）は直接拒否します——ブロック内でロールバックは行いますが、全体の長さは変えず、単に先延ばしにしてはいけません。12週＝4つの3週間フェーズ、9週＝3フェーズ、6週＝2フェーズ、8週＝2つの完全フェーズ＋最終フェーズを2週間に圧縮（最終フェーズを圧縮し、前のフェーズを延長しない）、4週＝単一フェーズ＋冗長週または4×1維持サイクル、3週＝単一フェーズ。
• 12週は4つの3週間フェーズを採用します（フェーズ1：量の増加→フェーズ2：強度向上→フェーズ3：筋力から爆発力へ→フェーズ4：筋持久力＋定着。第4フェーズではピーキングを行いません。4日間構造を参照）。周期の単位は一律「フェーズ」と呼び、「相」や「項」とは呼びません。番号は「フェーズ1-4」と記述し、文章では「各フェーズ／全フェーズ／フェーズ間」と記述し、「相1-4／各相／以降の相」とは記述しません。古い稿で「四相」とあるものは、これに従って修正します。周期内は全てトレーニングに使用し、テストセッション、テスト週、テスト前の負荷軽減は設けません。デフォルトでは週内および週間で負荷や重点に変化があり、3週間の負荷増加＋1週間の負荷軽減という固定パターンは取りません。

フェーズの負荷量は最大限に設定し、毎週4段階のステップは組みません：各フェーズに1つの範囲（例：容量セッション3×8-10）、W1は低端、W2は範囲内の1段階、W3は維持、3週間それぞれ確定した負荷量を記述し、正常完了時は表に従って進みます。計画を優先：まず12週間（または選択された長さ）のデフォルト負荷量とフェーズ間の接続を一度に全て提供し、W2／W3の値を実行結果に委ねてはいけません。フィードバックを受け取った後にのみ、未実行の週を変更し、実行済みの週は遡及しません。負荷量は満杯に記述して構いませんが、負荷の開始点は捏造してはいけません——セット数×レップ数、ランニング分数、スイム距離は週ごとに数値化しなければなりません。参照重量／ペースが実測できない場合は「後で記入」と記述し、汎用デフォルト値を実測値の代わりに使用してはいけません。「後で記入」は以下の2項目のみに使用できます——セット数とレップ数、目標RPE、セット間休憩、最初のセットの重量選択方法、ランニングとスイムの強度記述は全て記入しなければならず、「後で記入」と一緒にしてはいけません。そうしないと、過去の重量記録がない人は半分だけの計画を受け取ることになります。範囲の使い方は計画修正を参照。4段階のステップはブロック長に結びついており、ブロック長が変われば「2週間増加、1週間減少」に退化します。事前設定された処方は、実行結果を捏造することとは異なります。

範囲はテンプレート通りに記述し、独自に単一値を作り出してはいけません：テンプレートが「3×8-10／各動作24-30回」としている場合、範囲通りに記述します。範囲の両端からそれぞれ1つずつ選んで「24回」または「30回」に折るのは、範囲を単一値として読み替える独自の作り出しです。範囲はメソッドを記述するためのものであり、実行週は依然として確定値を設定します——W1／W2／W3にそれぞれ1つの数値（2×8、3×9、3×10）を割り当て、2週間とも範囲を残したままにしてはいけません。セット数の総量は処方の指標ではありません：まずエクササイズ×セット数×レップ数を決め、1回のセッションの総セット数＝当日のエクササイズ数×セット数、これはスケジュール後の結果であり、時間の見積もり（ウォームアップとコアを含む）にのみ使用します。「毎週のセット数範囲」という列を設けて逆にセッション数を管理するのは、テンプレートの使い方を間違えています。本当に確認する必要がある場合は、計算されたセット数を表の下に検算として記載し、閾値としては扱いません。

ロールバックとやり直しはブロック内で吸収し、全体の長さを先延ばしにしてはいけません：ある週が目標に達しなかった場合は最低限維持の週に落とし（計画形態を参照）、フェーズ終了時に「やり直し」と判断された場合は、次のフェーズの位置を使用します——全体の長さは依然として12週間であり、13週間などの非標準的な長さは直接不正と判断します。

• 生活とスポーツのニーズ、目標能力、実行条件に基づいて、機能的筋力、ランニング、水泳のタスクと優先順位を割り当て、種目の構成は目標に応じて変化します。主な休息日は日曜日を優先し、平日はトレーニングを維持し、6日間で強弱を交互に配置します。水泳、ウォームアップ中のランニングやジャンプ、筋力セッション終盤の代謝トレーニングはすべて総負荷に含みます。
• 持久力の発達は有酸素総量と漸進的負荷を読み、メインランセグメント、ネットスイム量、計画中の等価量、およびセッション全体の所要時間をそれぞれ計算します。低い開始点の場合は、具体的な週間経路を使用して総量を構築し、筋力、準備運動、プールサイドでの休息を有酸素運動に充当してはいけません。高いベースラインを持つ場合は、特異的なニーズに基づいて新しい刺激を設計します。
• 適用力トレーニングでは、明確に残り反復回数（RIR）スケールを使用して重量選択をガイドします。一般的なRPE7は約3回残り、RPE8は約2回残り、RPE9は約1回残りです（筋力フェーズの主要エクササイズではこれらの値を目安として使用します）。トレーニングセッション表にはアンカー値を記述します。RPEは最大筋力のパーセンテージと等しくなく、参照重量は固定された完了要件ではありません。DUP（日次変動計画）は、安定した主力エクササイズを用いて、隣接するトレーニングセッション間でレップ数とそれに対応する負荷を変化させるために使用します。宣言された主力アンカーはdesign_context.strength_wavesに保存され、ワークグループはwave_roleでマークされます。エクササイズの変更、タイトルの変更、またはフェーズの進行自体はDUPを証明するものではありません。すべての補助、爆発的、準備タスクが変動する必要はありません。
• 発展目標のためには実際の刺激と漸進的負荷を設計します。維持目標には対応する刺激があり、一時保留または未評価の項目は明確にマークします。任意の能力ラベルを使用してカバレッジを作り出したり、デフォルトですべての能力が独立してトレーニングされる必要があると想定してはいけません。
• エクササイズライブラリは、機能的筋力、ランニング、水泳、およびマクロなサポートタスクをカバーします。カバレッジ表はreferences/training-library/coverage.jsonを参照してください。必要な各能力には、適用可能なアセットがあるか、明確なギャップが特定されている必要があります。ライブラリに特定のエクササイズが存在することを、それが今周期で発展していることの証明としてはいけません。デフォルトでは、メインセッションでは貢献度が高く、漸進的負荷が可能で、時間的、技術的、回復コストが合理的なエクササイズを優先します。局所的な単独エクササイズは、明確なタスクがある場合にのみ採用を判断し、単に行数を揃えるためにメインセッションに追加してはいけません。
• デフォルトで完了可能であることは、未知の技術を自動的に習得していることや、既存の運動制限が許可されたことを意味しません。既に習得している代替を選択し、明確に特定された制限をプログラミングに組み込みます。異常な反応が現れた場合は、該当する内容を中止し、再評価します。
• まず汎用のプランニングを提供し、その後個別化する：最初のバージョンは健康な成人のための汎用処方として作成し、怪我、器具の不足、利用可能時間を前提としません。構造が確定した後にのみ、代替と負荷の軽減を行います。例外：既に登録された制限（または明らかに疑われる場合）がある場合は、このルートは通りません——まず制限に従ってエクササイズと総量をフィルタリングし、その後頻度に基づいてセッションを配置します。登録も評価もされていない場合は、最も保守的な段階でスケジュールを組み、評価結果が出てから制限を緩和します。順序を間違えると、最初のドラフトは禁忌エクササイズを含む健康な人の処方になってしまいます。2つのことを1つのバージョンで混在して修正すると、構造問題と個人の制限が混ざり合ってしまいます。ユーザーが頻度ごとに順次レビューする場合（4日→3日→2日）、一度に1つの頻度、1つのセッションのみを展開し、そのラウンドの確認が終わってから続行します。ユーザーが直接セッション表全体を要求するか、構造の選択を明確に委託した場合は、intakeに従って一度に全体を納品し、セッションごとに問いかけてはいけません。各セッションの前に、「どの項目が3週間の漸進的負荷で、どの3項目が固定か」を明確にし、事前に設定された漸進的負荷を確認できるようにします。

構造テンプレート：頻度に応じて1つを選択し、混在や結合は行わない

• 4日間構造：週内の交互配置（2下肢日＋2純粋上肢プッシュ日）、4フェーズの漸進的負荷（フェーズ1：量の増加→フェーズ2：強度向上→フェーズ3：筋力から爆発力へ→フェーズ4：筋持久力＋定着、ピーキングなし）、日の位置づけ。
• 3日間構造：骨格の本体（Core 2行／Pair 1組／Tri-set 3枠）、重－中－軽の強度勾配、サンプル表内のエクササイズの分類プールのみを使用可能、筋力軸＋テンプレート軸の2軸漸進的負荷。3日間は第1フェーズのみで、以降のフェーズは移植によるものです。
• 2日間構造：2つの主力項目構造、デフォルトでは補助層なし（唯一の例外として完全に統合された分岐は、全グループ順序／作業長さ／回復を記述しなければなりません）、完全な2日間セッション、ギャップリストと「拡張ルール無効」の漸進的負荷修正。

複数種目のプログラミング：まず骨格を決めてマウントし、その後強度枠を計算する

• 同時トレーニング：干渉閾値、毎週の高強度セッション予算（ハード上限4回、登録制限時3回、スクリプトで確認）、種目間の排他マトリックス、ランニング0-7回の勾配と4／3／2トレーニング×ランの週間カレンダーの組み合わせ、2段階の配分比率（筋力主体／混合、「支配的種目」は生成しない）。
• 複数種目のプログラミング：非専門特化者のための骨格＋マウント、2つの帳簿（強度／日数）、3形態の回復日と計数口径、7ステップのプログラミング、球技が筋力の重点に与える影響、同日の順序、1日2回トレーニングのルール、計算例。

機能的筋力は基盤であり、特異的種目はその使用シナリオです——「発展枠」を種目ごとに順番に割り振ってはいけません：まずユーザーに各スポーツに対する考え（興味本位の参加／体力補強／特定の側面を改善したい）と、毎週割ける時間を尋ねます。不明瞭な場合は維持としてスケジュールし、原稿上に「未確認」とマークします。配分比率を推測したり、ユーザーに代わって役割を決めてはいけません。筋力セッションは周期全体にわたって継続し、自身のセット数と重量で漸進的負荷をかけます。ランやスイムの順番だからといって譲歩したり、自身が増えたからといってランやスイムをストップするよう要求したりしてはいけません。 増加を制御するには負荷ラインに依存し、種目を並べて順番に扱う方法は取りません：「今週はラン、来週はスイム」といったローテーション表は誤った読み方であり、そのように記述された場合はロールバックして再スケジュールします。

5つの独立した負荷ライン：筋力セット数（重量アンカーを含む）／ランニング分数／ネットスイム量／衝撃接触回数／回復占有可能数。同じフェーズ内で最大1つのラインを明らかに上昇させることができ、2番目のラインを上昇させるには理由を明記しなければなりません（レビューレベル、エラーとしては報告しない）。維持項目はゼロ負荷ではありません——維持の筋力セッションも回復リソースを消費します。「ある項目が維持である」ことは、「他の2つの項目を安心して増やせる」ことを意味しません。上昇はセッション表に記述された負荷量で判断し、目標の文言で判断してはいけません：各フェーズの初週と最終週の筋力セット数×レップ数、ランニング分数、ネットスイム量を量とし、目標RPEの平均値を強度とし、主力種目の休息を回復とします。量が10%超、RPEが0.2上昇、休息が95%以下に低下、のいずれかの条件が成立すれば、このラインは上昇しているとみなします。stage_load_lines() がこの比較表を出力し、同じフェーズで1つ以上のラインが上昇している場合は stage_lines:<block>（レビュー）と報告し、主従関係ともう1つのラインも上昇する理由を明記するよう要求します。目標に「発展」と書かれていても、各セッションの負荷量が変わっていなければ、このラインはフラットです。

「1つのラインのみ上昇」は、「同じラインが連続して上昇し続けてよい」ことを意味しません：同じラインが連続して2フェーズ以上上昇している場合は stage_lines_streak と報告します。隣接する上昇ポイント間には少なくとも3週間の安定期間が必要であり、1-2週間しか間隔を置かずに連続上昇している場合は ramp_interval と報告します（メッセージには2つの週次と2つの量を含みます）。合法的な記述方法はフェーズ内では3つのライン全てがフラットであり、上昇はフェーズ境界にのみ発生するというものです（例：ランニング毎週62／75／88／100分、各段階で3週間安定）。フェーズ内で全てがフラットな場合は、どのラインが次の境界でバトンを引き継ぐかを明確に述べなければなりません。そうしないと、「誰もまだ動いていない」と読み取られ、周期全体に漸進的負荷がないと判断される可能性があります。以下の2つの形態は「フェーズ内での負荷増加」とは報告しません：① フェーズ初週1-2セット→翌週3セット、レップ数とRPEが変わらない場合。これは元の表のフェーズ1独自の導入週のリズム（_is_phase_intro() が prescribed_intro と記録、比較基準として翌週を使用）であり、自主的な負荷増加ではありません。② 容量日と高負荷日でレップ数が同じ場合（フェーズ2-4の両日で主力種目がともに5回）、日の変動は目標RPEが担います。design_checks は「レップ数が異なる」または「目標RPEが明確に高い」のいずれかを認めます。これがない場合、サンプルはフェーズ変更週から「高負荷セッションと容量セッションで明確に低いレップ範囲が指定されていない」と報告し始め、blocked_weeks が最終週まで続きます。

フェーズ間の接続は別途1回、ベースラインから初週への接続も別途1回実行します：各フェーズの初週と最終週のみを比較すると、「フェーズ内の3週間全てがフラットで、上昇が全て境界に集中している」というケースを見逃します。stage_load_lines() の handoff／handoff_rising は stage_handoff:<block> と報告します。design_context.review_resolutions に上昇なのか積み重ねなのかが明記されていない場合、actualモードでは表を出力しません。W1以降の上昇ポイントのみを比較すると、ベースラインからW1へのジャンプを見逃します（全表で最大のステップは、誰も見ていない場所にあることがよくあります）。ベースラインから初週への接続はパーセンテージではなく頻度で判断します：baseline_entry_check() は、ランニング頻度が増加した場合、単一回の延長のみをチェックします（最長単一回≤ベースライン最長単一回であれば合格、頻度の増加自体は負荷増加ではありません）。ランニング頻度が変わらず週間総量の増加が10%を超えた場合にのみ報告します。3つの口径は同じ名前を共有してはいけません：メインランセグメント合計（各セッションの最長単一セグメントを合計、スタートとクールダウンは含まない）／ランニング系合計（動作タイプごとに合計——スタート、クールダウンもラン系動作として分類されていれば含まれる）／セッション全体（速歩とクールダウンを含む）。3つの文に分けて記述します。40%上限、上昇判定、接続チェックのすべてに「移行を含む週間総走行量」という1つの口径のみを使用します。比較表を報告する際は、列名を正確に記述します：動作タイプごとに合計した数値を「メインラン合計」とラベル付けすると、同じ週に専門コーチのメインランセグメント数とは十数分の差が生じ、両者がそれぞれ半分ずつ間違っているように見えます。要約（mini_goal）内の分数は、当該セッションのメインランセグメント（最長単一セグメント）をチェックします。セッション全体や、スタートとクールダウンを含むランニング系合計ではありません。口径を間違えると、数十のセッションがすべて「不整合」と報告されることになり、白紙修正のラウンドが発生します。このようなずれは、スクリプトで全表をスキャンする必要があり、手動で数セクションをチェックしても、1-2分の差しかないものは見逃してしまいます。ベースラインのランニング頻度／最長単一回／週間総量は、baseline_basis の構造化フィールド（run_sessions_per_week／run_longest_minutes／run_weekly_minutes／minutes_basis）に落とし込み、observation の散文にのみ記述してはいけません。次のステップで誰もチェックできず、口径をまたいで除算すると+55%のような偽の増加率が計算される可能性があります。

計算できるフィールドは手書きしてはいけません：単一回の要約（mini_goal）とセッション全体の所要時間は、負荷量から生成されます（session_summary.mini_goal()／duration_model.apply()）。手書きのコピーと処方が共存する場合、一方を変更すると必ずもう一方が残ります。要約に数字が書かれていれば、それは検証可能な宣言であり、負荷量と一致しない場合は mini_goal と単回負荷量が一致しません（レビューレベル、生成値を付記）と報告します。セット数を変更した後の連携リスト（set_sequence／所要時間／要約／context_hash／フェーズ表）については、データ構造を参照してください。1つでも漏れると、さらに1ラウンドの手直しが発生します。context_hash は手入力せず、古い値も残してはいけません：主力種目または増加セットを変更した後、更新されていない決議は global_gaps で stage_handoff:<block>: review_resolutions に現在の context_hash を記録する必要があります… と報告し、連鎖的に出力がブロックされます。更新方法は、design_checks.check(plan, library()) を再実行し（library() は validate_plan からインポート）、requirements 内の review_id → context_hash を1つずつ design_context.review_resolutions に書き戻し、その後全量テストを実行します。理由の文章は、上昇の事実自体が変わらない限り、変更しません。

説明フィールドはセッション表の実際の負荷量に従って記述します：progression_condition／purpose に「本フェーズは8セットから12セットに増加」と記述する前に、まず当該フェーズの items の sets／reps／target_rpe を読み、実際にそのようにスケジュールされていることを確認します。コーチの目標数字をそのまま説明に転記し、セッション表がそれを実現していない場合、それは自分自身と矛盾する計画です——レビューでは「すでに記録されたものと主張する」とみなされて差し戻され、自己レビュー時にもこの文に騙される可能性があります。実行されていない漸進的負荷は、計画外の備考にのみ記述し、計画の説明には記述してはいけません。

衝撃接触は独自に1行で計算します：セット数表とランニング量表からは判別できません。週間接触量＝contacts_per_rep × sets × reps × 側数 を日ごとに累積します。ランニング分数と並べてチェックし、加算はせず、「2つのラインは同時に上昇してはいけない」というハードルールも設けません。特定のフェーズで衝撃が増加したかどうかを判断するには、まずこの式で計算してから結論を導き、単に「組織方法を変更した」という理由で推測してはいけません——独立した増強エクササイズセグメントをペアグループに移動すると、多くの場合、横ばいか減少になります。

処方調整とパフォーマンス改善は2つの欄に分けて記録します：同じ処方下でのパフォーマンス向上はトレーニングの結果であり、処方を変更してはいけません。セット数増加、距離延長、目標強度向上、次のフェーズへの進行のみが処方調整とみなされます。1つの欄に混在させると、基礎トレーニングの効果も、特異的種目が別途追加されたかどうかもわかりません。

単一種目の処方：ランニングと水泳のそれぞれの開始点、漸進的負荷、上限

• 計画修正：計画は計画、実行は実行——本パッケージは、どのようにトレーニングし、どのように記録するかを規定しません。結果を受け取った後に計画をどのように変更するかだけを管理します：週内判定、フェーズ終了判定、ブロック内ロールバック位置、計画全体を書き換えずに局所的な変更のみ。
• ランニングプログラミング：4段階の開始点処方、I／R頻度は球技に従う、漸進的負荷（最長単一ランの週間ランニング頻度による段階分けを含む：4+回30%／3回40%／2回55%／単回ランは適用外、>64kmは25%に抑える、スクリプトで確認）、ランニングフォーム3項目、強度記述、典型的な週間カレンダー。
• スイムプログラミング：泳法と具体的なタスクに応じて開始点を確認、2段階の努力（CSSは測定しない）、事前設定された単変数の漸進的負荷と異常時調整、実際のプール長とスイム距離、器具と既存の制限。サンプルの負荷量は汎用的な成人処方ではありません。

サポート判断：まず制限と器具を確認し、その後エクササイズ名に落とし込む

• 制限下でのトレーニング：長期／段階的の2種類の制限、7つの動作ファミリー×3段階、治癒の3段階（組織と翌朝の反応に基づく段階分け、カレンダーには基づかない）、3/10の疼痛はその日の上限としてのみ機能、衝撃バイパスは3クラス（明確に禁止／許可されているが条件が整っていない／今回の発症、3つのクラスを1つに混在させてはいけない）、レッドフラグリスト、紹介条件。
• 器具構成：器具リストと項目ごとの代替（アップグレード可能／ダウングレード可能／真のギャップの3段階）、膝支配的な機能的順序付け、4段階の構成における8つの主力ポジションの埋め方、重量がない場合の6つの漸進的負荷方法。
• エクササイズ名の中英対照表：用語のベースライン、書籍に未収録のエクササイズの注釈。「現名」列はエクササイズライブラリの name の元の値であり、セッション表はこれに従って記述します。そうしないと、パフォーマンス列の名前によるマッチングがずれます。
• 対照表の各行は、ライブラリIDを持つか、明示的に not_in_library と記述するかのいずれかでなければなりません。修正後は scripts/check_exercise_names.py を実行します：各行について「IDがライブラリにあるか、表の名前がライブラリのnameと等しいか、IDがあるのに現用名を自称していないか」をチェックし、補完可能なIDを提示します。not_in_library と記述された行は「ライブラリ内に無いと宣言済み」として別途リスト化され、エラーとはカウントされません。表見出し行はスキップされます。2つの状態以外に第3の状態はありません：IDがなく、かつライブラリ内に無いと宣言もされていない行は、「現用名」とはみなされず、スクリプトはエラーとして報告します——ライブラリにない移動スキル（クロスオーバージャンプ、サイドクロールなど）を現用名として記述することは、ライブラリに存在しない名前を作り出したことになります。「エクササイズライブラリと本表で同時に実行済み」と宣言する前に、grep -rn '旧名1\|旧名2' SKILL.md references/ を実行します：表の行を修正するのは簡単ですが、本文と構造ファイル（2／3／4日間構造、functional-session、gym-equipment、limitations、multi-sport）内には同じ名前が数十か所あり、表のみを修正して統一を宣言すると、次のレビューでgrepした際に表が本文より新しいことが判明します。
• ライブラリ内の欠落を判断するには、定義に従って検索する必要があります：id／name、english_name、およびエクササイズ定義を同時にチェックし、canonicalとruntimeの両方のアセットと同義名を確認します。ゼロヒットの場合のみ not_in_library とマークし、類似のエクササイズで欠落を代替してはいけません。キーワード、範囲、結果を報告します。
• 新しい項目を追加する前に、まず中国語名を決定し、「出典あり」と「提案訳語」の2段階に分けます：公開された中国語の用法があるものは直接記述します（深蹲保持／静态深蹲、侧向熊爬）。統一された訳語が見つからないものは「記述的な提案訳語、図による確認待ち」（薬球触趾深蹲など）とマークし、業界標準を偽ってはいけません。新しい名前はライブラリ内の同じファミリーと整合させます：ライブラリ内のcrawlは熊爬のみであり、横向きのバリエーションは「侧向熊爬」とすべきで、「侧向爬行」ではありません。臨床／テスト用語と衝突する場合は、違いを明記する必要があります：「単脚交叉跳」はリハビリテーション文献ではcrossover hop testの計測動作であり、ウォームアップ中のクロスオーバージャンプとは異なります。区別しないと、1つの名前が2つの動作を指すことになります。
• スクリプトが報告する行数から、まず解析上のアーティファクトを差し引き、その後で実際の不足数を議論します：対照表の見出し行がデータ行として扱われる（「現用中文名」セルが見出し名になる）、1行に2つのIDが並んだ結合行が同じセル名で2回チェックされる——これらの2種類はすべて「名前がライブラリと一致しない」または「ライブラリIDがないのに現用名を自称」として報告されます。修正方法は、スクリプトを見出し行をスキップするように変更し、結合行を1行1IDに分割することであり、エクササイズ名を修正することではありません。まずこれらの2種類を差し引いてから報告数とします。そうしないと、報告された件数の半分はパーサー自身が作り出したものになります。表に新しい合法的な状態を追加する場合、同じラウンドでバリデーターも変更します：not_in_library を表にのみ記述し、スクリプトが依然として「IDあり／IDなし」のみを認識する場合、表全体が常に赤くなり、毎回新しい未処理事項として再チェックされます。結合行自体がクロスソースの原因です：1行に2つのIDがぶら下がっている場合、名前によるマッチング時に2つのIDが同じセル名を争い、テストとレンダリングでそれぞれ異なるIDが取得され、どちらも正しく見えます。
• 問題の統計には口径を説明し、表示名の変更にはエイリアスを使用します：エクササイズエントリ、器具行、見出し行、ライブラリ外宣言済みエントリを区別します。ライブラリの name はマッチングキーです。alias はマッチングに参加しません。名前を変更する場合は、バリデーションと参照を同期する必要があります。
• エクササイズ名は原文に戻って確認し、独自に作り出してはいけません：中国語名は、書籍内の訳語またはパッケージ内で統一された名前を取ります。独自に作り出した名前は、書籍自体の立場と衝突する可能性があります（独自に作り出した「手枪蹲」は書籍のピストルスクワット反対の立場と衝突、独自に作り出した「保加利亚」は名称変更後の後脚挙上スプリットスクワットと衝突、独自に作り出した「下砍／上举」はチョップ／リフトと衝突）。ウォームアップとコレクションセクションは特に、英単語を直訳してはいけません：Inchwormは文字通り尺取り虫、書籍では毛毛虫。Leg Cradleを直訳して「腿摇篮」とするのも正しくありません。Cook hip liftとLeg lowerも中英混在で記述してはいけません。このセクションの動作は書籍内に準備セクションの表としてのみ存在し、英文字面と動作形態はしばしば乖離しています（shuffleは拖步であって「跚步」ではない）。一律に中国語版の元の表に従って記述し、完了後にエクササイズ名の中英対照表の第11節に補足します。名前の確認は、ページごとに原文と照合する必要があり、記憶に頼った列挙は必ず誤りを含みます。書籍にない動作（フロアベンチプレス、ノルディックハムストリングカール）は保持しますが、「パッケ内補足」とマークし、書籍にあると称してはいけません。パッケージ内で既に統一されたアセット名は、マッチング用語として優先され、エクササイズ名の中英対照表を基準とします。
• 構造的な結論はreferencesに記述し、エントリーポインタを更新します：修正が完了したら、ファイルを読み戻し、差異を確認し、関連テストと全量テストを実行します。議論の結論は、最終的なファイル内容を代替しません。

バージョン番号はSKILL.mdの前置きフィールドに記述します：現在 1.0 公開ソースパッケージ。plan.json の version は整数形式のリビジョン番号であり、schema_version はフォーマットバージョンの文字列であり、パッケージバージョンと混在してはいけません。

原稿修正と最終稿の規律：

• レビュー意見は修正権限と等しくありません：専門コーチ、リハビリテーション専門家、アドバイザー、あるいはヘッドコーチが「このバッチを撤回しろ」「私の言う通りに修正しろ」と言ったとしても、それは単なる提案です。SKILL.md と references/ を変更する前に、まず変更リストをユーザーに提示し、「変更」という明確な指示を得てから、一括して確定します。一度に確定し、変更しながら報告してはいけません。
• 同じラウンドの変更範囲を統合します：ファイル、場所、理由、連鎖的な影響を列記し、承認された範囲に従ってグループ化して変更し、1ラウンドの変更はバージョンを一貫して記録します。
• 最終稿確定後はトレーサビリティを維持します：承認された範囲内でのみ変更し、バージョンと実際の差異を保持します。実際のトレーニング効果と回復能力は、実行結果によって判断されなければなりません。
• 概要文と詳細表は項目ごとに照合し、一致しない場合は概要文を削除します：「元のセット数から1セット削減」「週3回の有酸素運動」「このセッションは20分」といった1文の概要は、詳細が変更された後に新しい数字と矛盾しやすくなります（1セット削減と書きながら5→3セット、週3回の有酸素運動と言いながらセッション表には4回、インターバルセッションが実際には30-40分など）。最終稿確定前に、各概要文を対応する表に引き戻して項目ごとに確認します。一致しない場合は、詳細を保持し、概要文を削除または書き換えます。2つの文が共存すると、読者はどちらが真実か判断できません。
• あるコンテンツを撤回する場合、同時にそのコンテンツを生成したルールも変更します：数字が削除されても、それらの数字を生成したルールがそのまま残っていれば、次のレビューラウンドで同じルールに従って数字が再作成されます。撤回後、まずそのコンテンツのキーストリングをgrepして0ヒットを確認し、次にその生成ルール自体も逆方向に書き換えるべきかどうかを読みます。
• 変更後は CHANGELOG.md に1件記録します：どのバージョンで何を撤回したか、なぜ撤回したか、影響を受けるファイルはどれか。これがないと、次のラウンドは「誰が覚えているか」に依存することになり、撤回されたものが漏れとして補完されてしまう可能性があります。
• バージョン差異レポートを使用して変更範囲を報告します：ファイルリスト、内容の差異、検証結果を使用し、記憶に基づいて完了を宣言してはいけません。

代わりに計算した結果には、方法と責任の境界を明記します：ソース事実、独立計算、設計選択を区別します。同じ判断基準には一貫した閾値と明確な適用範囲を保持します。

同じ量に対して結果が異なる場合は、まず口径を揃えます：入力、単位、移行時間、丸め方法を確認し、未解決の差異をリストアップしてから、採用値を決定します。

絶対的な数値をルールに組み込む前に、まず判断基準を通過させます：「毎回最大X分追加」「Y分を超えたら別の形式に切り替え」といった数値は、まず「開始点の異なる2人の人間に対して両方とも成立するか？」と自問します——週間60分の人は15分追加で+25%ですが、週間300分の人は15分追加で+5%であり、1つの数値では2つの量級を管理できません。成立しない場合は、「このサンプルパラメータ」に格下げし、トリガーポイントはユーザーの比率段階によって決定されることを明記し、一般則として記述してはいけません。特に、本パッケージ自身の割り当てから逆算された数値をルールに昇格させてはいけません（例：「3ラン40%段階では単一セッションが50分を超える」から「120分ではランニング頻度を増やす必要がある」を導き出すのは、2層の独自作成が重なったものです）。同様に、比率の上限がすでに単一セッションの長さを管理している場合は、固定分数をさらに重ねてはいけません——重複した閾値は遅かれ早かれ互いに矛盾します。

時間コストの計算と実現可能性の結論は、同じ口径でなければなりません：「X分でスケジュール可能」と言う前に、固定ブロック（準備＋爆発力＋コア）、増加セット／ウォームアップセット、ワークセットとセット間休憩、エクササイズ変更を一度に計算します。増加セットを含まない数値を先に出し、「増加セットを追加するとさらに6分かかります」と後から付け加えると、結論はすでに自己矛盾しています。2つの案のどちらがより時間を節約できるかを比較する前に、まず作業量を揃えます：セット数や所要時間が異なる場合、差異は作業量自体に由来するものであり、案の構造に帰することはできません（7セットと9セットを比較して「モード削減の方が時間がかかる」、6セットと9セットを比較して「4クラスを保持するのは不可能」とすることはすべてこのタイプです）。正しい記述方法は「予算 ↔ スケジュール可能なセット数」の比較表を1枚作成し、2つの案が同じ予算下でカバレッジと厚みを比較できるようにすることです。セッション全体の所要時間は負荷量から計算し、定数として記述してはいけません：scripts/duration_model.py が唯一の実装です（単一エクササイズ＝セット数×単一セット作業時間＋(セット数−1)×セット間休憩。単一セット作業時間は、優先順位としてRPE≥7の反復回数×5秒、次にアセット表のセット全体の作業秒数（備考に「約9秒/回」「毎回10秒保持、計6回」などと明記されている場合は直接採用し、逐次推定で上書きしてはいけません）、次に所要時間フィールド、技術反復回数×4秒。per_side は2倍）。apply() は items→modules→session の3層に書き戻します。検証で「処方量が割り当て時間を超えている」場合は、同じ関数を呼び出さなければなりません。距離の計算は動作速度に応じて行い、共通の定数を使用してはいけません：移動／横方向歩行とキックウォーキングは0.8 m/s、加重歩行は1.0 m/s、加速走行は約3 m/s（10m stridesは約3秒）。一律に1.3 m/sを使用すると、20mの移動が15秒、stridesが8秒と計算され、両方とも間違います。2つのセット作業推定が共存する場合、一方が「各セッション90分超」、もう一方が「すべて90分以内」と計算するなら、最初に間違っているのはデータではなく結論です。24のセッションすべてが1つの手書き定数を共有することは、実際の変動を隠蔽することになります。2つの実装でセッションごとに0.5-1.5分の差しかない場合、「エクササイズ変更の移行」や「項目ごとの四捨五入」にまず帰してはいけません——これらの2つはこの程度の差を生み出しません。相手のスクリプトを開き、単一セットの作業秒数を項目ごとにdiffし、差異はほぼ常にその層（セット全体のストップウォッチ測定 vs 逐次推定）にあります。具体的なエクササイズを特定してからどちらが正しいかを判断し、2つの可能な説明から1つを選んで結論としてはいけません。時間超過の場合、症状のある部位の準備セットを削減して埋め合わせてはいけません：増加セット／ウォームアップセットは、「十分な準備なしに直接ワークセットに移行する」という安全性の問題を解決するものであり、削減可能な容量には属しません。増加セットの追加と時間の削減は別に計算し、追加後も超過する場合は正直に超過を報告します。負荷量を審査する際は、エクササイズごとに増加セット（RPE4のセット）を数えます——特定の主力エクササイズがラウンド全体で0セットということは、安全ベルトがないことを意味します。