feat: add PostHog environment super property

[JakubAnderwald]

Summary

• Registers an environment super property (production / development) on PostHog init
• All PostHog events are now tagged with the environment, enabling dashboard filtering
• Marks task 1.2 complete in the environment separation plan

Test plan

• Unit + integration tests pass (456 tests)
• E2E tests pass (43 passed, 13 skipped)
• ESLint clean (0 errors)
• TypeScript type check clean

🤖 Generated with Claude Code

Summary by CodeRabbit

• Documentation

  • Updated progress tracking documentation for environment separation.

• New Features

  • Implemented automatic environment detection and tracking for analytics, distinguishing between production and development deployments based on deployment configuration.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
drafto	Ready	Preview, Comment	Mar 4, 2026 9:09pm

[coderabbitai]

📝 Walkthrough

Walkthrough

The pull request registers PostHog with an environment super property during client initialization, setting the value based on NODE_ENV, and updates a progress tracker documentation to mark Phase 1.2 as completed.

Changes

Cohort / File(s)	Summary
PostHog Environment Registration src/lib/posthog/client.ts	Added PostHog environment super property registration immediately after initialization, detecting whether the application is running in production or development mode via NODE_ENV.
Documentation Update docs/Dev-Prod Environment Separation-ralph.md	Updated progress tracker task status to completed for Phase 1.2 (Add PostHog environment super property).

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 In PostHog's realm, we hippity-hop,
Environment flags, they never stop,
Production or dev, we now declare,
With super properties floating in air! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly matches the main change: adding a PostHog environment super property that tags events with production/development.
Description check	✅ Passed	The description covers the What and Why, and includes test verification checklist items, but diverges from the template structure with a custom 'Summary' and 'Test plan' format rather than matching the template's prescribed sections.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

• 📝 Generate docstrings (stacked PR)
• 📝 Generate docstrings (commit on current branch)

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch worktree-feat-env-tagging

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/lib/posthog/client.ts`:
- Around line 18-20: The code calls posthog.register and reads
process.env.NODE_ENV directly; replace that raw process.env access with the
validated value exported from your env schema (the module that declares NODE_ENV
via zod, e.g., the exported `env` from src/env.ts). Import the env object (or
the specific exported variable that represents NODE_ENV) and use that (for
example `env.NODE_ENV === "production" ? "production" : "development"`) inside
posthog.register so the value is schema-validated rather than reading
process.env directly.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4e0abbd8-73fb-4c10-937b-0f8d39b75f9c

📥 Commits

Reviewing files that changed from the base of the PR and between 8c8feb0 and b97eea1.

📒 Files selected for processing (2)

• docs/Dev-Prod Environment Separation-ralph.md
• src/lib/posthog/client.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Replace raw process.env usage with validated env access.

Line 19 reads process.env.NODE_ENV directly inside src/, which violates the repository env-handling rule and bypasses schema-based configuration.

Proposed fix

     posthog.register({
-      environment: process.env.NODE_ENV === "production" ? "production" : "development",
+      environment: env.NEXT_PUBLIC_SENTRY_ENVIRONMENT ?? "development",
     });

As per coding guidelines: src/**/*.{ts,tsx,js,jsx}: "Declare all environment variables in src/env.ts using zod schemas. Never use process.env directly in code."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/posthog/client.ts` around lines 18 - 20, The code calls
posthog.register and reads process.env.NODE_ENV directly; replace that raw
process.env access with the validated value exported from your env schema (the
module that declares NODE_ENV via zod, e.g., the exported `env` from
src/env.ts). Import the env object (or the specific exported variable that
represents NODE_ENV) and use that (for example `env.NODE_ENV === "production" ?
"production" : "development"`) inside posthog.register so the value is
schema-validated rather than reading process.env directly.