Repository navigation
feat(self-driving): propose product analytics setup when events are default-only - #880
Closed
dkarasiewicz wants to merge 1 commit into
Closed
dkarasiewicz wants to merge 1 commit into
dkarasiewicz wants to merge 1 commit into
Conversation
…efault-only Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR improves the self-driving flow for repos where PostHog is already installed but the project has no (or only default) tracked events, by adding an authenticated “events-check” probe that can route users into the existing integration flow to set up product analytics instrumentation.
Changes:
- Add a new SelfDriving “events-check” step/screen after auth (already-present path) that probes for custom events and offers a product analytics setup when only default events exist.
- Extend self-driving integration detection to support an
instrumentExistingmode so already-integrated projects can be selected as instrumentation targets (instead of only “continue with existing”). - Add
fetchHasCustomEventsAPI helper, update self-driving OAuth scope additions, and add unit tests + architecture documentation updates.
Reviewed changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/ui/tui/screens/SelfDrivingIntegrationDetectScreen.tsx | Passes instrumentExisting to detection and adjusts copy when instrumenting existing installs. |
| src/ui/tui/screens/SelfDrivingHandoffScreen.tsx | Updates handoff copy to reflect “product analytics set up” vs “PostHog installed” based on the events-check path. |
| src/ui/tui/screens/SelfDrivingEventsCheckScreen.tsx | New screen that probes custom events and offers a “set up product analytics” choice. |
| src/ui/tui/screen-sequences.ts | Adds a new ScreenId for the events-check screen. |
| src/ui/tui/screen-registry.tsx | Registers the new events-check screen. |
| src/lib/programs/self-driving/steps.ts | Inserts the new events-check step into the self-driving program flow. |
| src/lib/programs/self-driving/detect.ts | Adds SELF_DRIVING_CUSTOM_EVENTS_KEY frameworkContext key for probe results. |
| src/lib/programs/self-driving/detect-agentic.ts | Adds IntegrationDetectOptions.instrumentExisting and updates classification logic accordingly. |
| src/lib/programs/self-driving/ARCHITECTURE.md | Documents the new step/flow and new scope; contains a couple of factual drift issues noted in comments. |
| src/lib/programs/tests/self-driving-detect.test.ts | Adds unit tests for the new step predicates and instrumentExisting classification. |
| src/lib/oauth/program-scopes.ts | Adds event_definition:read to self-driving scope additions and documents why. |
| src/lib/api.ts | Adds fetchHasCustomEvents API helper to query event definitions. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -97,7 +97,15 @@ are a cross-repo contract — change one, change both repos. | |||
| **Program definition** (`src/lib/programs/self-driving/`, five files): | |||
| `index.ts` (config + lifecycle), `prompt.ts` (the 9 steps + mechanics + project URLs), | |||
Comment on lines
144
to
146
| **OAuth scopes** (`src/lib/oauth/program-scopes.ts`). Base `WIZARD_OAUTH_SCOPES` | ||
| (`src/lib/constants.ts`) ∪ `SELF_DRIVING_SCOPE_ADDITIONS` — **12 strings**, requested via a PKCE | ||
| (`src/lib/constants.ts`) ∪ `SELF_DRIVING_SCOPE_ADDITIONS` — **14 strings**, requested via a PKCE | ||
| auth-code flow: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
when posthog is already in the repo, self-driving skips straight to setup even if the project captures only default events ($pageview, autocapture) or none. scouts then have almost no product behavior to watch.
Changes
events-checkstep + screen after auth (already-present path only): probes/event_definitions?event_type=event_customand, when only default events exist, proposes setting up product analyticsintegrate-detect→integrate-run→ handoff), so the standard integration program does the analytics setupdetect-agenticgains aninstrumentExistingmode so already-integrated projects are pickable targets instead of collapsing into "continue with existing"event_definition:read(already in the prod ceiling)Test plan
pnpm build && pnpm test && pnpm lintgreen locally (1323 tests)instrumentExistingclassificationLLM context
built with claude code; grounded in
self-driving/ARCHITECTURE.md(updated in lockstep).🤖 Generated with Claude Code