コンテンツへスキップ
TypeApe
ダウンロードウェイトリストに参加

Lattice リファレンス · 4 分の 4

検証と診断 ​

Lattice はまずファイルを読み込み、次にアウトラインまたは公開の準備状況で構造を検証します。執筆の確認は、その型付き構造を、ロケールを考慮した正確な本文統計と組み合わせます。プレビューや納品の前に公開の準備状況を使い、その後で影響を受ける経路を自分で読んでください。

パースと検証は別のゲート ​

パース ​

パースは次を検査します。

  • 読み込まれたすべての .la ファイルの Lattice 構文。
  • 引用符付きの相対 use パス。
  • インポートがプロジェクト内に留まること。
  • 重複するインポートとインポートの循環。

パース結果は、構文とインポートのエラーがないときに有効です。メタデータの型、参照、グラフ構造、ランタイム経路が有効であることは約束しません。

検証 ​

次に検証は次を検査します。

  • 必須のメタデータと値の型。
  • 実体、Scene、Block、注釈、Predicate、State、Group、Pool、Module の参照。
  • 選ばれたストーリー種別で許可される宣言とフローの終端。
  • リンクがメインストーリーまたは現在の Module の中に留まるか。
  • ナラティブの伏線、要件、回収、beat、明かしのプロパティ。
  • Linear または分岐グラフのプロパティ。
  • 有限状態のランタイム到達性、ソフトロック、循環、Module の有用性。
  • すべての可能な経路を完全に検査できるか。

検証結果が有効なのは、選ばれた検証経路が error 診断なしで完全に終了したときだけです。警告と情報メッセージはストーリーを無効にしません。

outline の準備状況は同じ構造検査を適用しますが、欠落した読者向け本文のエラーだけを一時的に抑制します。これにより、執筆前に安定した Scene と Block の ID、要約、purpose、フロー、予算、連続性の関係を確立できます。publish が既定で、完全な検証規則を保ちます。

執筆の進捗を確認する ​

執筆の確認は、ソースから導かれた本文ゴール、正確な Story、Scene、Block の数、観測された準備状況、残っている最大の局所的な不足を報告します。Scene と Block の目標は計画上の予算です。Story の最小値または最大値が厳格な完了ゲートになるのは、承認されたタスクがそのゴールを明示的に選んだときだけです。

必須の編集ループ ​

  1. まとまった単位を一つ編集します。
    診断を原因に結び付けられるよう、変更を小さく保ちます。
  2. 設定された entry をパースします。
    メタデータやグラフのメッセージを解釈する前に、構文とインポートのエラーを直します。
  3. アウトラインを検証して確認します。
    本文が未完成のうちに、構造、正確な進捗、局所的な不足を確認します。
  4. 公開に向けて検証します。
    可視コンテンツの要件を元に戻し、すべてのエラーを直し、すべての警告を意図的に判断します。
  5. 影響を受ける経路を体験します。
    構造の有効性は、声、テンポ、意味のある選択を証明できません。

常に、設定された entry とその完全なインポート展開を検証してください。孤立した一つのファイルをパースすると、重複した ID、解決されないファイル間の対象、全体的な経路の失敗を見逃すことがあります。

診断を読む ​

有用な診断は次を提供します。

  • 安定した診断コード。
  • 重大度（error、warning、情報）。
  • 正確なファイルとソース範囲。
  • 破られた規則を説明するメッセージ。
  • 別の宣言やエッジが関与する場合の、関連するソース位置。
  • 安全な修正が分かっている場合のヘルプテキスト。

最も早い構文 / インポートのエラーから始めてください。区切り記号の欠落はパーサーをずらし、後続の診断を誤解を招くものにすることがあります。構文の層が健全になったら、最後のメッセージの箇所だけを編集するのではなく、参照をその宣言と関連位置までたどってください。

重大度と執筆上の対応 ​

重大度意味必要な対応
エラーストーリーが有効な読書体験を生み出せない完了前に修正する
警告構造は機能するが、意図しない可能性がある文脈の中で確認する
情報有効性に影響しない役立つ文脈指針として使う

警告を自動的な書き換えに変えないでください。決して適合しない Module は、意図しない死んだコンテンツかもしれず、あるいは別の経路を待つ意図的な草稿かもしれません。変更する前に創作上の意図を確認してください。

よくある構文の失敗 ​

セミコロンの欠落 ​

text
# Wrong
use "./story/opening.la"

# Correct
use "./story/opening.la";

scene と module の本体、および外側の choice の本体は、セミコロンなしで閉じることを忘れないでください。その内部のコンテンツと option は依然としてセミコロンを使います。

誤ったコメント記号 ​

text
# Correct comment
# Mara enters from the west.

# Wrong
// Mara enters from the west.

ID の代わりに引用符付き参照 ​

text
# Wrong: string
entry: "opening"

# Correct: Block ID
entry: opening

文字列が必要な箇所でテキスト形式を使用 ​

text
# Wrong
language: en

# Correct
language: "en"

重複または未知のメタデータ ​

text
# Wrong: duplicate title and unsupported key
scene garden (
  title: "Garden",
  title: "The garden",
  color: "blue"
) { ... }

各キーは一度だけ保ってください。対応していないフィールドを削除するか、意図的な拡張メタデータを x_ キーに改名します。ただし、それが組み込みの意味に影響しないことを理解しておいてください。

よくある参照と所有の失敗 ​

誤った実体 kind ​

対話の話者または Scene の pov は登場人物を参照しなければなりません。Scene の location は場所を参照しなければなりません。CYOA のイベントタプルは、その Predicate スキーマに正確に一致しなければなりません。

欠落または改名された ID ​

タイトルを変えても参照には影響しません。ID を変える場合は、それを名指すすべての entry、フローの対象、所有者フィールド、Guard、Effect、注釈参照を更新する必要があります。

所有者をまたぐフロー ​

メインストーリーの Block は Module へ next や choice できません。Module はメインストーリーや別の Module を対象にできません。メインストーリーが Module のワークフローに入るのは enter <pool> -> <resume> を通じてのみで、Module が戻るのは complete を通じてのみです。

ストーリー種別の不一致 ​

Linear story は選択、有限 State、Pool、Module、enter、complete、initial_state を許可しません。CYOA に切り替えるのは、エラーを黙らせるためではなく、ストーリー自体が分岐や記憶された State を必要とするときだけです。

Linear 構造の復旧 ​

Linear のエラーでは、story.entry から一つの連鎖を描き、次を確認します。

  1. entry に入力エッジがない。
  2. 他のすべての Block が一つの入力 next を持つ。
  3. すべての Block が到達可能である。
  4. どの Block も自分自身に到達できない。
  5. end; で終わる Block がちょうど一つである。

宣言の順序と Scene のグループ化は、これらのグラフ規則には関係ありません。接続されていない Block は、連鎖にリンクするか削除しなければなりません。別の Block の隣に置いても、つながることはありません。

分岐 CYOA の復旧 ​

Pool / Module のない CYOA では、次のようにします。

  1. story.entry から始める。
  2. 好みの経路だけでなく、すべての option をたどる。
  3. すべての対象が存在し、メインストーリーに留まることを確認する。
  4. すべての Block が到達可能であることを確認する。
  5. 循環を拒否する。
  6. すべての極大経路が end; に到達することを確認する。

合流は許可されます。共有された Block は、複数の入力 choice エッジを持てます。

Pool とその Module を確認する ​

完全な検証を実行する前に、各 Pool を手作業で列挙します。

  1. Pool 進入時に有効な State。
  2. 条件を満たす未完了の Module すべて。
  3. 可能な各 complete が生む State すべて。
  4. 各完了の後に終了 Guard が一致するか。
  5. 終了がまだ偽のときに、別の未完了の Module が適合したままか。
  6. 再開の経路が結末に到達できるか。

この確認は、経路がどこで行き詰まるかを明らかにできますが、Validate の代わりにはなりません。TypeApe は依然として、到達可能なすべての Module の順序と State の組み合わせを検査します。

ソフトロックのパターン ​

次の Pool は、st_knows_signal を有効化できる Module がない場合に失敗します。

text
pool investigation (
  title: "Investigate",
  exit_requires: [st_knows_signal]
);

終了が偽で、条件を満たす未完了の Module がない場合、どの読者の行動も State を変えられません。到達可能な Module / Effect を追加するか、Guard を直すか、終了条件を改訂してください。拡張メタデータで問題を隠さないでください。

ランタイム循環のパターン ​

すべての所有者ローカルの Block グラフが非循環であっても、State と Pool の遷移が繰り返されるランタイム構成を作ることがあります。完全な検証は、到達可能なランタイム循環を拒否します。読者が終了を保証されずに続けられるからです。

検証が決定しないこと ​

検証は構造を検査し、執筆体験のすべての部分を検査するわけではありません。

  • 分岐の連続性は常に経路普遍とは限りません。 分岐だけのグラフでは、伏線の警告が証明するのは、以前の伏線がその Block に到達しうることだけで、すべての入力経路がそれを含むことではありません。
  • 浮動 beat 順序の診断は限定的です。 Pool / Module のランタイム検証は、現在すべての静的な beat_order 警告を出すわけではありません。
  • 同一 Block 内のイベント順序は、浮動ストーリーでは保守的です。 経路に敏感な順序が重要な場合は、関連する伏線と明かしのイベントを別々の Block に置いてください。
  • ナラティブのマーカー ID は冪等な集合の事実です。 同じマーカーを繰り返しても、数えられる出来事にはなりません。
  • Predicate は型付きのタプルラベルであり、規則エンジンではありません。 推移性、オントロジーの推論、ワイルドカード一致は含意されません。
  • requires には二つの領域があります。 Block の requires はナラティブのマーカーを名指し、Module の requires と Pool の exit_requires はランタイム State ID を名指しします。
  • 有効性は文学的な品質ではありません。 検証は、本文が一貫しているか、選択が意味を持つか、結末が満足できるかを証明しません。

マニュアルと TypeApe が一致しない場合 ​

TypeApe に表示される診断を使ってください。文書化されていない構文や x_ メタデータで回避しないでください。助けを求めるときは、診断コードと、問題を再現する最小のソース例を添えてください。

Lattice 言語の概要に戻るか、Agent ワークフローに進んでください。