first-principles-review

第一原理レビュー

目的

Aegis の別のワークフローが方向性を決める前に、軽量な意思決定レビューとして使用します。単独で完結するワークフローではなく、組み合わせて使用するスキルです。

brainstorming、systematic-debugging、writing-plans、requesting-code-review、verification-before-completion の代わりには使用しないでください。これらのスキルが扱う意思決定の論点を整理するために使用します。

このレビューによって方向性が大きく変わった場合は、自然な文章で Aegis Visibility を提示します。意思決定を変えた第一原理、取り下げた前提、必要十分な最小の道筋、またはオーナー／廃止時の反証条件を明示します。あくまで助言としてタスクに特化させ、この観点を承認権限や一般的なスキル実行履歴にしないでください。

使用する場合

• ユーザーが第一原理、第一原理思考、またはオッカムの剃刀について尋ねた場合。
• 設計、計画、修正に複数の妥当な選択肢があり、選択基準が不明確な場合。
• タスクの目標が曖昧、制約が競合している、またはプロダクト／アーキテクチャの方向性にリスクがある場合。
• デバッグが、修正の繰り返し、フォールバックの増加、オーナーの重複、コンシューマー側のパッチ、または「分岐をもう一つ追加すればよい」という発想に流れている場合。
• 実装自体は局所的には正しくても、方向性が間違っている可能性があるとレビューで判明した場合。

使用しない場合

• 単純な質疑応答、状況確認、些細な文言／設定の編集、または明確に範囲が限定された単一オーナーの変更。
• 新たな方向性の衝突が生じていないのに、承認済みの計画を機械的に実行する場合。
• すべてのタスク、すべてのターン、またはすべての TDD サイクルで必須のステップとして使用すること。

5 行レビュー

合意した目標に、数量、除外事項、関係性、条件などの抜けや、根拠のない追加がないか確認します。レビュー基準は承認済みの要件に基づきます。この観点で基準を追加したり、形式が異なるという理由だけで承認済みの変換を拒否したりすることはできません。

必要なことだけを、通常は簡潔な 5 行で回答します。

First Principle: What irreducible outcome must this satisfy?
Non-negotiables: What constraints cannot be broken?
Assumptions to Drop: What is habit, inherited shape, or unproven preference?
Smallest Sufficient Path: What is the least complex path that satisfies the first principle?
Escalation Signal: What finding would require spec/design/architecture review?

方向性が新しい仕組みや馴染みのない領域に左右される場合は、道筋とエスカレーションの間に任意の 1 行を挿入します。

Known Prior Art: proven external pattern worth adopting or adapting to project
constraints (cite source), or `unknown` when precedent cannot be verified here

修正や最適化では、原因またはボトルネックを示す証拠が得られるまで、解決策を採用しないでください。選択を変え得る不明点を解消します。実験をその判断に先立って行ってもかまいません。「最小」とは、差分やオーナーの数が最小であることではなく、必要な動作を維持しながら、関連する原因の経路を網羅する介入が最小であることを意味します。独立した原因には、個別の修正が必要な場合があります。共通の担体があるからといって、原因も共通とは限りません。原因の網羅性が未解決の場合は systematic debugging を使用します。判断が確定したケースに追加のチェックリストは不要です。

Minimality Check:
- Smallest textual diff:
- Correct owner:
- Bug class fixed:
- New branch/fallback added:
- Old path retired or scheduled:
- Verdict: sufficient repair | local patch | needs first-principles review

意思決定の健全性レビュー

設計、修正、または計画を仕様書や実装計画に記載する前に承認が必要な場合に限り、このエスカレーションを使用します。

次のリスク要因のいずれかが現れた場合は、5 行レビューからエスカレーションします。

• 妥当な選択肢が複数あり、明確な選択基準がない
• 新しいオーナー、重複するオーナー、フォールバック、アダプター、または互換性専用の担体がある
• 古い経路について、先に削除する対応や廃止のトリガーが必要となる可能性がある
• 提案が依存する前提が未検証である
• 「もっとエレガントに」「長期的に安定」「第一原理」「オッカム」といったユーザーの表現がある
• 計画によって、誤ったオーナー、抽象化、互換性の境界、または廃止スケジュールが定められる可能性がある
• 既存のオブジェクト、動作、責任、契約、または関係性が再解釈、限定、置換、あるいは廃止される可能性があり、無効な権限を取り除く際に、正当な役割や明示的な参照まで失われるおそれがある

次の簡潔な形式を使用します。

First-principles invariants:
- Non-negotiable goal:
- Non-negotiable constraints:
- Historical assumptions to delete:

Bounded preservation reminder:
- Evidence-backed behavior that must remain correct:
- Highest-risk counterexample:
- Material unknown / uninspected surface:
- Known explicit anchors / upstream-downstream refs and disposition:
- Role-before-value ambiguity, if any:

Owner / retirement matrix:
- New canonical owner:
- Old owner:
- Compat-only carrier:
- Delete-first / retirement trigger:

Falsification matrix (evaluate in order; stop at the first failing gate):
- Gate 0 - Premise evidence (stage-graded): design stage accepts spec/logic
  refs; implementation/runtime stage requires log, telemetry, or test
  evidence. No evidence -> park as watch-listed, do not enter value
  evaluation.
- Gate 1 - Decidability: no obtainable evidence to judge it -> park as a
  watched falsifier, do not act.
- Gate 2 - Value (any one): lowers future fix probability / shrinks the
  solution set / exposes a missing actionable acceptance criterion / the same
  broken assumption is reused elsewhere. Passing here still requires
  gates 3-5.
- Gate 3 - Cost match: change cost vs business priority, costed at the
  current stage; a valid but deferred counterexample is recorded in the owner
  doc, never parked orally.
- Gate 4 - Goal regression: the constrained solution still meets the original
  goal; re-read the accepted-constraint list at existing checkpoints (design
  review, plan approval, pre-completion verification).
- Gate 5 - Minimize then classify: boundary-shaped destructive claims must be
  minimized first; premise attacks classify as destructive directly.
  Classes: destructive (refactor/retirement track) | supplementary (boundary
  constraint) | watch-listed (falsifier). Conflicting counterexamples are
  decided by business-goal ranking, never by stacking constraints.
- Gate 6 - Adoption trace: the cheapest checkable form (regression test for
  destructive; contract, assertion, or checklist line for supplementary),
  written into the existing owner doc.

Verdict:
- Adopt / revise / reject / needs evidence:
- Blocking gaps:
- Next evidence:

アーキテクチャ整合性レンズ

提案は実行可能でも、誤った所有者、抽象化、契約境界、または廃止経路を含んでいる可能性がある場合は、この範囲を絞ったレンズを使用してください。これは助言を目的とするメソッドパックの出力であり、それで十分な場合は Decision Hygiene Review に埋め込んでもかまいません。

アプローチの選定、タスクの分解、レビュー、または完了リスクの報告より前に、次のいずれかが見られた場合に起動してください。

• 責務が重複している可能性がある、または標準的な所有者が明確でない
• 最小限の差分に、呼び出し元側のフォールバック、ガード、アダプター、または互換性専用の媒介物が追加される
• 既存の信頼できる情報源や契約を使えば、同種の問題をより上位のレベルで解決できる可能性がある
• 古くなった所有者、フォールバック、または旧経路が、実際のロジックを担い続ける可能性がある
• 作業で、長期的な安定性、「よりクリーンなアーキテクチャ」、または上位レベルでの簡素化を主張している

次の簡潔な形式を使用してください。

Architecture Integrity Lens:
- Invariant: What must remain true for the system to be coherent?
- Canonical owner / contract: Which owner, contract, or source-of-truth should carry the behavior?
- Responsibility overlap: What duplicate owner, caller-side patch, fallback, or stale path might still carry real logic?
- Higher-level simplification: Can the problem be solved at the owner / contract / source-of-truth layer instead of by another local branch?
- Retirement / falsifier: What old path retires, or what evidence would disprove this architecture judgment?
- Responsibility / capability boundary: Which invalid authority retires, and
  does the same carrier still serve a separately evidenced legitimate role?
- Verdict: proceed | revise design | split owner | return to baseline | needs ADR/baseline sync

Bounded preservation reminder は、リスクに応じて起動する推論支援であり、あらゆる場合に必要な成果物でも、網羅的な動作一覧でもありません。関連する契約、コンシューマー、テスト、または履歴のうち最小限のものを確認してください。既知の明示的な参照はそれぞれ維持、再バインド、廃止、または却下し、未解決の関係は再推論したり意味的に完全だと主張したりせず、不明として記述してください。Method Pack は、権威ある関係グラフの構築、参照整合性や入力の系譜の証明、完全な動作網羅率の算出、または実行時ゲートの発行を行いません。

低リスクのタスクすべてにこのレンズを適用しないでください。判断に影響しない場合は、直ちに進行中のワークフローに戻ってください。

組み合わせ

• brainstorming と組み合わせる場合：依頼の範囲が広い、曖昧である、不適切なプロダクト形状を引き継ぐ可能性が高い、または所有者／廃止／フォールバック／アダプターのリスクを伴う場合は、アプローチを選定する前に実行してください。こうした兆候が見られたら、アプローチを推奨または選定する前に Decision Hygiene Review または、より範囲を絞った Architecture Integrity Lens を使用してください。
• systematic-debugging と組み合わせる場合：修正の繰り返し、フォールバックの増加、所有者の重複、またはコンシューマー側でのパッチ適用を示す証拠が得られた後に実行してください。
• writing-plans と組み合わせる場合：計画によって誤った所有者、抽象化、互換性境界、フォールバック、アダプター、または廃止スケジュールが定められる可能性がある場合は、タスクを分解する前に実行してください。承認済みの仕様でこれがすでに扱われていない場合は、タスクを記述する前に Decision Hygiene Review または Architecture Integrity Lens を使用してください。
• requesting-code-review と組み合わせる場合：コード品質だけでなく、方向性と所有者の整合性もレビューする必要があるときに実行してください。
• verification-before-completion と組み合わせる場合：方向性に関する残存リスクを明示する場合に限り使用してください。完了を承認する権限は付与されません。

境界

• 現在のプロジェクトファイル、ベースライン文書、テスト、ログ、ユーザー要件から得られる証拠を優先してください。証拠が不足している場合は、原則を作り上げず、該当箇所を不明として記載してください。
• 結果は助言の範囲にとどめてください。このスキルはエスカレーションを推奨できますが、権威ある GateDecision、PolicySnapshot、または完了承認の権限を付与するものではありません。
• 5 行のレビューで判断に影響しない場合は、直ちに進行中のワークフローに戻ってください。