[CI] (4c70a79) next-js/15-pages-router-todo

[wizard-ci-bot]

Automated wizard CI run

Source: wizard-pr
Trigger ID: 4c70a79
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-4c70a79-next-js-15-pages-router-todo
Wizard branch: release-please--branches--main--components--wizard
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-09-09T22:26:24.229Z
Duration: 341.8s

YARA Scanner

✓ 139 tool calls scanned, 0 violations detected

No violations: ✓ 139 clean scans

[wizard-ci-bot]

PR Evaluation Report

Summary

This PR adds PostHog client-side integration to a Next.js 15 pages router todo app. It initializes PostHog via instrumentation-client.ts, adds posthog-js as a dependency, documents environment variables, and captures custom events for todo CRUD operations. No server-side SDK, user identification, or reverse proxy is included.

Files changed	Lines added	Lines removed
4	+46	-0

Confidence score: 5/5 🧙

• No identify() call: The integration never calls posthog.identify(). Even if the app currently lacks auth, the docs recommend identifying users as soon as possible — and the wizard should at minimum scaffold the pattern. [MEDIUM]
• No reverse proxy configured: Next.js supports rewrites in next.config.js or next.config.ts to proxy PostHog requests, which helps avoid ad blockers. This is missing. [MEDIUM]
• Most capture calls lack properties: todo_completed, todo_reopened, and todo_deleted are bare captures with no contextual properties (e.g., todo_id), limiting their usefulness for detailed analysis. [MEDIUM]

---

File changes

Filename	Score	Description
instrumentation-client.ts	4/5	Correct PostHog initialization with env vars, error tracking config, and development-mode guards
components/todos/todo-list.tsx	3/5	Adds capture calls for CRUD events; most events lack properties; uses direct posthog import (acceptable per Next.js docs)
.env.example	5/5	Documents both required env vars with placeholder values
package.json	5/5	Adds posthog-js dependency

---

App sanity check ✅

Criteria	Result	Description
App builds and runs	Yes	No syntax errors; all imports valid
Preserves existing env vars & configs	Yes	Only additive changes to existing files
No syntax or type errors	Yes	TypeScript is valid; posthog-js types are correct
Correct imports/exports	Yes	posthog-js imported correctly in client-side files
Minimal, focused changes	Yes	Only PostHog-related additions
Pre-existing issues	None	—

Issues

No issues.

Other completed criteria

• Environment variables documented in .env.example
• Build configuration valid — posthog-js added to package.json dependencies
• isPostHogConfigured guard prevents runtime errors when env vars are missing

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js ^1.429.0 added to package.json
PostHog client initialized	Yes	posthog.init() in instrumentation-client.ts with api_host, defaults, and capture_exceptions
capture()	Yes	4 custom events: todo_created, todo_completed, todo_reopened, todo_deleted
identify()	No	No posthog.identify() call anywhere in the integration
Error tracking	Yes	capture_exceptions configured with capture_unhandled_errors: true and capture_unhandled_rejections: true
Reverse proxy	No	No Next.js rewrites configured for proxying PostHog requests

Issues

• Missing user identification: No posthog.identify() call is implemented. The wizard should scaffold an identify pattern (e.g., in a login handler or auth callback) so events can be linked to known users. Without this, all events remain anonymous. [MEDIUM]
• No reverse proxy: Next.js supports rewrites in next.config.js/next.config.ts to proxy /ingest/* to PostHog, improving event delivery past ad blockers. This is missing. [MEDIUM]

Other completed criteria

• API key loaded from NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN environment variable
• API host loaded from NEXT_PUBLIC_POSTHOG_HOST environment variable
• Development-mode error throwing when env vars are missing is a nice touch
• defaults: '2026-05-30' correctly set per docs

---

PostHog insights and events ⚠️

Filename	PostHog events	Description
instrumentation-client.ts	captureException (auto)	Unhandled errors and promise rejections automatically captured
components/todos/todo-list.tsx	todo_created, todo_completed, todo_reopened, todo_deleted	CRUD lifecycle events for todos; only todo_created includes properties

Issues

• Sparse event properties: todo_completed, todo_reopened, and todo_deleted are bare captures with no properties. Adding todo_id, todo_title_length, or similar context would enable richer analysis (e.g., which todos get completed vs deleted). [MEDIUM]

Other completed criteria

• Events represent real user actions (create, complete, reopen, delete todos)
• Events enable product insights — can build a funnel from create → complete and track deletion rates
• No PII in event properties
• Event naming is consistent snake_case and descriptive

---

Reviewed by wizard workbench PR evaluator