declare-when-a-setting-takes-effect
保存には成功するのに再起動まで何も変わらない設定は、失敗する設定より悪いものです。いつ効くのかを明示し、それを読み取り箇所から導いてください。
カードを読んだレビュアーが与えるものであり、ファイルが自分について主張するものではありません。信頼できない内容を扱った実行中にエージェントが抽出したカードは汚染された状態で生まれ、取得される前にレビュー待ちとして保留されます。
どんなときに思い出すか
- 設定画面を追加する
- 設定がキャッシュされている
- 変更が反映されない
- 再起動が必要
価値はたいてい「回避」と「確認」にあります。「実施」は誰でも書ける節です。
上のカード本文は翻訳です。CLI が取り込み、エージェントが実行時に読み、下のハッシュが証明するのは英語の原文です。
トリガー
ユーザーインターフェースに設定項目を公開しようとしていて、その値を消費するコードが、使用のたびにではなく、ある特定の時点——プロセス起動時、セッション構築時、キャッシュされたオブジェクトへの取り込み時——に値を読み取る場合に当てはまる。
使用のたびに読み取られる設定には当てはまらない。それらは即座に適用され、何も言うべきではない——存在しない遅延についての注記は、注記がないのと同じ不信感を植え付ける。
実施
- 各設定について、それを読み取る行を特定する。いつ適用されるかは、そのコントロールの性質ではなく、その行の性質である。
- できる限りライブ読み取りにする。アクセス時に解決するプロパティなら、たいていコストはかからず、問題を説明するのではなく取り除いてしまえる。
- 本当にそれができない場合——起動時に何かが開始されるような場合——はラベルを付け、そのラベルを読み取り箇所を知っているサーバーや同じモジュールから生成し、ラベルがずれないようにする。
- ラベルを意味のあるクラスにまとめる。今すぐ適用、次回の会話から適用、再起動後に適用、といった具合に。
回避
保存を確認しておきながら、実際には何もしない設定画面。これはエラーより悪い。エラーはユーザーに原因を探させるが、成功表示はユーザーに機能やモデル、あるいは自分自身を責めさせてしまう。
インターフェース内に「再起動が必要」というリストをハードコードするのは避けること。そのリストは、どこか別の場所にある知識のコピーであり、読み取り箇所が移動した瞬間——静かに——古くなる。そしてそれこそが元々の問題が生まれた経緯である。
「一部の設定には再起動が必要です」という一律の注記も避けること。それは事実ではあるが役に立たず、必要のないものまで覆ってしまう。
確認
設定を変更し、機能を使い、画面ではなく挙動を観察する。値は、送信したばかりのフォームからではなく、稼働中のシステムから読み戻すこと。
機械的な検証版: 「即時適用」とラベル付けされた設定が実は即時ではないことがないか、そしてインターフェースが公開しているすべての設定がサーバーの公開する分類の中に登場するかを検証する。
リスク
ラベルは設定画面にノイズを加える。すべての行にバッジが付いた画面は、バッジが何の意味も持たない画面になる。ラベルが必要なのは遅延して適用されるものだけだ。
より根深いリスクは、ラベルを修正そのものとして扱ってしまうことだ。あるコントロールが再起動まで無効であると宣言することは誠実だが、それをライブにする方が優れており、ラベルがより難しい変更を避けるための都合の良い逃げ道になってはならない。
使い方
カードはデータです。リポジトリをクローンし、パスで取り込んでください。ネットワーク経由で届いたものは汚染扱いとなり、承認されるまで保留されます。それが望ましい挙動であり、ここにワンライナーのインストーラーがない理由です。
git clone https://github.com/brcampidelli/chimera-agent.gitchimera skills-import chimera-agent/skills/declare-when-a-setting-takes-effect/SKILL.md完全性
公開された状態のファイルの SHA-256。取り込む側は、受け取ったものがこのページに表示されたものと同じか確認できます。
2f1c9fd86ac24a61af75b11945b5042d1a2b53ef081cd9a87c3031d5fa97fcf3