modifying-taxonomic-filter

TaxonomicFilter の変更

TaxonomicFilter は、ユーザーが「PostHog が認識しているあらゆるもの」（イベント、プロパティ、アクション、コホート、グループ）を選択するためのピッカーです。 ほぼすべての分析、フラグ、リプレイの設定への入り口となります。 コードは frontend/src/lib/components/TaxonomicFilter/ にあります。

このファイルはインデックスです。 まず全体を読み、変更に必要な参照資料だけを読み込んでください。 詳細と根拠は参照資料に記載されています。

4 つのガードレール

1. 好みではなく、根拠に基づいて判断してください。 このピッカーに携わった人は誰もが強い意見を持っていますが、その中には誤ったものもあります。 このスキル内の主張も含め、課題、Slack、またはこのスキル内の主張に基づいて行動する前に、product-reality と evidence-sources で主張を確認してください。
2. ユーザーが実際に選択しているものの優先度を下げるのは、すべてのテストが成功してもリグレッションです。 並び順、昇格、位置 0、デフォルトタブの変更には、明示的な人間の承認が必要です。
3. 2 つの画面には、2 つの実装があります。 リビルドでは、従来のデータレイヤーを再実装しています。 ほとんどの動作変更は両方に反映する必要があり、そうしないと両者に差が生じます。 surfaces-and-mirroring を参照してください。
4. テレメトリーは公開契約です。 ダッシュボードとリプレイのスキャナーは、これらのイベントを読み取ります。 プロパティの名前を変更したり、用途を変えたりする場合は、必ず明示してください。 telemetryContract.test.ts は、キャプチャ呼び出しと契約に不一致があると失敗するため、同じ PR で契約も更新してください。 telemetry-contract を参照してください。

5 行で見る概要（2026-10-15 更新）

• 利用度の高い従来版の起動のほとんどは選択に至り（約 85%）、カテゴリタブを一度も操作しないケースが大半です（約 96%）。
• Suggested ビューは、従来版の選択の約 70% を占めています。 そのうち半数強は最近使った項目からの選択です。
• 位置は重要です。従来版では約 52% が 0 行目、約 85% が上位 3 件から選ばれています。
• 最も大きな問題は、最初にカテゴリを選択した後、検索しても何も見つからないことです。 空の検索のほとんどは、正しい語を間違ったタブで検索しています。
• 顧客からは、動作の遅さよりも UI の不具合や項目の欠落について、はるかに多く報告されています。

詳細、対象期間、注意事項については、product-reality を参照してください。 これらの数値はある時点のものです。 最新の値を確認するには、PostHog データカタログで taxonomic_filter_* メトリクスを実行してください（refreshing-product-reality を参照）。

変更内容に応じた参照先

変更する内容	最初に読む資料
並び順、プロモーション、おすすめ、デフォルトタブ	product-reality、design-principles、contested-decisions
グループやタブの追加、削除、非表示	feature-inventory、surfaces-and-mirroring、call-sites
検索、空の状態、検索結果がない場合の復旧	failure-modes、design-principles
最近使った項目、ピン留め、記憶される状態	contested-decisions、design-principles
読み込み、遅延、ページネーション、エラー	performance、failure-modes
テレメトリやダッシュボード	telemetry-contract、measuring-changes
あらゆるリファクタリング	architecture、common-pitfalls、testing-patterns
再現できないバグ報告	surfaces-and-mirroring（まず対象のサーフェスを確認してください）
変更する価値があるかどうかの判断	evidence-sources、measuring-changes

作業の進め方

1. ユーザーの問題を明確にします。 どのサーフェスで、どのユーザーに、何が起きているのか。 依頼内容だけでなく、エビデンスから問題を見つけます。 evidence-sourcesを参照してください。
2. 影響の規模を見積もります。 テレメトリの比率を使います。 開く操作の0.1%に役立つだけで、おすすめビューにリスクをもたらす変更には価値がありません。
3. 該当する原則と議論のある決定事項を確認します。 変更によって文書化された決定を覆す場合は、その旨を伝え、エビデンスを提示します。
4. 両方のサーフェスに変更を加えるか、加えない理由を明確に説明します。
5. 変更したコールサイトに対するReact Testing Libraryのテストで、動作を固定します。 エージェントにとってこのコンポーネントは分かりにくいため、RTLテストが最も手早い保護策になります。 testing-patternsを参照してください。
6. マージ前に、変更が機能したとどうすれば判断できるかを決めます。 並び順やデフォルトの変更は、メトリクスとガードレールを設け、フラグの背後でリリースします。 measuring-changesを参照してください。

変更前のチェックリスト

• ユーザーの問題がエビデンス（テレメトリ、リプレイ、チケット）と関連付けられている
• レガシー版と再構築版の両方に変更を反映している、または差分を明記している
• タブまたはグループを変更した場合、両方の画面でテストしている
• 共有テレメトリペイロードが、両方の送信元で引き続き一致している
• 並び順、昇格、位置 0、またはデフォルトタブについて、人による承認を得ている
• 検索または読み込みについて、プランの境界を確認し、任意のリクエストが結果を遅らせないことを確認している
• 成功指標とガードレール指標を明示している
• 事実関係を変更した場合は、product-reality を更新している

hogli test frontend/src/lib/components/TaxonomicFilter/

このスキルの正確性を保ってください。データと矛盾する場合は、同じ PR でスキルを修正してください。 数値が約 3 か月以上前のものになったら、refreshing-product-reality に従って更新してください。