rigor

Rigor

具体的なコード変更を、依頼から証拠まで一貫して行います。

範囲。 Rigor はコードを変更するか、コード変更に至る過程で不具合や速度低下を診断します。未決のプロダクトに関する問いは /interview-me の対象です。タスクを定義する決定事項がまだ不明な場合は、これを推奨して終了してください。

1. 方針を定めて振り分ける

依頼とリポジトリから、次の事項を明確にします。

• 完了条件： タスクを終える観測可能な条件です。「何が問題なのか調べる」は診断で終了します。「修正する」なら、実装と証明まで続けます。同じ区分は、パフォーマンスの診断と最適化にも当てはまります。
• 範囲： 影響を受けるシステムと、問題の妥当な最小範囲です。
• リスク： セキュリティ、権限、金銭、データ損失、移行、並行処理、外部互換性、本番環境へのアクセス、一方向のアーキテクチャ上の選択です。

次に、プレイブックを1つだけ読み込みます。

依頼の内容	プレイブック
誤った動作、失敗するテスト、クラッシュ、リグレッションの診断または修正	Bug fix
プロダクトまたはシステムの動作の追加・変更	Feature
動作を維持しながら構造を変更	Refactoring
測定された速度、メモリ、スループット、リソース使用量の診断または改善	Performance

完了条件： 完了条件が明示され、作業の種類と許可された停止地点の両方に一致するプレイブックが1つ選ばれていることです。該当するものがない場合は、その不足点を示して終了します。

2. 実行する

以下の原則に従い、プレイブックの手順を進めます。リスクに応じて手続きの規模を調整します。ローカルで元に戻せる作業は、対象を絞った検証に直ちに進めます。計画、委任、チェックを追加する場合は、それぞれが明示された不確実性への対処となるようにします。

完了条件： プレイブックの完了基準を満たし、作業ツリーに意図した変更だけが残っていることです。

3. 引き継ぐ

結果、今回収集した証拠、すべての不足点と未検証の主張を報告します。その後、エンドツーエンドの全体的な根拠を固めるために /convince-me を、名前を挙げたリスクに関わるタスクでは独立したレビューを受けるために /code-quorum を推奨します。

原則

証拠

• 観察事項、仮説、不明点を区別します。
• 根本原因を修正します。症状を確認し、複数の仮説を立て、不確実な状態に計測を加え、失敗を生み出す仕組みを変更します。防御的なガードは、根本原因の説明にはなりません。
• 実用上可能な最も確かな境界で、実際の結果を証明します。コンパイル、要約、自己申告は補助的な証拠です。委任した成果物は直接確認します。
• チェックが失敗したときに原因となる変更を特定できるよう、作業を十分に小さな単位に分けます。
• 規模や反復回数が正当化される場合は、スクリプト、コードモッド、再現可能なコマンドを作成します。それ以外の場合は直接変更します。

形

状態、インターフェース、境界を変更する Feature と Refactoring の作業では、次の点に従います。

• 分岐ロジックを書く前に、データの形とその不変条件を明確にします。散在するルールや無効な状態をなくせる場合は、ステートマシン、判別可能なモデル、テーブル、レジストリを活用します。ローカルなコードはローカルに保ちます。
• 外部入力は、受け取る箇所で信頼できる値に変換します。
• 不正な状態を表現しにくくし、既知のバリアントをすべて網羅します。型キャストではなく、絞り込みや検証を行います。
• 要件によって既存の前提が無効になる場合は、最初からその要件が存在していたかのように設計します。確立された拡張ポイントが適合する場合は、それを使用します。
• 重大な未決の設計上の選択については、同じ基準に照らして、実質的に異なる設計案を2つまたは3つ比較します。

負担

• まず削除します。問題の範囲内で、不要になったデッドパス、古くなったアダプター、変更によって置き換えられる重複検証を取り除きます。
• 仕組みと完了条件が必要とするものだけを変更します。隣接する整理はタスクの範囲外に保ちます。
• ラッパーや抽象化は、実際の不変条件を担う、有意な複雑さを隠す、または実際の呼び出し元に使われる場合に限り、導入する価値があります。

安全性

• 状態を変更する操作には、明示的な再試行および部分実行の契約を設けます。
• 並行して作業する書き手には、それぞれ別のファイル、ブランチ、またはワークツリーを割り当てます。実際に共有される不変条件がある場合に限り、直列化します。
• 内部 API を変更する場合、現実の外部契約により段階的な移行が必要でない限り、同じ作業内ですべての呼び出し元を移行し、古い経路を削除します。
• 同じ失敗が繰り返される場合は、修正を構造的に保証するテスト、型、またはリンターを優先します。

権限

• 事実の確認は自分で行います。質問する前に、検索や安全なコマンドの実行、または低コストな検証を行います。どの動作が発生するかを尋ねる代わりに、技術的な選択肢をテストします。
• プロダクトの方向性、許容できるリスク、支出、機密データ、外部への連絡に関する判断はユーザーに委ねます。推奨案を添えて、まとめて確認します。
• 変更を加える前に、リポジトリのガイダンスと現在の作業内容を確認し、無関係な作業は保持します。
• デプロイ、リリース、許可のないマージ、破壊的なデータ操作、共有履歴への強制プッシュ、本番環境の変更、他者へのメッセージ送信の前には、一旦停止します。
• 隔離性、独立性、または作業量の削減によって結果が大きく改善される場合に限り、作業を委任します。各委任先には、期待する成果、範囲、書き込み権限、検証基準、想定する報告内容、停止条件を明示します。範囲、判断、統合、最終的な主張には、自ら責任を持ちます。