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

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: bd5a2b4
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-bd5a2b4-next-js-15-pages-router-todo
Wizard branch: main
Examples branch: main
PostHog (MCP) branch: master
Timestamp: 2026-01-21T21:06:20.412Z
Duration: 278.2s

[wizard-ci-bot]

Now I have all the information needed to provide a comprehensive PR evaluation. Let me compile my findings:

---

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, implements a reverse proxy for ad-blocker bypass, and captures todo CRUD events with exception tracking.

Files changed	Lines added	Lines removed
9	+503	-3

Confidence score: 4/5 👍

• Server-side events use hardcoded 'anonymous' distinctId: Events won't be linkable to specific users, making the server-side analytics less useful for user-level insights. Ideally should extract user identity from cookies/session. [MEDIUM]
• NEXT_PUBLIC_POSTHOG_HOST env var mismatch: Server-side client uses NEXT_PUBLIC_POSTHOG_HOST but this isn't used by the client-side init (uses /ingest proxy). The server should use the direct PostHog host, but this creates potential confusion. [LOW]
• instrumentation-client.ts requires Next.js 15.3+: Comment indicates this pattern is for Next.js 15.3+, but no validation exists. The app uses Next.js 15.5.7, so this is compatible. [LOW]

---

File changes

Filename	Score	Description
components/todos/todo-list.tsx	4/5	Adds PostHog import and event captures for todo created/completed/uncompleted/deleted actions with exception tracking in catch blocks
instrumentation-client.ts	4/5	New file - Client-side PostHog initialization with proper reverse proxy host, defaults, and exception capture enabled
lib/posthog-server.ts	3/5	New file - Server-side PostHog singleton client, but uses NEXT_PUBLIC_POSTHOG_HOST which may be undefined and doesn't shut down gracefully
next.config.ts	5/5	Adds reverse proxy rewrites for PostHog ingestion and skipTrailingSlashRedirect setting
package.json	5/5	Adds posthog-js and posthog-node dependencies
pages/api/todos/[id].ts	3/5	Adds server-side tracking for update/delete operations, but uses hardcoded 'anonymous' distinctId
pages/api/todos/index.ts	3/5	Adds server-side tracking for create operation, but uses hardcoded 'anonymous' distinctId
pnpm-lock.yaml	5/5	Lock file updated with new PostHog dependencies
posthog-setup-report.md	5/5	Documentation file describing the integration

---

App sanity check: 5/5 ✅

Criteria	Result	Description
App builds and runs	Yes	Build completed successfully with no errors
Preserves existing env vars & configs	Yes	Original config preserved, PostHog rewrites added appropriately
No syntax or type errors	Yes	TypeScript compilation successful
Correct imports/exports	Yes	All imports are valid and modules export correctly
Minimal, focused changes	Yes	Changes are scoped to PostHog integration only

Issues

None - App sanity check passes all criteria.

Other completed criteria

• Existing app code and logic preserved
• Clear, readable code with appropriate comments
• Error handling maintained in original locations
• Build configuration is valid
• Environment variables documented in .env file

---

PostHog implementation: 4/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 (Next.js 15.3+ pattern), server-side via singleton in lib/posthog-server.ts
capture()	Yes	Client: posthog.capture() for todo created/completed/uncompleted/deleted. Server: posthog.capture() for CRUD operations
Identify()	No	No posthog.identify() call implemented for user identification
Error tracking	Yes	capture_exceptions: true in init + posthog.captureException() in catch blocks
Reverse proxy	Yes	Rewrites configured in next.config.ts routing /ingest/* to PostHog servers

Issues

• No user identification: No posthog.identify() call is implemented. Server-side events use hardcoded 'anonymous' distinctId, preventing user-level analytics and cohort analysis. Should identify users when authentication is available. [MEDIUM]
• Server-side host configuration: posthog-server.ts uses process.env.NEXT_PUBLIC_POSTHOG_HOST but this points to https://us.i.posthog.com directly, bypassing the reverse proxy. This is correct for server-side, but naming is confusing. [LOW]

Other completed criteria

• API key via environment variable (not hardcoded)
• Correct API host configuration for client (/ingest) and server (https://us.i.posthog.com)
• ui_host correctly set to https://us.posthog.com
• defaults: "2025-05-24" configured as required
• Debug mode conditionally enabled in development
• No PII in event properties
• Proper singleton pattern for server-side client

---

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 todo actions with enriched properties (todo_id, has_description)
pages/api/todos/index.ts	server todo created	Server-side confirmation of todo creation with source tracking
pages/api/todos/[id].ts	server todo updated, server todo deleted	Server-side confirmation of updates and deletes with completion status
instrumentation-client.ts	Automatic pageviews, captureException	Default autocapture includes pageviews; exception capture enabled globally

Issues

• Duplicate client/server events: Both client and server capture the same user actions (e.g., todo created and server todo created). While this provides redundancy, it may inflate event counts. Consider whether both are needed or if server-side could be primary source of truth. [LOW]
• Missing engagement metrics: No tracking for page views of specific pages (e.g., about page), time spent on page, or todo edit interactions. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, delete todos)
• Events can build insights: task completion rate, creation funnel, deletion patterns
• Properties enriched with todo_id, has_description, completed, source
• No PII captured in events
• Error tracking enabled for operation failures

---

Reviewed by wizard workbench PR evaluator