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

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: 362fa9c
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-362fa9c-next-js-15-pages-router-todo
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-02-11T17:35:31.319Z
Duration: 404.8s

[wizard-ci-bot]

Now I have all the information I need to write my evaluation. Let me compile the PR Evaluation Report:

---

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) SDKs, implements event tracking for todo CRUD operations, configures a reverse proxy to bypass ad blockers, and sets up exception capture.

Files changed	Lines added	Lines removed
10	+494	-4

Confidence score: 4/5 👍

• Server-side events lack client correlation: Server-side tracking expects x-posthog-distinct-id header but client never sends it, causing all server events to use 'anonymous' as distinctId. [MEDIUM]
• Server-side host configuration mismatch: posthog-server.ts uses NEXT_PUBLIC_POSTHOG_HOST env var but this is not set anywhere (only NEXT_PUBLIC_POSTHOG_KEY is referenced), and should use the same /ingest proxy path or direct https://us.i.posthog.com. [MEDIUM]
• No user identification implemented: posthog.identify() is not called anywhere, which limits user tracking across sessions. This is acceptable for an anonymous app but noted. [LOW]

---

File changes

Filename	Score	Description
.gitignore	5/5	Properly ignores .env.local to prevent secrets from being committed
components/todos/todo-list.tsx	4/5	Adds client-side event tracking for todo operations with proper error capturing via captureException()
instrumentation-client.ts	4/5	Correct client-side PostHog initialization using Next.js 15.3+ convention file with proper config options
lib/posthog-server.ts	3/5	Server-side singleton pattern is correct but uses NEXT_PUBLIC_POSTHOG_HOST which may not be set
next.config.ts	5/5	Properly configured reverse proxy rewrites to circumvent ad blockers with correct PostHog endpoints
package.json	5/5	Both posthog-js and posthog-node SDKs added with appropriate versions
pages/api/todos/[id].ts	3/5	Server-side tracking added but distinctId correlation won't work without client sending header
pages/api/todos/index.ts	3/5	Same issue - server-side tracking lacks proper user correlation
pnpm-lock.yaml	5/5	Lock file properly updated with all PostHog dependencies
posthog-setup-report.md	4/5	Good documentation of integration, though claims .env.local created but it's not committed

---

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 config preserved, new rewrites added properly
No syntax or type errors	Yes	TypeScript compilation passes
Correct imports/exports	Yes	All imports are valid and follow existing patterns
Minimal, focused changes	Yes	Changes are focused on PostHog integration only

Issues

• Environment variable documentation incomplete: The .env.local file is referenced but not committed (correctly gitignored). However, there's no .env.example or clear documentation of required variables (NEXT_PUBLIC_POSTHOG_KEY, NEXT_PUBLIC_POSTHOG_HOST). [LOW]

Other completed criteria

• Handler functions correctly changed from sync to async
• Error handling preserved and enhanced with PostHog exception capture
• Existing Zod validation logic maintained
• Code style consistent with existing codebase

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.345.5 and posthog-node@^5.24.15 added to dependencies
PostHog client initialized	Yes	Client initialized via instrumentation-client.ts convention file with api_host: '/ingest', capture_exceptions: true, and defaults: '2025-05-24'
capture()	Yes	Multiple capture calls for todo_created, todo_completed, todo_uncompleted, todo_deleted on client; server events for _server variants
identify()	No	No user identification implemented - all users are anonymous
Error tracking	Yes	posthog.captureException(error) called in all catch blocks, capture_exceptions: true enabled in config
Reverse proxy	Yes	Properly configured in next.config.ts with rewrites to us.i.posthog.com and us-assets.i.posthog.com

Issues

• Server-side distinctId correlation broken: Server-side events expect x-posthog-distinct-id header from client requests, but the client-side fetch calls never include this header. All server events will have distinctId: 'anonymous', defeating the purpose of server-side tracking correlation. [CRITICAL]
• Server-side host configuration: posthog-server.ts uses process.env.NEXT_PUBLIC_POSTHOG_HOST but this should likely be https://us.i.posthog.com directly or undefined (which defaults correctly). If NEXT_PUBLIC_POSTHOG_HOST is undefined, PostHog will use default API host which is incorrect for US region. [MEDIUM]
• Missing pageview tracking verification: While instrumentation-client.ts initializes PostHog, there's no explicit pageview tracking setup. The defaults: '2025-05-24' should enable automatic pageviews, but this should be verified. [LOW]

Other completed criteria

• API key properly loaded from environment variable via process.env.NEXT_PUBLIC_POSTHOG_KEY!
• Debug mode correctly enabled only in development
• flushAt: 1 and flushInterval: 0 configured for immediate event sending in server context
• skipTrailingSlashRedirect: true correctly added for PostHog API compatibility
• ui_host correctly set to https://us.posthog.com for session replay

---

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 core todo actions with properties like todo_id and has_description. Captures exceptions for error monitoring.
pages/api/todos/index.ts	todo_created_server	Server-side event for todo creation with todo_id, has_description, and source: 'api' properties
pages/api/todos/[id].ts	todo_updated_server, todo_deleted_server	Server-side events for updates and deletes with todo_id, completed status, and source: 'api'

Issues

• Duplicate client/server events without correlation: Both client and server track the same actions separately. Without proper distinctId correlation, this creates duplicate events that can't be linked to the same user action. [MEDIUM]
• Limited event properties: Events could include more contextual properties like title_length, todo_count (before/after), or timing information. [LOW]

Other completed criteria

• Events capture meaningful user actions (create, complete, uncomplete, delete)
• Boolean properties properly tracked (has_description, completed)
• Numeric IDs included for drill-down analysis
• Server events distinguish source as 'api' for multi-channel tracking potential
• Exception capture enables error rate monitoring and debugging

---

Reviewed by wizard workbench PR evaluator