sillytavern-card-components

SillyTavern カードコンポーネント

共通のコミュニケーション

TW の平易な言葉遣いとガイダンスのルールを適用します。用語は初めて使うときに説明し、ユーザーが選択した新人／入门／熟练／老手のレベルに合わせてください。また、どのレベルでも、必要な変更やバグについて説明してください。Soul モードや文章モードでも、この基本ルールは無効になりません。

プラグインの実行環境

このスキルがプラグイン、クラウドホスト、またはリモートマシンを通じて実行される場合は、開始時にプラグイン実行契約を読み、ホスト固有のコマンドを実行する前に、ホスト、ツール、永続化に関する確認事項を適用してください。このスキルの対象範囲、認可、受け入れ基準を維持してください。

分解やレジストリへの書き込みを行う前に、sillytavern-card-components ルートを指定して $consult-tavernweave-library を使い、A0 と、返されたカード形式／正規表現のガイダンスを読み、ラウンドトリップ計画に受領記録を残してください。

再利用可能なコンポーネントのソースと、パック済みのカード成果物は分けてください。共有ライブラリを安定した状態に保てるよう、探索的な作業は破棄可能な形にしてください。証拠が十分に裏付ける場合にのみ、変更を昇格させてください。

境界を明確にする

1. カードファイルを調査または変更する前に、リポジトリの指示を読みます。
2. 次のいずれかにタスクを分類します。
   • 入力カードを新しいサンドボックスに分解する。
   • バージョン固有のコンポーネントスナップショットを編集する。
   • 既存のレシピを組み合わせる。
   • 成熟した作業を共有ライブラリに明示的に昇格させる。
3. 現在の信頼できる情報源を特定します。リポジトリに明示的な指示がない限り、バージョン固有の components/ ツリー、パック済み JSON、パック済み PNG は成果物として扱ってください。
4. 以前のリリースを保持してください。コンポーネント作業の副作用として、アーカイブ済みの成果物を移行、書き換え、正規化してはいけません。
5. 既存のレジストリ、レシピ、ビルド規約を再利用する、最小限の変更を優先してください。

カードを安全に分解する

JSON または PNG の入力を抽出する前に、safe-disassembly.mdを読んでください。

• 入力ディレクトリ、作業中のバージョンツリー、共有コンポーネントライブラリには抽出しないでください。
• 入力を新しいサンドボックスにコピーし、そのハッシュとサイズを記録して、そのスナップショットを読み取り専用の証拠として扱ってください。
• 抽出ツールには、明示的な入力先と出力先を指定できることを必須としてください。暗黙のマニフェストパス経由で書き込む場合は、サンドボックス内にあるその設定の破棄可能なコピーに対してのみ実行するか、別の方法を選んでください。
• 論理コンポーネントに分割する前に、PNG ペイロードを正規化されたカード JSON にデコードしてください。
• 抽出したファイルごとに、安定した論理識別子、カード JSON ポインターまたはセレクター、ソースハッシュ、出力ハッシュを使って、出所を記録してください。
• 明示的な契約によって変換が許可されている場合を除き、不明なフィールド、エントリ識別子、配列順序、拡張メタデータを保持してください。

抽出に成功しても、それを共有ライブラリの更新許可と解釈してはいけません。

コンポーネントライブラリをモデル化する

レジストリ、モジュール宣言、出力宣言、レシピ、依存関係、変数ルート、または置換関係を作成・変更する際は、component-model.md をお読みください。

レジストリを機械可読な信頼できる唯一の情報源として使用してください。人間向けのカタログはレジストリから生成し、CSV やスプレッドシートのエクスポートをビルド入力にしないでください。

すべてのモジュールで、少なくとも次の項目を宣言してください。

• 安定した ID とカテゴリ
• ソースファイルと生成される出力
• 明示的な依存関係と競合
• ランタイム依存関係の宣言と配布クラス
• コンテンツがモデルから参照可能かどうか
• ビルドまたはマージの動作
• 影響を受けるランタイム層または変数層
• ライブラリが対応している場合は、適用可能性と成熟度のメタデータ

依存関係の不足、循環依存、競合、未宣言の出力の衝突、ソースの欠落、または意図されたルート外に出るパスがある場合は、構成を失敗させてください。component_assembly と release では、解決されていない必須の埋め込みランタイムアセットや、無効な地域別代替の選択がある場合も失敗させてください。ワールドブック、MVU、正規表現、ヘルパースクリプト、埋め込み UI の API は分離してください。依存関係を宣言しても、別のランタイム層がグローバルに利用可能になるわけではありません。

レシピは選択として定義する

コンポーネントの本体はモジュールに保持してください。レシピではモジュールを選択して出力境界を宣言し、ビルドロジックやコンテンツをコピーしないでください。

リポジトリで定義されているステージを使用してください。リポジトリに同等のステージがある場合は、次のセマンティクスを維持してください。

• variable_core：完全な変数チェーンのみを出力する
• component_assembly：カード固有のアダプターとプレゼンテーションコンポーネントを追加する
• release：宣言された出力一式とリリースチェックを必須とする

レシピの出力先は、デフォルトでサンドボックスにしてください。書き込み範囲がすでに承認されている明示的な再ビルドまたは昇格操作の場合にのみ、バージョンスナップショットを指定してください。レジストリで延期対象の所有者と必須ステージが指定されている場合に限り、variable_core レシピで後続の埋め込みアダプターを延期できるようにしてください。この延期を component_assembly や release に持ち越さないでください。

関連するフィールドを同期する

変数フィールドはファイルをまたぐ単一の契約として扱ってください。該当するすべての利用側を次の順序で追跡し、更新してください。

initial data -> schema -> update rules -> output format -> context -> variable groups -> runtime readers -> rendered examples

意図的に存在しない層は記録してください。書き込み側や画面の変更がひとつ成功しただけで、フィールドの移行が完了したと判断しないでください。

ソースと成果物の整合性を検証する

1. レジストリとレシピの構造を検証します。
2. 依存関係グラフと出力の所有権を解決します。
3. ランタイム依存関係のクラス、所有する埋め込み出力、地域別代替グループを解決します。
4. クリーンなサンドボックスに構成します。
5. 構文、エンコーディング、必須および禁止コンテンツ、ランタイム層の契約を検証します。
6. サンドボックス JSON と、対象範囲に含まれる場合はサンドボックス PNG をビルドします。
7. ビルドした成果物を、2つ目のクリーンなサンドボックスに再抽出します。
8. 正規化されたカードのセマンティクスとコンポーネントマッピングを比較します。バイト単位の一致が契約で求められる場合に限り、バイト単位で比較してください。JSON の書式や PNG コンテナのバイト列は異なる場合があります。
9. 変更の影響を受ける、これまで正常に動作していたすべての利用側について、回帰チェックを実行します。
10. ホストに依存する UI、正規表現、ブリッジ、リモートローダーの実行、インタラクションのチェックは、SillyTavern での実環境受け入れテストに合格するまで保留にします。

成熟したコンポーネントのみを昇格する

共有ライブラリを更新する場合は、明示的な依頼と、事前に宣言された成熟度ゲートを必須とします。独立してテスト可能な機能を一度に1つだけ昇格し、合成、往復、回帰、および該当するランタイムのチェックに合格した後に限り昇格します。

共有モジュールを置き換える場合は、関係の両方向を登録し、旧バージョンのアーティファクトを保持して、レジストリから派生カタログを再生成します。実験用または検証専用のモジュールは、本番用レシピの対象外であることを明示します。繰り返しデバッグしても機能が不安定なままの場合は、ライブラリに互換性パッチを重ねるのではなく、作業を止めてコア設計を再評価します。

結果を報告する

以下を明記します。

• 入力スナップショットのハッシュとサンドボックスの場所。
• 作成または変更したファイル。
• レジストリ、レシピ、依存関係に関する判断。
• 検出されたカードの機能と、埋め込みアセット、ホスト要件、リモートローダー、地域選択を含むランタイム依存関係台帳。
• 往復チェックと回帰チェック、およびその結果。
• 共有ライブラリへの昇格を実施したかどうか。
• 実際のSillyTavernで引き続き必要なチェック。