feat(posthog-integration): detect existing PostHog, surface the other tricks

[joshtronic]

Problem

If you run the wizard on a project that already has PostHog you need to walk through the full integration flow again. The original issue quotes a user who bailed out of fear it would overwrite their setup. I also ran into this issue and fortunately, in my testing re-runs mostly don't do anything (destructive or otherwise). No-op still takes ~8 minutes due to auth, skill installation, and running of the agent. Adjacent problem is that the additional wizard tools (or "tricks") aren't made apparent to the user, first run or subsequent runs.

Part of #616.

Changes

• Detection step scans package.json files for PostHog SDK using the existing findPackageJsons() (same helper revenue-analytics detection uses, monorepo-aware) and sets session.posthogSdkDetected
• Intro leads with Looks like you already have PostHog installed. when detected; clean projects keep the "two hours in eight minutes" tagline. The PostHog ✔ detected in package.json row sits below the framework line as supporting evidence
• New "Explore wizard tricks" menu item opens a registry-driven list of the subcommands, their descriptions, and how to run them. When PostHog is detected it is hoisted to the first option, ahead of "Continue anyway" (label borrowed from the health-check view) — exploring the other commands outranks re-running an integration the project may not need. Either way the continue path still routes into the normal (full) flow.
• Headline and menu construction moved to an ink-free src/ui/tui/posthog-integration-intro.ts so both can be asserted in vitest, which stubs ink suite-wide
• posthog_sdk_detected added to the standard session properties so existing events can be filtered by it

Regarding the weak signal: the notes on the issue call out that a dependency isn't proof of a working install (agreed 💯) which is why nothing gates or routes on this. A false positive costs a slightly more cautious button label. Init and/or env-key checks or post-auth server-side signals can tighten it further before anything ever routes on the flag.

On the proposed menu, the issue's UX launches the selected command, which needs an in-session program handoff that doesn't exist today. That seemed like maybe something that would be included in the v3 wizard's navigation. This ships the groundwork, but the telemetry already baked to track view changes will give a good signal on when to iterate down the road. I also left the intro's tagline untouched primarily because I couldn't come up with anything that had enough "WOW" as the "2 hours in 8 minutes" line (srsly, so good).

Test plan

• Contract test, written red-first, for detectExistingPostHog. Covers 6 cases: no package.json, dependencies without PostHog SDK, dependencies, devDependencies, nested monorepo packages, invalid installation directory (shouldn't throw)
• Store setter test alongside the existing session-setter tests with a sessionProperties test pinning the new property
• Headline and menu-order tests, also red-first. Order is pinned on each option's value rather than its label, so copy edits do not drag the test along; the only label asserted is the continue one, which branches on the detection
• Running pnpm build && pnpm test && pnpm fix all came back clean
• Live runs against a few projects via pnpm try. Projects that were already set up showed the new row, relabel, and tricks view (screenshots above). Clean project showed identical to upstream's main. Nothing gates on the flag, so --ci/headless usage is unaffected

LLM context

Friendly robots, specifically Claude Code, were utilized to help me better understand an unfamiliar codebase. Tests were generated (with my direction) with attribution on those commits. Code changes were guided, but handcrafted to help knock some ring rust off (mostly, as I think Claude committed one of my changes when I wasn't looking 👀 ). All verification runs were done by a human. Robots also played janitor and helped me identify typos.

[gewenyu99]

Hey, this is incredible! I'm gonna nudge you with some more context:

• Deterministic detection is what whacking infinite moles with a finite number of sticks feel like. We believe a haiku/GPT luna agent can do this better 10/10 times for cheaper. We actually already have this code around and are soon swapping over to it. This is a great idea, and I think we should roll this in with that bit of detection code.
• Another migration in flight is the orchestration model for the wizard. If you look carefully at live runs today, we actually enqueue tasks dynamically, albeit for now a fixed list. There's probably more magic to be had this way, if you'd like to play around, go for it! If not, I'd be happy to take this contribution forward once you're happy with the detection related changes.

See if this gives you more ideas ;) Apologies for the highly out of dates docs around these things. They're changing like every other week.

[joshtronic]

Hey @gewenyu99, thanks for the additional context!

Totally tracks on the deterministic detection being mole-whacking nightmare fuel. The manifest scan was always meant as a cheap first signal, with the final answer being the agentic plumbing that sounds in flight on your end.

Fortunately, the detection and disclosure are decoupled already. detectExistingPostHog is the only thing that knows how the verdict happened, as it just sets posthogSdkDetected and everything downstream works off the flag. Your agentic detection can set the same flag and the rest should carry over as-is.

I just pushed a small change so the flag's comment describes the outcome rather than the mechanism. One less thing to change when the agentic detection lands.

I'm happy with this PR as-is. You can consider the detector disposable and the rest is yours to take forward whenever. I may poke at the dynamic task enqueuing this week out of curiosity, but don't let me block anything.

Appreciate you taking the time to put eyes on this PR. 🙇

[gewenyu99]

Hellooooo friend,

I'm two weeks late but I took a look.

The way you implemented this makes perfect sense and will be easy to extend later. Good job!

I think we can be more aggressive here and say something like:

• Looks like you already have PostHog installed
• PostHog ✔ detected in package.json
• Explore other wizard tricks should switch places with continue anyway
• Maybe we can wire the menu directly so that you don't need to exit and rerun the program to use the tricks.

Go for it if you've got some time. I'll pick this up another time if you don't. Thanks!

[joshtronic]

Hey @gewenyu99 -- no worries on the delay. The feedback is great and appreciated. Actually stoked to get in there and wire up the tricks menu. I may also have a second PR (wrt warehouse source detection) before some travel next week :)