[CI] (3f39e0e) tanstack-start/tanstack-start-saas

[wizard-ci-bot]

Automated wizard CI run

Source: wizard-pr
Trigger ID: 3f39e0e
App: tanstack-start/tanstack-start-saas
App directory: apps/tanstack-start/tanstack-start-saas
Workbench branch: wizard-ci-3f39e0e-tanstack-start-tanstack-start-saas
Wizard branch: release-please--branches--main--components--wizard
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-09-23T22:24:03.519Z
Duration: 439.4s

YARA Scanner

✓ 152 tool calls scanned, 0 violations detected

No violations: ✓ 152 clean scans

[wizard-ci-bot]

---

PR Evaluation Report

Summary

This PR integrates PostHog into a TanStack Start SaaS invoice app. It adds client-side analytics via @posthog/react with PostHogProvider in the root route, captures two custom events (invoice_created, invoice_marked_paid), implements error tracking via a catch boundary, and sets up server-side OpenTelemetry logging to PostHog's logs endpoint. User identification is missing entirely, no reverse proxy is configured, and the custom events lack enriching properties.

Files changed	Lines added	Lines removed
8	+146	-1

Confidence score: 4/5 👍

• No user identification: The app has no identify() or reset() calls anywhere. For a full-stack SaaS app, this means all events are anonymous and cannot be tied to users, significantly reducing analytics value. [CRITICAL]
• No reverse proxy configured: Client-side posthog-js (via @posthog/react) sends requests directly to PostHog, making them susceptible to ad blockers. No rewrites or proxy setup found in Vite config. [MEDIUM]
• Custom events have no properties: Both invoice_created and invoice_marked_paid are bare capture() calls with zero properties — no invoice ID, amount, or status — limiting their usefulness for product analysis. [MEDIUM]

---

File changes

Filename	Score	Description
.env.example	4/5	Adds VITE_PUBLIC_POSTHOG_PROJECT_TOKEN and VITE_PUBLIC_POSTHOG_HOST env vars
package.json	3/5	Adds @posthog/react, posthog-node (unused), and 4 OpenTelemetry packages for server-side logging
src/routes/__root.tsx	4/5	Wraps app in PostHogProvider with env var validation and correct config
src/components/DefaultCatchBoundary.tsx	4/5	Adds captureException via useEffect for route-level errors
src/routes/posts..tsx	3/5	Adds invoice_marked_paid capture event — no properties
src/routes/posts.index.tsx	3/5	Adds invoice_created capture event — no properties
src/utils/invoices.ts	3/5	Integrates OTel logging in server functions for invoice operations
src/utils/posthog-logs.ts	3/5	New file: OTel SDK setup for server-side logging to PostHog's /i/v1/logs endpoint

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	Syntax is valid, dependencies resolve, no type errors visible
Preserves existing env vars & configs	Yes	Existing code and configs preserved; only additions made
No syntax or type errors	Yes	All changed files have valid TypeScript/TSX syntax
Correct imports/exports	Yes	@posthog/react imports are correct for client-side; OTel imports are valid
Minimal, focused changes	No	posthog-node is added as a dependency but never imported or used — only OTel logging is used server-side. 5 extra dependencies for OTel logging is heavyweight
Pre-existing issues	None	No pre-existing issues identified in the base app

Issues

• Unused posthog-node dependency: posthog-node is added to package.json but never imported anywhere in the codebase. The server-side integration uses OpenTelemetry logging directly, not posthog-node for event capture. This adds an unnecessary dependency. [LOW]

Other completed criteria

• Environment variables documented in .env.example
• Build configuration (package.json) is valid with correct dependency declarations

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	@posthog/react (^1.11.1) for client-side; OTel packages for server-side logging
PostHog client initialized	Yes	PostHogProvider in __root.tsx with apiKey, api_host, defaults, capture_exceptions, and tracing_headers
capture()	Yes	invoice_created and invoice_marked_paid events in route handlers
identify()	No	No identify() or reset() calls anywhere in the app. All events are anonymous
Error tracking	Yes	captureException in DefaultCatchBoundary plus capture_exceptions: true in init config for unhandled errors
Reverse proxy	No	No reverse proxy configured. Client-side SDK sends directly to PostHog host

Issues

• Missing user identification: No posthog.identify() calls exist anywhere. The TanStack Start docs explicitly show calling posthog.identify(userId, { email }) on login and posthog.reset() on logout. Without this, all captured events, session replays, and error tracking remain anonymous — the primary purpose of a SaaS app's analytics (understanding per-user behavior) is lost. [CRITICAL]
• No reverse proxy: The client-side SDK (@posthog/react wrapping posthog-js) sends requests directly to the PostHog host. This makes event capture vulnerable to ad blockers. A Vite/Nitro rewrite or managed proxy should be configured. [MEDIUM]
• Outdated defaults date: The init uses defaults: '2025-05-24' while current docs recommend '2026-05-30'. This means the SDK uses an older configuration snapshot. [LOW]

Other completed criteria

• API key loaded from VITE_PUBLIC_POSTHOG_PROJECT_TOKEN environment variable (not hardcoded)
• API host loaded from VITE_PUBLIC_POSTHOG_HOST environment variable
• tracing_headers configured for client-server session linking
• Graceful fallback when env vars are missing (renders without PostHog in production, throws in dev)

---

PostHog insights and events ⚠️

Filename	PostHog events	Description
posts..tsx	invoice_marked_paid	Captured when user marks an invoice as paid — no properties attached
posts.index.tsx	invoice_created	Captured when user creates a new invoice — no properties attached
DefaultCatchBoundary.tsx	captureException	Route-level errors captured as exceptions
__root.tsx	capture_exceptions: true	Global unhandled exception autocapture enabled
invoices.ts	OTel logs: invoice.created, invoice.marked_paid	Server-side structured logs with invoice_status attribute sent to PostHog logs endpoint

Issues

• Events lack enriching properties: Both invoice_created and invoice_marked_paid are bare posthog.capture('event_name') calls with no properties. Invoice data (amount, title, status, ID) is available in the surrounding code but not passed. This severely limits the ability to segment, filter, or build meaningful funnels. [MEDIUM]

Other completed criteria

• Events represent real user actions (creating and paying invoices are core SaaS flows)
• Events could enable basic funnel analysis (create → pay flow)
• No PII in event properties
• Event names are descriptive and use consistent snake_case convention

---

Reviewed by wizard workbench PR evaluator