ストリクトモードリファレンス (Strict Mode Reference)

ワーカーサブプロセス内でライブラリを分離して実行するタイミングや方法については、まず ワーカーによるノードの分離 (Node Isolation with Workers) を参照してください。このページは、分離時の互換性の問題を検出するルールカタログ（一覧）です。

このページ全体を通じて、「aprocess」はノードに実装された process メソッドをラップするフレームワークの非同期ラッパーを指します。ルールが「aprocess の実行中」と記述している場合、それは「実装した process メソッドの内部を含む、ノードの実行中」を意味します。

ストリクトモード（Strict Mode）は、オーケストレーターとワーカーサブプロセスの間でノードコードが何を行うことが許されているかを規定するランタイム契約（コントラクト）です。ノードがこの契約に違反した場合、フレームワークは名前付きの違反を記録し、それをノードの結果ペイロードに送るため、作者は予期せぬ無言の無視、デッドロック、または無関係なレイヤーを示すスタックトレースに悩まされることなく、エディタ上で直接修正方法（Remediation）メッセージを確認できます。

ストリクトモードは常に有効化されています。設定フラグ、環境変数、ランタイムでの無効化スイッチは存在しません。重要度はルールごとに決定されます：正確性ルールは実行を失敗させ、人間工学（エルゴノミクス）ルールは警告を発行します。

違反の通知方法 (How it surfaces)

違反は送信される ResultPayload の ResultDetails に添付されます。エディタでは、ノードの出力パネルにルール ID、重要度、および修復ガイダンスが表示されます。ワーカー側では、正確性違反が発生すると、成功していたはずの ExecuteNodeResultSuccess が ExecuteNodeResultFailure に昇格されます。人間工学違反は非致命的な警告として残ります。

違反は griptape_nodes.strict_mode ロガーを通じても出力されます。コンソール上ですべての違反を確認したい場合は、ロガーのレベルを WARNING 以下に設定してください。

ルールカタログ (Rule catalog)

各ルールは、正確性（Correctness）ルール（オーケストレーターとワーカーの両方で失敗となる）または 人間工学（Ergonomics）ルール（オーケストレーターでは警告となり、ルールが個別に除外を宣言しない限りワーカー側で失敗に昇格する）のいずれかに分類されます。

正確性ルール（実行失敗） (Correctness rules (fail execution))

reentrant-bus-in-init

ノードが自身の __init__ の内部からイベントバスリクエストを発行しました。ワーカーのライブラリプローブはパラメータスキーマを抽出するために __init__ を実行しますが、その途中でバスに再突入（リエントラント）するとワーカーがデッドロックします。

修復方法: 呼び出しを aprocess（またはインスタンス生成後に実行されるライフサイクルフック）に移動してください。

人間工学ルール（警告） (Ergonomics rules (warnings))

parameter-behaviors-dropped-in-schema

Parameter にアタッチされた converters、validators、または traits がワーカーのスキーマにキャプチャされませんでした。オーケストレーター側のスタブはこれらの動作を再実行できないため、UI 側の挙動とワーカー側の実行動作が乖離してしまいます。

修復方法: コンバーターやバリデータ処理を process の内部で再実行し、ワーカーが実際の値に対して適用できるようにするか、この乖離をオーケストレーター専用の UI 装飾として許容してください。処理を process 内に移動すると、エディタ上でのインラインバリデーションフィードバック（入力時のリアルタイムエラー表示）は失われ、ユーザーはノード実行時にのみエラーを確認できる点に注意してください。

parameter-mutation-during-aprocess

ノードが aprocess の実行中に add_parameter または remove_parameter_element を直接呼び出しました。ワーカー上では、これらの変更は一時的なノードインスタンスにのみ適用され、オーケストレーター側には同期されません。

なお、before_value_set / after_value_set から行われるハイドレーション時の変更（標準的な動的パラメータパターン）は、このルールの対象外です。

修復方法: 変更が正幹であるオーケストレーター側のノードに伝播するように、AddParameterToNodeRequest または RemoveParameterFromNodeRequest を発行してください。

connection-hooks-inert-on-worker

ワーカーホストされたライブラリのノードクラスが、1 つ以上の接続ライフサイクルフック（allow_incoming_connection、before_incoming_connection、after_incoming_connection、それらの outgoing 側の対応フック、または _removed 系のフック）をオーバーライドしています。接続はオーケストレーターが管理・所有する状態であるため、これらのフックはオーケストレーター上で呼び出されます — 一方、ワーカーホストされたライブラリはオーケストレーター上ではオーバーライドを含まない合成スタブクラスで表現されているため、作者のコードは一切実行されず、静かに無視されます。

このルールは、ワーカーのスキーマプローブ中、ライブラリ読み込み時にノードクラスごとに 1 回発火します。エンジンが提供する基底クラスやコンポーネントによって実装されたフックにはフラグは立たず、ライブラリ作者が変更可能なコードのみを対象とします。

修復方法: 分離されたライブラリでは、接続状態に連動する動的パラメータはサポートされていません。ライブラリを Shared モードで実行するか、フックのオーバーライドを削除してください。

value-hooks-execute-only-on-worker

ワーカーホストされたライブラリのノードクラスが before_value_set / after_value_set をオーバーライドしています。分離されたライブラリの場合、これらのフックは実行時の入力ハイドレーション中に、一時的なワーカー側のノード上でのみ発火します。入力された値の変換は正常に動作しますが、エディタ上で値が変更された際にはフックが実行されず、フック内で行われたパラメータリストの変更は一時ノードの破棄とともに破棄されます。

このルールは、ワーカーのスキーマプローブ中、ライブラリ読み込み時にノードクラスごとに 1 回発火します。エンジンが提供する基底クラスやコンポーネントによって実装されたフックは対象外です。

修復方法: 値フックの役割を値の変換のみに留めてください。値の変更に応じてパラメータを増減させるようなエディタ時のリアクティビティが必要な場合は、ライブラリを Shared モードで実行してください。