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

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: 3864784
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-3864784-next-js-15-pages-router-todo
Wizard branch: main
Examples branch: main
PostHog (MCP) branch: master
Timestamp: 2026-01-21T22:24:02.321Z
Duration: 276.3s

[wizard-ci-bot]

The build passes. Now I have all the information I need to provide a comprehensive PR evaluation.

---

PR Evaluation Report

Summary

This PR integrates PostHog analytics into a Next.js 15 Pages Router todo application. It adds both client-side (posthog-js) and server-side (posthog-node) tracking, configures a reverse proxy for ad-blocker circumvention, and implements event tracking for CRUD operations on todos. The implementation uses instrumentation-client.ts for client-side initialization and a singleton pattern for server-side tracking.

Files changed	Lines added	Lines removed
9	+616	-2

Confidence score: 3/5 🤔

• Missing user identification: No posthog.identify() calls anywhere in the codebase. Users are tracked as "anonymous" on server-side, and client-side tracks only with auto-generated anonymous IDs. This significantly limits the usefulness of analytics. [CRITICAL]
• Hardcoded API key committed: .env.local contains a real PostHog API key (phc_sBGFIjin7AfcLwLJ4yc79wY84KHkvrTw5SnUeKD0SWE) but this file is NOT in the committed files list, so this appears to be a local-only file (acceptable). However, there's no .env.example documenting required variables in the committed changes. [MEDIUM]
• Server-side host configuration mismatch: The server-side PostHog client uses NEXT_PUBLIC_POSTHOG_HOST which points to https://us.i.posthog.com, but it should ideally use the direct host without the ingestion subdomain, or be explicitly set. [LOW]

---

File changes

Filename	Score	Description
components/todos/todo-list.tsx	4/5	Adds client-side event tracking for todo CRUD with proper error tracking via captureException(). Clean implementation.
instrumentation-client.ts	3/5	Client-side PostHog init with reverse proxy and exception capture. Missing capture_pageview: true explicit config (relies on defaults).
lib/posthog-server.ts	4/5	Clean singleton pattern for server-side client. Includes proper shutdown method.
next.config.ts	5/5	Correct reverse proxy rewrites for PostHog with proper static assets and trailing slash handling.
package.json	5/5	Both posthog-js and posthog-node added with recent versions.
pages/api/todos/[id].ts	4/5	Comprehensive server-side tracking for updates and deletes with error tracking.
pages/api/todos/index.ts	4/5	Server-side tracking for todo creation and errors.
pnpm-lock.yaml	5/5	Lock file properly updated with PostHog dependencies.
posthog-setup-report.md	4/5	Good documentation of implementation, though references non-committed .claude/skills/ folder.

---

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	Only adds new config, doesn't remove existing
No syntax or type errors	Yes	TypeScript compilation passes
Correct imports/exports	Yes	All imports resolve correctly
Minimal, focused changes	Yes	Changes are scoped to PostHog integration only

Issues

• _app.tsx unchanged: The _app.tsx file doesn't import or reference the instrumentation-client setup. For Pages Router, it relies on Next.js 15.3+ automatic loading of instrumentation-client.ts, which is correct but should be verified that instrumentation hooks are enabled. [LOW]

Other completed criteria

• Existing todo functionality preserved
• Error handling maintained with added tracking
• Code is readable and follows existing patterns
• No unnecessary modifications to unrelated files

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.333.0 and posthog-node@^5.24.1 in package.json
PostHog client initialized	Yes	Client-side via instrumentation-client.ts, server-side via singleton in lib/posthog-server.ts
capture()	Yes	Client-side: todo_created, todo_completed, todo_uncompleted, todo_deleted. Server-side: todo_create_api, todo_update_api, todo_delete_api, api_error
identify()	No	No user identification implemented. Server uses 'anonymous' fallback or custom header.
Error tracking	Yes	posthog.captureException(error) on client errors, api_error events on server
Reverse proxy	Yes	Properly configured in next.config.ts with /ingest/ routes

Issues

• No user identification: Without posthog.identify(), all users are tracked anonymously. This severely limits the ability to understand user journeys, retention, and attribution. Should add posthog.identify(userId) when users log in or register. [CRITICAL]
• Server-side distinctId relies on custom header: Server uses req.headers['x-posthog-distinct-id'] which is never sent by the client code. All server-side events will have distinctId: 'anonymous', making them unlinkable to client sessions. [CRITICAL]
• No page view tracking verification: The defaults: '2025-05-24' option enables pageviews, but this should be explicitly verified. Consider adding explicit capture_pageview: true for clarity. [LOW]

Other completed criteria

• API host correctly uses reverse proxy (/ingest)
• UI host correctly points to PostHog dashboard
• Debug mode enabled in development
• Exception capture enabled
• Proper singleton pattern prevents multiple server instances
• Shutdown function available 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	Tracks full todo lifecycle from client perspective with error capture
pages/api/todos/index.ts	todo_create_api, api_error	Server-side creation tracking with validation and server error differentiation
pages/api/todos/[id].ts	todo_update_api, todo_delete_api, api_error	Server-side update/delete tracking with comprehensive error categorization

Issues

• Duplicate client/server events: Both client and server track the same actions (e.g., todo_created client-side and todo_create_api server-side). While this provides redundancy, it may complicate analysis. Should document which to use for which purpose. [LOW]

Other completed criteria

• Events capture meaningful properties (todo_id, has_description, error_type)
• Error tracking differentiates validation vs server errors
• Events can support funnel analysis (pageview → todo_created → todo_completed)
• Event naming is consistent and descriptive
• Properties enable breakdown analysis (by error_type, completed status)

---

Reviewed by wizard workbench PR evaluator