[CI] (6fb03e7) sveltekit/CMSaasStarter

[wizard-ci-bot]

Automated wizard CI run

Source: scheduled
Trigger ID: 6fb03e7
App: sveltekit/CMSaasStarter
App directory: apps/sveltekit/CMSaasStarter
Workbench branch: wizard-ci-6fb03e7-sveltekit-CMSaasStarter
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-05-13T17:50:14.725Z
Duration: 495.2s

[wizard-ci-bot]

Now I have enough context to write the full evaluation.

---

PR Evaluation Report

Summary

This PR integrates PostHog into a SvelteKit CMSaasStarter app with both client-side (posthog-js) and server-side (posthog-node) SDKs. It adds initialization via hooks.client.ts, a reverse proxy in hooks.server.ts, user identification on sign-in/sign-up, posthog.reset() on sign-out, error tracking on both client and server, and 12+ meaningful events across authentication, billing, and profile management flows.

Files changed	Lines added	Lines removed
14	+261	-8

Confidence score: 4/5 👍

• .env.example not updated with PostHog env vars: The .env file contains PUBLIC_POSTHOG_PROJECT_TOKEN and PUBLIC_POSTHOG_HOST, but .env.example was not updated, so new developers won't know these variables are required. [MEDIUM]
• user_signed_up fires on SIGNED_IN event: The sign-up page listens for the Supabase SIGNED_IN auth state change, which also fires on subsequent logins — meaning user_signed_up could be captured on re-login, not just on initial registration. [MEDIUM]
• Server error tracking uses hardcoded distinctId: "server": The handleError hook in hooks.server.ts uses "server" as distinctId, creating a single phantom person profile instead of associating errors with the actual user. [MEDIUM]

---

File changes

Filename	Score	Description
package.json	5/5	Adds posthog-js and posthog-node to dependencies
src/hooks.client.ts	5/5	New file: client-side PostHog init in init() with reverse proxy host, error tracking via handleError
src/hooks.server.ts	4/5	Adds reverse proxy for /ingest and server-side handleError; uses hardcoded distinctId: "server"
src/lib/server/posthog.ts	5/5	Singleton server-side PostHog client with env-based config
svelte.config.js	5/5	Sets paths.relative: false for session replay SSR compatibility
sign_in/+page.svelte	5/5	Adds posthog.identify() and user_signed_in capture on auth state change
sign_up/+page.svelte	3/5	Adds identify + capture on SIGNED_IN event — may misfire on re-login
sign_out/+page.svelte	5/5	Captures user_signed_out and calls posthog.reset()
contact_us/+page.svelte	4/5	Captures contact_us_submitted on form success
pricing_module.svelte	5/5	Captures pricing_plan_selected with plan details; also adds keyed {#each} blocks
subscribe/[slug]/+page.server.ts	5/5	Server-side subscription_checkout_started event with price and customer IDs
billing/manage/+page.server.ts	5/5	Server-side billing_portal_accessed event
account/api/+page.server.ts	5/5	Multiple server-side events for profile and account management
posthog-setup-report.md	N/A	Documentation report, not code

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors; all imports resolve to valid SvelteKit and PostHog packages
Preserves existing env vars & configs	Yes	Existing Supabase and Stripe configs untouched; only PostHog additions
No syntax or type errors	Yes	All TypeScript and Svelte syntax is valid
Correct imports/exports	Yes	posthog-js used client-side, posthog-node server-side; /static/public used correctly
Minimal, focused changes	Yes	All changes relate to PostHog integration; minor {#each} keying improvement is acceptable
Pre-existing issues	None	-

Issues

• .env.example missing PostHog variables: PUBLIC_POSTHOG_PROJECT_TOKEN and PUBLIC_POSTHOG_HOST are used throughout but .env.example was not updated. New developers won't discover these are required. Add both variables to .env.example. [MEDIUM]

Other completed criteria

• Build configuration is valid — package.json has correct dependency entries
• Existing supabase and authGuard hooks preserved and still sequenced correctly
• The posthogProxy handle is placed first in the sequence, which is correct for intercepting /ingest requests before auth

---

PostHog implementation ✅

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.373.4 and posthog-node@^5.34.1 added to package.json
PostHog client initialized	Yes	Client: posthog.init() in hooks.client.ts init() function with env var token, reverse proxy host, and defaults. Server: singleton PostHog in /server/posthog.ts
capture()	Yes	12+ events captured across client and server files
identify()	Yes	posthog.identify(session.user.id, { email }) called on sign-in and sign-up via Supabase auth state changes; posthog.reset() on sign-out
Error tracking	Yes	Client: capture_exceptions: true in init + posthog.captureException(error) in handleError. Server: server_error events captured in handleError
Reverse proxy	Yes	/ingest/* proxy in hooks.server.ts correctly routes to us.i.posthog.com for API and us-assets.i.posthog.com for /ingest/static/ and /ingest/array/ paths

Issues

• Server handleError uses hardcoded distinctId: "server": The server error handler captures server_error events with distinctId: "server", creating a single catch-all person profile. It should attempt to extract the real user ID from the session/locals if available, or use a request-scoped identifier. [MEDIUM]

Other completed criteria

• API key loaded from PUBLIC_POSTHOG_PROJECT_TOKEN env var on both client and server — never hardcoded
• Host configured via PUBLIC_POSTHOG_HOST for server; client uses /ingest reverse proxy with ui_host pointing to us.posthog.com
• paths.relative: false set in svelte.config.js for session replay SSR compatibility (SvelteKit-specific requirement)
• Both /ingest/static/ and /ingest/array/ correctly route to the assets origin

---

PostHog insights and events ✅

Filename	PostHog events	Description
hooks.client.ts	captureException	Client-side error tracking via capture_exceptions and handleError
hooks.server.ts	server_error	Unhandled server errors captured with error message and status
sign_in/+page.svelte	user_signed_in	Fired on successful sign-in with provider info; also calls identify()
sign_up/+page.svelte	user_signed_up	Fired on sign-up with provider info; also calls identify()
sign_out/+page.svelte	user_signed_out	Fired on sign-out; calls posthog.reset()
contact_us/+page.svelte	contact_us_submitted	Fired on successful contact form submission
pricing_module.svelte	pricing_plan_selected	Fired with plan_id, plan_name, plan_price
subscribe/[slug]/+page.server.ts	subscription_checkout_started	Server-side with price_id, customer_id
billing/manage/+page.server.ts	billing_portal_accessed	Server-side with customer_id
account/api/+page.server.ts	profile_created, profile_updated, account_deleted, email_subscription_toggled, password_changed	Server-side account management events with contextual properties

Issues

• user_signed_up may misfire: The sign-up page listens for Supabase's SIGNED_IN event, which fires on any login — not just initial registration. If a user navigates to the sign-up page while already logged in or on subsequent visits, this event could fire incorrectly. Consider checking for a signup-specific signal (e.g., comparing timestamps or using a different auth event). [MEDIUM]

Other completed criteria

• Events represent real user actions mapped to actual product flows (auth, billing, profile, contact)
• Events enable product insights — signup funnels, checkout conversion, churn tracking
• Events include relevant properties (plan details, provider, customer IDs, subscription status)
• No PII in capture event properties — email is only passed via identify() person properties
• Event names are descriptive, consistent snake_case convention

---

Reviewed by wizard workbench PR evaluator