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

[wizard-ci-bot]

Automated wizard CI run

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

[wizard-ci-bot]

---

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, a reverse proxy configuration for ad-blocker circumvention, server-side tracking in API routes, and client-side event tracking for todo CRUD operations. The implementation includes both posthog-js and posthog-node SDKs with exception capture for error monitoring.

Files changed	Lines added	Lines removed
9	+587	-2

Confidence score: 3/5 🤔

• Incorrect initialization approach for Pages Router: The instrumentation-client.ts file is designed for Next.js 15.3+ App Router, but this is a Pages Router app. Pages Router doesn't automatically load instrumentation-client.ts - this requires a pages/_app.tsx wrapper or direct import. PostHog may not initialize at all. [CRITICAL]
• Server-side host misconfiguration: Server-side PostHog client uses NEXT_PUBLIC_POSTHOG_HOST but the client uses /ingest (proxy). The server should use the proxy or direct host consistently. Currently pointing to a potentially undefined variable. [MEDIUM]
• No posthog.identify() implementation: User identification is absent - all server-side events default to 'anonymous' and client-side events have no user linking. [MEDIUM]
• Redundant getPostHogClient() call in PATCH error handler: Line 74 in [id].ts re-declares posthog when it's already in scope from line 39. [LOW]

---

File changes

Filename	Score	Description
components/todos/todo-list.tsx	4/5	Adds client-side event tracking for todo CRUD operations with posthog.capture() and posthog.captureException(). Well-structured, non-invasive changes.
instrumentation-client.ts	2/5	PostHog client initialization with proper config, but wrong approach for Pages Router - this file won't auto-load.
lib/posthog-server.ts	3/5	Server-side singleton pattern for PostHog Node client. Uses aggressive flush settings (flushAt: 1, flushInterval: 0). Host config may be undefined.
next.config.ts	5/5	Correctly configured reverse proxy rewrites for PostHog with skipTrailingSlashRedirect.
package.json	5/5	Correctly adds posthog-js and posthog-node dependencies with appropriate versions.
pages/api/todos/[id].ts	4/5	Adds server-side tracking for PATCH/DELETE operations with error tracking. Has redundant getPostHogClient() call on line 74.
pages/api/todos/index.ts	4/5	Adds server-side tracking for POST operations with validation and server error tracking.
pnpm-lock.yaml	5/5	Lock file correctly updated with PostHog dependencies and transitive dependencies.
posthog-setup-report.md	4/5	Documentation file. Claims .env was created but it's not in the PR diff. References non-existent .claude/skills/ folder.

---

App sanity check: 3/5 ⚠️

Criteria	Result	Description
App builds and runs	Likely No	The instrumentation-client.ts approach won't work for Pages Router without explicit import
Preserves existing env vars & configs	Yes	Only adds new config, doesn't remove existing settings
No syntax or type errors	Yes	Code is syntactically correct TypeScript
Correct imports/exports	Yes	All imports are valid and properly structured
Minimal, focused changes	Yes	Changes are focused on PostHog integration only

Issues

• Client initialization won't auto-load: instrumentation-client.ts is an App Router pattern. Pages Router requires PostHog initialization in pages/_app.tsx or imported at the entry point. PostHog client will not be initialized when the app runs. [CRITICAL]
• Missing .env file: The setup report claims .env was created, but it's not included in the PR diff. Users won't know required env vars at runtime. [MEDIUM]
• Redundant PostHog client instantiation: In pages/api/todos/[id].ts line 74, getPostHogClient() is called again when posthog is already in scope from line 39. [LOW]

Other completed criteria

• TypeScript types are properly used throughout
• Zod validation preserved in API routes
• No PII exposed in event properties
• Existing app logic (todo CRUD) unchanged
• Import statements are correct

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.325.0 and posthog-node@^5.21.0 added to package.json
PostHog client initialized	Partial	Client config exists but won't auto-load in Pages Router
capture()	Yes	Multiple capture calls for todo events on client and server
identify()	No	No user identification implemented - server uses 'anonymous' fallback
Error tracking	Yes	captureException() on client, api_error events on server
Reverse proxy	Yes	Properly configured in next.config.ts with rewrites to /ingest

Issues

• Initialization pattern incompatible with Pages Router: The instrumentation-client.ts file is the correct approach for App Router (Next.js 15.3+), but this is a Pages Router app (pages/ directory). PostHog needs to be initialized in _app.tsx or via a provider. Without this, no client-side events will be captured. [CRITICAL]
• No posthog.identify() calls: User identification is completely absent. Server-side events fall back to 'anonymous' distinctId, and client events have no user linking. This limits analytics value significantly. [MEDIUM]
• Server host configuration inconsistency: Server-side client uses NEXT_PUBLIC_POSTHOG_HOST environment variable while client uses /ingest proxy. Server should either use the proxy endpoint or explicitly define the host. [MEDIUM]
• defaults: '2025-05-24' is unusual: This option format appears non-standard for posthog-js. It may be ignored or cause issues. [LOW]

Other completed criteria

• capture_exceptions: true enabled for automatic error tracking
• Debug mode enabled in development
• Proper API host pointing to proxy (/ingest)
• UI host correctly set to https://us.posthog.com
• Server-side singleton pattern prevents multiple client instantiations
• Shutdown function provided for graceful cleanup

---

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 user actions with todo_id property. Exception capture on errors.
pages/api/todos/index.ts	server_todo_created, api_error	Server-side creation tracking with has_description property. Validation and server errors tracked.
pages/api/todos/[id].ts	server_todo_updated, server_todo_deleted, api_error	Server-side update/delete tracking with updated_fields and is_completion_change properties.

Issues

• No pageview tracking: Automatic pageview capture is not configured. Without initialization working, pageviews won't be tracked anyway. [MEDIUM]
• Duplicate event tracking: Both client and server capture similar events (e.g., todo_created and server_todo_created). This may cause confusion in analytics unless intentional for client/server comparison. [LOW]
• No or for user properties: Events lack user property enrichment that would enable cohort analysis. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, delete todos)
• Events enriched with relevant properties (todo_id, has_description, updated_fields)
• Error events include error_type, endpoint, method, and error_message
• Events can build funnels (creation → completion → deletion lifecycle)
• API error monitoring enables reliability tracking
• Source property distinguishes API vs client events

---

Reviewed by wizard workbench PR evaluator