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

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: b3fa00a
App: next-js/15-app-router-todo
App directory: apps/next-js/15-app-router-todo
Workbench branch: wizard-ci-b3fa00a-next-js-15-app-router-todo
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-03-24T16:51:40.928Z
Duration: 292.4s

[wizard-ci-bot]

Now I have all the context I need. Let me produce the full evaluation report.

---

PR Evaluation Report

Summary

This PR integrates PostHog into a Next.js 15 App Router Todo application. It adds both client-side (posthog-js) and server-side (posthog-node) SDKs, initializes PostHog via instrumentation-client.ts, configures a reverse proxy through Next.js rewrites, captures meaningful CRUD events on both client and server, and includes error tracking via captureException. No identify() call is present anywhere in the codebase.

Files changed	Lines added	Lines removed
9	+138	-0

Confidence score: 4/5 👍

• Missing identify() call: No posthog.identify() is called anywhere. This is a todo app without authentication, so there's no real user to identify — but the framework rules state identify should be called. Given the app has no auth system, this is a lower-severity gap. [MEDIUM]
• No .env.example file: The .env.local file is gitignored (good), but no .env.example or equivalent documentation of the required environment variables exists for other developers to know what to set. The setup report mentions them, but it's not a standard mechanism. [MEDIUM]
• Missing await posthog.shutdown() in API routes: The server-side PostHog client uses flushAt: 1 and flushInterval: 0 which helps, but the API routes never call await posthog.shutdown() after capturing events. In serverless environments, this could lead to events being lost if the function terminates before the flush completes. [MEDIUM]

---

File changes

Filename	Score	Description
instrumentation-client.ts	5/5	Correct Next.js 15.3+ pattern for client-side PostHog init with reverse proxy, error tracking, and defaults
lib/posthog-server.ts	4/5	Singleton server-side PostHog client with immediate flushing; uses correct env vars
next.config.ts	5/5	Reverse proxy rewrites for /ingest and /ingest/static pointing to PostHog US endpoints
components/todos/todo-list.tsx	4/5	Client-side capture calls and exception tracking in event handlers; passes distinct/session IDs to API
app/api/todos/route.ts	4/5	Server-side todo_created_api capture with session correlation; missing shutdown()
app/api/todos/[id]/route.ts	4/5	Server-side todo_updated_api and todo_deleted_api captures; missing shutdown()
package.json	5/5	Both posthog-js and posthog-node added to dependencies
.gitignore	5/5	Added .env.local to gitignore to prevent secret leakage
posthog-setup-report.md	5/5	Comprehensive report documenting all changes and suggested insights

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors, valid TypeScript, correct dependencies added
Preserves existing env vars & configs	Yes	Existing next.config.ts structure preserved; only PostHog additions made
No syntax or type errors	Yes	All TypeScript syntax is valid; types are correct
Correct imports/exports	Yes	posthog-js imported client-side, posthog-node imported server-side — correct separation
Minimal, focused changes	Yes	All changes relate solely to PostHog integration
Pre-existing issues	None	Base app appears clean

Issues

• No .env.example for required variables: The .env.local is gitignored but no .env.example or equivalent template documents the required NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN and NEXT_PUBLIC_POSTHOG_HOST variables. Other developers cloning the repo won't know what to set. [MEDIUM]

Other completed criteria

• Build configuration is valid — package.json scripts unchanged, dependencies correctly added
• No unrelated modifications — all changes are PostHog-specific
• Code follows existing patterns — naming conventions, file structure, indentation match the codebase

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.363.4 and posthog-node@^5.28.5 added to package.json
PostHog client initialized	Yes	Client initialized in instrumentation-client.ts using the recommended Next.js 15.3+ pattern; server client initialized via singleton in lib/posthog-server.ts with flushAt: 1 / flushInterval: 0
capture()	Yes	Client-side: todo_created, todo_completed, todo_uncompleted, todo_deleted. Server-side: todo_created_api, todo_updated_api, todo_deleted_api
identify()	No	No posthog.identify() call anywhere in the codebase. The app has no authentication, but no identify is implemented even as a placeholder pattern
Error tracking	Yes	capture_exceptions: true in init config + explicit posthog.captureException(error) calls in catch blocks
Reverse proxy	Yes	Next.js rewrites configured in next.config.ts routing /ingest/* to PostHog US endpoints; api_host set to /ingest

Issues

• No identify() call: There is no posthog.identify() anywhere. The app lacks authentication, so there's no natural user ID source. However, the framework rules state identify should be called on login/page refresh for authenticated users. Since no auth exists, this is contextually understandable but still a gap in the integration. [MEDIUM]
• Missing await posthog.shutdown() in API routes: Server-side API routes capture events but never call await posthog.shutdown(). The PostHog Next.js docs explicitly recommend calling await posthog.shutdown() after sending server-side events. While flushAt: 1 helps mitigate this (events are queued to send after each capture), the lack of shutdown() means there's no guarantee the HTTP request completes before the serverless function terminates. [MEDIUM]

Other completed criteria

• API key loaded from NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN environment variable — not hardcoded (the .env.local value is gitignored)
• Host correctly configured — client uses /ingest (reverse proxy), server uses NEXT_PUBLIC_POSTHOG_HOST (https://us.i.posthog.com)
• ui_host set to https://us.posthog.com for toolbar/survey access through the proxy
• defaults: '2026-01-30' configuration set per PostHog docs
• Client/server event correlation implemented via x-posthog-distinct-id and x-posthog-session-id custom headers

---

PostHog insights and events ✅

Filename	PostHog events	Description
components/todos/todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted, captureException	Client-side CRUD events with todo_id properties; exception tracking in all catch blocks
app/api/todos/route.ts	todo_created_api	Server-side capture on successful todo creation with todo_id, has_description, and ``
app/api/todos/[id]/route.ts	todo_updated_api, todo_deleted_api	Server-side capture on successful update/delete with todo_id, completed status, and ``

Issues

• No critical or medium issues with event quality

Other completed criteria

• Events represent real user actions — create, complete, uncomplete, delete map to actual todo app workflows
• Events enable product insights — can build creation trends, completion funnels (todo_created → todo_completed), deletion rates
• Events include relevant properties — todo_id, has_description, completed status provide useful context
• No PII in event properties — only todo IDs and boolean flags
• Event names are descriptive and consistent — snake_case convention, clear action names
• Client/server event pairs enable correlated analysis

---

Reviewed by wizard workbench PR evaluator