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

[wizard-ci-bot]

Automated wizard CI run

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

[wizard-ci-bot]

---

PR Evaluation Report

Summary

This PR integrates PostHog into a Next.js 15 App Router todo application. It adds client-side initialization via instrumentation-client.ts, a server-side singleton client, a reverse proxy via Next.js rewrites, and event captures for todo CRUD operations on both client and server. However, it is missing user identification entirely, and all server-side events use a hardcoded distinctId: 'server', which makes server events unattributable to real users.

Files changed	Lines added	Lines removed
9	+135	-0

Confidence score: 4/5 👍

• No identify() call anywhere: The app has no posthog.identify() implementation. Users are never linked to their events, making person-level analytics impossible. [CRITICAL]
• Hardcoded distinctId: 'server' on all server-side captures: All server events are attributed to a single fake user 'server', making them useless for per-user analytics. The server should extract a real user/session identifier from the request context. [CRITICAL]
• No await posthog.shutdown() in API routes: The Next.js docs explicitly recommend calling await posthog.shutdown() in server-side handlers to ensure events are flushed before the response completes. Without it, events may be silently dropped. [MEDIUM]
• No .env.example file: The required environment variables (NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN, NEXT_PUBLIC_POSTHOG_HOST) are not documented anywhere for other developers. [MEDIUM]

---

File changes

Filename	Score	Description
instrumentation-client.ts	4/5	Correct Next.js 15.3+ initialization pattern with reverse proxy, exception capture, and debug mode
next.config.ts	5/5	Proper reverse proxy rewrites for /ingest/static/*, /ingest/array/*, and /ingest/* with correct asset origin
lib/posthog-server.ts	3/5	Singleton pattern is correct but env var name is inconsistent (uses project token var for both client and server)
components/todos/todo-list.tsx	4/5	Good client-side event captures with properties and exception handling
app/api/todos/route.ts	2/5	Hardcoded distinctId: 'server', no shutdown() call
app/api/todos/[id]/route.ts	2/5	Same issues: hardcoded distinctId: 'server', no shutdown() call
package.json	5/5	Both posthog-js and posthog-node added correctly
.gitignore	5/5	.env.local properly gitignored
posthog-setup-report.md	3/5	Decent report but doesn't mention missing identify setup

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors; all imports resolve correctly
Preserves existing env vars & configs	Yes	Existing next.config.ts structure preserved, only PostHog additions
No syntax or type errors	Yes	TypeScript is valid across all changed files
Correct imports/exports	Yes	posthog-js on client, posthog-node on server — correct separation
Minimal, focused changes	Yes	All changes are PostHog-related
Pre-existing issues	None	Base app appears functional

Issues

• No .env.example file: The required environment variables (NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN, NEXT_PUBLIC_POSTHOG_HOST) are not documented for other developers or CI/CD setup. [MEDIUM]

Other completed criteria

• All changes are PostHog-related with no unrelated modifications
• Correct files modified for Next.js app router pattern
• Code follows existing codebase conventions (TypeScript, consistent formatting)
• Build configuration (package.json) is valid with correct dependency additions

---

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 the recommended Next.js 15.3+ pattern; server singleton in lib/posthog-server.ts
capture()	Yes	Client: todo_created, todo_completed, todo_uncompleted, todo_deleted. Server: todo_created, todo_updated, todo_deleted
identify()	No	No posthog.identify() call anywhere in the codebase. Users are never linked to events.
Error tracking	Yes	capture_exceptions: true in init config + manual posthog.captureException(error) in catch blocks
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() implementation: There is no posthog.identify() call anywhere in the app. The docs state "Identifying users is required" — without it, all client events are anonymous and cannot be linked to specific users. This should be called on login/session load. [CRITICAL]
• Hardcoded distinctId: 'server' on server-side captures: All three server-side posthog.capture() calls use distinctId: 'server', meaning every server event is attributed to one fake "user". This produces meaningless analytics. The server should extract a real user identifier from the request (e.g., session cookie, auth token). [CRITICAL]
• No await posthog.shutdown() in API routes: Per the Next.js PostHog docs, server-side routes should call await posthog.shutdown() to flush queued events. Without this, events may be lost in short-lived serverless functions. [MEDIUM]

Other completed criteria

• API key loaded from environment variable (process.env.NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN)
• Host correctly configured (reverse proxy /ingest for client, env var for server)
• Server-side client uses correct flushAt: 1 and flushInterval: 0 settings
• Reverse proxy routes both /static/* and /array/* to the assets origin

---

PostHog insights and events ⚠️

Filename	PostHog events	Description
components/todos/todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted, captureException	Client-side tracking of all todo CRUD actions with properties (todo_id, has_description); exception capture on API failures
app/api/todos/route.ts	todo_created	Server-side capture when a todo is persisted, includes todo_id and has_description
app/api/todos/[id]/route.ts	todo_updated, todo_deleted	Server-side capture on update (with completed status) and delete

Issues

• Hardcoded distinctId: 'server' prevents product insights: Since all server events use the same fake distinct ID, they cannot be used in funnels, retention charts, or user-level analysis. Server events are effectively useless for product analytics. [CRITICAL]
• Duplicate event names across client and server without differentiation: todo_created and todo_deleted are captured on both client and server with the same event name. While the server events include source: 'api', this could lead to double-counting in insights if not carefully filtered. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, uncomplete, delete todos)
• Events could enable product insights (creation trends, completion funnels) if identify were implemented
• Events include relevant properties (todo_id, has_description, completed status)
• No PII in event properties
• Event names are descriptive and use consistent snake_case convention

---

Reviewed by wizard workbench PR evaluator