[CI] (6fb03e7) tanstack-router/tanstack-router-code-based-saas

[wizard-ci-bot]

Automated wizard CI run

Source: scheduled
Trigger ID: 6fb03e7
App: tanstack-router/tanstack-router-code-based-saas
App directory: apps/tanstack-router/tanstack-router-code-based-saas
Workbench branch: wizard-ci-6fb03e7-tanstack-router-tanstack-router-code-based-saas
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-05-13T17:52:40.640Z
Duration: 454.3s

[wizard-ci-bot]

PR Evaluation Report

Summary

This PR integrates PostHog into a TanStack Router code-based SaaS app ("CloudFlow"). It adds posthog-js and @posthog/react, initializes PostHog with a Vite reverse proxy, wraps the root component in PostHogProvider, instruments 6 custom events across login, invoices, team member views, and plan upgrades, and captures SPA pageviews via router subscription.

Files changed	Lines added	Lines removed
6	+125	-9

Confidence score: 4/5 👍

• PII in capture event properties: username is included in user_logged_in event properties and user_name in team_member_viewed. These should be set via person properties (identify / ``), not in capture() event properties. [MEDIUM]
• No .env.example committed: The .env file is gitignored and the env var names are only documented in the setup report, not in a standard .env.example file. [MEDIUM]

---

File changes

Filename	Score	Description
src/main.tsx	4/5	Core integration: PostHog init, PostHogProvider wrapper, identify/reset on auth, capture calls for invoices/login/logout/profile/team, SPA pageview via router subscription
vite.config.js	5/5	Correct Vite dev proxy for /ingest/static, /ingest/array, and /ingest routing to PostHog assets/ingestion endpoints
package.json	5/5	Added posthog-js and @posthog/react dependencies
tsconfig.json	5/5	Added "types": ["vite/client"] to resolve import.meta.env types
.gitignore	5/5	Added .env to gitignore
posthog-setup-report.md	4/5	Comprehensive setup report documenting all changes and events

---

App sanity check ✅

Criteria	Result	Description
App builds and runs	Yes	Valid syntax, correct imports, proper TypeScript config update
Preserves existing env vars & configs	Yes	Existing app code preserved; only PostHog additions made
No syntax or type errors	Yes	All changes are syntactically valid; vite/client types added for import.meta.env
Correct imports/exports	Yes	posthog-js and @posthog/react imported correctly for browser use
Minimal, focused changes	Yes	All changes directly support PostHog integration
Pre-existing issues	None

Issues

• No .env.example file: Env variables (VITE_PUBLIC_POSTHOG_PROJECT_TOKEN, VITE_PUBLIC_POSTHOG_HOST) are only documented in the setup report, not in a committed .env.example file for easy onboarding. [MEDIUM]

Other completed criteria

• Build configuration is valid — tsconfig.json updated correctly, vite.config.js syntax is valid
• .env correctly added to .gitignore to prevent secret leakage

---

PostHog implementation ✅

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.373.4 and @posthog/react@^1.9.0 added to package.json
PostHog client initialized	Yes	posthog.init() at module level with PostHogProvider wrapping RootComponent; capture_pageview: false with manual SPA pageview via router.subscribe('onResolved')
capture()	Yes	6 custom events: user_logged_in, user_logged_out, invoice_created, invoice_updated, plan_upgrade_clicked, team_member_viewed, plus manual ``
identify()	Yes	Called on login with username as distinct_id; posthog.reset() called on both logout paths
Error tracking	Yes	capture_exceptions: true in init config enables exception autocapture
Reverse proxy	Yes	Vite dev proxy routes /ingest/static and /ingest/array to us-assets.i.posthog.com, /ingest to us.i.posthog.com

Issues

• Reverse proxy is dev-only: The Vite server.proxy only works during development. A production deployment would need its own reverse proxy (e.g., Vercel rewrites, Cloudflare, nginx). Not a code error but worth noting. [LOW]

Other completed criteria

• API key loaded from import.meta.env.VITE_PUBLIC_POSTHOG_PROJECT_TOKEN environment variable
• ui_host correctly set to us.posthog.com (UI host, not API host) with env var fallback
• posthog.reset() correctly called on both logout paths (profile page and login page)
• capture_pageview: false correctly disables automatic pageview to avoid duplicates with manual SPA pageview tracking
• defaults: '2026-01-30' config snapshot included
• debug: import.meta.env.DEV enables debug logging only in development

---

PostHog insights and events ✅

Filename	PostHog events	Description
src/main.tsx	user_logged_in	Fired on login form submission with username property; identify() called with username
src/main.tsx	user_logged_out	Fired on sign-out from both profile and login pages; reset() called after
src/main.tsx	invoice_created	Fired on successful invoice creation with invoice_id and title properties
src/main.tsx	invoice_updated	Fired on successful invoice update with invoice_id and title properties
src/main.tsx	plan_upgrade_clicked	Fired when user clicks the Upgrade button on account settings
src/main.tsx	team_member_viewed	Fired when a user clicks on a team member with user_id and user_name properties
src/main.tsx	``	Captured on every route resolution via router.subscribe('onResolved')
src/main.tsx	captureException (auto)	Enabled via capture_exceptions: true in init config

Issues

• PII in event properties (user_logged_in): username is included as an event property in posthog.capture('user_logged_in', { username }). Since username is already used as the distinct_id in the identify() call on the line above, it is redundant and places identifying information in event properties. Remove { username } from the capture call. [MEDIUM]
• PII in event properties (team_member_viewed): user_name (a person's name) is included in event properties. Person names should be set via person properties, not in capture(). Consider replacing with just user_id or moving name to `` on the viewed person's profile. [MEDIUM]

Other completed criteria

• Events represent real user actions mapped to actual product flows (login, invoice CRUD, plan upgrade, team browsing)
• Events enable product insights — can build login-to-invoice funnels, upgrade intent trends, team engagement analysis, and retention charts
• Events include relevant contextual properties (invoice IDs, titles, user IDs)
• Event names are descriptive and follow consistent snake_case convention

---

Reviewed by wizard workbench PR evaluator