[CI] (gpt5-trial-2) next-js/15-app-router-todo

[wizard-ci-bot]

Automated wizard CI run

Source: manual
Trigger ID: gpt5-trial-2
App: next-js/15-app-router-todo
App directory: apps/next-js/15-app-router-todo
Workbench branch: wizard-ci-gpt5-trial-2-next-js-15-app-router-todo
Wizard branch: 1eb16c89a1ac295f0887a96381fff7314e999b05
Context Mill branch: main
PostHog (MCP) branch: master
Timestamp: 2026-07-03T16:21:00.299Z
Duration: 420.7s

YARA Scanner

✓ 44 tool calls scanned, 0 violations detected

No violations: ✓ 44 clean scans

[wizard-ci-bot]

PR Evaluation Report

Summary

This PR integrates PostHog into a Next.js 15 App Router todo application. It adds client-side initialization via instrumentation-client.ts, server-side tracking via posthog-node singleton, a reverse proxy through Next.js rewrites, and captures events for todo CRUD operations on both client and server sides. User identification is missing entirely.

Files changed	Lines added	Lines removed
8	+166	-2

Confidence score: 4/5 👍

• No identify() call anywhere: The integration never calls posthog.identify(). There is no user identification on login or page load, meaning all events are anonymous. PostHog docs state "Identifying users is required." [CRITICAL]
• Environment variables not documented: NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN and NEXT_PUBLIC_POSTHOG_HOST are referenced but no .env.example or equivalent is updated. [MEDIUM]
• Fallback distinct_id of 'server': Server-side routes fall back to 'server' as distinctId when the header is missing, which collapses all unidentified server events onto a single fake user, causing fragmented/misleading data. [MEDIUM]

---

File changes

Filename	Score	Description
instrumentation-client.ts	4/5	Correct Next.js 15 client init pattern via instrumentation-client.ts, uses env var, configures reverse proxy host, enables error tracking
lib/posthog-server.ts	4/5	Proper singleton pattern with flushAt: 1 / flushInterval: 0 for serverless; missing shutdown() calls in routes but flush settings mitigate this
next.config.ts	5/5	Correct reverse proxy with /ingest/static/* and /ingest/array/* routing to assets origin, and catch-all to API origin
package.json	5/5	Both posthog-js and posthog-node added with reasonable versions
components/todos/todo-list.tsx	3/5	Good client-side event captures in event handlers; passes X-POSTHOG-DISTINCT-ID header to server. However, direct import of posthog works with instrumentation-client pattern
app/api/todos/route.ts	3/5	Server-side captures for create/list/validation; api_todos_listed is noisy (fires on every GET)
app/api/todos/[id]/route.ts	4/5	Server-side captures for update/delete/validation with relevant properties
posthog-setup-report.md	N/A	Wizard report, not production code

---

App sanity check ⚠️

Criteria	Result	Description
App builds and runs	Yes	No syntax errors, valid TypeScript, proper imports
Preserves existing env vars & configs	Yes	Only adds PostHog-related config; existing next.config comment removed but harmless
No syntax or type errors	Yes	All code is syntactically valid; optional chaining used appropriately
Correct imports/exports	Yes	posthog-js on client, posthog-node on server, correct separation
Minimal, focused changes	Yes	All changes are PostHog-related
Pre-existing issues	None	Base app appears clean

Issues

• Environment variables not documented: NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN and NEXT_PUBLIC_POSTHOG_HOST are used but no .env.example or README is updated to document them. Collaborators won't know what to set. [MEDIUM]

Other completed criteria

• Build configuration is valid — next.config.ts exports proper NextConfig with rewrites
• All changes are relevant to PostHog integration
• Code follows existing codebase patterns (TypeScript, async/await, error handling structure)

---

PostHog implementation ⚠️

Criteria	Result	Description
PostHog SDKs installed	Yes	posthog-js@^1.396.6 and posthog-node@^5.39.4 in package.json
PostHog client initialized	Yes	Client via instrumentation-client.ts with env var token, reverse proxy host, and capture_exceptions: true. Server via singleton in lib/posthog-server.ts with flushAt: 1
capture()	Yes	4 client-side captures (todo_created, todo_completed, todo_uncompleted, todo_deleted) and 5 server-side captures
identify()	No	No posthog.identify() call anywhere — not on login, not on page load, not in any component. All events are anonymous
Error tracking	Yes	capture_exceptions: true in init config enables exception autocapture; api_validation_error events capture server-side validation failures
Reverse proxy	Yes	Correctly configured in next.config.ts with /ingest/static/* and /ingest/array/* → us-assets.i.posthog.com, catch-all → us.i.posthog.com, plus skipTrailingSlashRedirect: true

Issues

• No user identification: posthog.identify() is never called. The PostHog docs explicitly state this is required for linking frontend captures, session replays, and error tracking to known users. Without it, all data is anonymous and cannot be associated with user profiles. [CRITICAL]
• Fabricated 'server' fallback distinct_id: When x-posthog-distinct-id header is missing, server routes use 'server' as the distinct_id. This creates a single fake "user" that accumulates all unidentified server events, producing misleading analytics. Should use a request-scoped identifier or skip the capture. [MEDIUM]

Other completed criteria

• API key loaded from process.env.NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN environment variable, not hardcoded
• API host correctly configured — client points to /ingest (reverse proxy), server uses NEXT_PUBLIC_POSTHOG_HOST
• posthog.reset() not present but acceptable since there's no auth/logout flow in the todo app

---

PostHog insights and events ⚠️

Filename	PostHog events	Description
components/todos/todo-list.tsx	todo_created, todo_completed, todo_uncompleted, todo_deleted	Client-side user action tracking with properties like todo_id, has_description, title_length
app/api/todos/route.ts	api_todos_listed, api_todo_created, api_validation_error	Server-side tracking of list/create operations and validation failures
app/api/todos/[id]/route.ts	api_todo_updated, api_todo_deleted, api_validation_error	Server-side tracking of update/delete operations and validation failures
instrumentation-client.ts	captureException (via capture_exceptions: true)	Automatic exception autocapture for unhandled errors

Issues

• Duplicate client+server events: Both client and server capture the same actions (e.g., todo_created on client AND api_todo_created on server). While not necessarily wrong, this creates double-counting unless carefully filtered. Consider whether both layers need to capture. [LOW]
• api_todos_listed is noisy: Fires on every GET /api/todos request (page load, refresh, etc.). This is not a deliberate user action and will generate high event volume with low analytical value. [LOW]

Other completed criteria

• Events use descriptive snake_case naming convention consistently
• Event properties are enriched with contextual data (todo_id, has_description, title_length, count, errors)
• No PII in event properties — no emails, names, or personal data in capture() calls
• Events enable product insights — can build a create → complete → delete funnel from client events

---

Reviewed by wizard workbench PR evaluator