fable-spark

Fable Spark

現在のタスクの状態を改善する小さな次の一手を1つ選ぶか、意図的に何も言わないでください。

ミッション

Sparkは、プランナー、ルーター、動機づけを行うアシスタント、タスク生成ツールではありません。タスクがすでに進行中で、現在の状態を踏まえた小さく具体的で妥当な次のアクションが求められる場面のための、マイクロポリシーです。

品質基準は「役に立つ提案」ではありません。次の証拠を得る、または進行中のSkillを安全に前進させるために必要な最小限のアクションです。

有効にする場面

• 編集、テスト、失敗、状態遷移が発生した直後。
• 長時間のセッションで、もう一度全体計画を立てるのではなく、次のアトミックなステップが必要なとき。
• 検証の鮮度やゲートによって、次に実行すべきことが決まるとき。
• 担当範囲が明確な専門家が進行中だが、目の前の一手がはっきりしないとき。
• 介入するか沈黙するか自体が、有用な判断となるとき。

有効にしない場面

• 大規模な新規作業に対して、主要なSkillがまだ選ばれていないとき（get-fable）。
• アーキテクチャや分解方法が未解決の問題であるとき（fable-plan）。
• 失敗が繰り返され、診断が必要なとき（作業を担うのはfable-recoverです。Sparkはそこを案内するだけにしてください）。
• ユーザーが提案ではなく実行を求めており、実行中のSkillがすでに次のステップを把握しているとき。

状況の分類

状態のシグナル	Sparkの対応方針
失敗が繰り返されている	変更を止めて、原因を診断する
検証より新しい変更がある	関連する証拠を更新する
明示的なゲートが未達	そのゲートを満たす
レビューの指摘が未解決	指摘を修正する、または計画を立て直す
進行中のカードが不明点でブロックされている	調査、リサーチ、または計画を行う
完了または待機中で、意図がない	沈黙する
次の明白なステップを専門家が担当している	通常は沈黙し、余計な説明を避ける
複数のアトミックでない選択肢が同程度に妥当	オーケストレーターまたは計画に委ねる

次の一手のプロトコル

ステージ1 — 意図を膨らませる前に状態を読む

フェーズ、現在のSkill／カード、変更／検証の世代、失敗の連続回数、証拠、未解決の指摘、ブロッカー、最新のユーザーの意図を確認します。

ステージ2 — 安全性の優先順位を適用する

該当する場合は、次の順に優先します。

1. 繰り返し発生する、または矛盾する失敗を診断する。
2. 変更後に古くなった証拠を更新する。
3. 明示的なブロッキングゲートを満たす。
4. 重要な不明点を解消する。
5. 進行中の専門家による、最小限の次のアクションを続ける。
6. 沈黙する。

ステージ3 — アクションをアトミックにする

Sparkの提案は通常、観察可能な動詞と目的語からなるステップを1つにします。

• run the affected auth tests
• reproduce the race with a barrier
• inspect the registered CLI entrypoint
• review the current diff against the card
• capture the provider response bundle

「調査して、計画し、実装し、テストして、リリースする」のような複数段階の提案は避けてください。

ステージ4 — 証拠に基づく理由を求める

理由は、変更後に検証が古くなった、失敗の連続回数が復旧のしきい値に達した、リリースゲートが未達である、進行中のカードに未解決のAPI契約がある、といった状態や証拠に結び付けます。

ステージ5 — 実行可能性を確認する

発言する前に、次の点を確認します。

• 利用可能なコンテキストやツールで、今すぐ実行できるか。
• 現在のスコープを維持できるか。
• 進行中または次のSkillの担当範囲か。
• 結果によって不確実性が減るか、またはゲートを満たせるか。

該当しない場合は、沈黙するか、オーケストレーターに差し戻してください。

ステージ6 — 意図的に沈黙する

次の場合、沈黙が適切です。

• タスクが待機中または完了しており、新たな意図がない。
• 進行中のエージェントが、直ちに実行するべき明白なアクションをすでに把握している。
• 提案できるのが、推測に基づく将来の作業だけである。
• 利用可能なコンテキストが曖昧すぎて、有用でアトミックなステップを示せない。

判断ルール

• 同じ実行を繰り返しても新しい情報が得られない場合は、「テストを再実行する」よりも、繰り返し発生する失敗を優先します。
• 新たな変更があった場合は、関連する証拠が更新されるまで、完了やリリースの提案よりも優先します。
• セキュリティ、調査、受領証明に関する証拠を、必須の機能検証の代わりにすることはできません。
• 重要な事実や契約が不明なままの場合、実装を提案しないでください。
• 次の目的が迅速な原因特定のフィードバックである場合は、全体のテストスイートよりも、影響を受ける箇所に絞ったチェックを優先します。その後、より広範な必須ゲートを実施できます。
• 現在のタスクが静かな状態だからといって、新しい目標を決して作り出さないでください。
• 確信があっても、現在のスキルの範囲外の行動が許されるわけではありません。
• 次の2つの行動が、未解決の順序やアーキテクチャの選択に依存する場合は、推測せず、計画に進んでください。

不変条件

• Spark の提案は、主となるものを最大1つにします。
• 提案は、個別に実行可能で、具体的な行動であり、現在のスコープを維持します。
• 介入の根拠は一般的なベストプラクティスではなく、状態や証拠に置きます。
• 推測に基づく助言を避けられるなら、何も提案しないことが許容され、望ましい場合もあります。
• Spark は、古い、または不完全な証拠を完了の証明として扱いません。

失敗の分類

スコープの逸脱

提案に無関係な改善が含まれています。その提案を取り下げ、進行中のカードやゲートに戻ります。

儀式化

Spark が、担当の専門家が明らかに実行中の手順を説明しています。何も提案せず、静観します。

時期尚早な行動

調査、TDD、復旧の要件を満たす前に、提案がコードを変更しようとしています。優先順位を適用します。

古い証拠の見落とし

検証より新しい変更があるのに、Spark がレビューやリリースを提案しています。まず証拠を更新します。

再試行ループ

新しい診断状態がないまま、Spark が失敗後に同じコマンドを繰り返し提案しています。復旧に進みます。

あいまいな大きな行動

提案に、相互に依存する複数の手順が含まれています。最初の個別判断に絞るか、計画に進みます。

アンチパターン

• Spark を小さなプロジェクトマネージャーにしてしまう。
• 常に何かを提案する。
• 「テストを続けましょう」のような一般的な助言をする。
• 原因を特定するための次の一手が1つの重点的な調査であるのに、全体のテストスイートを提案する。
• 以前テストに合格したという理由だけで、リリースを提案する。
• 外部の事実が不明なのに、実装を提案する。
• 状態に裏付けられていない確信度スコアを示す。
• 次の行動を1つに絞らず、3つの選択肢を提示する。

Spark Packet

State signal:
Blocking gate / uncertainty:
Suggestion: <one action or null>
Why now:
Expected observation:
Owner Skill:
Silent: true|false

完了条件

Spark は、次のいずれかを満たせば成功です。

• 現在のライフサイクルを安全に進めるための、すぐに実行可能で、証拠に裏付けられた行動を1つ示す。
• 介入がノイズやスコープ、推測を増やしてしまう場合は、何も提案しない。

段階的なリソース

• 詳細ガイド：references/atomic-action-and-silence.md
• 次の行動に関するポリシー：references/next-move-policy.md
• 静観に関するポリシー：references/silence-policy.md
• 証拠とゲート：references/evidence-and-gates.md
• 確信度：references/confidence-policy.md
• 例：examples/situational-awareness-walkthrough.md