[CI] (a283762) next-js/15-app-router-todo

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: a283762
App: next-js/15-app-router-todo
App directory: apps/next-js/15-app-router-todo
Workbench branch: wizard-ci-a283762-next-js-15-app-router-todo
Wizard branch: main
Examples branch: main
PostHog (MCP) branch: master
Timestamp: 2026-01-15T22:36:12.713Z
Duration: 248.4s

[wizard-ci-bot]

Now I have all the information needed to provide the evaluation. Let me compile the full review:

---

PR Evaluation Report

Summary

This PR integrates PostHog analytics into a Next.js 15 App Router todo application. It adds client-side initialization via instrumentation-client.ts, server-side tracking with posthog-node in API routes, a reverse proxy configuration to bypass ad blockers, and event tracking for all todo CRUD operations.

Files changed	Lines added	Lines removed
9	+493	-2

Confidence score: 3/5 🤔

• No user identification: All server-side events use distinctId: 'anonymous' which prevents proper user tracking and limits analytics value. Should link client-side identity to server or use cookies/headers to correlate. [CRITICAL]
• Duplicate event tracking: Both client-side and server-side events fire for the same action (e.g., todo_created and server_todo_created), leading to double-counting without a clear correlation strategy. [MEDIUM]
• Missing posthog.shutdown() in API routes: Server-side PostHog client is initialized but never properly shut down after each request, which could cause event loss in serverless environments. [MEDIUM]

---

File changes

Filename	Score	Description
app/api/todos/[id]/route.ts	3/5	Added PostHog tracking for PATCH and DELETE operations with hardcoded 'anonymous' distinctId
app/api/todos/route.ts	3/5	Added PostHog tracking for POST operations with hardcoded 'anonymous' distinctId
components/todos/todo-list.tsx	4/5	Added client-side event tracking with capture() and captureException() for error handling
instrumentation-client.ts	4/5	New file - Correct Next.js 15.3+ client initialization using instrumentation file
lib/posthog-server.ts	3/5	New file - Singleton pattern for server-side PostHog but uses aggressive flush settings
next.config.ts	5/5	Added reverse proxy rewrites for PostHog - follows best practices
package.json	5/5	Added posthog-js and posthog-node dependencies
pnpm-lock.yaml	5/5	Lock file updated appropriately
posthog-setup-report.md	4/5	Documentation of the integration - helpful but references .env file not in diff

---

App sanity check: 4/5 ✅

Criteria	Result	Description
App builds and runs	Yes	Build completes successfully with no errors
Preserves existing env vars & configs	Yes	Existing app logic untouched, only PostHog additions
No syntax or type errors	Yes	TypeScript compilation passes
Correct imports/exports	Yes	All imports resolve correctly
Minimal, focused changes	Yes	Changes limited to PostHog integration only

Issues

• .env file committed: The .env file contains the PostHog API key and is committed to the repo. While NEXT_PUBLIC_* keys are meant to be public, committing .env files directly is often not best practice. Should use .env.example instead. [LOW]

Other completed criteria

• No breaking changes to existing functionality
• Appropriate error handling preserved from original code
• All existing API endpoints continue to work
• Build output shows all routes generating correctly

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.324.1 and posthog-node@^5.21.0 in dependencies
PostHog client initialized	Yes	Client init in instrumentation-client.ts with /ingest proxy, capture_exceptions: true
capture()	Yes	Events captured for todo CRUD operations on both client and server
Identify()	No	No posthog.identify() calls present; server uses hardcoded 'anonymous' distinctId
Error tracking	Yes	posthog.captureException(error) used in catch blocks on client-side
Reverse proxy	Yes	Rewrites configured in next.config.ts to /ingest → us.i.posthog.com

Issues

• Missing user identification: Server-side events all use distinctId: 'anonymous', breaking user journey analysis. Should implement cookie-based distinctId sharing or use posthog.identify() on client after auth. [CRITICAL]
• No shutdown() call after server events: In serverless environments, events may be lost because the singleton client isn't flushed/shutdown per request. Should call await posthog.shutdown() after captures in API routes. [MEDIUM]
• No pageview tracking: While capture_exceptions is enabled, there's no explicit pageview tracking configuration (capture_pageview not explicitly set). Pageviews may not auto-capture depending on routing approach. [LOW]

Other completed criteria

• Correct api_host pointing to reverse proxy /ingest
• ui_host configured for toolbar functionality
• defaults option set for PostHog SDK versioning
• Debug mode enabled in development
• skipTrailingSlashRedirect configured for PostHog compatibility

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
components/todos/todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted, captureException	Client-side events with todo_id and has_description properties. Error tracking on failures.
app/api/todos/route.ts	server_todo_created	Server-side creation tracking with todo_id, has_description, source properties
app/api/todos/[id]/route.ts	server_todo_updated, server_todo_deleted	Server-side update/delete tracking with todo_id, updated_completed, source properties

Issues

• Duplicate events for same actions: Both client and server capture the same user action (e.g., creating a todo fires both todo_created client-side and server_todo_created server-side). This doubles event counts without clear deduplication strategy. [MEDIUM]
• Limited event properties: Events could include more context like todo_title_length, timestamps, or session info for richer insights. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, delete todos)
• Events can power funnel analysis: todo_created → todo_completed
• Error tracking captures failures for debugging
• Boolean completion status tracked (todo_completed vs todo_uncompleted)
• Server-side events provide redundancy for ad-blocked users

---

Reviewed by wizard workbench PR evaluator