[wizard-ci-bot]

Automated wizard CI run

Source: scheduled
Trigger ID: cc5471b
App: stripe/stripe-saas-demo
App directory: apps/stripe/stripe-saas-demo
Workbench branch: wizard-ci-cc5471b-stripe-stripe-saas-demo
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-10-28T17:12:41.172Z
Duration: 194.5s

YARA Scanner

✓ 37 tool calls scanned, 0 violations detected

No violations: ✓ 37 clean scans

[wizard-ci-bot]

Now I have full context. Let me write the evaluation.

---

PR Evaluation Report

Summary

This PR adds PostHog revenue analytics integration to a Stripe SaaS demo app by attaching posthog_person_distinct_id metadata to Stripe Customer, Checkout Session, and Subscription objects. The changes enable PostHog to link Stripe revenue data back to PostHog person profiles. The PR also changes the Checkout Session's client_reference_id from the internal user ID to the PostHog distinct ID, which introduces a regression in the webhook handler's user lookup.

Files changed	Lines added	Lines removed
4	+50	-6

Confidence score: 4/5 👍

• client_reference_id change breaks webhook user lookup: The PR changes client_reference_id from userId to posthogDistinctId, but webhooks.ts (unchanged) calls getUser(session.client_reference_id) which looks up users by internal ID. This will now always return undefined since posthogDistinctId !== user.id. The PostHog capture still works via the fallback chain, but the user lookup and logging at lines 43-48 of webhooks.ts are broken. [MEDIUM]
• No new capture() events added: The PR is purely about Stripe metadata linking. While the base app already has capture calls in webhooks.ts, this PR adds none — the revenue-analytics wizard could have added revenue-specific events like subscription_upgraded, mrr_changed, etc. [MEDIUM]
• No error tracking configured: No error tracking setup was added. [MEDIUM]
• No reverse proxy configured: For the client-side posthog-js already present in the frontend, no reverse proxy was set up. [MEDIUM]

---

File changes

Filename	Score	Description
backend/routes/checkout.ts	4/5	Adds posthog_person_distinct_id metadata to Checkout Session and subscription_data. Changes client_reference_id to posthogDistinctId — correct for PostHog linking but breaks webhook user lookup
backend/routes/customers.ts	5/5	Cleanly adds posthog_person_distinct_id metadata to Stripe Customer creation
backend/routes/subscriptions.ts	5/5	Refactors user lookup and adds posthog_person_distinct_id metadata to Subscription
posthog-revenue-report.md	4/5	Good documentation of changes, verification steps, and manual next steps

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors or missing dependencies introduced
Preserves existing env vars & configs	No	client_reference_id change from userId to posthogDistinctId breaks the webhook handler's getUser() lookup
No syntax or type errors	Yes	All TypeScript is syntactically valid with correct types
Correct imports/exports	Yes	getUser import correctly added to checkout.ts
Minimal, focused changes	Yes	Only metadata additions and one refactor in subscriptions.ts
Pre-existing issues	See below	Webhook handler uses Stripe customer ID as distinctId for subscription/invoice events (not PostHog distinct ID)

Issues

• client_reference_id change breaks webhook user lookup: In webhooks.ts line 40, getUser(session.client_reference_id) expects an internal user ID (e.g., user_1698...), but the PR changes client_reference_id to posthogDistinctId. getUser() uses users.get(id) which indexes by internal ID, so it will always return undefined. The PostHog distinctId for captures still resolves correctly via the ?? session.client_reference_id fallback, but the user lookup and console logging on lines 43-48 are broken. Fix: either add a getUserByPosthogDistinctId() function, or store both values in the Checkout Session metadata. [MEDIUM]

Other completed criteria

• Environment variables already documented in base app's .env.example
• Build configuration unchanged and valid
• No unrelated code modifications

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-node v5.29.0 in backend, posthog-js v1.205.2 in frontend (pre-existing)
PostHog client initialized	Yes	Backend uses PostHog from posthog-node, frontend uses posthog-js (pre-existing)
capture()	No	This PR adds no new posthog.capture() calls; base app has captures in webhooks.ts
identify()	Yes	Pre-existing in customers.ts route (not modified by PR)
Error tracking	No	No error tracking setup added
Reverse proxy	No	No reverse proxy configured for the frontend posthog-js client

Issues

• No capture events added: The revenue-analytics wizard should ideally add revenue-specific capture events (e.g., tracking subscription changes, MRR events). The PR only adds Stripe metadata linking without any new PostHog event captures. [MEDIUM]
• No error tracking: No captureException or error boundary setup was added to either frontend or backend. [MEDIUM]
• No reverse proxy: The frontend uses posthog-js directly against us.i.posthog.com without a reverse proxy, making it susceptible to ad blockers. [MEDIUM]

Other completed criteria

• API key correctly loaded from environment variables (POSTHOG_API_KEY for backend, VITE_POSTHOG_API_KEY for frontend)
• Host correctly configured via environment variables
• posthog_person_distinct_id metadata correctly uses the real PostHog distinct ID from the user object, not fabricated values

---

PostHog insights and events ⚠️

Filename	PostHog events	Description
backend/routes/checkout.ts	(metadata only)	Adds posthog_person_distinct_id to Checkout Session metadata and subscription_data.metadata — enables PostHog revenue analytics to link checkout-created subscriptions to persons
backend/routes/customers.ts	(metadata only)	Adds posthog_person_distinct_id to Stripe Customer metadata — enables PostHog to link Stripe customers to PostHog persons
backend/routes/subscriptions.ts	(metadata only)	Adds posthog_person_distinct_id to direct Subscription metadata — enables PostHog to link subscriptions to persons

Issues

• No new events captured: The PR only adds Stripe metadata without introducing new PostHog events. Revenue-specific events like subscription_started, plan_upgraded, or payment_received would significantly improve the analytics value. [MEDIUM]
• Webhook events use Stripe customer ID as distinctId: Pre-existing issue — subscription_created and invoice_paid webhook handlers use subscription.customer (Stripe customer ID) as the PostHog distinctId rather than the posthog_person_distinct_id from metadata. This means those events won't be linked to the correct PostHog person unless the Stripe data source resolves the mapping. [LOW]

Other completed criteria

• No PII placed in event properties or metadata — only the PostHog distinct ID is used
• Metadata key posthog_person_distinct_id follows the PostHog convention for Stripe revenue analytics linking

---

Reviewed by wizard workbench PR evaluator