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

[wizard-ci-bot]

Automated wizard CI run

Source: scheduled
Trigger ID: 8f345fc
App: next-js/15-app-router-todo
App directory: apps/next-js/15-app-router-todo
Workbench branch: wizard-ci-8f345fc-next-js-15-app-router-todo
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-01-28T16:21:06.966Z
Duration: 312.4s

[wizard-ci-bot]

Now I have all the information needed to complete the evaluation. Let me compile the PR Evaluation Report.

---

PR Evaluation Report

Summary

This PR adds PostHog analytics integration to a Next.js 15 App Router todo application. The integration includes client-side tracking via instrumentation-client.ts, server-side error tracking via posthog-node, a reverse proxy configuration to bypass ad blockers, and custom event tracking for todo CRUD operations.

Files changed	Lines added	Lines removed
9	+508	-2

Confidence score: 4/5 👍

• Missing user identification: No posthog.identify() calls exist—this is a significant gap for analytics since all events are anonymous or use a static 'server' distinctId, limiting product analytics usefulness. [MEDIUM]
• Server-side distinctId is static 'server': All server-side events use distinctId: 'server' instead of correlating with actual user sessions, making it impossible to tie server-side errors to specific users. [MEDIUM]
• No await on PostHog capture in API routes: The posthog.capture() calls in API routes are not awaited, and while flushAt: 1 and flushInterval: 0 are set, there's no guarantee events are sent before the response returns in serverless environments. [LOW]

---

File changes

Filename	Score	Description
app/api/todos/[id]/route.ts	4/5	Added PostHog import and error tracking for PATCH and DELETE failures. Server-side error events use static distinctId: 'server' instead of correlating with users.
app/api/todos/route.ts	4/5	Added PostHog import and error tracking for POST failures. Same distinctId limitation as above.
components/todos/todo-list.tsx	4/5	Added client-side event tracking for todo_created, todo_completed, todo_uncompleted, todo_deleted, and exception capture. Well-placed events but no user identification.
instrumentation-client.ts	4/5	New file for client-side PostHog initialization using the modern defaults: '2025-11-30' approach with automatic pageview/exception capture. Correctly uses /ingest reverse proxy.
lib/posthog-server.ts	4/5	New singleton pattern for server-side PostHog client. Uses env vars for configuration. Includes shutdown function though it's not called anywhere.
next.config.ts	5/5	Added rewrites for PostHog reverse proxy including static assets. Correctly configured with skipTrailingSlashRedirect.
package.json	5/5	Added posthog-js and posthog-node dependencies.
pnpm-lock.yaml	5/5	Lock file updated with new dependencies.
posthog-setup-report.md	5/5	Comprehensive documentation of the integration including events, files modified, and next steps.

---

App sanity check: 5/5 ✅

Criteria	Result	Description
App builds and runs	Yes	Build completes successfully with no errors
Preserves existing env vars & configs	Yes	Original functionality preserved; .env file exists with PostHog keys
No syntax or type errors	Yes	TypeScript compilation passes
Correct imports/exports	Yes	All imports are valid and properly structured
Minimal, focused changes	Yes	Changes are limited to PostHog integration only

Issues

None.

Other completed criteria

• Existing app logic preserved in API routes and components
• Error handling patterns maintained
• Code style consistent with existing codebase
• Environment variables properly documented in setup report

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.335.5 and posthog-node@^5.24.3 added to dependencies
PostHog client initialized	Yes	Client-side via instrumentation-client.ts using modern defaults: '2025-11-30'; Server-side via singleton in lib/posthog-server.ts
capture()	Yes	Client-side captures for todo CRUD operations; Server-side captures for API errors
identify()	No	No user identification implemented—all events are anonymous
Error tracking	Yes	capture_exceptions: true enabled; captureException() used in catch blocks
Reverse proxy	Yes	/ingest rewrites configured in next.config.ts to bypass ad blockers

Issues

• No user identification: The app has no posthog.identify() calls. All client-side events are captured with anonymous distinct IDs, and server-side events use a static distinctId: 'server'. This severely limits the analytics value for understanding user behavior. [MEDIUM]
• Static server distinctId: Server-side error events use distinctId: 'server' which doesn't correlate with the actual user experiencing the error. Should extract user/session info from request context or pass client distinct ID in headers. [MEDIUM]
• Server-side client not awaiting flush: In serverless environments, events captured with posthog.capture() may not be sent before the response returns. Consider using await posthog.flush() before returning responses, or use the shutdownPostHog() function. [LOW]

Other completed criteria

• API key sourced from environment variable (NEXT_PUBLIC_POSTHOG_KEY)
• API host correctly configured via reverse proxy
• Debug mode enabled only in development
• Modern initialization pattern with defaults: '2025-11-30' for automatic pageview tracking
• skipTrailingSlashRedirect enabled for PostHog API 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	Core user actions for todo app lifecycle. Events include relevant properties like todo_id and has_description. Enables funnel analysis (create → complete).
app/api/todos/route.ts	todo_create_failed	Server-side error tracking with reason (validation_error/server_error) and error details
app/api/todos/[id]/route.ts	todo_update_failed, todo_delete_failed	Server-side error tracking for PATCH and DELETE failures with error context
instrumentation-client.ts	Automatic pageviews, exceptions	Uses defaults: '2025-11-30' which enables automatic pageview and pageleave tracking

Issues

• Limited event enrichment: Events could include more context like todo title length, time since creation for completed events, or task count at time of action. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, delete)
• Events enable conversion funnel analysis (create → complete)
• Error events distinguish between validation and server errors
• Events include useful properties (todo_id, has_description, reason, error message)
• Automatic exception capture enabled for unhandled errors

---

Reviewed by wizard workbench PR evaluator