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

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: d819646
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-d819646-next-js-15-pages-router-todo
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-05-14T16:35:58.856Z
Duration: 273.4s

[wizard-ci-bot]

Now I have all the information needed. Let me compile the evaluation.

---

PR Evaluation Report

Summary

This PR integrates PostHog into a Next.js 15 Pages Router todo application. It adds client-side initialization via instrumentation-client.ts, server-side event capture via posthog-node in API routes, a reverse proxy through Next.js rewrites, and error tracking via capture_exceptions. Custom events track todo CRUD operations on both client and server.

Files changed	Lines added	Lines removed
9	+145	-0

Confidence score: 4/5 👍

• No user identification: There is no posthog.identify() call anywhere in the app. Users are never linked to a known identity, which means all analytics data is anonymous and cannot be correlated to specific users. [CRITICAL]
• Server-side events always use 'anonymous' distinct_id: The client-side fetch() calls in todo-list.tsx do not include x-posthog-distinct-id or x-posthog-session-id headers, and __add_tracing_headers is not configured in instrumentation-client.ts. Server-side captures will always fall back to 'anonymous', creating a single mega-user. [CRITICAL]
• No .env.example file committed: The .env.local is gitignored (correctly), but no .env.example or equivalent is committed to guide developers on required environment variables. The setup report mentions them, but this is non-standard. [MEDIUM]

---

File changes

Filename	Score	Description
instrumentation-client.ts	4/5	Correct Next.js 15.3+ client init pattern with reverse proxy, error tracking, and debug mode
next.config.ts	5/5	Proper reverse proxy rewrites for /ingest/static/*, /ingest/array/*, and /ingest/* with skipTrailingSlashRedirect
lib/posthog-server.ts	4/5	Singleton server-side client with appropriate flushAt: 1 and flushInterval: 0
components/todos/todo-list.tsx	3/5	Good capture calls in event handlers, but no identify and direct import of posthog rather than through a hook
pages/api/todos/index.ts	2/5	Server-side capture with header-based identity that will always be 'anonymous' since headers are never sent
pages/api/todos/[id].ts	2/5	Same header identity issue; events will all collapse into one 'anonymous' user
package.json	5/5	Both posthog-js and posthog-node added correctly
.gitignore	5/5	Properly ignores .env.local
posthog-setup-report.md	3/5	Good documentation of changes but counts as non-standard env documentation

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors; all imports resolve; dependencies added correctly
Preserves existing env vars & configs	Yes	Only additions to existing configs; no deletions
No syntax or type errors	Yes	TypeScript is valid throughout
Correct imports/exports	Yes	posthog-js used client-side, posthog-node server-side; correct package separation
Minimal, focused changes	Yes	All changes relate strictly to PostHog integration
Pre-existing issues	None	Base app appears well-structured

Issues

• No .env.example committed: The .env.local is gitignored but no .env.example exists to document required variables (NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN, NEXT_PUBLIC_POSTHOG_HOST). The setup report mentions them but is non-standard. [MEDIUM]

Other completed criteria

• Build configuration is valid with proper next.config.ts rewrites
• All imports resolve to correct packages
• No existing functionality broken

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.373.4 and posthog-node@^5.34.1 in package.json
PostHog client initialized	Yes	instrumentation-client.ts uses posthog.init() with env var token, reverse proxy host, defaults, capture_exceptions, and debug mode
capture()	Yes	4 client-side captures (todo_created, todo_completed, todo_uncompleted, todo_deleted) and matching server-side captures
identify()	No	No posthog.identify() call exists anywhere in the app
Error tracking	Yes	capture_exceptions: true set in init config
Reverse proxy	Yes	Next.js rewrites in next.config.ts correctly route /ingest/static/* and /ingest/array/* to us-assets.i.posthog.com and /ingest/* to us.i.posthog.com

Issues

• No identify() call: No posthog.identify() is called anywhere. Users are never linked to known identities, making all analytics anonymous. This should be added at login or page load when the user is authenticated. [CRITICAL]
• Server-side events always anonymous: The server-side API routes read x-posthog-distinct-id and x-posthog-session-id from request headers, but the client-side fetch() calls in todo-list.tsx never send these headers. Additionally, __add_tracing_headers is not configured in posthog.init(). All server-side events will have distinctId: 'anonymous', collapsing all server events into a single user. [CRITICAL]

Other completed criteria

• API key loaded from process.env.NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN (not hardcoded)
• Host correctly configured through reverse proxy (/ingest → us.i.posthog.com)
• Reverse proxy includes both /static/* and /array/* asset routes to us-assets.i.posthog.com
• skipTrailingSlashRedirect: true correctly set for proxy compatibility
• Server-side client uses singleton pattern with flushAt: 1 for immediate flushing

---

PostHog insights and events ⚠️

Filename	PostHog events	Description
components/todos/todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted	Client-side captures in event handlers for all CRUD operations with todo_id and has_description properties
pages/api/todos/index.ts	todo_created	Server-side capture on POST with todo_id, has_description, and session ID
pages/api/todos/[id].ts	todo_completed, todo_uncompleted, todo_deleted	Server-side captures on PATCH/DELETE with todo_id and session ID
instrumentation-client.ts	capturedException (via capture_exceptions: true)	Automatic exception capture for unhandled errors

Issues

• Duplicate client/server events without correlation: The same events (todo_created, todo_completed, etc.) are captured on both client and server. Without tracing headers linking them, this creates duplicate uncorrelated events. Either send tracing headers or remove server-side duplicates. [MEDIUM]

Other completed criteria

• Events represent real user actions (creating, completing, deleting todos)
• Events enable product insights (can build creation trends, completion funnels, deletion rates)
• Events include relevant properties (todo_id, has_description)
• No PII in event properties
• Event names are descriptive and use consistent snake_case convention

---

Reviewed by wizard workbench PR evaluator