sillytavern-card-pipeline

SillyTavern カードパイプライン

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

TW の平易な表現とガイダンスのルールを適用してください。用語は初出時に説明し、ユーザーが選択したレベル（初心者／入門／熟練／上級者）を維持しつつ、どのレベルでも必要な変更やバグについて説明してください。ソウルモードや文章モードを使っても、この基本ルールは無効になりません。

プラグインの実行環境

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

このスキルは対象リポジトリのワークフローを調整するもので、ビルドエンジンを同梱するものではありません。プロジェクト独自のツールを見つけて検証し、小規模なアダプター契約に対応付け、設定、ソース、成果物を分離してください。

書き込み、ビルド、またはパッケージ化の操作を行う前に、sillytavern-card-pipelineルートを指定して$consult-tavernweave-libraryを使用してください。A0と、返されたビルド／デプロイガイドを読み、ルートの実行記録をプリフライト証跡と一緒に保管してください。

acceptance-ledger.mdを使って、機能ごとの証跡を記録してください。ソース、自動化、オフライン成果物、ブラウザー、実際のSillyTavern、人的確認、リリースの各ゲートを分けてください。自動化によってdriver-acceptedを書き込むことはありません。

要求されたゲートを確認する

変更を伴うコマンドを実行する前に、要求を分類してください。

• ライブ反復：プロジェクトで検証済みのウォッチャーを実行し、ソース編集後に開発用出力を再ビルドします。
• 反復：ソースを変更し、影響範囲に基づくチェックを実行します。
• チェックポイントパッケージ：次の段階で必要なJSONまたはPNGを作成します。
• リリース候補：構成、パッケージ化、埋め込みを行い、オフラインの全ゲートを実行します。
• 承認済みリリース：残りのホストチェックを完了し、納品を承認します。

ユーザーがパッケージ化、再パッケージ化、PNG生成、最終成果物、全ワークフロー、納品、リリース、またはパッケージ化済み成果物が必要なチェックポイントを明示的に求めた場合にのみ、パッケージ化してください。コンポーネントを編集するたびにパッケージ化しないでください。

プロジェクトアダプターを調査する

プロジェクトツールを呼び出す前に、ツールアダプター契約を読んでください。

1. リポジトリの指示と現在のビルドドキュメントを読みます。
2. リポジトリのルート、有効な設定のエントリーポイント、実行可能なランタイム、利用可能なワークフロー機能を特定します。
3. 各機能をヘルプ出力、スキーマ、テスト、またはソースの調査で検証します。ファイル名だけから動作を推測しないでください。
4. コマンド、作業ディレクトリ、明示的な入力、明示的な出力、ドライランの対応状況、副作用、成功基準を記録します。
5. まず読み取り専用の情報取得または検証機能を実行します。

必要な機能がない場合は、レポートでその機能を明示してください。同梱エンジンや代替コマンドが存在すると主張しないでください。

ライブ開発ループを実行する

ユーザーがリアルタイムコンパイル、ウォッチモード、ホットリロード、または同等の開発ループを求めた場合に限り、ライブ反復を使用します。

1. 対象プロジェクトのパッケージスクリプト、ビルド設定、開発ドキュメントを確認します。コマンドが pnpm watch だと決めつけたり、すべてのウォッチャーで出力先の構成が同じだと考えたりしないでください。
2. ウォッチャーのコマンド、作業ディレクトリ、ソースルート、正確な出力、初回ビルドの準備完了シグナル、再ビルドの成功・失敗シグナル、停止手順をアダプターレコードに記録します。
3. 出力パスが、カード、正規表現、ローカルサーバー、または Tavern Helper バインディングで使用されるパスと一致していることを確認します。初回ビルドが成功していない状態でプロセスが実行中でも、準備完了ではありません。
4. ウォッチャーを1つ起動し、その出力を確認できる状態に保ちます。ソースを編集するたびに、sillytavern-runtime-debug にリスナーの再読み込みと SillyTavern での新しい動作の検証を依頼する前に、再ビルドの成功を待ちます。
5. リスナーの切断、コンパイラーエラー、古い出力は、反復の失敗として扱います。新しいソースが読み込まれているかのように、以前に成功した成果物に対してランタイムの動作を診断しないでください。

ウォッチ出力は、プロジェクトが dist/ に書き込む場合でも、開発候補です。チェックポイントまたはリリース用にパッケージ化する前に、検証済みの本番ビルドと成果物チェックを実行します。両方のコマンドが同じ出力先に書き込む場合は、まずウォッチャーを停止するか、分離してください。

設定の正を確定する

ワークフローデータを作成、編集、または整合させる場合は、configuration-contracts.md をお読みください。

有効なファイルをまとめて確定します。

• プロファイル：カードファミリーの識別情報、デフォルト値、プロトコル、変数ルート、レシピ、設定リンク、および宣言されたカードタイプ／機能のデフォルト値。
• マニフェスト：正確なバージョンパス、コンポーネントのマッピング、パッケージ化ポリシー、成果物、フィールドチェーン、カードに紐付いたワールドブックの識別情報、ランタイム依存関係台帳、リリース固有の動作。
• 計画：既知の状態間で予定されている変更を確認できる順序。
• コントラクト：安定した必須不変条件と禁止不変条件。

記憶に頼らず、実際に有効なプロファイルとマニフェストを再確認します。カード名やバージョン固有のツールを複製せず、差異はデータとして保持します。生成される成果物には、プロトコルやバージョンのルールを重複させず、これらの宣言を参照させます。

保守されているソースから主要なカードタイプと機能フラグを検出し、宣言されたプロファイル／マニフェストと照合します。パッケージ化された拡張機能の公開範囲と矛盾する宣言は、明示的な互換性の説明がない限り受け入れないでください。

変更の準備

1. 現在のソースと既存の成果物を、変更せずに一覧化します。
2. 正規表現、Tavern Helper スクリプト、スキーマ、ホストの機能、リモートインポート、地域別代替グループを一覧化します。ホスト必須、埋め込み必須、リモート実行時、地域別代替、任意、開発専用に分類します。
3. すでに埋め込まれているコンテンツと、ホストのセットアップ、リモート実行時の読み込み、地域別選択、開発専用ツールを分けて、事前通知に記載します。MVU Zod カードでは、パッケージに含まれるスキーマと国内向け／グローバル向けスクリプトをすでに埋め込み済みとして記載し、そのうえで Git／CDN の配信先を別途記載します。この読み込み経路を、ローカルの Zod インストール手順に置き換えてはいけません。
4. 書き込み対象の正確な範囲と、新しい成果物のパスを定義します。以前のリリースは保持し、新しいバージョンまたはステージング用ディレクトリをデフォルトにします。
5. 対象範囲内で、すでに動作しているすべての利用側について、回帰チェックリストを作成します。
6. 正確な操作、条件を付けた置換、競合時の方針、各ステップに付随する検証を含む計画を作成するか、既存の計画を確認します。
7. プロファイル、マニフェスト、計画、コントラクト、実行時の依存関係構造を検証します。
8. 計画のドライランを実行し、適用前に書き込み予測を確認します。

派生させる対象がソースコンポーネントのみの場合、過去のリリース全体をコピーしてはいけません。編集対象のコンポーネントに、古い JSON や PNG を抽出して上書きしてはいけません。

影響に応じた検証

release-gate.md の影響マトリクスを使用します。変更されたコントラクトを証明できる最小限のチェックセットを実行し、境界をまたぐ変更がある場合にのみ範囲を広げます。

連動する変数フィールドについて、初期データ、スキーマ、更新ルール、出力形式、コンテキスト、グループ、実行時の読み取り側、例のすべてにわたって、常に検証します。モデルに表示されるテキストに、開発者向けのコメントを含めないでください。ワールドブック、正規表現、ヘルパースクリプト、iframe が別のレイヤーと同じ API を共有すると仮定せず、実行時の各レイヤーを個別に検証します。component_assembly と release の段階では、embedded_required 依存関係の欠落や、地域別代替の選択が無効であることは、注意喚起ではなくブロッキング不具合です。

誤ったチェックは不具合として扱います。コントラクトでは安定した動作を保証し、一時的な実装上の好みを定めるのではなく、再発させてはならない問題を明示します。

作成とパッケージ化

1. ソースの編集と対象を絞ったチェックが完了していることを確認します。
2. 保守対象のソースに対して、カードタイプとランタイム依存関係の検出を再実行します。 ステージング出力を書き込む前に、検出内容と宣言済みの台帳を照合して整合させます。
3. アクティブなプロファイルで生成コンポーネントが選択され、レシピが現在のターゲットと一致する場合に限り、作成します。ビルドを通すために手動コンポーネントのスナップショットを上書きしてはいけません。
4. ステージング領域に作成し、必要な出力、依存関係の解決、構文、コンポーネントの同等性を検証します。
5. 必須の埋め込み正規表現、スキーマ、ヘルパースクリプト、ローダー、バインディングがすべて、宣言されたパック済みフィールドに、期待される安定した ID と有効状態で含まれていることを検証します。地域別グループでは、カードで約束されているすべてのスクリプトを必須とし、マニフェストの有効状態ポリシーを適用します。共通の国内／グローバルのペアでは、両方のスクリプトをパッケージに含め、宣言された既定のものだけを有効にします。
6. カードに紐づく、または同梱されるすべてのワールドブックを、アクティブなマニフェストから安定 ID で解決します。保守対象のソースと宣言されたバージョンがカードのリリースと一致することを検証します。表示名、タイムスタンプ、または最新に見えるファイル名でワールドブックを選択してはいけません。
7. コンポーネントのソースから JSON をマニフェストのステージング済みターゲットにパックします。パック後に修正を注入してはいけません。まず保守対象のソースを更新し、その後もう一度パックします。
8. パック済み JSON を開き直し、ランタイム依存関係の台帳、拡張機能のサーフェス、添付されたワールドブックの ID、バージョンのサーフェス、意味上の内容が、解決済みの保守対象ソースと一致することを検証します。単体のワールドブックも配布する場合は、同じ宣言済みバージョンと内容であることを必須とします。
9. パック済み JSON を埋め込む前に検証します。
10. マニフェストのポリシーに従い、コピーした PNG シェルまたは明示的に宣言された PNG シェルに JSON を埋め込みます。無関係なチャンクを保持し、出力されるすべてのカードペイロードがパック済み JSON にデコードされることを検証します。
11. 逆抽出は既定で無効のままにします。パックと埋め込みの後、サンドボックス内での往復チェックとしてのみ使用します。

既存のターゲットの再パックが明示的に必要な場合は、まず現在のアーティファクトのスナップショットを取り、ハッシュを計算してから、置き換えたことを報告します。古いリリースを黙って置き換えてはいけません。

リリースゲートを通過する

チェックポイント、候補、受け入れ基準については、release-gate.md に従います。

最低限、以下を証明します。

• 設定とバージョンの整合性
• カードタイプ／機能の根拠と、ランタイム依存関係の完全な分類
• 必須の埋め込みランタイムアセットと地域別の選択
• カードとワールドブックの安定 ID、バージョン、添付、ソースの同等性
• コントラクトと禁止されたリグレッションのチェック
• 宣言されたコンポーネントと配布物の完全なセット
• パック済み JSON の妥当性とソースとの同等性
• PNG の構造、ペイロード数、JSON との意味的な同等性
• アーティファクトのパス、サイズ、ハッシュ
• 宣言された範囲外への予期しない書き込みがないこと

プロジェクトのリリース監査は、リリース候補の場合、または明示的に要求された場合に限って実行します。オフラインでの成功では、ホストに依存する UI、正規表現、ブリッジ、インポート、新規チャット、リモートローダーの実行、インタラクションの各チェックは完了しません。実際の SillyTavern での受け入れが完了するまで、これらは保留中として記録します。

引き継ぎを報告する

以下を明記します。

• アダプターの機能と、実際に使用した正確なコマンド
• ライブ反復の場合、ウォッチャーの準備完了シグナル、出力パス、最後に成功した再ビルド、実際の SillyTavern での再読み込みを検証したかどうか
• アクティブなプロファイル、マニフェスト、プラン、コントラクト
• 検出された主要なカードタイプと機能フラグ
• すでに埋め込み済みの依存関係、引き続き必要なホストへのインストール／有効化、リモートの Git／CDN 読み込み、選択された地域別の代替、オプション機能、開発専用の除外項目
• 解決済みのカード／ワールドブックのバージョンの組み合わせと添付の検証
• 書き込んだファイルと保持したアーティファクト
• 対象を絞ったチェック、標準チェック、リリースチェックの合格／不合格の結果
• JSON と PNG のハッシュ、およびペイロードの同等性の結果
• スキップしたゲートと、残っている実ホストでの受け入れ確認