[CI] (bd1f803) laravel/laravel12-saas

[wizard-ci-bot]

Automated wizard CI run

Source: wizard-pr
Trigger ID: bd1f803
App: laravel/laravel12-saas
App directory: apps/laravel/laravel12-saas
Workbench branch: wizard-ci-bd1f803-laravel-laravel12-saas
Wizard branch: release-please--branches--main--components--wizard
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-03-03T17:33:43.145Z
Duration: 475.0s

[wizard-ci-bot]

---

PR Evaluation Report

Summary

This PR integrates PostHog analytics into a Laravel 12 SaaS application. It adds the posthog/posthog-php SDK, creates a dedicated PostHogService class registered as a singleton, and instruments 8 key business events across authentication flows (signup, login, logout) and billing actions (checkout, plan swap, billing portal access, account deletion). The implementation includes user identification with consistent properties and exception tracking.

Files changed	Lines added	Lines removed
13	+222	-10

Confidence score: 3/5 🤔

• Missing environment variable documentation: POSTHOG_API_KEY, POSTHOG_HOST, and POSTHOG_DISABLED are not documented in .env.example. Developers won't know these are required. [MEDIUM]
• Dependency injection broken in RedirectToBillingPortal: The __invoke method signature changed to require PostHogService, but the calling code in SubscriptionController::redirectToBillingPortal still calls (->user()) without the service. This will throw an error at runtime. [CRITICAL]
• No reverse proxy configuration: Events will be blocked by ad blockers when sent directly to us.i.posthog.com. [MEDIUM]
• Email used as distinct_id: Using email as the identifier is not ideal since it can change and contains PII. Consider using the user's database ID instead. [LOW]

---

File changes

Filename	Score	Description
app/Services/PostHogService.php	4/5	Well-structured service class with singleton pattern, disabled mode support, and methods for capture, identify, and exception tracking
config/posthog.php	4/5	Clean config file using env vars with sensible defaults
composer.json	5/5	PostHog PHP SDK v4.0 added correctly
app/Providers/AppServiceProvider.php	5/5	Service registered as singleton correctly
app/Models/User.php	5/5	Helper method getPostHogProperties() returns consistent user properties
app/Http/Controllers/Auth/SocialiteController.php	4/5	Correctly tracks social auth with identify and capture for both new and existing users
app/Http/Controllers/SubscriptionController.php	4/5	Tracks checkout and plan swap with rich properties, includes exception capture
app/Actions/Billing/RedirectToBillingPortal.php	2/5	Breaking change: Added required PostHogService parameter but caller doesn't pass it
app/Livewire/Actions/Logout.php	4/5	Correctly captures logout before session is cleared
resources/views/livewire/pages/auth/login.blade.php	4/5	Identifies user and captures login event with method property
resources/views/livewire/pages/auth/register.blade.php	4/5	Identifies new user and captures signup event
resources/views/livewire/profile/delete-user-form.blade.php	4/5	Captures account deletion before user is removed
posthog-setup-report.md	4/5	Good documentation of events and suggested dashboard insights

---

App sanity check: 2/5 ❌

Criteria	Result	Description
App builds and runs	Partial	Laravel boots, but runtime error will occur on billing portal access
Preserves existing env vars & configs	No	Missing PostHog env vars in .env.example
No syntax or type errors	Yes	PHP syntax is valid
Correct imports/exports	Yes	All use statements are correct
Minimal, focused changes	Yes	Changes are focused on PostHog integration only

Issues

• RedirectToBillingPortal signature mismatch: The __invoke(User , PostHogService ) method now requires two parameters, but SubscriptionController::redirectToBillingPortal calls it as (->user()) without passing the PostHogService. This will cause a TypeError at runtime when users try to access the billing portal. Fix: Either inject PostHogService in the controller and pass it, or resolve it from the container inside the action class. [CRITICAL]
• Environment variables not documented: The config file references POSTHOG_API_KEY, POSTHOG_HOST, and POSTHOG_DISABLED but these are not added to .env.example. Developers setting up the project won't know these variables exist. [MEDIUM]

Other completed criteria

• Clear, readable code with consistent style
• Consistent with existing Laravel patterns (services, DI, config)
• Appropriate error handling (disabled check, exception capture)
• Build configuration is valid

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog/posthog-php: ^4.0 in composer.json
PostHog client initialized	Yes	Initialized as singleton in AppServiceProvider, with API key and host from config
capture()	Yes	8 events captured across auth and billing flows
identify()	Yes	Users identified on login/signup with properties (name, email, provider, email_verified, date_joined)
Error tracking	Yes	captureException() method with `` event type and stack trace
Reverse proxy	No	Events sent directly to us.i.posthog.com - will be blocked by ad blockers

Issues

• No reverse proxy setup: PostHog events are sent directly to us.i.posthog.com. This means ad blockers will block analytics requests. A reverse proxy through the app's domain (e.g., via Laravel route or nginx config) should be configured to ensure reliable event delivery. [MEDIUM]
• Email as distinct_id: Using ->email as the distinct ID is problematic - emails can change and are PII. Better to use ->id or a UUID. [LOW]
• No pageview tracking: This is a server-side implementation, so no automatic pageview tracking. Consider adding a client-side JS snippet for comprehensive page analytics. [LOW]

Other completed criteria

• API key sourced from environment variable (not hardcoded)
• Configurable host URL
• Disabled mode for development/testing
• Debug mode tied to APP_DEBUG
• Feature flag support methods included
• Properties do not contain passwords or sensitive data

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
register.blade.php	user_signed_up	Tracks new user registration with signup_method: form
login.blade.php	user_logged_in	Tracks password login with login_method: password
SocialiteController.php	user_signed_up, user_logged_in	Tracks social auth (new + returning users) with provider name
Logout.php	user_logged_out	Tracks session end
SubscriptionController.php	subscription_checkout_started, subscription_plan_swapped, ``	Tracks checkout with plan details, swaps with new plan info, and exceptions
RedirectToBillingPortal.php	billing_portal_accessed	Tracks Stripe billing portal visits
delete-user-form.blade.php	user_account_deleted	Tracks account deletion

Issues

• Missing subscription_completed event: subscription_checkout_started is tracked, but there's no subscription_completed event when the user returns from Stripe checkout. The funnel will be incomplete. [MEDIUM]
• No old plan info on swap: subscription_plan_swapped captures the new plan but not the old plan, making it harder to analyze upgrade vs downgrade patterns. [LOW]

Other completed criteria

• Events represent real user actions and product flows
• Events can build meaningful funnels (signup → checkout)
• Events enriched with relevant properties (plan_name, plan_price, login_method, signup_method)
• Complete user lifecycle covered (signup → login → billing → deletion)
• Exception tracking captures error context

---

Reviewed by wizard workbench PR evaluator