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

[wizard-ci-bot]

Automated wizard CI run

Trigger ID: dabf817
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-dabf817-next-js-15-pages-router-todo
Wizard branch: feat-skill-based-integration
Examples branch: rearchitect-generator
PostHog (MCP) branch: feat-mcp-skill-deployment
Timestamp: 2026-01-14T20:54:58.391Z
Duration: 250.3s

[wizard-ci-bot]

Now I have all the information needed to write a comprehensive review. Let me compile the evaluation:

---

PR Evaluation Report

Summary

This PR adds PostHog analytics integration to a Next.js 15 Pages Router todo application. It implements client-side tracking via instrumentation-client.ts, server-side tracking in API routes using posthog-node, and a reverse proxy configuration to bypass ad blockers. The integration tracks CRUD operations on todos with both success and error events.

Files changed	Lines added	Lines removed
9	+538	-3

Confidence score: 3/5 🤔

• Potential client-side initialization issue: The instrumentation-client.ts file exists but may not be automatically loaded in Next.js Pages Router. The _app.tsx does not import it, and instrumentation-client.ts is only auto-loaded in App Router (Next.js 15.3+). The PostHog client is imported directly in todo-list.tsx, but without explicit initialization import, the posthog.init() may never run. [CRITICAL]
• Server-side PostHog host configuration mismatch: The server-side client uses NEXT_PUBLIC_POSTHOG_HOST (https://us.i.posthog.com) but should use the local reverse proxy /ingest for consistency, or the server should bypass the proxy entirely with direct API access. Current setup may work but is inconsistent. [MEDIUM]
• Missing user identification: No posthog.identify() calls are present, meaning all events will be attributed to anonymous users, limiting analytics usefulness for user-level insights. [MEDIUM]

---

File changes

Filename	Score	Description
components/todos/todo-list.tsx	4/5	Added PostHog import and event captures for all CRUD operations with error tracking. Well-structured with meaningful event properties.
instrumentation-client.ts	2/5	New file for PostHog client initialization with modern defaults config. However, may not be auto-loaded in Pages Router architecture.
lib/posthog-server.ts	4/5	Singleton pattern for server-side PostHog client. Good implementation with shutdown helper.
next.config.ts	4/5	Added reverse proxy rewrites correctly. Replaced empty config comment with functional config.
package.json	5/5	Added posthog-js and posthog-node dependencies correctly.
pages/api/todos/[id].ts	4/5	Added server-side event captures for update and delete operations with proper distinctId handling.
pages/api/todos/index.ts	4/5	Added server-side event captures for create operations and error tracking.
pnpm-lock.yaml	5/5	Lock file updated correctly with new dependencies.
posthog-setup-report.md	4/5	Comprehensive documentation of the integration, though incorrectly states instrumentation-client.ts uses "recommended Next.js 15.3+ pattern" which is for App Router only.

---

App sanity check: 3/5 ⚠️

Criteria	Result	Description
App builds and runs	Likely	Dependencies are correct, but PostHog client initialization may not execute
Preserves existing env vars & configs	Yes	Added new env vars without removing existing ones
No syntax or type errors	Yes	All TypeScript code appears syntactically correct
Correct imports/exports	Partial	Import of posthog from posthog-js in todo-list.tsx works, but relies on instrumentation-client.ts being loaded first
Minimal, focused changes	Yes	Changes are focused on PostHog integration only

Issues

• Client initialization not guaranteed: In Pages Router, instrumentation-client.ts is not automatically loaded. The file needs to be explicitly imported in _app.tsx or another entry point to ensure posthog.init() runs before any posthog.capture() calls. Without this, the PostHog client may be used uninitialized. [CRITICAL]
• 'use client' directive in Pages Router: The todo-list.tsx file has 'use client' directive which is an App Router concept and is unnecessary in Pages Router. Not harmful but indicates confusion about the router type. [LOW]

Other completed criteria

• Environment variables properly documented in .env.local
• Build configuration is valid
• Consistent with existing patterns
• Appropriate error handling
• No PII in event properties

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	Both posthog-js@^1.321.2 and posthog-node@^5.21.0 added to dependencies
PostHog client initialized	Partial	Init code exists in instrumentation-client.ts but may not execute in Pages Router
capture()	Yes	Multiple capture calls for todo CRUD operations on both client and server
identify()	No	No user identification implemented
Error tracking	Yes	captureException() used for all client-side error paths
Reverse proxy	Yes	Properly configured in next.config.ts rewrites pointing to US PostHog servers

Issues

• Initialization not imported in _app.tsx: The instrumentation-client.ts file exists but is not imported anywhere in the Pages Router architecture. For Pages Router, you need to explicitly import the initialization in _app.tsx or use pages/_app.tsx to initialize PostHog. The instrumentation-client.ts pattern is for App Router only. [CRITICAL]
• No pageview tracking: Automatic pageview tracking is not explicitly configured. While capture_exceptions: true is set, there's no capture_pageview or router-based pageview tracking. [MEDIUM]
• Server client host configuration: Server-side PostHog uses NEXT_PUBLIC_POSTHOG_HOST which points to PostHog directly, while client uses /ingest reverse proxy. This inconsistency is functional but not ideal. [LOW]

Other completed criteria

• API key properly stored in environment variable
• Debug mode enabled in development
• Modern defaults: '2025-05-24' configuration used
• Singleton pattern for server-side client
• Proper shutdown function exported
• Ad-blocker bypass via reverse proxy properly configured with skipTrailingSlashRedirect

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted, todo_fetch_failed, todo_create_failed, todo_update_failed, todo_delete_failed, captureException	Comprehensive client-side tracking of all user actions and errors with relevant properties (todo_id, has_description, error)
pages/api/todos/index.ts	server_todo_created, server_todo_create_failed	Server-side tracking with source identification and distinctId from headers
pages/api/todos/[id].ts	server_todo_updated, server_todo_deleted	Server-side tracking for update/delete operations with todo_id and completion status

Issues

• No funnel-friendly event naming: Events could be more consistently named for funnel analysis (e.g., todo_create_started, todo_create_completed, todo_create_failed pattern). [LOW]
• Missing timing/performance data: No duration or latency properties tracked on operations, which would be valuable for performance insights. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, uncomplete, delete)
• Error events capture exception messages for debugging
• Server-side events include source: 'api' for distinguishing origin
• has_description boolean allows analysis of todo detail patterns
• Completion toggle tracked with distinct events for measuring task completion rates
• Todo ID included in events for drill-down analysis

---

Reviewed by wizard workbench PR evaluator