[CI] (6fb03e7) laravel/laravel12-saas

[wizard-ci-bot]

Automated wizard CI run

Source: scheduled
Trigger ID: 6fb03e7
App: laravel/laravel12-saas
App directory: apps/laravel/laravel12-saas
Workbench branch: wizard-ci-6fb03e7-laravel-laravel12-saas
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-05-13T17:23:31.160Z
Duration: 499.5s

[wizard-ci-bot]

PR Evaluation Report

Summary

This PR integrates PostHog into a Laravel 12 SaaS application using both the PHP SDK (posthog/posthog-php) for server-side event tracking and a client-side JS snippet in the Blade layout. A dedicated PostHogService wrapper class, a config/posthog.php config file, and environment variables are properly set up. Events cover auth flows (login, register, social login), subscription/billing flows, and account deletion.

Files changed	Lines added	Lines removed
13	+196	-2

Confidence score: 5/5 🧙

• PII in user_signed_up event properties: The user_signed_up capture call includes email and name as event properties. These are already correctly set via PostHogService::identify() right above — they should be removed from the capture() call to avoid storing PII on individual events. [MEDIUM]
• No error tracking: No exception or error capture is configured (no captureException on client or server side). [MEDIUM]

---

File changes

Filename	Score	Description
app/Services/PostHogService.php	5/5	Clean static wrapper with capture() and identify() methods, respects disabled config
app/Providers/AppServiceProvider.php	5/5	Correctly initializes PostHog::init() in boot() with config values, respects disabled flag
config/posthog.php	5/5	Proper Laravel config file using env() for all settings
.env.example	5/5	Documents all three PostHog env vars with sensible defaults
composer.json	5/5	Adds posthog/posthog-php dependency
resources/views/layouts/app.blade.php	4/5	JS snippet with client-side init and identify for authenticated users; no reverse proxy
resources/views/livewire/pages/auth/register.blade.php	3/5	PII (email, name) in capture event properties
resources/views/livewire/pages/auth/login.blade.php	5/5	Identify + capture on login
app/Http/Controllers/Auth/SocialiteController.php	5/5	Identify + capture with provider context on social login
app/Http/Controllers/SubscriptionController.php	5/5	Good subscription funnel events with plan properties
app/Actions/Billing/RedirectToBillingPortal.php	5/5	Simple billing portal access event
resources/views/livewire/profile/delete-user-form.blade.php	5/5	Account deletion tracked before logout/delete
posthog-setup-report.md	4/5	Comprehensive setup report

---

App sanity check ✅

Criteria	Result	Description
App builds and runs	Yes	No syntax errors, valid PHP, valid Blade templates, composer dependency properly declared
Preserves existing env vars & configs	Yes	Existing env vars and configs untouched; PostHog additions are additive only
No syntax or type errors	Yes	All PHP code is syntactically valid; Blade directives used correctly
Correct imports/exports	Yes	All use statements reference valid classes (PostHog\PostHog, App\Services\PostHogService)
Minimal, focused changes	Yes	All changes relate directly to PostHog integration; refactors in delete-user-form and SubscriptionController are minimal and necessary
Pre-existing issues	None	—

Issues

No issues.

Other completed criteria

• Environment variables properly documented in .env.example with POSTHOG_PROJECT_TOKEN, POSTHOG_HOST, POSTHOG_DISABLED
• Build configuration valid — composer.json properly formatted with new dependency in alphabetical order
• Config file follows Laravel conventions with env() helper

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog/posthog-php ^4.3 added to composer.json; client-side JS snippet added via standard PostHog loader
PostHog client initialized	Yes	Server: PostHog::init() in AppServiceProvider::boot() with api_key and host from config. Client: JS snippet in app.blade.php with posthog.init()
capture()	Yes	8 meaningful events across auth, subscription, billing, and account deletion flows
identify()	N/A	Server-only architecture. (Note: PR implements identify both server and client-side, which is good practice)
Error tracking	No	No error/exception tracking configured on either client or server side
Reverse proxy	N/A	Server-only architecture

Issues

• No error tracking: Neither PostHog::captureException() nor client-side posthog.captureException() is configured. Adding error tracking would provide visibility into application errors. [MEDIUM]

Other completed criteria

• API key loaded from environment variable via config('posthog.api_key') — not hardcoded
• Host correctly configured via config('posthog.host') with default https://us.i.posthog.com in .env.example
• Disabled flag allows toggling PostHog off without code changes
• PostHogService wrapper follows Laravel service pattern with static methods
• Client-side JS conditionally loads only when API key is present and not disabled

---

PostHog insights and events ✅

Filename	PostHog events	Description
register.blade.php	user_signed_up	Tracks new user registration with identify call
login.blade.php	user_logged_in	Tracks email/password login with identify call
SocialiteController.php	user_logged_in_with_google	Tracks OAuth login with provider and is_new_user flag
SubscriptionController.php	subscription_page_viewed, subscription_checkout_started, subscription_plan_swapped	Full subscription funnel with plan details (id, name, price)
RedirectToBillingPortal.php	billing_portal_accessed	Tracks Stripe billing portal redirects
delete-user-form.blade.php	user_account_deleted	Tracks account deletion before logout
app.blade.php	Client-side ``, identify	Auto-pageview tracking and authenticated user identification

Issues

• PII in user_signed_up event properties: The user_signed_up capture call passes email and name as event properties. Since PostHogService::identify() is called immediately before with the same data, these person properties are already set on the user profile. Remove email and name from the capture() properties array to avoid PII on events. [MEDIUM]

Other completed criteria

• Events represent real user actions mapping to actual SaaS product flows (signup → login → subscribe → upgrade → churn)
• Subscription events enable a conversion funnel: subscription_page_viewed → subscription_checkout_started → subscription_plan_swapped
• Events enriched with relevant properties (plan_id, plan_name, plan_price, provider, is_new_user, demo_mode)
• Event naming is consistent snake_case with descriptive action names

---

Reviewed by wizard workbench PR evaluator