[CI] (e2f7ab0) django/django3-saas

[wizard-ci-bot]

Automated wizard CI run

Source: wizard-pr
Trigger ID: e2f7ab0
App: django/django3-saas
App directory: apps/django/django3-saas
Workbench branch: wizard-ci-e2f7ab0-django-django3-saas
Wizard branch: release-please--branches--main--components--wizard
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-07-06T22:00:32.480Z
Duration: 488.4s

YARA Scanner

✓ 42 tool calls scanned, 0 violations detected

No violations: ✓ 42 clean scans

[wizard-ci-bot]

---

PR Evaluation Report

Summary

This PR integrates PostHog into a Django SaaS application by adding the Python SDK to requirements.txt, initializing PostHog via AppConfig.ready() using module-level configuration, adding the PosthogContextMiddleware, and instrumenting 13 events across accounts, billing, and dashboard views covering the full user lifecycle.

Files changed	Lines added	Lines removed
7	+180	-0

Confidence score: 4/5 👍

• Module-level initialization instead of instance-based API: Uses posthog.api_key = ... instead of the Posthog() class constructor, which prevents setting enable_exception_autocapture=True and registering atexit.register(posthog.shutdown). [CRITICAL]
• PII in event properties: tag('username', user.username) and tag('is_staff', user.is_staff) inject user-identifiable data into event properties rather than person properties via /. [MEDIUM]
• .env.example not updated: POSTHOG_PROJECT_TOKEN and POSTHOG_HOST are not documented in .env.example, leaving collaborators unaware of required configuration. [MEDIUM]

---

File changes

Filename	Score	Description
accounts/apps.py	3/5	PostHog initialization in AppConfig.ready() — correct hook, but uses module-level config instead of constructor
accounts/views.py	3/5	Login, logout, register, and profile update events with context-based identification; PII in tags
billing/views.py	4/5	Comprehensive billing lifecycle events with good properties
config/settings.py	5/5	PostHog env vars and middleware correctly placed after AuthenticationMiddleware
dashboard/views.py	4/5	Project CRUD events, though missing properties on project events
requirements.txt	5/5	posthog dependency added
posthog-setup-report.md	4/5	Good documentation of all events and next steps

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors; all imports valid
Preserves existing env vars & configs	Yes	All existing settings and code preserved
No syntax or type errors	Yes	All added code is syntactically correct
Correct imports/exports	Yes	from posthog import new_context, identify_context, tag, capture are valid module-level imports
Minimal, focused changes	Yes	Only PostHog-related additions
Pre-existing issues	None	—

Issues

• .env.example not updated: POSTHOG_PROJECT_TOKEN and POSTHOG_HOST are added to settings.py but not documented in .env.example. Collaborators won't know to set these variables. [MEDIUM]

Other completed criteria

• All changes are relevant to PostHog integration
• Correct files modified for Django framework
• Code follows existing codebase patterns (indentation, style)
• Build configuration (requirements.txt) is valid

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog added to requirements.txt
PostHog client initialized	No	Uses deprecated module-level posthog.api_key / posthog.host pattern in AppConfig.ready() instead of Posthog() class constructor. Missing enable_exception_autocapture=True and atexit.register(posthog.shutdown)
capture()	Yes	13 meaningful events across accounts, billing, and dashboard views
identify()	N/A	Server-only app
Error tracking	No	PosthogContextMiddleware captures view exceptions by default, but enable_exception_autocapture=True is not configured on the client, so exceptions outside the request/response cycle are not tracked
Reverse proxy	N/A	Server-only app

Issues

• Module-level initialization pattern: The PR uses posthog.api_key = settings.POSTHOG_PROJECT_TOKEN instead of posthog = Posthog(settings.POSTHOG_PROJECT_TOKEN, host=settings.POSTHOG_HOST, enable_exception_autocapture=True). The instance-based constructor is the recommended pattern and is required to enable exception autocapture and other constructor-only options. [CRITICAL]
• Missing atexit.register(posthog.shutdown): Without registering shutdown, queued events may be lost on process exit. Should add import atexit; atexit.register(posthog.shutdown) in AppConfig.ready(). [MEDIUM]

Other completed criteria

• API key loaded from environment variable via os.environ.get('POSTHOG_PROJECT_TOKEN')
• Host correctly configured with default https://us.i.posthog.com
• PosthogContextMiddleware correctly placed after AuthenticationMiddleware
• Context API properly used with new_context(), identify_context(), and capture()
• Users identified by str(user.pk) — correct for Django

---

PostHog insights and events ⚠️

Filename	PostHog events	Description
accounts/views.py	user_logged_in, user_logged_out, user_registered, profile_updated	Full auth lifecycle; login includes login_method, register includes has_company_name
billing/views.py	pricing_viewed, subscription_started, subscription_changed, subscription_canceled, checkout_completed, payment_failed	Complete billing funnel from pricing page through subscription lifecycle
dashboard/views.py	project_created, project_updated, project_deleted	Project CRUD events (no properties attached)

Issues

• PII in event properties via tag(): tag('username', user.username) in login and registration views injects the username into event properties. PII should be set as person properties via / in capture calls, not as event-level tags. [MEDIUM]
• Project events lack properties: project_created, project_updated, and project_deleted are captured with no properties — no project name, type, or count. This limits analytical usefulness. [LOW]

Other completed criteria

• Events represent real user actions mapping to actual product flows
• Events enable product insights — pricing_viewed → subscription_started forms a clear conversion funnel; subscription lifecycle enables churn analysis
• Billing events include relevant properties (plan_name, plan_interval, plan_price, days_remaining)
• Event names follow consistent snake_case convention with descriptive [noun]_[verb] pattern

---

Reviewed by wizard workbench PR evaluator