convex-launch-readiness

リリース準備状況レポート

準備状況は単一のチェックではありません。重複を排除し、優先順位を付けてスコア化した各チェックの総合結果です。この機能は検出結果バス（specs/finding.schema.json）上で純粋に各機能を組み合わせ、各監査機能を実行し、その出力を1つのレポート（specs/finding-report.schema.json）に正規化して、監査可能なスコアを算出します。また、各検出結果には修正用の fixCapability が記載されているため、4つの個別レポートではなく、優先順位付きの実行可能な修正項目リストをユーザーに提示します。この機能自体は何も修正しません。何をどの順番で修正するかを決め、その後、修正機能に処理を振り分けます。

ワークフロー

1. GUARD + SCOPE：deploy-guard が対象を分類します（local-anonymous / dev / preview / prod）。分類結果を通知します。評価可能な対象を検出します。convex/ ディレクトリがあるか、トラフィックのあるデプロイ済み環境があるか、認証の基盤があるかを確認します。前提条件を満たさないパスはスキップし、どのパスをスキップしたかを明示します（スキップされたパスは合格ではありません）。
2. 各パスを実行し、検出結果をバスに出力します：
   • convex-authz — authz スキャン（identity-from-arg、missing ownership、PII leak、parent-ref-on-write）。コードに対して常に実行できます。
   • convex-reviewer — validators、indexes-not-filter、idiom、error handling。コードに対して常に実行できます。
   • convex-advisor — 実環境における read-limit / OCC の証拠（トラフィックのあるデプロイ済み環境が存在する場合のみ。存在しない場合は「skipped: no traffic」と記録します）。
   • convex-insights — ログから最近の失敗を検出します（デプロイ済み環境が存在する場合のみ）。 独立したパスは並行して実行します。各パスは修正ではなく検出結果を返します。
3. 正規化 + 重複排除：すべての検出結果を1つのレポートに集約します。各検出結果の identity フィールドには、正規化された関数／テーブルのキー（例：messages:list）を設定します。このキーは、パスがその関数についてコード上の位置を報告した場合も、デプロイ環境上の位置を報告した場合も同一でなければなりません。これにより、2つの位置から検出された同じ不具合（reviewer がコード上の位置でインデックス不足を指摘し、advisor がデプロイ環境上の位置でその read-limit 症状を指摘した場合など）は、バスの (class, identity) による重複排除で1つに統合され、スコアに二重計上されません。信頼度の高いソースを残します。何も黙って破棄してはいけません。エラーになった、またはスキップされたパスは、クリーンな結果ではなく、明示されたカバレッジの不足として扱います。
4. 監査可能なスコアを算出します：100から開始し、重大度ごとに CONFIRMED の検出結果の点数を差し引きます（high −15、med −5、low −1）。下限は0です。数値を再現できるよう、正確な計算式とクラスごとの内訳を表示します。根拠のない印象で判断してはいけません。plausible-only の検出結果は候補として一覧表示しますが、スコアには影響させません（根拠を重視し、印象に頼りません）。デプロイ済み環境もトラフィックもない実行では、コードのみのスコアであることを報告します。
5. レポート：スコアを提示し、その後、重大度順に検出結果を並べます。それぞれに証拠、位置、fixCapability、および1行の修正メモを記載します。「blockers」（high）／「should-fix」（med）／「nice-to-have」（low）に分類します。最後に、実行する機能と順番を示した修正計画を記載します（まず authz／データ損失、次にパフォーマンス／スケーラビリティ、最後に idiom／可観測性）。
6. 要望があれば振り分けます：ユーザーが承認した各検出結果について、その fixCapability を呼び出します（convex-authz、convex-reviewer の修正機能、スキーマ変更には migrate-rehearse、コンポーネントの置き換えには suggest）。修正後、影響を受けたパスを再実行し、スコアの変化を示します。準備状況の数値が意味を持つのは、修正に応じて変化するときだけです。
7. 実行した範囲を超えるカバレッジを決して主張しないでください。レポートのヘッダーには、実行したパスと、スキップしたパスおよびその理由を記載します。コードのみの実行でスコアが良好でも、それは「コードの準備はできている」という意味であり、「本番環境で検証済み」という意味ではありません。

ルール

• 再実装ではなく、既存機能を組み合わせてください。既存の監査機能を実行し、そのバスの検出結果を集約します。認可チェックやパフォーマンスチェックをインラインで再導出してはいけません。
• スコアに含めるのは、重要度別に集計した確認済みの検出結果のみです。計算式を明記してください。妥当性がありそうな検出結果は候補であり、スコアには影響しません。
• 重複排除の前に、各検出結果の発生箇所を関数またはテーブルの識別子に正規化してください（デプロイ側の functionId とコード側のファイル名・行番号を対応付けます）。2つの発生箇所から同じ不具合が検出された場合は、1つにまとめて二重にスコアへ加算されないようにします。より信頼度の高い情報源を採用し、何も黙って削除してはいけません。
• すべての検出結果に fixCapability を含めてください。レポートの最後には、修正計画を順序付きで記載します（まずデータ損失・認可、次にスケーラビリティ、最後に慣用的な書き方・可観測性）。
• 修正後は、影響を受けるパスを再実行し、スコアの変化を示してください。修正しても数値が変わらないレディネススコアは、見せかけにすぎません。
• 実行していない内容を実行したと主張してはいけません。ヘッダーに、実行したパスとスキップしたパスを記載してください。コードのみの実行では、コードのみのスコアであることを明示します。
• これは読み取り・集約・ディスパッチを行うパスです。修正は、各修正機能で、それぞれの同意・デプロイ先のルールに従って実行します。