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 view shows PostHog: detected in package.json under the framework line. Primary action (when detected) reads "Continue anyway" (borrowed from the health-check view) and still routes into the normal (full) flow.
• New "More wizard tricks" menu item opens a registry-driven list of the subcommands, their descriptions, and how to run them
• 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
• 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. 🙇