feat(experiments): gate new_d1_experience on intro quest presence

[AmarTrebinjac]

Summary

Only show the new_d1_experience GrowthBook experiment to users who actually have intro quests assigned. If useQuestDashboard().data?.intro is empty, the feature is forced to false regardless of GrowthBook assignment.

Changes

• New shared hook useNewD1ExperienceFeature in packages/shared/src/hooks/ that ANDs hasIntroQuests into the caller's shouldEvaluate before delegating to useConditionalFeature.
• Replaced all 7 existing useConditionalFeature({ feature: featureNewD1Experience, ... }) call sites with the new hook (Feed, FeedContainer, IntroQuestButton, layout/common, ClickbaitShield, ToggleClickbaitShield, useProfileCompletionIndicator).
• Jest tests covering empty intro, GrowthBook delegation, shouldEvaluate: false, and loading semantics.

Key decisions

• Client-side gating: the user's intro-quest state already lives in the client; adding a backend GrowthBook attribute would require server-side changes plus a dashboard rule update. This ships in one PR and is fully reversible.
• featureNewD1Experience definition unchanged: analytics/allocation tracking continues to function; only the post-evaluation value is gated.
• Loading semantics: hook treats data === undefined as no intro quests so the experiment can't briefly evaluate true then flip.

Test plan

• useNewD1ExperienceFeature unit tests (empty intro, GrowthBook true/false, shouldEvaluate false, default param, loading)
• IntroQuestButton.spec.tsx updated to mock the new hook
• layout/common.spec.tsx updated to mock the new hook (no QueryClientProvider in that suite)
• Lint, strict typecheck, and impacted Jest suites pass

Closes ENG-1434

---

Created by Huginn 🐦‍⬛

Preview domain

https://eng-1434-add-criteria-to-new-d1.preview.app.daily.dev

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
daily-webapp	Ready	Preview	May 12, 2026 1:07pm

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
storybook	Ignored		May 12, 2026 1:07pm

[AmarTrebinjac]

@claude please fix the failing test if its clear why its failing. If its functionality conflicts with the stated changes in the PR, let me know

[claude]

Claude finished @AmarTrebinjac's task in 7m 0s —— View job

---

Investigation summary

• Check CI status for failing tests
• Get test_shared failure log from CircleCI
• Identify root cause of failure
• Reproduce locally

Failing test: packages/shared/src/components/profile/ProfileButton.spec.tsx → should show settings option that opens modal (only 1 of 1593 tests failed; everything else green).

Failure on CI:

expect(element).toBeInTheDocument()
element could not be found in the document
> 76 |   expect(settingsButton).toBeInTheDocument();

What I found

The failing test is not exercising any of this PR's changes — it doesn't touch useNewD1ExperienceFeature, useProfileCompletionIndicator, intro quests, or any of the call sites swapped over. The PR's own tests (useNewD1ExperienceFeature.spec.tsx, IntroQuestButton.spec.tsx, layout/common.spec.tsx) all passed.

I re-ran ProfileButton.spec.tsx multiple times locally — passes every time (5/5, ~150ms for the failing case). The CI failure pattern (findByRole succeeds, then toBeInTheDocument reports element not found a moment later) is the classic async-detach symptom of a flake.

Plausible (but not proven) link to this PR

useProfileCompletionIndicator is used by both ProfilePictureWithIndicator and ProfileMenu. After this PR it transitively calls useQuestDashboard, which is a useQuery fired when isLoggedIn. The test does not mock that query, so it makes a real (failing) network attempt with retry: false. The resulting state transition can re-render ProfileMenu and (very rarely) race with the menu's open state in CI. useActions already fires a query in this hook, so we're adding one more — not introducing the pattern.

Recommendation

This doesn't look like a functional conflict with the PR's stated changes, and I can't reproduce it. My suggestion is to re-run the test_shared CircleCI job first; if it goes red again on the same test, the cheapest robust fix is to mock useQuestDashboard in ProfileButton.spec.tsx so the menu render is fully synchronous (mirroring the mocking approach this PR already uses in IntroQuestButton.spec.tsx and layout/common.spec.tsx).

I haven't pushed a change — flipping a passing-locally test on a flake we can't reproduce risks masking a real issue, and an unconditional jest.mock('useQuestDashboard') would add scope that isn't actually about this test. Happy to add that mock if you'd prefer me to ship a defensive fix anyway — just say the word.
· Branch