[no-ticket] Flag reinvented feature-flag exposure tracking in review

prompts/_shared/analytics-tracking-rules.md

@@ -0,0 +1,20 @@
+The React frontend already has a generic mechanism for tracking a feature flag's exposure in
+Segment/Amplitude: `ENABLED_FEATURES_TO_TRACK` in `frontend/utils/analytics.ts`. Each entry
+pairs a flag name with a path `constraint`, and `trackSegmentPage` uses it to identify the flag
+as a boolean user trait and include it in the page event's `enabled_features` array whenever the
+constraint matches — with no per-component code.
+
+When a diff adds a NEW Segment/Amplitude event (a `useTrackSegmentEvent`/`trackSegmentEvent`
+call, or a new `useEffect` whose only job is firing one) whose sole purpose is recording that a
+reader saw something gated by a feature flag — not a distinct user action like a click or a
+form submission — check whether adding that flag to `ENABLED_FEATURES_TO_TRACK` would capture
+the same signal (the flag being on for a reader on the relevant page(s)) before the bespoke
+event is treated as necessary. Flag it with a file/line reference when it looks like exposure
+tracking has been reinvented per-component rather than registered once in the shared list, and
+suggest adding the flag/constraint entry instead.
+
+Don't flag it when the event carries information the shared mechanism can't express — e.g. a
+property tied to specific content the flag doesn't determine (which record, which variant of
+several), a count of how many times something happened rather than whether a flag was on, or an
+event that fires on a genuine interaction (a click, a submission) rather than passive exposure.
+The rule targets exposure-only tracking of a flag's on/off state, not tracking in general.

prompts/claude-synthesize-thesis-first.md

@@ -40,11 +40,14 @@ Synthesize a single review decision for pull request #{{PR}}.
 10. Check whether the diff renames, moves, or deletes a name that is persisted outside
    the codebase and read back after deploy, per these rules:
    {{@prompts/_shared/rename-compatibility-rules.md}}
-11. Validate which of Codex's findings are real (discard false positives), add any genuine
+11. Check whether new feature-flag exposure tracking reinvents the existing shared mechanism,
+   per these rules:
+   {{@prompts/_shared/analytics-tracking-rules.md}}
+12. Validate which of Codex's findings are real (discard false positives), add any genuine
    issues Codex missed, and (when a ticket is available) judge genuine misses of the ticket's
    intent or clear scope creep — but give credit when the author went beyond the literal
    acceptance criteria in a sound way rather than flagging it as non-compliant.
-12. Decide ONE verdict. Be pragmatic: use "request_changes" only when there is at least one
+13. Decide ONE verdict. Be pragmatic: use "request_changes" only when there is at least one
    genuine, blocking issue (such as a bug, regression, privacy violation, half-finished task,
    placeholder, or deferred work); otherwise "approve". A change that exceeds the AC without
    breaking the ticket's intent is a reason to approve, not to block.

prompts/claude-synthesize.md

@@ -40,11 +40,14 @@ Synthesize a single review decision for pull request #{{PR}}.
 10. Check whether the diff renames, moves, or deletes a name that is persisted outside
    the codebase and read back after deploy, per these rules:
    {{@prompts/_shared/rename-compatibility-rules.md}}
-11. Validate which of Codex's findings are real (discard false positives), add any genuine
+11. Check whether new feature-flag exposure tracking reinvents the existing shared mechanism,
+   per these rules:
+   {{@prompts/_shared/analytics-tracking-rules.md}}
+12. Validate which of Codex's findings are real (discard false positives), add any genuine
    issues Codex missed, and (when a ticket is available) judge genuine misses of the ticket's
    intent or clear scope creep — but give credit when the author went beyond the literal
    acceptance criteria in a sound way rather than flagging it as non-compliant.
-12. Decide ONE verdict. Be pragmatic: use "request_changes" only when there is at least one
+13. Decide ONE verdict. Be pragmatic: use "request_changes" only when there is at least one
    genuine, blocking issue (such as a bug, regression, privacy violation, half-finished task,
    placeholder, or deferred work); otherwise "approve". A change that exceeds the AC without
    breaking the ticket's intent is a reason to approve, not to block.

prompts/codex-first-pass.md

@@ -34,7 +34,10 @@ verbatim and handed to a second reviewer, so do not add conversational preamble.
 9. Check whether the diff renames, moves, or deletes a name that is persisted outside
    the codebase and read back after deploy, per these rules:
    {{@prompts/_shared/rename-compatibility-rules.md}}
-10. Report concrete issues — bugs, regressions, security problems, member-privacy
+10. Check whether new feature-flag exposure tracking reinvents the existing shared mechanism,
+   per these rules:
+   {{@prompts/_shared/analytics-tracking-rules.md}}
+11. Report concrete issues — bugs, regressions, security problems, member-privacy
    violations, incomplete tasks/half-measures/placeholders/deferred work, and genuine misses
    of the ticket's intent or clear scope creep — each with a file/line reference and a brief
    rationale. Do not list "doesn't match acceptance criteria" as an issue by itself; only