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

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: 362fa9c
App: next-js/15-app-router-todo
App directory: apps/next-js/15-app-router-todo
Workbench branch: wizard-ci-362fa9c-next-js-15-app-router-todo
Wizard branch: main
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-02-11T17:35:01.276Z
Duration: 441.9s

[wizard-ci-bot]

Now I have a comprehensive view of the PR. Let me generate the evaluation report:

---

PR Evaluation Report

Summary

This PR adds PostHog analytics integration to a Next.js 15 App Router todo application. It implements client-side tracking via instrumentation-client.ts, server-side tracking for API routes, and a reverse proxy configuration to circumvent ad blockers. The integration captures CRUD operations for todos on both client and server sides.

Files changed	Lines added	Lines removed
10	+508	-2

Confidence score: 3/5 🤔

• No user identification implemented: All server-side events use hardcoded distinctId: 'server', making it impossible to link user actions across sessions or correlate client/server events to the same user. [CRITICAL]
• Server-side PostHog client not flushed: Events captured in API routes may be lost on serverless environments because posthog.capture() is async and no await posthog.flush() is called before responses are sent. [CRITICAL]
• Missing identify() calls: No posthog.identify() on the client-side to establish user identity for analytics cohesion. [MEDIUM]

---

File changes

Filename	Score	Description
instrumentation-client.ts	4/5	Correct client-side PostHog initialization using Next.js 15.3+ pattern with capture_exceptions enabled, reverse proxy via /ingest, and debug mode in development
lib/posthog-server.ts	3/5	Singleton pattern for server-side PostHog client, but uses NEXT_PUBLIC_POSTHOG_KEY (intended for client) instead of a server-specific key, and flushAt: 1 / flushInterval: 0 configuration without explicit flush calls
next.config.ts	5/5	Properly configured reverse proxy rewrites for PostHog ingestion to bypass ad blockers, with skipTrailingSlashRedirect enabled
components/todos/todo-list.tsx	4/5	Good client-side event tracking for CRUD operations with relevant properties; missing error tracking for toggle/delete failures
app/api/todos/route.ts	3/5	Server-side event tracking added but uses hardcoded distinctId: 'server' and doesn't flush before returning responses
app/api/todos/[id]/route.ts	3/5	Server-side event tracking for update/delete operations; same issues as above with distinctId and flushing
package.json	5/5	Correctly added posthog-js and posthog-node dependencies
pnpm-lock.yaml	5/5	Lockfile properly updated with PostHog dependencies
.gitignore	5/5	Correctly added .env.local to prevent committing secrets
posthog-setup-report.md	4/5	Comprehensive documentation of the integration with event summary and next steps

---

App sanity check: 4/5 ✅

Criteria	Result	Description
App builds and runs	Yes	Build completes successfully with no errors
Preserves existing env vars & configs	Yes	Original app functionality maintained, only PostHog additions
No syntax or type errors	Yes	TypeScript compilation passes
Correct imports/exports	Yes	All imports resolve correctly
Minimal, focused changes	Yes	Changes are scoped to PostHog integration only

Issues

• .env.local not committed but exists locally: The .env.local file exists with NEXT_PUBLIC_POSTHOG_KEY=sTMFPsFhdP1Ssg but is correctly gitignored. However, this appears to be a test/placeholder key rather than a real one. Should add an .env.example file documenting required variables. [LOW]

Other completed criteria

• Clear, readable code following existing patterns
• Appropriate error handling preserved
• Build configuration is valid
• Environment variables are used (not hardcoded keys)

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.345.5 and posthog-node@^5.24.15 added to dependencies
PostHog client initialized	Yes	Client-side via instrumentation-client.ts, server-side via singleton in lib/posthog-server.ts
capture()	Yes	Multiple capture calls for todo CRUD operations on both client and server
identify()	No	No posthog.identify() calls anywhere in the codebase
Error tracking	Partial	capture_exceptions: true enabled on client; manual error event captures but no captureException()
Reverse proxy	Yes	Properly configured rewrites to /ingest endpoint

Issues

• No user identification: Server-side events all use distinctId: 'server' which prevents user-level analytics. Client-side events will use anonymous IDs but are never linked to authenticated users. This makes funnel analysis and user behavior tracking impossible. [CRITICAL]
• Server-side events may be lost: In serverless environments, the PostHog client's async capture calls need to be flushed before the response is sent. The flushAt: 1 and flushInterval: 0 settings suggest immediate flush, but without await posthog.flush() or await posthog.shutdown(), events may be dropped. [CRITICAL]
• Using NEXT_PUBLIC key for server: The server client uses NEXT_PUBLIC_POSTHOG_KEY which is the same as the client key. While this works, best practice is to use a separate server-side API key. [LOW]
• Page view tracking not explicitly configured: The instrumentation-client.ts doesn't set capture_pageview: true (though this may be default behavior). [LOW]

Other completed criteria

• API key loaded from environment variable
• Correct API host configuration for reverse proxy
• ui_host properly set for US region
• Debug mode enabled only in development
• defaults: '2025-05-24' for latest SDK defaults
• skipTrailingSlashRedirect enabled for PostHog compatibility

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
components/todos/todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted, todo_create_failed	Client-side tracking for all user-facing todo interactions with relevant properties (todo_id, has_description)
app/api/todos/route.ts	api_todo_created, api_todo_create_error	Server-side tracking for todo creation with validation and server error differentiation
app/api/todos/[id]/route.ts	api_todo_updated, api_todo_deleted, api_todo_not_found	Server-side tracking for todo modifications with operation context
instrumentation-client.ts	capturedException (automatic)	Automatic exception capture enabled via capture_exceptions: true

Issues

• Duplicate events for same action: Both client and server capture events for the same user actions (e.g., todo_created and api_todo_created). While this provides redundancy, it may inflate metrics and complicate analysis if not properly filtered. Consider choosing one source of truth. [MEDIUM]
• Missing error tracking for toggle/delete failures: Client-side handleToggleTodo and handleDeleteTodo catch errors but don't capture PostHog events for failures. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, delete todos)
• Events enriched with relevant properties (todo_id, has_description, updated_fields)
• Error events capture error types and details
• Events can be used for funnel analysis (created → completed)
• API activity monitoring for backend observability

---

Reviewed by wizard workbench PR evaluator