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

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: afd8cc2
App: next-js/15-app-router-todo
App directory: apps/next-js/15-app-router-todo
Workbench branch: wizard-ci-afd8cc2-next-js-15-app-router-todo
Wizard branch: main
Examples branch: main
PostHog (MCP) branch: master
Timestamp: 2026-01-16T13:58:56.184Z
Duration: 278.0s

[wizard-ci-bot]

The files don't exist locally because this is a PR evaluation. Let me analyze based on the diff provided in the PR description. I have all the information I need from the comprehensive diff to evaluate this PR.

---

PR Evaluation Report

Summary

This PR integrates PostHog analytics into a Next.js 15 App Router todo application. It adds both client-side tracking via instrumentation-client.ts and server-side tracking via posthog-node, implements a reverse proxy to bypass ad blockers, and tracks all CRUD operations on todos with proper error capture.

Files changed	Lines added	Lines removed
9	+496	-2

Confidence score: 4/5 👍

• Server-side events use hardcoded distinctId: 'server' - This prevents proper user attribution for server-side events. Should pass user identifier from request headers/cookies. [MEDIUM]
• No posthog.identify() implementation - User identification is not implemented, limiting the ability to track user journeys across sessions. [MEDIUM]
• Missing await posthog.shutdown() calls - Server-side PostHog client captures events but never awaits shutdown, which could cause event loss in serverless environments. [MEDIUM]

---

File changes

Filename	Score	Description
app/api/todos/[id]/route.ts	4/5	Adds server-side PostHog tracking for PATCH and DELETE operations with relevant properties. Uses hardcoded distinctId.
app/api/todos/route.ts	4/5	Adds server-side tracking for POST (todo creation). Same distinctId issue as above.
components/todos/todo-list.tsx	4/5	Adds comprehensive client-side event tracking for all CRUD operations with error capture via captureException().
instrumentation-client.ts	5/5	Correct Next.js 15.3+ initialization pattern using instrumentation file. Proper configuration with reverse proxy host, defaults, and exception capture.
lib/posthog-server.ts	4/5	Singleton pattern for server-side PostHog client. Includes shutdown helper but it's never called in API routes.
next.config.ts	5/5	Properly configured reverse proxy rewrites for PostHog with skipTrailingSlashRedirect.
package.json	5/5	Correctly adds posthog-js and posthog-node dependencies.
pnpm-lock.yaml	5/5	Lock file properly updated with PostHog dependencies and transitive dependencies.
posthog-setup-report.md	4/5	Good documentation of setup, but references .env file and .claude/skills/ folder not included in PR.

---

App sanity check: 4/5 ✅

Criteria	Result	Description
App builds and runs	Yes	No syntax errors, proper TypeScript usage, correct imports
Preserves existing env vars & configs	Yes	Only extends next.config.ts with rewrites, no destructive changes
No syntax or type errors	Yes	All code follows TypeScript patterns correctly
Correct imports/exports	Yes	All imports are valid - posthog-js, posthog-node, and internal modules
Minimal, focused changes	Yes	Changes are strictly focused on PostHog integration

Issues

• Missing .env file: The setup report references environment variables in .env but this file is not included in the PR. Users will need to manually create it. [LOW]
• Missing .claude/skills/ folder: Referenced in setup report but not included in PR. [LOW]

Other completed criteria

• Clear, readable code with appropriate comments
• Consistent with existing patterns in the codebase
• Error handling implemented via captureException()
• Build configuration is valid

---

PostHog implementation: 4/5 ✅

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.325.0 and posthog-node@^5.21.0 added
PostHog client initialized	Yes	Client: instrumentation-client.ts with proper config. Server: singleton in lib/posthog-server.ts
capture()	Yes	7 distinct events tracked across client and server
identify()	No	No user identification implemented
Error tracking	Yes	captureException() used in all catch blocks on client; capture_exceptions: true enabled
Reverse proxy	Yes	Properly configured in next.config.ts with /ingest rewrites to us.i.posthog.com

Issues

• No posthog.identify() implementation: User identification is critical for tracking user journeys. Without it, all users appear as anonymous. Should add identify calls when user context is available. [MEDIUM]
• Server-side distinctId is hardcoded to 'server': All server events will be attributed to a single "user" called 'server', making it impossible to correlate server events with client events for the same user. Should extract user ID from cookies/headers. [MEDIUM]
• Server-side events not awaited for flush: In serverless environments, calling posthog.capture() without awaiting posthog.shutdown() can result in lost events. The shutdownPostHog() helper exists but is never called. [MEDIUM]

Other completed criteria

• Correct API host configuration via reverse proxy (/ingest)
• UI host properly configured for PostHog dashboard links
• Uses modern defaults: '2025-05-24' configuration
• Debug mode enabled in development
• Proper environment variable usage with process.env.NEXT_PUBLIC_POSTHOG_KEY
• Server client configured with flushAt: 1 and flushInterval: 0 for immediate sends
• Clear comment warning against mixing initialization approaches

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted, captureException	Client-side tracking of all todo lifecycle events with relevant properties (todo_id, has_description)
api/todos/route.ts	todo_created_server	Server-side creation tracking with todo_id, has_description, source properties
api/todos/[id]/route.ts	todo_updated_server, todo_deleted_server	Server-side update/delete tracking with todo_id, completed, source properties

Issues

• Duplicate client/server events without correlation: Both client and server track the same actions (create, update, delete) but there's no correlation ID to link them. This could cause confusion in analytics. Consider either removing server events or adding a correlation mechanism. [LOW]
• Limited event properties: Events could include more context like timestamp, list size, or task title length for richer analytics. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, uncomplete, delete)
• Events can be used to build conversion funnels (creation → completion)
• Events enriched with relevant properties (todo_id, has_description, completed status)
• Error tracking captures failures in API calls
• Good coverage of friction points (errors during CRUD operations)

---

Reviewed by wizard workbench PR evaluator