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

[wizard-ci-bot]

Automated wizard CI run

Source: context-mill-pr
Trigger ID: 7f79337
App: next-js/15-app-router-todo
App directory: apps/next-js/15-app-router-todo
Workbench branch: wizard-ci-7f79337-next-js-15-app-router-todo
Wizard branch: main
Context Mill branch: clarify-next-provider
PostHog (MCP) branch: master
Timestamp: 2026-02-12T21:00:49.701Z
Duration: 425.3s

[wizard-ci-bot]

Now I have all the information I need. Let me provide the comprehensive evaluation:

---

PR Evaluation Report

Summary

This PR integrates PostHog analytics into a Next.js 15 App Router todo application. It adds client-side tracking via instrumentation-client.ts, server-side tracking via posthog-node, reverse proxy configuration, and event capture for todo CRUD operations including error tracking.

Files changed	Lines added	Lines removed
10	+502	-2

Confidence score: 3/5 🤔

• Missing user identification: No posthog.identify() calls anywhere in the codebase. Users are tracked as anonymous, making user-level analytics impossible. [MEDIUM]
• No success event tracking on server-side: Server-side only tracks failures (*_failed events) but not successful operations. Client tracks success but server could also track for redundancy/completeness. [LOW]
• defaults option is non-standard: The defaults: '2026-01-30' option in the PostHog init is not a documented PostHog configuration option and may be ignored or cause issues. [MEDIUM]
• No page view tracking configured: While capture_exceptions is enabled, there's no capture_pageview configuration. The default behavior may or may not capture pageviews depending on PostHog version. [LOW]

---

File changes

Filename	Score	Description
instrumentation-client.ts	3/5	New file for PostHog client init. Uses modern Next.js 15.3+ approach but has non-standard defaults option.
lib/posthog-server.ts	4/5	Clean server-side PostHog singleton pattern with proper shutdown function.
next.config.ts	5/5	Correct reverse proxy configuration for PostHog with proper asset and API routing.
components/todos/todo-list.tsx	4/5	Good event tracking for CRUD operations with captureException for errors.
app/api/todos/route.ts	4/5	Server-side error tracking added. Only tracks failures, not successes.
app/api/todos/[id]/route.ts	4/5	Server-side error tracking for update/delete. Only tracks failures.
package.json	5/5	Correctly adds posthog-js and posthog-node dependencies.
.gitignore	5/5	Correctly adds .env.local to ignore list (though already covered by .env*.local).
pnpm-lock.yaml	5/5	Lock file updated with PostHog dependencies.
posthog-setup-report.md	4/5	Good documentation of the integration, though claims .env.local was modified but it's not in the PR diff (created locally).

---

App sanity check: 4/5 ✅

Criteria	Result	Description
App builds and runs	Yes	Build succeeds with npm run build producing optimized production build
Preserves existing env vars & configs	Yes	Existing Next.js config enhanced, no existing functionality removed
No syntax or type errors	Yes	TypeScript compiles successfully, no type errors
Correct imports/exports	Yes	All imports resolve correctly, posthog-js and posthog-node imported properly
Minimal, focused changes	Yes	Changes are focused on PostHog integration only

Issues

• Duplicate .gitignore entry: .env.local is added but .env*.local already covers it. Minor redundancy. [LOW]
• Environment variables not documented in repo: .env.local is gitignored and not committed, but no .env.example file exists to document required variables (NEXT_PUBLIC_POSTHOG_KEY, NEXT_PUBLIC_POSTHOG_HOST). [MEDIUM]

Other completed criteria

• Clear, readable code with appropriate comments
• Consistent with existing patterns in the codebase
• Error handling present in all modified files
• Build configuration is valid

---

PostHog implementation: 3/5 ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.347.0 and posthog-node@^5.24.15 in package.json
PostHog client initialized	Yes	Client init in instrumentation-client.ts, server singleton in lib/posthog-server.ts
capture()	Yes	Client-side capture for todo_created, todo_completed, todo_uncompleted, todo_deleted; Server-side for *_failed events
identify()	No	No user identification anywhere - all users tracked as anonymous
Error tracking	Yes	capture_exceptions: true enabled plus manual captureException() calls
Reverse proxy	Yes	Properly configured in next.config.ts with /ingest rewrites to PostHog endpoints

Issues

• No posthog.identify() implementation: The integration lacks user identification entirely. Users cannot be distinguished or tracked across sessions. For a todo app, even a simple anonymous ID persistence or user-based identification should be implemented. [MEDIUM]
• Non-standard defaults option: defaults: '2026-01-30' in init config is not a valid PostHog option. This appears to be an error or misunderstanding. Should be removed or corrected. [MEDIUM]
• Server-side uses client env var: posthog-server.ts uses NEXT_PUBLIC_POSTHOG_KEY but server-side should use a non-public key (e.g., POSTHOG_API_KEY). While this works, it exposes the key unnecessarily. [LOW]
• No pageview tracking explicitly configured: capture_pageview is not set. Default behavior may vary. [LOW]

Other completed criteria

• API host correctly configured to use reverse proxy (/ingest)
• UI host correctly set to https://us.posthog.com
• Debug mode enabled in development only
• Server-side client has proper flush configuration for serverless
• Shutdown function available for cleanup

---

PostHog insights and events: 4/5 ✅

Filename	PostHog events	Description
components/todos/todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted, captureException	Core user actions tracked with todo_id property. has_description property on create. Client-side exceptions captured.
app/api/todos/route.ts	todo_create_failed	Server-side validation and error tracking with error_type and error_details/error_message properties
app/api/todos/[id]/route.ts	todo_update_failed, todo_delete_failed	Server-side error tracking for update/delete operations

Issues

• Success events not tracked server-side: Only failures are tracked on the server. A todo_created_server, todo_updated_server, todo_deleted_server could provide server-side confirmation and correlation. [LOW]
• Missing properties on some events: todo_completed/todo_uncompleted only include todo_id but could include todo_title_length or time_since_creation for richer analysis. [LOW]

Other completed criteria

• Events represent real user actions (create, complete, delete todos)
• Events capture meaningful product flows (todo lifecycle)
• Error events differentiate between validation and server errors
• Properties include relevant context (error_type, error_details, todo_id)
• No PII in event properties

---

Reviewed by wizard workbench PR evaluator