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

[wizard-ci-bot]

Automated wizard CI run

Trigger ID: bd496c4
App: next-js/15-pages-router-todo
App directory: apps/next-js/15-pages-router-todo
Workbench branch: wizard-ci-bd496c4-next-js-15-pages-router-todo
Wizard branch: main
Examples branch: rearchitect-generator
PostHog (MCP) branch: master
Timestamp: 2026-01-14T16:16:08.828Z
Duration: 231.6s

[wizard-ci-bot]

Now I have read all the changed files. Let me also verify the build status by checking if there are any obvious issues with the code.

---

PR Evaluation Report

Summary

This PR adds PostHog analytics integration to a Next.js 15 Pages Router todo application. It installs posthog-js, initializes the client via instrumentation-client.ts, configures a reverse proxy for ad-blocker resistance, and adds event tracking for CRUD operations on todos with error capture via captureException().

Files changed	Lines added	Lines removed
6	+451	-2

Confidence score: 3/5 🤔

• Incorrect PostHog initialization approach for Pages Router: Using instrumentation-client.ts is the App Router approach (Next.js 15.3+), but this is a Pages Router app. The _app.tsx file was not modified to import this initialization, meaning PostHog is never initialized at runtime. [CRITICAL]
• Missing page view tracking: No posthog.capture('') calls or router-based page view tracking implemented. For SPAs, this typically requires hooking into Next.js Router events. [MEDIUM]
• Missing posthog.identify() implementation: No user identification is set up, limiting analytics usefulness for understanding individual user behavior. [MEDIUM]

---

File changes

Filename	Score	Description
components/todos/todo-list.tsx	4/5	Added PostHog import and event tracking for CRUD operations with proper error capture. Clean implementation that follows existing code patterns.
instrumentation-client.ts	2/5	New file for PostHog init, but uses App Router pattern (instrumentation-client.ts) for a Pages Router app. This file won't be auto-loaded.
next.config.ts	4/5	Added reverse proxy rewrites for /ingest path and skipTrailingSlashRedirect. Configuration is correct.
package.json	5/5	Added posthog-js dependency correctly.
pnpm-lock.yaml	5/5	Lock file updated with PostHog dependencies and OpenTelemetry peer dependencies.
posthog-setup-report.md	3/5	Documentation created but contains inaccurate claim about .env being added (not in diff).

---

App sanity check: 2/5 ❌

Criteria	Result	Description
App builds and runs	Likely No	The instrumentation-client.ts pattern is for App Router. In Pages Router, this file is not automatically loaded, so PostHog is never initialized.
Preserves existing env vars & configs	Yes	Existing Next.js config extended, not replaced.
No syntax or type errors	Yes	Code is syntactically correct TypeScript.
Correct imports/exports	Yes	All imports are valid and from installed packages.
Minimal, focused changes	Yes	Changes are focused on PostHog integration only.

Issues

• PostHog never initializes in Pages Router: The instrumentation-client.ts file is an App Router feature (Next.js 15.3+ with appDir). For Pages Router, PostHog must be initialized in _app.tsx or a provider component. The current implementation means PostHog is never loaded, and all posthog.capture() calls will fail silently or error. [CRITICAL]
• .env file not in diff but claims to be created: The setup report claims .env was created, but it's not in the PR diff. The .env file exists with a test API key, but committing secrets to version control is poor practice. [MEDIUM]

Other completed criteria

• Code follows existing TypeScript patterns
• No unnecessary modifications to unrelated files
• Error handling preserves existing console.error calls

---

PostHog implementation: 2/5 ❌

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.321.1 added to dependencies
PostHog client initialized	No	instrumentation-client.ts is not loaded in Pages Router apps. Must be imported in _app.tsx.
capture()	Partial	Calls exist but won't work until initialization is fixed
identify()	No	No user identification implemented
Error tracking	Partial	captureException() calls present with capture_exceptions: true config, but won't work until init is fixed
Reverse proxy	Yes	Properly configured in next.config.ts with /ingest rewrites to us.i.posthog.com

Issues

• Initialization never happens: For Pages Router, add import '../instrumentation-client' at the top of _app.tsx, or initialize PostHog directly in _app.tsx using a useEffect with proper SSR guards. [CRITICAL]
• Missing page view tracking: Pages Router requires manual page view tracking via Router events. Should use Router.events.on('routeChangeComplete', ...) pattern. [MEDIUM]
• Missing identify(): No user identification for tying events to users. [MEDIUM]
• No SSR guard in init file: PostHog should check typeof window !== 'undefined' before initializing to prevent SSR errors. [MEDIUM]

Other completed criteria

• Correct API host configuration (/ingest proxy path)
• ui_host properly set to https://us.posthog.com
• capture_exceptions: true enabled
• Debug mode conditional on development environment
• defaults option set for PostHog compatibility

---

PostHog insights and events: 3/5 ⚠️

Filename	PostHog events	Description
todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted	Core CRUD success events with todo_id property. Enables funnel analysis and completion rate tracking.
todo-list.tsx	todo_fetch_failed, todo_create_failed, todo_update_failed, todo_delete_failed	Error events with error message properties. Good for monitoring app health.
todo-list.tsx	captureException	Exception capture on all error paths for Error Tracking feature.

Issues

• Events won't fire until init is fixed: All event tracking is correctly implemented but non-functional due to the initialization issue. [CRITICAL]
• Missing page view events: Cannot track user navigation or engagement patterns. [MEDIUM]
• Limited event properties: Events could include more context like todo_title_length, timestamp, or session context for richer analysis. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, delete todos)
• Events capture friction points (all failure scenarios tracked)
• has_description property on todo_created enables feature usage analysis
• Completion vs uncomplete distinction enables toggle behavior analysis
• Events follow consistent naming convention ({entity}_{action} pattern)

---

Reviewed by wizard workbench PR evaluator