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

[wizard-ci-bot]

Automated wizard CI run

Source: scheduled
Trigger ID: 6fb03e7
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-6fb03e7-next-js-15-pages-router-todo
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-05-13T17:26:47.400Z
Duration: 355.8s

[wizard-ci-bot]

Now I have all the context needed. Let me produce the evaluation.

---

PR Evaluation Report

Summary

This PR integrates PostHog into a Next.js 15 Pages Router todo app. It adds client-side initialization via instrumentation-client.ts, a reverse proxy via Next.js rewrites, server-side tracking with posthog-node, custom event captures for CRUD operations, and exception tracking with captureException.

Files changed	Lines added	Lines removed
9	+132	-0

Confidence score: 4/5 👍

• No user identification implemented: There is no posthog.identify() call anywhere in the codebase, and no posthog.reset() on logout. The docs state "Identifying users is required." Even if the app has no auth, this is a gap in the integration. [MEDIUM]
• Environment variables not documented for other developers: The .env.local is gitignored (correctly), but no .env.example or equivalent is committed to document NEXT_PUBLIC_POSTHOG_KEY and NEXT_PUBLIC_POSTHOG_HOST. New developers won't know which env vars are needed. [MEDIUM]
• Server-side PostHog client never calls shutdown(): In both API routes (pages/api/todos/index.ts and pages/api/todos/[id].ts), getPostHogClient() is called and capture() is invoked, but shutdown() is never called. The docs explicitly warn: "Make sure to always call await client.shutdown() after sending events from the server-side." Events may be lost in serverless environments. [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, exception capture, and debug mode
next.config.ts	5/5	Proper reverse proxy rewrites for /ingest/static/*, /ingest/array/*, and /ingest/* with correct asset origins
lib/posthog-server.ts	4/5	Singleton server-side client with proper flushAt/flushInterval settings; exported shutdownPostHog is never used
components/todos/todo-list.tsx	4/5	Good event captures in event handlers (not useEffect); exception tracking in catch blocks
pages/api/todos/index.ts	3/5	Server-side todo_created capture; missing shutdown() call
pages/api/todos/[id].ts	3/5	Server-side todo_deleted capture; missing shutdown() call
package.json	5/5	Both posthog-js and posthog-node correctly added
.gitignore	5/5	Correctly ignores .env.local
posthog-setup-report.md	N/A	Documentation/report file

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors; valid TypeScript, correct imports
Preserves existing env vars & configs	Yes	Only adds PostHog-related config; existing nextConfig preserved
No syntax or type errors	Yes	All code is syntactically valid
Correct imports/exports	Yes	posthog-js imported client-side, posthog-node server-side — correct separation
Minimal, focused changes	Yes	All changes relate to PostHog integration
Pre-existing issues	None	Base app appears clean

Issues

• Environment variables not documented: .env.local is gitignored and no .env.example is committed. Developers cloning the repo won't know to set NEXT_PUBLIC_POSTHOG_KEY and NEXT_PUBLIC_POSTHOG_HOST. [MEDIUM]

Other completed criteria

• Build configuration is valid — package.json scripts are standard Next.js
• All imports resolve to correct packages
• No unrelated modifications or reformatting

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.373.4 and posthog-node@^5.34.1 added to package.json
PostHog client initialized	Yes	instrumentation-client.ts uses the recommended Next.js 15.3+ pattern with posthog.init()
capture()	Yes	4 client-side captures (todo_created, todo_completed, todo_uncompleted, todo_deleted) + 2 server-side captures
identify()	No	No posthog.identify() or posthog.reset() calls anywhere. This is a full-stack app where user identification should be implemented
Error tracking	Yes	capture_exceptions: true in init config + manual posthog.captureException(error) in 3 catch blocks
Reverse proxy	Yes	Properly configured via Next.js rewrites: /ingest/static/* and /ingest/array/* → us-assets.i.posthog.com, /ingest/* → us.i.posthog.com

Issues

• No identify() implementation: No posthog.identify() call exists. Even though the todo app may lack authentication, the integration is incomplete without user identification. At minimum, a comment or stub should indicate where to add it. [MEDIUM]
• Server-side shutdown() never called: The shutdownPostHog() helper exists in posthog-server.ts but is never invoked in the API routes. In serverless/edge environments, events may be dropped because the queue isn't flushed before the function terminates. [MEDIUM]
• API key loaded from env var: Uses process.env.NEXT_PUBLIC_POSTHOG_KEY! — correct pattern with non-null assertion. Host is also from env var on the server side. [OK]

Other completed criteria

• API host correctly configured via reverse proxy (/ingest) on client and direct host on server
• defaults: '2026-01-30' correctly set in init
• skipTrailingSlashRedirect: true set in next.config.ts for reverse proxy compatibility
• Server-side client uses singleton pattern appropriate for Pages Router API routes
• Session ID correlation via X-POSTHOG-SESSION-ID header on server-side captures

---

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 properties (todo_id, has_description); exception tracking in catch blocks
pages/api/todos/index.ts	todo_created	Server-side creation event with todo_id, has_description, ``
pages/api/todos/[id].ts	todo_deleted	Server-side deletion event with todo_id, ``

Issues

• No issues with event quality — events are well-named, represent real user actions, and include relevant properties without PII.

Other completed criteria

• Events represent real user actions (create, complete, uncomplete, delete todos)
• Events enable product insights — can build creation trends, completion funnels, deletion rate analysis
• Events include relevant properties (todo_id, has_description) for filtering and breakdown
• No PII in event properties
• Consistent snake_case naming convention
• Both client-side and server-side events for key actions provides redundancy

---

Reviewed by wizard workbench PR evaluator