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

[wizard-ci-bot]

Automated wizard CI run

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

[wizard-ci-bot]

The build succeeded. Now I have all the information needed to write a comprehensive PR evaluation report.

---

PR Evaluation Report

Summary

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

Files changed	Lines added	Lines removed
9	+541	-2

Confidence score: 3/5 🤔

• instrumentation-client.ts is for App Router, not Pages Router: The instrumentation-client.ts file is a Next.js 15.3+ App Router feature. Pages Router apps should initialize PostHog in _app.tsx using a useEffect hook or wrap the app with a PostHog provider. This approach may not work correctly in Pages Router. [CRITICAL]
• Server-side PostHog client uses NEXT_PUBLIC_POSTHOG_HOST but it's set incorrectly: The .env file sets NEXT_PUBLIC_POSTHOG_HOST=https://us.i.posthog.com but the server client expects the raw PostHog host, while the client uses the reverse proxy /ingest. The server client should use https://us.i.posthog.com directly (which it does), but the env var naming is confusing and the reverse proxy isn't used server-side. [MEDIUM]
• No user identification: No posthog.identify() calls are present, so all events are anonymous or use hardcoded 'anonymous' distinctId. This limits the usefulness of analytics for understanding user behavior. [MEDIUM]

---

File changes

Filename	Score	Description
components/todos/todo-list.tsx	4/5	Adds PostHog event tracking for todo create/complete/delete operations with captureException for errors. Clean implementation with appropriate event properties.
instrumentation-client.ts	2/5	Incorrect initialization approach for Pages Router. This file is for App Router only. Pages Router needs initialization in _app.tsx.
lib/posthog-server.ts	4/5	Proper singleton pattern for server-side PostHog client. flushAt: 1 and flushInterval: 0 ensure immediate flushing which is appropriate for serverless.
next.config.ts	5/5	Correct reverse proxy configuration for PostHog with static asset handling and trailing slash support.
package.json	5/5	Both posthog-js and posthog-node dependencies added correctly.
pages/api/todos/[id].ts	3/5	Server-side error tracking added, but uses hardcoded 'anonymous' distinctId and only tracks failures (not successes).
pages/api/todos/index.ts	3/5	Server-side error tracking added, but uses hardcoded 'anonymous' distinctId and only tracks failures.
pnpm-lock.yaml	5/5	Lock file properly updated with new dependencies.
posthog-setup-report.md	4/5	Good documentation of the integration, though it incorrectly describes the initialization approach as valid for Pages Router.

---

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.tsx unchanged; new env vars added
No syntax or type errors	Yes	TypeScript compilation passes
Correct imports/exports	Yes	All imports resolve correctly
Minimal, focused changes	Yes	Changes are focused on PostHog integration only

Issues

• Instrumentation file may not execute in Pages Router: instrumentation-client.ts is an App Router convention. In Pages Router, this file may never be loaded, meaning PostHog won't initialize on the client. Initialize in _app.tsx instead. [CRITICAL]

Other completed criteria

• Environment variables documented in .env file
• No unnecessary modifications to existing app logic
• Clear, readable code with comments
• Consistent code style with existing patterns

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.324.1 and posthog-node@^5.21.0 added
PostHog client initialized	Partial	Client initialization uses wrong pattern for Pages Router; server client is correct
capture()	Yes	Events captured for todo_created, todo_completed, todo_uncompleted, todo_deleted, and failure events
identify()	No	No user identification implemented; all server events use hardcoded 'anonymous' distinctId
Error tracking	Yes	capture_exceptions: true enabled client-side; captureException() called on errors; server failures tracked
Reverse proxy	Yes	Properly configured in next.config.ts with /ingest rewrites to us.i.posthog.com

Issues

• Wrong initialization pattern for Pages Router: instrumentation-client.ts is an App Router feature. Pages Router should initialize PostHog in _app.tsx using useEffect or wrap with a provider component. Without this, client-side PostHog may not initialize. [CRITICAL]
• No pageview tracking: No explicit pageview tracking is configured. For Pages Router, you typically need to set up capture_pageview: true or manually track page changes via router events. [MEDIUM]
• No user identification: All server-side events use distinctId: 'anonymous'. Should correlate with client-side distinct ID or implement proper user identification. [MEDIUM]

Other completed criteria

• Correct API host configuration using reverse proxy /ingest
• UI host correctly set to https://us.posthog.com
• Debug mode enabled in development
• Server-side client uses singleton pattern
• Immediate flush configuration for serverless environment
• No PII in event properties

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted	Client-side tracking of core user actions with relevant properties (todo_id, has_description)
todo-list.tsx	captureException	Automatic exception capture on fetch failures
pages/api/todos/index.ts	todo_create_failed	Server-side tracking of creation failures with error type and details
pages/api/todos/[id].ts	todo_update_failed, todo_delete_failed	Server-side tracking of update/delete failures with error type and details

Issues

• No success events on server-side: Server only tracks failures, not successful operations. This limits visibility into successful API calls. [LOW]
• Missing properties on some events: todo_completed and todo_deleted could include more context like todo title length or time since creation. [LOW]

Other completed criteria

• Events capture real user actions (create, complete, delete todos)
• Events can build useful funnels (todo_created → todo_completed)
• Error events include error type and details for debugging
• Events include todo_id for correlation
• has_description property on creation enables content analysis

---

Reviewed by wizard workbench PR evaluator