スキルシステム設計

概要

本ドキュメントは、レシピがいつ作れるようになるかを決める仕組みをまとめたものです。何を作れるかの定義（recipes の文法）は GameElementDefinition.md 13 節、レシピが成立する仕組みは RecipeSystem.md の担当です。実際に用意するスキルの一覧は Skills.md にあります。

ExplorationSystem.md と同じく、専用の新しい文法は導入せず、既存の props/stages/conditions/passives/interactions の応用として組みます（唯一の例外は 4 節）。

本ドキュメントは検討結果であり、確定仕様書ではありません（【確定】 の付いた節を除く）。 Skills.md 2 節のスキルはプレイヤーキャラクタの props（2 節）として投入済みで、解放条件（4 節）も書かれています。 3 節の経路は実行も発見も動きます（発見の契機は 3.3 節の形で locations.yaml に入っています）。初歩の行動をまだ持たないスキルがあります（どれかは tests/world-codex/skillsYaml.test.ts の「伸ばす操作をまだ持たない腕は…」が持ちます）——開ける物が世界にまだ 1 つも無いためで、解放条件にも書いていません（3.2 節）。 料理は初歩の行動だけを持ちます——下ごしらえ（Skills.md 2.5 節）が入ったので腕は伸びますが、開けるレシピはまだ無く、効くのはその下ごしらえ自身の速さだけです。未決事項は 8 節に整理しています。

1. 「研究」という別概念を持たない

スキルは、領域ごとの習熟度を表す数値プロパティです。レシピの解放条件は、対応するスキルが一定の段に達していることとして表します。「研究課題を明示的に選び、それが完了するまで待つ」という枠は設けません。

スキルは工程ではなく領域なので、素材チェーンと直交します。解放のゲートを素材チェーンに沿って置くと、中間素材が 1 段増えるたびに解放待ちが直列に挟まり、進行が間延びします。

2. スキルはキャラクターのプロパティ

スキルはプレイヤーキャラクターの props として持たせます。conditions の subject: agent （GameElementDefinition.md 14.1 節）から直接参照でき、world シングルトンを参照する迂回（同節、subject: world は未対応）が要りません。

traits:
  player_character:
    props:
      skill_cordage:
        tags: [skill]
        value: 0
        stages:   # 段ごとの寄与（腕が縮めるもの）は省いている
          - {name: novice, min: 0}
          - name: basic
            min: 20
          - name: skilled
            min: 60
          - name: expert
            min: 180

3. 進捗が伸びる経路

スキル値は、次の経路から同じプロパティへ加算されます。仕組みは共通で、量の決め方だけが違います。

経路	契機	量
発見	探索で物に出会う（`ExplorationSystem.md`）	一律（3.3 節）
実行	その腕の技術を手で行う・その腕を名乗るレシピの工程を進める（3.4 節）	その手の長さから（下）

発見と手作業の実行は、契機となる操作の効果として agent のスキルへ add します（レシピの工程が書ける場所を持たないことと、その配り方は 3.4 節）。 tick ごとの自然増加は持たせません（何もしていない時間に伸びると、プレイヤーの行動が進捗と無関係になるため）。

量を長さから決めても、段へ届くまでに払う時間は腕ごとに開きます。 端数の切り上げぶん時間あたりは 2〜4 に散る（下の「整数で配るので」）ので、最も短い手が 15 分の腕は上端で、1 時間の手しか持たない腕は下端で進み、届くまでの時間は最大で 2 倍ひらきます。開きをそのまま作っているのは手の長さです。入口の本数ではありません（3.2.1 節）——口を足しても、最も割のよい手が変わらない限り届くまでの時間は動きません。この開きを許すかは本節と 7 節の持ち場で、どちらも確定していません。

interactions:
  make_cord:
    trigger: menu
    duration: 30
    add:
      agent:
        skill_cordage: 1

実行経路が 1 回に配る量は、その操作の長さで決まります。 30 分につき 1 で、端数は切り上げます（30 分までなら 1、1 時間なら 2）。1 回が 1 時間を超えないので（ActionSystem.md 6.3 節）、置かれるのはこの 2 つだけです——長い仕事は手を割って重ねるので、割っても時間あたりは変わりません。レシピの工程も同じ規則で、同じ上限の中に居ます（3.4 節）——工程 1 つが 1 時間を超えないのは手作業と同じ根拠です。

長さに依らない一律の量にはしません。 操作の duration は数分から数時間まで開いているので、同じ量が届くと短い操作を繰り返すのが最も速い伸ばし方になり、7 節が唯一の抑止として挙げている時間のコストが、そこだけ効かなくなります。腕を伸ばす手が初歩の行動そのものである以上（3.1 節）、この差はそのまま「どの行動を繰り返すのが得か」になり、初歩の行動ほど短くなりがちなので向きも噛み合いません。

整数で配るので、時間あたりには幅が残ります。 素の分数で見ると、端数が切り上がるぶん 2〜4 の間に散ります（ちょうど 30 分ごとの操作が 2、15 分の操作が 4）。上限を 4 に保つため、15 分より短い操作には配りません——くべる手のような、数分で済む受け渡しがここで外れます。長さの足りている操作へ配らない理由は別です——どの作業がその腕の技術かは Skills.md 2 節が決めるので、汲む手のように長さは足りていても配らないものがあります（src/assets/world-codex/characters/player_character.yaml の腕前の前書き）。レシピの工程には、配らない選択肢がありません（3.4 節）——名乗ったレシピの工程は必ず配るので、刻み 1 つより短い工程を置くとそこが幅から出て、下の検査が落とします。

腕が上がって縮んだ後も、同じ幅に収めます。 腕で縮む分は行動の側が宣言し（Skills.md 7 節）、縮めるのは分の絶対値なので、短い作業ほど比では大きく縮みます。それでも幅から出ないのは、所要時間が 15 分の格子に乗っていて、縮む量もその 1 目盛りだからです（ActionSystem.md 6.2 節）——30 分の作業が 15 分になっても時間あたりは 4 で、上端にちょうど届きます。1 目盛りより深く縮める宣言を置くと、そこが幅から出ます（45 分を 2 目盛り縮めて 15 分にすると 8）。

縮まないのは、腕で縮む宣言を持たない操作です（獲物を突く手・火を起こす手）。アクセス系の腕が決めるのは重みだけで、速さではありません（Skills.md 5 節）。

tests/world-codex/skillsYaml.test.ts が、配る量と素の分数の対応と、時間あたりが素でも縮みきった後でもこの幅に収まることを見張ります。幅は手作業とレシピの工程を同じ 1 本で見ます——規則が同じである以上、別々に見ると片方だけが幅から出ても緑のままになります。レシピが配る量のほうは、実際に工程を回して確かめます（3.4 節）——書き下した数字が無いので、宣言を読むだけでは確かめようがありません。 腕を配る add が操作の外に無いことも同じ検査が見ます——外に出ると長さが無く、上の規則の掛からない伸ばし方になるためです。

発見は、道具を一切必要としない唯一の経路です。 採取・製作に道具が要るスキル（狩猟には武器が、採鉱には掘削具が要る）は、実行経路だけでは自分より深い依存の先からしか立ち上がれません——狩猟の入口が、石を打ち欠いた先の打ちかかる手になっているのはそのためです（Skills.md 2 節）。「動物を観察する」は素手でできるので、狩猟はその依存の手前から立ち上がります（3.2 節）。 採鉱・製錬は立ち上がりません——「鉱石を見つける」も素手でできますが、鉱石の出る土地は島の生成に現れない沖の小島だけで、下の「どの島にも 1 つは残る」を満たせないためです。

3.1 練習は、その腕の初歩の行動そのもの【確定】

腕を伸ばすための専用のアクションも、専用の仕組みも持ちません。 時間を投じて腕を伸ばしたいときプレイヤーが行うのは、その腕の最も初歩的な行動です——狩猟なら安全な小型の獣を狩ること、その獣が見つからないなら探すこと自体が練習になります。料理なら、凝った料理ではなく茹でる・焼くための下ごしらえがそれで、そこがそのまま上位の料理への練習を兼ねます。

上位の行動のための練習を、別に用意しません。 初歩の行動がそのまま上位への練習です。
対象が要る腕には、対象を探す手か、対象の代わりになる物を置きます。 打ちかかる腕なら、木と葉で作る的がそれです——生きた獣を待たずに手を動かせます。
腕だけが伸びる操作は置きません。 初歩の行動は、物を出すか、手を出す相手を要します。

出どころ: ユーザーの指示

3.2 最初の一歩（ブートストラップ）

スキルを追加するとき、次を満たさなければなりません。

そのスキルの条件を一切満たさない状態で実行できる「伸ばす行動」が最低1つ存在し、かつその行動が依存する他スキルの関係に循環がないこと。

ここで要求している行動が、3.1 節の言う練習そのものです。 専用のアクションを持たないので、これを満たさないスキルは伸ばす手を 1 つも持ちません——立ち上がりの条件であると同時に、その腕へ時間を投じられるかどうかの条件でもあります。配るのは実行経路の量（3 節）で、経路は 1 つも増えません。

3.1 節の「腕だけが伸びる操作は置かない」は tests/world-codex/skillsYaml.test.ts が見張ります ——腕を配る操作は、物を出すか、相手へ重ねて始まる（trigger が drag）という形で。何を消費するかまでは見ていないので、道具の傷み以外に何も減らない操作（海鳥を捕る手）もそこを通ります。

この検査が見るのは手作業だけで、レシピの工程は入りません（3.4 節）。物を出すことを求める単位がレシピのほうだからです——工程は 1 時間で割った 1 段にすぎず、何も要求せず何も出さない工程が在ります （src/assets/world-codex/tools.yaml の槍の工程）。プレイヤーが選べるのはレシピを進めることで、工程だけを繰り返す道はないので、3.1 節の言う「腕だけが伸びる操作」にはなりません。

探索で獣に気づく手も、打ちかかる腕の的も在ります——前者は 3.3 節の発見の契機、後者は hunting_practice.yaml（拾った枝とヤシの葉で据える相手で、武器を重ねれば実行経路のぶんが伸びます）。的は獣を1つも通らない材料で作れるので、打ちかかる手は生きた獣を待ちません。

各スキルが単独で立ち上がれる必要はありません。木材加工の最初の一歩が「石の刃物で削る」ことに依存するのは、石器が独立して立ち上がる以上、循環しないので問題ありません。

「A と B を組み合わせる」だけの技術は、スキルにしてはいけません。 固有の素材も固有の入手経路も持たないため、伸ばす行動が必ずその技術自身を要求し、循環します。この種の技術は 4 節の条件を連言で並べて表します（Skills.md 3 節の柄付けが実例）。

この検査は、レシピの到達可能性の閉包（8 節）と同じ走査で機械的に行えます。スキルが増えると目視では成立しません。

3.2.1 入口が 1 本でよいのは、その腕が担う手がその 1 つだけのとき

3.2 節の「最低 1 つ」は立ち上がりの条件であって、足りているかどうかの条件ではありません。 3.1 節で練習が初歩の行動そのものになったので、入口の本数は、その腕へ時間を投じるあいだに選べる手の数そのもの になりました——1 本しか無い腕では、段へ届くまでその 1 手を繰り返すことになります。

入口が 1 本でよいのは、その腕が世界で担っている手がその 1 つだけのときです。 担う手が他にも在るのに 1 本しか配っていないなら、足りないのは口のほうで、配り漏れです。どちらであるかは腕の側からは読めません ——世界にどの手が在るかで決まるので、腕ごとの判断は Skills.md が腕ごとに持ちます。

本数は、段へ届くまでに払う時間を決めません。 口が何本あってもプレイヤーは最も割のよい手を選べるので、届くまでの時間を決めるのは 1 回の手が配る量と、その手の長さだけです（3 節）。本数が変えるのは、その時間のあいだに選べる手の数だけで、分数ではありません。

1 本と決めたら、その理由をその入口のコメントへ書きます。 tests/world-codex/skillsYaml.test.ts が、入口が 1 本の腕を並べて数え上げと突き合わせ、理由の書かれていない入口で落とします——数え上げは足せば黙って通せるので、理由を書かせる側が別に要ります。

3.3 発見の契機は、型を名指しで書く

発見の加算は、土地の explore の pick の候補へ、その候補が spawn する型と並べて書きます。 候補は一時的な命令（GameElementDefinition.md 9 節）をそのまま持てるので（同 10.1 節）、add を足すだけで済み、概要で置いた「新しい文法を導入しない」から外れません。候補はすでに出す型を名指ししているので、型と腕前の対応はそこに書き切れます。

  wasteland:
    interactions:
      explore:
        pick:
          - weight: {prop: stone_find}
            spawn: {object: stone, into: self}
            add: {agent: {skill_knapping: 1}}

配る量は +1 です。 発見だけは長さから決めません——契機は候補を引き当てたことそのもので、 explore にかけた時間ではないためです。配れる正の整数でこれより小さいものは無いので、実行が置きうる量のうち最も小さいところに並びます——30 分までの手と同じ +1 で、1 時間の手（+2）より小さい。同じ +2 で並べると、15 分の探索が 1 時間の仕事と同じ入口になります。

tests/world-codex/skillsYaml.test.ts は経路を分けて見張ります——pick をくぐって届いた add を発見、操作の直下のものを実行として数え、発見は一律 +1、実行は 3 節の規則（長さから決まる量）で確かめます。経路をまたいで揃えはしません。

配る相手は、その型を使う仕事がその腕を配っている腕です。 石は打ち欠く手が石器を配るので石器、ヤシの実は皮を叩き解す手が配るので繊維・編み——型そのものが何でできているかではなく、その型から始まる連鎖の先で誰が腕を受け取っているかで決まります。だから、その腕が使いそうに見えても配らない型があります（太い枝を素材にする仕事は、今どれも木材加工を配りません）。どの型がどの腕へ配るかは src/assets/world-codex/locations.yaml の pick に書いてあり、ここには写しません。 探索そのもの（explore 直下の add）は何も配りません——土地を調べる 1 手ではなく、何に出くわしたかが腕を分けるためです。契機を持たない腕もあります（火口が枯れ草しかなく、下の「どの島にも残る」を満たせない火など）。

「初めて見たか」は見ず、当たるたびに配ります。 既に見た型を覚える箱は世界に無く、置けば型ごとに 1 つずつ要ります。そのぶん探索を繰り返せば伸び続けますが、繰り返しの稼ぎを抑えるのは時間のコストだけという線（7 節）の中に収まります——探索が出すのはその腕が使う素材そのものなので、回した時間は素材集めの時間でもあり、探索だけを空回しする形になりません。

狩猟だけは環になります。 獣のつまみは狩猟の腕を土台にする（Skills.md 5 節）ので、腕が上がるほど出くわしやすくなり、出くわすほど腕が上がります。発散はしません——上乗せは段ごとの固定値で頭打ちになり、押し上げるのも獣の候補の重みだけなので、回るのは実りの割合が獣へ寄る幅の中だけです。ほかの腕の契機は、腕が出やすさを動かさないので環になりません。

札（タグ、GameElementDefinition.md 4.1 節）では書けません。 効果から「今 spawn した物」を指す起点が無いからです（同 11.5 節の役に無く、picked は among で選んだ相手だけを指します）。札で書くには spawn をきっかけにする trigger か、生まれた物を指す起点のどちらかを足すことになり、これも概要の前提から外れます。

代わりに、同じ腕前へ配る型を、土地の型をまたいで置きます。 札が消えにくかったのは札そのものではなく、束が土地の型をまたいでいたからで、束は型を並べても同じように作れます。

単独の型に頼ると、その型を出す土地が生成されなかった島では契機ごと消えます。密林からしか出ないマニラ麻（abaca）なら 52% の島から消えます。土地の型をまたぐ束——獣（animal を名乗る型）——なら 0.00% です。束が 1 つの型しか持たない札は、型ごとに書いたのと同じだけ消えます（artifact は golden_chalice だけなので 2%）——札にしたこと自体は何も守りません。

どの型がどれだけ消えるかは stats/discovery_coverage.yaml にあり、npm run stats:discovery で作り直します（読み方は DiscoveryCoverageStats.md）。契機を足すときは、その腕前へ配る型の locations を合わせて、どの島にも 1 つは残ることをそこで確かめます。

残っているかは目で確かめません。 tests/world-codex/skillsYaml.test.ts が多数の島を生成し、 契機を配っている腕ごとに、その契機を出す土地が 1 つも無い島が出たら落ちます——どの土地がどの島に出るかは生成が決めるので、定義を読んでも分からないためです。統計は差分を読むための数字、テストは線を割ったときに止めるもので、役が違います。

数えるのは「どの型が契機を担うか」ではなく「どこで配られるか」です。 候補は複数の型を出すので、出す型の側から数えると、腕と関わりの無い型（石と一緒に出る小枝）が混ざり、契機が消えない理由をその型が肩代わりします。契機が在るかどうかは土地の側で決まるので、その腕を配る候補を持つ土地の型をそのまま数えます。島に出ない土地（海区・沖の小島）もそこに並びますが、生成に現れないので島との突き合わせで落ちます——渡って行く先は、流れ着いた時点での契機になりません。

腕の契機の在り処が 1 つも立たなくなったときも落ちます。 立たない腕は一覧から消えるので、そのままだと「見ていない」と「緑」が見分けられません。

3.4 レシピの工程も実行経路で、配る腕は `deftness` の名乗りが決める

レシピの工程を 1 つ終えるたび、そのレシピが deftness で名乗った腕が伸びます （GameElementDefinition.md 13.5 節）。量は 3 節の規則そのままで、その工程が宣言した仕事の量から決まります（30 分につき 1、端数は切り上げ）。名乗っていないレシピは配りません。

名乗らない側には 2 通りあります（Skills.md 7.1 節）。どの腕の仕事でもないものはそれで正しいのですが、その腕の仕事なのに、工程が刻み 1 つ（15 分）で縮める先が無いために名乗れないもの（src/assets/world-codex/fire.yaml の torch.wrapped）は、仕事なのに 1 も配らない側へ落ちます。直すのは名乗りではなく工程の側で、刻み 2 つにします（同 7.1 節）——名乗りを速さと伸びで分けない以上、直し方も 1 つに揃えます。

書ける場所が無いので、宣言ではなく engine が引きます。 工程を進める操作はレシピから自動生成されるもので（RecipeSystem.md 4 節）、著者が書けるのは requires と duration だけです（GameElementDefinition.md 13.1 節）。add を置ける場所を足しません ——置くと、速さを名乗る場所と伸びを配る場所が別々になり、同じレシピが 2 つの腕を指せるようになります。

名乗りを速さと伸びで兼ねるので、どの仕事が腕の仕事かを決める軸が 2 本に割れません （Skills.md 7 節。手作業では、配る腕と縮める腕を揃えることで同じ線を保っています）。

工程で技術が分かれても、名乗った 1 本へ積みます。 工程が何をしている工程かは宣言に現れないので、配り分ける手がかりが engine には在りません。その割り切りを引き受けているのが「長いほうを名乗る」規則 です（Skills.md 7.1 節）——名乗りはもともと、工程ごとの技術ではなくそのレシピ全体の代表として選ばれています。

工程ごとに配り、完成時にまとめません。 量を長さから決める規則が掛かるのは 1 手ぶんの長さで、それが幅（3 節）に収まるのは 1 工程が 1 時間を超えないからです（ActionSystem.md 6.3 節）。合計に掛けるとその枠から出ます。途中でやめても、進めた工程のぶんは残ります。

解放を要求するレシピがその腕を配ることは、循環ではありません。 立ち上がりを担うのは手作業の側で（3.2 節）、そこが開いている限り、名乗るレシピは段を上げた後の口として後ろに並びます。

入口の本数（3.2.1 節）には、名乗るレシピも入ります。 その腕へ時間を投じるあいだに選べる手が増えるので、口の数え方も手作業だけを見るわけにはいきません。

tests/world-codex/skillsYaml.test.ts が、世界のレシピを実際に最後の工程まで回して、名乗った腕が工程の長さぶん伸び、名乗っていない腕が 1 も動かないことを見張ります。時間あたりの幅は、手作業と同じ 1 本の検査が見ます（3 節）。

4. 解放条件は段のしきい値

レシピの解放は、recipes のエントリに conditions （GameElementDefinition.md 14 節）を書き、agent のスキル段を判定する形で表します。「その段以上」を表す in_stage_or_above で書きます——腕前は単調に増えるので、今いる段ちょうどを見る in_stage で書くと、腕が上がった瞬間にレシピが閉じ直します（GameElementDefinition.md 14.1 節）。

object_defs:
  fishing_net:
    recipes:
      basic:
        conditions:
          - {subject: agent, prop: skill_cordage, in_stage_or_above: skilled}
        steps: ...

conditions は既存の条件木をそのまま使います。recipes のエントリがこのキーを持てるようにする追加が、本システムが必要とする唯一の文法変更です（同 13.2 節）。

解放条件に書ける subject は限られます（同 13.2 節）。そのため、季節や天候のような世界側の状態を解放条件にすることは現時点でできません——起点になる個体がまだ無いので、そこから遡って世界へ届く書き方も使えません。

条件を満たさないレシピも一覧に表示します（作れないものが見えないと、必要なレシピに辿り着けないまま詰みます）。満たしていない条件の理由をどう見せるかは Windows.md 9.3 節です。誘導のための表示条件と、実際に作れるかの可否条件は別に持ちます。

4.1 上位のものは、スキルを積み上げず連言で要求する

「基礎の木工の上に高度な木工を置く」といった段階的なスキルは作りません。前提の辺を書くことになり（DesignNotes.md）、下段が終わるまで上段が始まらない直列のゲートが戻ります。また、どちらも同じ行動で伸びるならバーが増えるだけで決定は増えません。

代わりに、上位のレシピほど複数スキルの連言を要求します。

そり: 木材加工 skilled + 繊維・編み basic
弓:   木材加工 skilled + 繊維・編み skilled

スキルは互いに独立した1本ずつのまま、分岐はレシピ側の条件に置きます。n 個のスキルから n(n-1)/2 通りの組み合わせが得られるので、少ない本数で多くのニッチを表現できます。

4.2 素材チェーンが既にゲートしている場所には置かない

requires の道具要求（consume: false、GameElementDefinition.md 13.1 節）と、素材そのものの入手難度は、それ自体がゲートです。青銅器は採掘と製錬という長い素材チェーンの先にあるため、さらにスキル条件を足すと二重になります。

スキルによる解放が効くのは、素材チェーンが平坦なのに強力なものです。編み籠は植物繊維だけで作れるので、素材だけでは初日から作れてしまいます。

ここで解放を置かないことは、腕が効かないことではありません。 作る速さを決める腕はレシピが別に名乗るので（GameElementDefinition.md 13.5 節）、解放を要求しないレシピも手際を名乗れます——どのレシピがどの腕の仕事かは Skills.md 7.1 節です。

5. 表示: レベルと段内進捗

スキル値は指数的に増えるため（6 節）、生の値や最大値に対する割合をそのまま出すと、序盤が常にほぼ 0% に見えます。UI へは次のように分けて出します。

レベル — 現在いる段（stages の name）。段はしきい値ごとに 1 つなので、等間隔に並んで見えます。
段内進捗 — (現在値 - 現在の段の min) ÷ (次の段の min - 現在の段の min)。段が上がるたび 0 に戻ります。

対数を取った値は出しません。対数表示は指数的な鈍化を打ち消してしまい、「低い段の作業を繰り返しても伸びが悪い」という、鈍化によって伝えたい情報そのものを隠します。段内進捗であれば、上の段ほどバーが目に見えて進まなくなり、鈍化が体感として残ります。

どちらも stages の境界からの純粋な計算なので、プロパティ自身が導出します （PropertyDef.stageReadingAt）。採否が未決の derived （GameElementDefinition.md 17 節）は必要としません。UI 側で数え直さないのは、 今いる段の上端と次の段の min が同じ 1 つの値だからです——別々に探すと、段の選び方が 2 箇所に散り、片方だけを変えたときに食い違います。見せ方は StatusArea.md 9 節です。

6. 数値の置き方

指数はしきい値（stages の min）側に置き、1 回あたりの獲得量は小さい整数に保ちます。 獲得量を指数にすると、YAML に 1 と 4096 が並んで行動間の相対的な重み付けが読めなくなります。

獲得量に残る差は、その操作の長さの差そのものです（3 節）。行動ごとに重み付けを与えるのではなく、分数を 30 で割って切り上げた値がそこに書かれるだけなので、並んだ数字は「その操作が何分かかるか」として読めます。

目安は 1 スキルあたり 4〜6 段、しきい値の比は 2.5〜3 程度です。

7. この仕組みが成立する前提

スキルは実際に行ったことから伸びるため、生存の仕方が実質 1 通りしかないと、全員が同じスキルを同じ順で伸ばします。その場合、この仕組みは分岐を生まず、進行を演出するだけのものになります。

逆に、同じ生存課題に対して複数の方針が拮抗していれば、スキルの伸び方とレシピの解放順は、追加の記述なしに分岐します。したがって、方針の拮抗はコンテンツ側の調整課題であると同時に、本システムが機能するための前提条件です。マップがランダム生成であることは、方針ごとの有利不利を島の側へ分散できるため、この調整を容易にします。

拮抗しているかを読む数字は stats/balance.yaml にあり、npm run stats:balance で作り直します（読み方は BalanceStats.md）。

なお、低い段の作業の繰り返しで上位のレシピへ到達できてしまうかどうかは、しきい値だけでは決まりません（指数的なしきい値は到達を遅くするだけで、防ぎはしません）。本作では時間が最も希少な資源であり、稼ぎに費やした時間は生存に使えないため、当面は時間コストによる抑止だけを持たせます。実際に稼ぎが成立してしまう場合は、その行動のコストがレシピ側で安すぎることを先に疑います。

この抑止が実際に効くのは、配る量が操作の長さから決まっているからです（3 節）。長さに依らない一律の量にすると、短い操作では同じ量が短い時間で届き、時間のコストがそこだけ抜けます。

8. 未決事項

粒度と個数の結論は Skills.md にあります。分類の軸は素材ではなく技術（どの行動同士が習熟を転移させるか）で、総数は「1回のプレイで実用域へ届く数の 2〜3 倍」を目安とします。数が届く数と等しいと、全員が全部を上げきってしまい 7 節の前提が崩れます。

初歩の行動をまだ持たない腕（どれかは概要）へ、それを置く形（3.1 節）。開ける物が世界に無いことと同じ問題なので、物の側と一緒に決まる
レシピ一覧で未解放のものを見せる際の、解放条件の表示粒度（どのスキルがどの段に必要か、をどこまで出すか）
到達可能性の検査をテストとして持つ形（何も持たない状態から「今作れるもの」の閉包を取り、全レシピが到達可能かを確かめる）