[CI] (4c70a79) laravel/laravel12-saas

[wizard-ci-bot]

Automated wizard CI run

Source: wizard-pr
Trigger ID: 4c70a79
App: laravel/laravel12-saas
App directory: apps/laravel/laravel12-saas
Workbench branch: wizard-ci-4c70a79-laravel-laravel12-saas
Wizard branch: release-please--branches--main--components--wizard
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-09-09T22:24:27.213Z
Duration: 517.9s

YARA Scanner

✓ 234 tool calls scanned, 0 violations detected

No violations: ✓ 234 clean scans

[wizard-ci-bot]

PR Evaluation Report

Summary

This PR adds PostHog analytics to a Laravel 12 SaaS application through a dedicated PostHogService class, capturing auth events (login, register, logout), subscription/billing events, profile updates, email verification, and exception tracking. The implementation follows Laravel conventions with a config file, env variables, and service class pattern.

Files changed	Lines added	Lines removed
15	+191	-4

Confidence score: 4/5 👍

• Config uses non-standard key name: config/posthog.php uses api_key referencing POSTHOG_PROJECT_TOKEN env var — docs recommend using config/services.php with a posthog key, but this approach is functional. [LOW]
• Duplicate logout tracking: Logout is captured in both Logout.php Livewire action and routes/auth.php GET logout route, potentially double-counting logout events. [MEDIUM]
• No PostHog::flush() consideration: No flush calls after captures — in standard request lifecycle this is fine, but for queue workers/Octane mentioned in docs, this could silently lose events. [LOW]

---

File changes

Filename	Score	Description
app/Services/PostHogService.php	4/5	New service class wrapping PostHog SDK with identify, capture, captureException methods and disabled/initialization guards
config/posthog.php	4/5	Config file with api_key, host, and disabled toggle using env()
.env.example	5/5	Documents POSTHOG_PROJECT_TOKEN, POSTHOG_HOST, POSTHOG_DISABLED
bootstrap/app.php	5/5	Exception reporting via PostHog::captureException with user context
composer.json	5/5	Adds posthog/posthog-php ^4.12.1
app/Providers/AppServiceProvider.php	5/5	Registers PostHogService as singleton
app/Http/Controllers/Auth/SocialiteController.php	5/5	Identify + capture on OAuth login
app/Http/Controllers/SubscriptionController.php	5/5	Captures subscription checkout, start, plan change, billing portal events
resources/views/livewire/pages/auth/login.blade.php	5/5	Identify + capture on password login
resources/views/livewire/pages/auth/register.blade.php	5/5	Identify + capture on registration
app/Livewire/Actions/Logout.php	4/5	Captures logout — duplicated in routes/auth.php
routes/auth.php	3/5	Duplicate logout capture; unused import of PostHogService if Livewire logout is used
Other profile/auth files	5/5	Captures password update, profile update, email verification

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	Valid PHP syntax, correct Composer package, proper Laravel patterns
Preserves existing env vars & configs	Yes	Only adds new env vars and config; existing code preserved
No syntax or type errors	Yes	All PHP files use correct syntax and types
Correct imports/exports	Yes	All use statements reference valid classes
Minimal, focused changes	Yes	All changes relate to PostHog integration
Pre-existing issues	None	—

Issues

• Duplicate logout tracking: user_logged_out is captured in both app/Livewire/Actions/Logout.php and routes/auth.php GET logout route. If both paths are used, events double-count. [MEDIUM]

Other completed criteria

• Environment variables documented in .env.example
• Build configuration valid — composer.json has correct package spec
• PostHogService registered as singleton in AppServiceProvider

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog/posthog-php: ^4.12.1 in composer.json
PostHog client initialized	Yes	PostHog::init() in PostHogService constructor with api_key and host
capture()	Yes	Multiple meaningful capture calls across auth, subscription, and profile flows
identify()	N/A	Server-only app
Error tracking	Yes	PostHog::captureException() in bootstrap/app.php exception handler with user ID and request context
Reverse proxy	N/A	Server-only app

Issues

• Initialization in service constructor vs AppServiceProvider boot: The docs recommend initializing PostHog in AppServiceProvider::boot(). This PR initializes in the PostHogService constructor, which works but defers initialization until first use. The static `` flag prevents double-init, which is correct. The singleton registration ensures constructor runs only once. This is acceptable but non-standard. [LOW]
• Config in separate file instead of config/services.php: Docs recommend adding PostHog config to config/services.php. The PR creates a separate config/posthog.php — functional but diverges from the documented pattern. [LOW]

Other completed criteria

• API key loaded from environment variable via config('posthog.api_key') → env('POSTHOG_PROJECT_TOKEN')
• Host correctly configured via environment variable
• Disabled toggle allows disabling PostHog without code changes
• PostHogService properly guards against missing config with early returns

---

PostHog insights and events ✅

Filename	PostHog events	Description
login.blade.php	user_logged_in	Password login with login_method property
SocialiteController.php	user_logged_in	OAuth login with login_method and provider properties
register.blade.php	user_registered	Registration with registration_method property
Logout.php, routes/auth.php	user_logged_out	Logout event (duplicated in two locations)
VerifyEmailController.php	email_verified	Email verification event
SubscriptionController.php	subscription_checkout_started, subscription_started, subscription_plan_changed, billing_portal_opened	Subscription lifecycle events with plan details
update-password-form.blade.php	password_updated	Password change event
update-profile-information-form.blade.php	profile_updated	Profile update with email_changed, name_changed booleans
bootstrap/app.php	captureException	All Laravel exceptions with user ID and request context

Issues

• No issues — events are well-named, enriched with relevant properties, and cover the full user lifecycle.

Other completed criteria

• Events use consistent snake_case naming convention
• Events represent real user actions across auth, billing, and profile flows
• Events enable funnel analysis (register → login → subscribe → checkout)
• Properties are contextual and relevant (plan details, login method, change flags)
• No PII in event properties — email/name only passed via identify() on person profiles

---

Reviewed by wizard workbench PR evaluator