diff --git a/.claude/skills/integration-astro-view-transitions/.posthog-wizard b/.claude/skills/integration-astro-view-transitions/.posthog-wizard new file mode 100644 index 00000000..e69de29b diff --git a/.claude/skills/integration-astro-view-transitions/SKILL.md b/.claude/skills/integration-astro-view-transitions/SKILL.md new file mode 100644 index 00000000..9defe9ce --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/SKILL.md @@ -0,0 +1,57 @@ +--- +name: integration-astro-view-transitions +description: PostHog integration for Astro with ClientRouter view transitions +metadata: + author: PostHog + version: 1.21.1 +--- + +# PostHog integration for Astro (View Transitions) + +This skill helps you add PostHog analytics to Astro (View Transitions) applications. + +## Workflow + +Follow these steps in order to complete the integration: + +1. `basic-integration-1.0-begin.md` - PostHog Setup - Begin ← **Start here** +2. `basic-integration-1.1-edit.md` - PostHog Setup - Edit +3. `basic-integration-1.2-revise.md` - PostHog Setup - Revise +4. `basic-integration-1.3-conclude.md` - PostHog Setup - Conclusion + +## Reference files + +- `references/EXAMPLE.md` - Astro (View Transitions) example project code +- `references/astro.md` - Astro - docs +- `references/identify-users.md` - Identify users - docs +- `references/basic-integration-1.0-begin.md` - PostHog setup - begin +- `references/basic-integration-1.1-edit.md` - PostHog setup - edit +- `references/basic-integration-1.2-revise.md` - PostHog setup - revise +- `references/basic-integration-1.3-conclude.md` - PostHog setup - conclusion + +The example project shows the target implementation pattern. Consult the documentation for API details. + +## Key principles + +- **Environment variables**: Always use environment variables for PostHog keys. Never hardcode them. +- **Minimal changes**: Add PostHog code alongside existing integrations. Don't replace or restructure existing code. +- **Match the example**: Your implementation should follow the example project's patterns as closely as possible. + +## Framework guidelines + +- Always use the is:inline directive on PostHog script tags to prevent Astro from processing them and causing TypeScript errors +- Use PUBLIC_prefix for client-side environment variables in Astro (e.g., PUBLIC_POSTHOG_PROJECT_TOKEN) +- Create a posthog.astro component in src/components/ for reusable initialization across pages +- Import the PostHog component in a Layout and wrap all pages with that layout +- Wrap PostHog initialization with a window.__posthog_initialized guard to prevent stack overflow during soft navigation +- Set capture_pageview option to 'history_change' for automatic pageview tracking during soft navigation +- Use the astro page-load event instead of just DOMContentLoaded to re-run scripts after soft navigation +- When a reverse proxy is configured, both /static/*AND /array/* must route to the assets origin (us-assets.i.posthog.com or eu-assets.i.posthog.com). + +## Identifying users + +Identify users during login and signup events. Refer to the example code and documentation for the correct identify pattern for this framework. If both frontend and backend code exist, pass the client-side session and distinct ID using `X-POSTHOG-DISTINCT-ID` and `X-POSTHOG-SESSION-ID` headers to maintain correlation. + +## Error tracking + +Add PostHog error tracking to relevant files, particularly around critical user flows and API boundaries. diff --git a/.claude/skills/integration-astro-view-transitions/references/EXAMPLE.md b/.claude/skills/integration-astro-view-transitions/references/EXAMPLE.md new file mode 100644 index 00000000..56c5a23f --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/references/EXAMPLE.md @@ -0,0 +1,809 @@ +# PostHog Astro (View Transitions) Example Project + +Repository: +Path: basics/astro-view-transitions + +--- + +## README.md + +### PostHog Astro View Transitions Example + +This is an [Astro](https://astro.build/) example demonstrating PostHog integration with [View Transitions](https://docs.astro.build/en/guides/view-transitions/) (ClientRouter) for SPA-like navigation. + +It uses the PostHog web snippet with special handling to prevent stack overflow errors during soft navigation, and shows how to: + +- Initialize PostHog with an initialization guard for View Transitions +- Track pageviews automatically during soft navigation +- Identify users after login +- Track custom events from pages +- Capture errors via `posthog.captureException()` +- Reset PostHog state on logout + +## Features + +- **View Transitions**: Smooth client-side navigation with `` +- **Product analytics**: Track login and burrito consideration events +- **Automatic pageview tracking**: Uses `capture_pageview: 'history_change'` for soft navigation +- **Session replay**: Enabled via PostHog snippet configuration +- **Error tracking**: Manual error capture sent to PostHog +- **Simple auth flow**: Demo login using localStorage + +## Getting started + +### 1. Install dependencies + +```bash +npm install +# or +pnpm install +``` + +### 2. Configure environment variables + +Create a `.env` file in the project root: + +```bash +PUBLIC_POSTHOG_PROJECT_TOKEN=your_posthog_project_token +PUBLIC_POSTHOG_HOST=https://us.i.posthog.com +``` + +Get your PostHog project token from your project settings in PostHog. + +### 3. Run the development server + +```bash +npm run dev +# or +pnpm dev +``` + +Open `http://localhost:4321` in your browser. + +## Project structure + +```text +src/ + components/ + posthog.astro # PostHog snippet WITH initialization guard + Header.astro # Navigation + logout, uses astro:page-load event + layouts/ + PostHogLayout.astro # Root layout with and PostHog + lib/ + auth.ts # Auth utilities (localStorage-based) + pages/ + index.astro # Login form, identifies user + captures 'user_logged_in' + burrito.astro # Burrito consideration demo, captures 'burrito_considered' + profile.astro # Profile + error tracking demo + styles/ + global.css # Global styles + view transition animations +``` + +## Key integration points + +### PostHog initialization with View Transitions (`src/components/posthog.astro`) + +When using Astro's View Transitions (ClientRouter), you **must** wrap the PostHog initialization with a guard to prevent stack overflow errors: + +```astro + +``` + +Without this guard, ClientRouter's soft navigation can re-execute the inline script during page transitions, causing a stack overflow error. + +The `capture_pageview: 'history_change'` option ensures pageviews are tracked automatically as users navigate between pages. + +### Layout with ClientRouter (`src/layouts/PostHogLayout.astro`) + +The layout includes Astro's ClientRouter for smooth page transitions: + +```astro +--- +import { ClientRouter } from 'astro:transitions'; +import PostHog from '../components/posthog.astro'; +--- + + + + + + ... + +``` + +### Handling View Transitions in scripts + +When using View Transitions, you need to set up event listeners after each page navigation: + +```javascript +function setupPage() { + // Your setup code here +} + +// Run on initial page load +document.addEventListener("DOMContentLoaded", setupPage); + +// Run after view transitions complete (for soft navigation) +document.addEventListener("astro:page-load", setupPage); +``` + +### User identification (`src/pages/index.astro`) + +After a successful "login", the app identifies the user and captures a login event: + +```javascript +window.posthog?.identify(username); +window.posthog?.capture("user_logged_in"); +``` + +### Event tracking (`src/pages/burrito.astro`) + +The burrito page tracks a custom event when a user "considers" the burrito: + +```javascript +window.posthog?.capture("burrito_considered", { + total_considerations: newCount, + username: currentUser, +}); +``` + +### Logout and session reset (`src/components/Header.astro`) + +On logout, both the local auth state and PostHog state are cleared: + +```javascript +window.posthog?.capture("user_logged_out"); +localStorage.removeItem("currentUser"); +window.posthog?.reset(); +``` + +## Scripts + +```bash +# Run dev server +npm run dev + +# Build for production +npm run build + +# Preview production build +npm run preview +``` + +## Learn more + +- [PostHog documentation](https://posthog.com/docs) +- [PostHog Astro guide](https://posthog.com/docs/libraries/astro) +- [Astro View Transitions](https://docs.astro.build/en/guides/view-transitions/) +- [Astro documentation](https://docs.astro.build/) + +--- + +## .env.example + +```example +PUBLIC_POSTHOG_PROJECT_TOKEN=your_posthog_project_token_here +PUBLIC_POSTHOG_HOST=https://us.i.posthog.com + +``` + +--- + +## astro.config.mjs + +```mjs +import { defineConfig } from "astro/config"; + +export default defineConfig({}); + +``` + +--- + +## src/components/Header.astro + +```astro +--- +// Header component with navigation and logout functionality +// Works with View Transitions by using data-astro-reload for logout +--- +
+
+ +
+ + Not logged in + +
+
+
+ + + + + +``` + +--- + +## src/components/posthog.astro + +```astro +--- +// PostHog analytics snippet with View Transitions support +// Uses is:inline to prevent Astro from processing the script +// Includes initialization guard to prevent stack overflow with ClientRouter +--- + + +``` + +--- + +## src/layouts/PostHogLayout.astro + +```astro +--- +import { ClientRouter } from 'astro:transitions'; +import PostHog from '../components/posthog.astro'; +import Header from '../components/Header.astro'; +import '../styles/global.css'; + +interface Props { + title: string; +} + +const { title } = Astro.props; +--- + + + + + + + + {title} + + + + +
+
+ +
+ + + +``` + +--- + +## src/lib/auth.ts + +```ts +// Client-side auth utilities for localStorage-based authentication + +export interface User { + username: string; + burritoConsiderations: number; +} + +export function getCurrentUser(): User | null { + if (typeof window === "undefined") return null; + + const username = localStorage.getItem("currentUser"); + if (!username) return null; + + const considerations = parseInt( + localStorage.getItem("burritoConsiderations") || "0", + 10, + ); + + return { + username, + burritoConsiderations: considerations, + }; +} + +export function login(username: string, password: string): boolean { + if (!username || !password) return false; + + localStorage.setItem("currentUser", username); + // Initialize burrito considerations if not set + if (!localStorage.getItem("burritoConsiderations")) { + localStorage.setItem("burritoConsiderations", "0"); + } + + return true; +} + +export function logout(): void { + localStorage.removeItem("currentUser"); + localStorage.removeItem("burritoConsiderations"); +} + +export function incrementBurritoConsiderations(): number { + const current = parseInt( + localStorage.getItem("burritoConsiderations") || "0", + 10, + ); + const newCount = current + 1; + localStorage.setItem("burritoConsiderations", newCount.toString()); + return newCount; +} + +``` + +--- + +## src/pages/burrito.astro + +```astro +--- +import PostHogLayout from '../layouts/PostHogLayout.astro'; +--- + +
+

Burrito consideration zone

+

Take a moment to truly consider the potential of burritos.

+ +
+ + + +
+ +
+

Consideration stats

+

Total considerations: 0

+
+
+ + + + +``` + +--- + +## src/pages/index.astro + +```astro +--- +import PostHogLayout from '../layouts/PostHogLayout.astro'; +--- + +
+ + +
+

Welcome to Burrito Consideration App

+

Please sign in to begin your burrito journey

+ +
+
+ + +
+ +
+ + +
+ + + + +
+ +

+ Note: This is a demo app. Use any username and password to sign in. +

+
+
+ + + + +``` + +--- + +## src/pages/profile.astro + +```astro +--- +import PostHogLayout from '../layouts/PostHogLayout.astro'; +--- + +
+

User Profile

+ +
+

Your Information

+

Username:

+

Burrito Considerations: 0

+
+ +
+

Your Burrito Journey

+

+
+ +
+

Error Tracking Demo

+

Click the button below to trigger a test error and send it to PostHog:

+ + +
+
+ + + + +``` + +--- diff --git a/.claude/skills/integration-astro-view-transitions/references/astro.md b/.claude/skills/integration-astro-view-transitions/references/astro.md new file mode 100644 index 00000000..a9a2ba14 --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/references/astro.md @@ -0,0 +1,165 @@ +# Astro - Docs + +PostHog makes it easy to get data about traffic and usage of your [Astro](https://astro.build/) app. Integrating PostHog into your site enables analytics about user behavior, custom events capture, session recordings, feature flags, and more. + +This guide walks you through integrating PostHog into your Astro app using the [JavaScript Web SDK](/docs/libraries/js.md). + +## Beta: integration via LLM + +Install PostHog for Astro in seconds with our wizard by running this prompt with [LLM coding agents](/blog/envoy-wizard-llm-agent.md) like Cursor and Bolt, or by running it in your terminal. + +`npx @posthog/wizard@latest` + +[Learn more](/wizard.md) + +Or, to integrate manually, continue with the rest of this guide. + +## Installation + +In your `src/components` folder, create a `posthog.astro` file: + +Terminal + +PostHog AI + +```bash +cd ./src/components +# or 'cd ./src && mkdir components && cd ./components' if your components folder doesnt exist +touch posthog.astro +``` + +In this file, add your `Web snippet` which you can find in [your project settings](https://us.posthog.com/settings/project#snippet). Be sure to include the `is:inline` directive [to prevent Astro from processing it](https://docs.astro.build/en/guides/client-side-scripts/#opting-out-of-processing), or you will get Typescript and build errors that property 'posthog' does not exist on type 'Window & typeof globalThis'. + +posthog.astro + +PostHog AI + +```javascript + +``` + +### Using with Astro's view transitions (ClientRouter) + +If you've opted in to Astro's `` component for client-side navigation, you'll need to add an initialization guard to prevent PostHog from running multiple times during page transitions. + +Update your `posthog.astro` file to wrap the snippet with a check: + +posthog.astro + +PostHog AI + +```javascript +--- +// src/components/posthog.astro +--- + +``` + +Without this guard, `ClientRouter`'s soft navigation can re-execute the inline script during page transitions, causing a stack overflow error. The `capture_pageview: 'history_change'` option ensures pageviews are tracked automatically as users navigate. + +The next step is to a create a [Layout](https://docs.astro.build/en/core-concepts/layouts/) where we will use `posthog.astro`. Create a new file `PostHogLayout.astro` in your `src/layouts` folder: + +Terminal + +PostHog AI + +```bash +cd .. && cd .. # move back to your base directory if you're still in src/components/posthog.astro +cd ./src/layouts +# or 'cd ./src && mkdir layouts && cd ./layouts' if your layouts folder doesn't exist yet +touch PostHogLayout.astro +``` + +Add the following code to `PostHogLayout.astro`: + +PostHogLayout.astro + +PostHog AI + +```javascript +--- +import PostHog from '../components/posthog.astro' +--- + + + +``` + +Lastly, update `index.astro` to wrap your existing app components with the new Layout: + +index.astro + +PostHog AI + +```javascript +--- +import PostHogLayout from '../layouts/PostHogLayout.astro'; +--- + + + +``` + +## Identifying users + +> **Identifying users is required.** Call `posthog.identify('your-user-id')` after login to link events to a known user. This is what connects frontend event captures, [session replays](/docs/session-replay.md), [LLM traces](/docs/ai-engineering.md), and [error tracking](/docs/error-tracking.md) to the same person — and lets backend events link back too. +> +> See our guide on [identifying users](/docs/getting-started/identify-users.md) for how to set this up. + +Set up a reverse proxy (recommended) + +We recommend [setting up a reverse proxy](/docs/advanced/proxy.md), so that events are less likely to be intercepted by tracking blockers. + +We have our [own managed reverse proxy service](/docs/advanced/proxy/managed-reverse-proxy.md), which is free for all PostHog Cloud users, routes through our infrastructure, and makes setting up your proxy easy. + +If you don't want to use our managed service then there are several other options for creating a reverse proxy, including using [Cloudflare](/docs/advanced/proxy/cloudflare.md), [AWS Cloudfront](/docs/advanced/proxy/cloudfront.md), and [Vercel](/docs/advanced/proxy/vercel.md). + +Grouping products in one project (recommended) + +If you have multiple customer-facing products (e.g. a marketing website + mobile app + web app), it's best to install PostHog on them all and [group them in one project](/docs/settings/projects.md). + +This makes it possible to track users across their entire journey (e.g. from visiting your marketing website to signing up for your product), or how they use your product across multiple platforms. + +Add IPs to Firewall/WAF allowlists (recommended) + +For certain features like [heatmaps](/docs/toolbar/heatmaps.md), your Web Application Firewall (WAF) may be blocking PostHog’s requests to your site. Add these IP addresses to your WAF allowlist or rules to let PostHog access your site. + +**EU**: `3.75.65.221`, `18.197.246.42`, `3.120.223.253` + +**US**: `44.205.89.55`, `52.4.194.122`, `44.208.188.173` + +These are public, stable IPs used by PostHog services (e.g., Celery tasks for snapshots). + +## Next steps + +For any technical questions for how to integrate specific PostHog features into Astro (such as analytics, feature flags, A/B testing, surveys, etc.), have a look at our [JavaScript Web SDK docs](/docs/libraries/js/features.md). + +Alternatively, the following tutorials can help you get started: + +- [How to set up Astro analytics, feature flags, and more](/tutorials/astro-analytics.md) +- [How to set up A/B tests in Astro](/tutorials/astro-ab-tests.md) +- [How to set up surveys in Astro](/tutorials/astro-surveys.md) + +### Community questions + +Ask a question + +### Was this page useful? + +HelpfulCould be better diff --git a/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.0-begin.md b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.0-begin.md new file mode 100644 index 00000000..a315b4e2 --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.0-begin.md @@ -0,0 +1,56 @@ +--- +title: PostHog Setup - Begin +description: Start the event tracking setup process by analyzing the project and creating an event tracking plan +--- + +We're making an event tracking plan for this project. + +This is the first of several phases — plan the events, implement them, revise and validate changes, then conclude by creating a dashboard and writing a setup report. + +## Task list + +As soon as you've read this description and have a rough sense of the work, make a single **call `TaskCreate` immediately** before reading any reference file or beginning analysis. The user is watching the task pane and shouldn't see it sit empty. + +It's fine if your first list is incomplete or imprecise. Seed it with whatever high-level items you can infer from the overview above, then call `TaskCreate` again (or `TaskUpdate` to refine existing items) every time your understanding sharpens: after a phase reveals work you didn't anticipate, after planning surfaces concrete sub-items, after you hit something new. Use `TaskUpdate` to mark items `in_progress` when you start them and `completed` when you finish. Keeping the list current matters more than getting it right on the first call. + +Keep task titles broad and job-oriented. Describe the purpose or area of work with wording like "Planning event tracking", "Identifying users", "Installing PostHog", "Capturing events", or "Creating dashboards", not the specific files, paths, or symbols involved. Adjust the task names according to the user's project and context. + +Before proceeding, find any existing `posthog.capture()` code. Make note of event name formatting. + +From the project's file list, select between 10 and 15 files that might have interesting business value for event tracking, especially conversion and churn events. Also look for additional files related to login that could be used for identifying users, along with error handling. Read the files. If a file is already well-covered by PostHog events, replace it with another option. Do not spawn subagents. + +Look for opportunities to track client-side events. + +**IMPORTANT: Server-side events are REQUIRED** if the project includes any instrumentable server-side code. If the project has API routes (e.g., `app/api/**/route.ts`) or Server Actions, you MUST include server-side events for critical business operations like: + +- Payment/checkout completion +- Webhook handlers +- Authentication endpoints + +Do not skip server-side events - they capture actions that cannot be tracked client-side. + +Create a new file with a JSON array at the root of the project: .posthog-events.json. It should include one object for each event we want to add: event name, event description, and the file path we want to place the event in. If events already exist, don't duplicate them; supplement them. + +Track actions only, not pageviews. These can be captured automatically. Exceptions can be made for "viewed"-type events that correspond to the top of a conversion funnel. + +As you review files, make an internal note of opportunities to identify users and catch errors. We'll need them for the next step. + +## Status + +Before beginning a phase of the setup, you will send a status message with the exact prefix '[STATUS]', as in: + +[STATUS] Checking project structure. + +Status to report in this phase: + +- Checking project structure +- Verifying PostHog dependencies +- Generating events based on project + +## Abort statuses + +If and only if the instructions have `[ABORT]` states specified, and you clearly match the conditions for an abort, emit the abort message. Do NOT attempt to exit or halt yourself — the wizard's middleware catches `[ABORT]` and terminates the run for you. + +--- + +**Upon completion, continue with:** [basic-integration-1.1-edit.md](basic-integration-1.1-edit.md) diff --git a/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.1-edit.md b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.1-edit.md new file mode 100644 index 00000000..b5d6b49c --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.1-edit.md @@ -0,0 +1,36 @@ +--- +title: PostHog Setup - Edit +description: Implement PostHog event tracking in the identified files, following best practices and the example project +--- + +For each of the files and events noted in .posthog-events.json, make edits to capture events using PostHog. Make sure to set up any helper files needed. Carefully examine the included example project code: your implementation should match it as closely as possible. Do not spawn subagents. + +Use environment variables for PostHog keys. Do not hardcode PostHog keys. + +If a file already has existing integration code for other tools or services, don't overwrite or remove that code. Place PostHog code below it. + +For each event, add useful properties, and use your access to the PostHog source code to ensure correctness. You also have access to documentation about creating new events with PostHog. Consider this documentation carefully and follow it closely before adding events. Your integration should be based on documented best practices. Carefully consider how the user project's framework version may impact the correct PostHog integration approach. + +Remember that you can find the source code for any dependency in the node_modules directory. This may be necessary to properly populate property names. There are also example project code files available via the PostHog MCP; use these for reference. + +Where possible, add calls for PostHog's identify() function on the client side upon events like logins and signups. Use the contents of login and signup forms to identify users on submit. If there is server-side code, pass the client-side session and distinct ID to the server-side code to identify the user. On the server side, make sure events have a matching distinct ID where relevant. + +It's essential to do this in both client code and server code, so that user behavior from both domains is easy to correlate. + +You should also add PostHog exception capture error tracking to these files where relevant. + +Remember: Do not alter the fundamental architecture of existing files. Make your additions minimal and targeted. + +Remember the documentation and example project resources you were provided at the beginning. Read them now. + +## Status + +Status to report in this phase: + +- Inserting PostHog capture code +- A status message for each file whose edits you are planning, including a high level summary of changes +- A status message for each file you have edited + +--- + +**Upon completion, continue with:** [basic-integration-1.2-revise.md](basic-integration-1.2-revise.md) diff --git a/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.2-revise.md b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.2-revise.md new file mode 100644 index 00000000..285ee734 --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.2-revise.md @@ -0,0 +1,22 @@ +--- +title: PostHog Setup - Revise +description: Review and fix any errors in the PostHog integration implementation +--- + +Check the project for errors. Read the package.json file for any type checking or build scripts that may provide input about what to fix. Remember that you can find the source code for any dependency in the node_modules directory. Do not spawn subagents. + +Ensure that any components created were actually used. + +Once all other tasks are complete, run any linter or prettier-like scripts found in the package.json, but ONLY on the files you have edited or created during this session. Do not run formatting or linting across the entire project's codebase. + +## Status + +Status to report in this phase: + +- Finding and correcting errors +- Report details of any errors you fix +- Linting, building and prettying + +--- + +**Upon completion, continue with:** [basic-integration-1.3-conclude.md](basic-integration-1.3-conclude.md) diff --git a/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.3-conclude.md b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.3-conclude.md new file mode 100644 index 00000000..2bd36227 --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/references/basic-integration-1.3-conclude.md @@ -0,0 +1,40 @@ +--- +title: PostHog Setup - Conclusion +description: Review and fix any errors in the PostHog integration implementation +--- + +Use the PostHog MCP to create a new dashboard named "Analytics basics (wizard)" based on the events created here. Keep the `(wizard)` tag with that exact casing so anyone browsing PostHog can see the wizard created this dashboard, and so a quick search for `(wizard)` surfaces every wizard-created artifact in one go. Make sure to use the exact same event names as implemented in the code. Populate it with up to five insights, with special emphasis on things like conversion funnels, churn events, and other business critical insights. + +Search for a file called `.posthog-events.json` and read it for available events. + +Do not spawn subagents. + +Create the file posthog-setup-report.md. It should include a summary of the integration edits, a table with the event names, event descriptions, and files where events were added, along with a list of links for the dashboard and insights created. Follow this format: + + +# PostHog post-wizard report + +The wizard has completed a deep integration of your project. [Detailed summary of changes] + +[table of events/descriptions/files] + +## Next steps + +We've built some insights and a dashboard for you to keep an eye on user behavior, based on the events we just instrumented: + +[links] + +### Agent skill + +We've left an agent skill folder in your project. You can use this context for further agent development when using Claude Code. This will help ensure the model provides the most up-to-date approaches for integrating PostHog. + + + +Upon completion, remove .posthog-events.json. + +## Status + +Status to report in this phase: + +- Configured dashboard: [insert PostHog dashboard URL] +- Created setup report: [insert full local file path] diff --git a/.claude/skills/integration-astro-view-transitions/references/identify-users.md b/.claude/skills/integration-astro-view-transitions/references/identify-users.md new file mode 100644 index 00000000..13defe51 --- /dev/null +++ b/.claude/skills/integration-astro-view-transitions/references/identify-users.md @@ -0,0 +1,271 @@ +# Identify users - Docs + +Linking events to specific users enables you to build a full picture of how they're using your product across different sessions, devices, and platforms. + +This is straightforward to do when [capturing backend events](/docs/product-analytics/capture-events?tab=Node.js.md), as you associate events to a specific user using a `distinct_id`, which is a required argument. + +However, in the frontend of a [web](/docs/libraries/js/features.md#capturing-events) or [mobile app](/docs/libraries/ios.md#capturing-events), a `distinct_id` is not a required argument — PostHog's SDKs will generate an anonymous `distinct_id` for you automatically and you can capture events anonymously, provided you use the appropriate [configuration](/docs/libraries/js/features.md#capturing-anonymous-events). + +To link events to specific users, call `identify`: + +PostHog AI + +## Web + +```javascript +posthog.identify( + 'distinct_id', // Replace 'distinct_id' with your user's unique identifier + { email: 'max@hedgehogmail.com', name: 'Max Hedgehog' } // optional: set additional person properties +); +``` + +## Android + +```kotlin +PostHog.identify( + distinctId = distinctID, // Replace 'distinctID' with your user's unique identifier + // optional: set additional person properties + userProperties = mapOf( + "name" to "Max Hedgehog", + "email" to "max@hedgehogmail.com" + ) +) +``` + +## iOS + +```swift +PostHogSDK.shared.identify("distinct_id", // Replace "distinct_id" with your user's unique identifier + userProperties: ["name": "Max Hedgehog", "email": "max@hedgehogmail.com"]) // optional: set additional person properties +``` + +## React Native + +```jsx +posthog.identify('distinct_id', { // Replace "distinct_id" with your user's unique identifier + email: 'max@hedgehogmail.com', // optional: set additional person properties + name: 'Max Hedgehog' +}) +``` + +## Dart + +```dart +await Posthog().identify( + userId: 'distinct_id', // Replace "distinct_id" with your user's unique identifier + userProperties: { + email: "max@hedgehogmail.com", // optional: set additional person properties + name: "Max Hedgehog" +}); +``` + +Events captured after calling `identify` are identified events and this creates a person profile if one doesn't exist already. + +Due to the cost of processing them, anonymous events can be up to 4x cheaper than identified events, so it's recommended you only capture identified events when needed. + +## How identify works + +When a user starts browsing your website or app, PostHog automatically assigns them an **anonymous ID**, which is stored locally. + +Provided you've [configured persistence](/docs/libraries/js/persistence.md) to use cookies or `localStorage`, this enables us to track anonymous users – even across different sessions. + +By calling `identify` with a `distinct_id` of your choice (usually the user's ID in your database, or their email), you link the anonymous ID and distinct ID together. + +Thus, all past and future events made with that anonymous ID are now associated with the distinct ID. + +This enables you to do things like associate events with a user from before they log in for the first time, or associate their events across different devices or platforms. + +Using identify in the backend + +Although you can call `identify` using our backend SDKs, it is used most in frontends. This is because there is no concept of anonymous sessions in the backend SDKs, so calling `identify` only updates person profiles. + +## Best practices when using `identify` + +### 1\. Call `identify` as soon as you're able to + +In your frontend, you should call `identify` as soon as you're able to. + +Typically, this is every time your **app loads** for the first time, and directly after your **users log in**. + +This ensures that events sent during your users' sessions are correctly associated with them. + +You only need to call `identify` once per session, and you should avoid calling it multiple times unnecessarily. + +If you call `identify` multiple times with the same data without reloading the page in between, PostHog will ignore the subsequent calls. + +### 2\. Use unique strings for distinct IDs + +If two users have the same distinct ID, their data is merged and they are considered one user in PostHog. Two common ways this can happen are: + +- Your logic for generating IDs does not generate sufficiently strong IDs and you can end up with a clash where 2 users have the same ID. +- There's a bug, typo, or mistake in your code leading to most or all users being identified with generic IDs like `null`, `true`, or `distinctId`. + +PostHog also has built-in protections to stop the most common distinct ID mistakes. + +### 3\. Reset after logout + +If a user logs out on your frontend, you should call `reset()` to unlink any future events made on that device with that user. + +This is important if your users are sharing a computer, as otherwise all of those users are grouped together into a single user due to shared cookies between sessions. + +**We strongly recommend you call `reset` on logout even if you don't expect users to share a computer.** + +You can do that like so: + +PostHog AI + +### Web + +```javascript +posthog.reset() +``` + +### iOS + +```swift +PostHogSDK.shared.reset() +``` + +### Android + +```kotlin +PostHog.reset() +``` + +### React Native + +```jsx +posthog.reset() +``` + +### Dart + +```dart +Posthog().reset() +``` + +If you *also* want to reset the `device_id` so that the device will be considered a new device in future events, you can pass `true` as an argument: + +Web + +PostHog AI + +```javascript +posthog.reset(true) +``` + +### 4\. Person profiles and properties + +You'll notice that one of the parameters in the `identify` method is a `properties` object. + +This enables you to set [person properties](/docs/product-analytics/person-properties.md). + +Whenever possible, we recommend passing in all person properties you have available each time you call identify, as this ensures their person profile on PostHog is up to date. + +Person properties can also be set being adding a `$set` property to a event `capture` call. + +See our [person properties docs](/docs/product-analytics/person-properties.md) for more details on how to work with them and best practices. + +### 5\. Use deep links between platforms + +We recommend you call `identify` [as soon as you're able](#1-call-identify-as-soon-as-youre-able-to), typically when a user signs up or logs in. + +This doesn't work if one or both platforms are unauthenticated. Some examples of such cases are: + +- Onboarding and signup flows before authentication. +- Unauthenticated web pages redirecting to authenticated mobile apps. +- Authenticated web apps prompting an app download. + +In these cases, you can use a [deep link](https://developer.android.com/training/app-links/deep-linking) on Android and [universal links](https://developer.apple.com/documentation/xcode/supporting-universal-links-in-your-app) on iOS to identify users. + +1. Use `posthog.get_distinct_id()` to get the current distinct ID. Even if you cannot call identify because the user is unauthenticated, this will return an anonymous distinct ID generated by PostHog. +2. Add the distinct ID to the deep link as query parameters, along with other properties like UTM parameters. +3. When the user is redirected to the app, parse the deep link and handle the following cases: + +- The mobile app is already authenticated. In this case, call [`posthog.alias()`](/docs/libraries/js/features.md#alias) with the distinct ID from the web. This associates the two distinct IDs as a single person. +- The mobile app is unauthenticated. In this case, call [`posthog.identify()`](/docs/libraries/js/features.md#identifying-users) with the distinct ID from the web so pre-login mobile events stay connected to the web session. When the user later logs in on mobile, call `identify()` again with your canonical user ID. + +As long as you associate the distinct IDs with `posthog.identify()` or `posthog.alias()`, you can track events generated across platforms. + +Here's an example implementation for handling deep links from web to mobile: + +PostHog AI + +#### iOS + +```swift +import PostHog +class DeepLinkIdentityManager { + static let shared = DeepLinkIdentityManager() + // MARK: - Deep Link Received + func handleDeepLink(_ url: URL, isAuthenticatedOnMobile: Bool) { + guard let webDistinctId = URLComponents(url: url, resolvingAgainstBaseURL: true)? + .queryItems?.first(where: { $0.name == "ph_distinct_id" })?.value else { + return + } + if isAuthenticatedOnMobile { + // The mobile app already knows the current user. + // Alias the incoming web distinct ID to that user. + PostHogSDK.shared.alias(webDistinctId) + } else { + // Reuse the web distinct ID until login on mobile. + PostHogSDK.shared.identify(webDistinctId) + } + } + // MARK: - Login/Signup + func handleLogin(canonicalUserId: String) { + // Switch from the web distinct ID (or a mobile anon ID) + // to your canonical user ID. + PostHogSDK.shared.identify(canonicalUserId) + // Set user properties, track signup event, etc. + } + func handleLogout() { + PostHogSDK.shared.reset() + } +} +``` + +#### Android + +```kotlin +import android.net.Uri +import com.posthog.PostHog +object DeepLinkIdentityManager { + // Deep Link Received + fun handleDeepLink(uri: Uri, isAuthenticatedOnMobile: Boolean) { + val webDistinctId = uri.getQueryParameter("ph_distinct_id") ?: return + if (isAuthenticatedOnMobile) { + // The mobile app already knows the current user. + // Alias the incoming web distinct ID to that user. + PostHog.alias(webDistinctId) + } else { + // Reuse the web distinct ID until login on mobile. + PostHog.identify(webDistinctId) + } + } + // Login/Signup + fun handleLogin(canonicalUserId: String) { + // Switch from the web distinct ID (or a mobile anon ID) + // to your canonical user ID. + PostHog.identify(canonicalUserId) + // Set user properties, track signup event, etc. + } + fun handleLogout() { + PostHog.reset() + } +} +``` + +## Further reading + +- [Identifying users docs](/docs/product-analytics/identify.md) +- [How person processing works](/docs/how-posthog-works/ingestion-pipeline.md#2-person-processing) +- [An introductory guide to identifying users in PostHog](/tutorials/identifying-users-guide.md) + +### Community questions + +Ask a question + +### Was this page useful? + +HelpfulCould be better diff --git a/.github/prompts/docs-review.md b/.github/prompts/docs-review.md index 1784e025..c274c7c8 100644 --- a/.github/prompts/docs-review.md +++ b/.github/prompts/docs-review.md @@ -1,6 +1,6 @@ You are reviewing the **documentation** of the WaveHouse project — the prose itself, and whether it kept up with the code; not the code's correctness. Read AGENTS.md at the repo root first: §Documentation Sync maps each code area to the docs that describe it, §SDK Sync covers the client, and the architecture/config context tells you what the docs *should* say. -**Scope** is the canonical docs-prose set resolved by `scripts/docs-prose.sh` — a *denylist*: every tracked `.md`/`.mdx` file EXCEPT `.claude/**`, `.github/**`, `CHANGELOG.md`, `AGENTS.md`, `CLAUDE.md`, `*.draft.md`/`*.old.md`, and `PERF-CLAIMS-REVIEW.md`. That is the Astro Starlight site under `docs/src/content/docs/` (`.md` + `index.mdx`) **plus** the user-facing governance docs — `README.md`, the SDK readme `clients/ts/README.md`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, `SUPPORT.md` — and any doc added later (new files are covered automatically). `CODE_OF_CONDUCT.md` and `SUPPORT.md` are mostly boilerplate: only deep-review them when they changed or when a material change elsewhere warrants it. +**Scope** is the canonical docs-prose set resolved by `scripts/docs-prose.sh` — a *denylist*: every tracked `.md`/`.mdx` file EXCEPT `.claude/**`, `.github/**`, `CHANGELOG.md`, `AGENTS.md`, `CLAUDE.md`, `*.draft.md`/`*.old.md`, `PERF-CLAIMS-REVIEW.md`, and `docs/posthog-setup-report.md` (frozen wizard artifact). That is the Astro Starlight site under `docs/src/content/docs/` (`.md` + `index.mdx`) **plus** the user-facing governance docs — `README.md`, the SDK readme `clients/ts/README.md`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, `SUPPORT.md` — and any doc added later (new files are covered automatically). `CODE_OF_CONDUCT.md` and `SUPPORT.md` are mostly boilerplate: only deep-review them when they changed or when a material change elsewhere warrants it. This review **complements** the deterministic layers that already run — do **not** duplicate them: diff --git a/.github/workflows/admin-approval.yml b/.github/workflows/admin-approval.yml index 37754016..64c28671 100644 --- a/.github/workflows/admin-approval.yml +++ b/.github/workflows/admin-approval.yml @@ -21,7 +21,8 @@ name: Admin approval # to admin review like any human PR — closed a hole where a bot's # APPROVED review (e.g. CodeRabbit) could merge a major bump (see # #130, PR #127). The ruleset's `required_approving_review_count` -# is 0; this status check is the single admin-review gate. +# is 1 (any collaborator's approval satisfies it); this status check +# is what makes one of those approvals specifically an admin's. on: pull_request: diff --git a/.gitignore b/.gitignore index a476cbaf..dd45df83 100644 --- a/.gitignore +++ b/.gitignore @@ -74,6 +74,7 @@ __debug_bin* # Docs site build outputs docs/.astro/ +docs/.dev-dist/ docs/.env.production docs/.wrangler/ docs/dist/ diff --git a/.vscode/launch.json b/.vscode/launch.json index 5de4a9f4..d84c3f5f 100644 --- a/.vscode/launch.json +++ b/.vscode/launch.json @@ -2,11 +2,18 @@ "version": "0.2.0", "configurations": [ { - "name": "Docs: Astro dev server", + "name": "Docs: dev loop (rebuild-on-save + wrangler, :4321)", "type": "node-terminal", "request": "launch", "cwd": "${workspaceFolder}/docs", "command": "pnpm dev" + }, + { + "name": "Docs: Astro HMR dev server (no Worker/search/md twins)", + "type": "node-terminal", + "request": "launch", + "cwd": "${workspaceFolder}/docs", + "command": "pnpm start" } ] } diff --git a/AGENTS.md b/AGENTS.md index 4f5b90c6..cb88884e 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -95,7 +95,10 @@ make ci # Full pre-push pipeline — run it the documented way ( make build # Compile → bin/wavehouse make dev # ClickHouse + hot-reload server on :8080 (Docker) make deps-up # Start ClickHouse alone — for `make dev`; NOT needed by `make ci` -make build-docs # Production docs build → docs/dist/ +make dev-docs # Prod-faithful docs dev loop: rebuild-on-save + wrangler dev on :4321 +make build-docs # Production build → docs/dist/ +make preview-docs # Wrangler preview of the production build (auto-builds if dist/ missing) +make branding-docs # Regenerate logo/favicon/OG assets from docs/src/assets/branding/mark.svg ``` Verbose: `V=1 make test`. Extra args: `make test ARGS="-run TestFoo"`. Build tags: `make build TAGS="foo"`. @@ -287,7 +290,7 @@ Then run the reviewers relevant to the PR's diff (the same set from `scripts/pre Documentation *prose* — accuracy against the code, runnable examples, clarity, completeness — **and code↔docs sync** (code that changed but whose docs didn't) are reviewed by the **`docs-reviewer`** subagent, not the code-focused `pre-push-reviewer`. The canonical rubric is `.github/prompts/docs-review.md`. It complements the deterministic prose tools — misspell, markdownlint, starlight-links-validator — reviewing only what they can't, and it never edits docs or posts PR comments. -**Scope** is the canonical docs-prose set from `scripts/docs-prose.sh` — a *denylist*: every tracked `.md`/`.mdx` EXCEPT `.claude/**`, `.github/**`, `CHANGELOG.md`, `AGENTS.md`, `CLAUDE.md`, `*.draft.md`/`*.old.md`, `PERF-CLAIMS-REVIEW.md`. So it covers the Starlight site under `docs/src/content/` **and** the governance docs (`README.md`, the SDK readme `clients/ts/README.md`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, `SUPPORT.md`) — new docs are picked up automatically. `CODE_OF_CONDUCT.md`/`SUPPORT.md` are deep-reviewed only on change or material suspicion. +**Scope** is the canonical docs-prose set from `scripts/docs-prose.sh` — a *denylist*: every tracked `.md`/`.mdx` EXCEPT `.claude/**`, `.github/**`, `CHANGELOG.md`, `AGENTS.md`, `CLAUDE.md`, `*.draft.md`/`*.old.md`, `PERF-CLAIMS-REVIEW.md`, `docs/posthog-setup-report.md`. So it covers the Starlight site under `docs/src/content/` **and** the governance docs (`README.md`, the SDK readme `clients/ts/README.md`, `CONTRIBUTING.md`, `SECURITY.md`, `CODE_OF_CONDUCT.md`, `SUPPORT.md`) — new docs are picked up automatically. `CODE_OF_CONDUCT.md`/`SUPPORT.md` are deep-reviewed only on change or material suspicion. **It is a hard pre-push gate**, run in parallel with the other pre-push reviewers (see §Pre-push self-review). Invoked with the **default (branch) scope** it emits a `VERDICT:` line; on `ship_it` the `review-marker.sh` SubagentStop hook writes `tmp/docs-reviewer-passed-`, which the push gate requires — unconditionally, on every PR-branch push (even code-only ones). Run it via **`/docs-review`**; with **no arg** that's the gating review (branch scope), while an explicit **path/glob** or **`all`** is **advisory** (no `VERDICT:`, no marker) for ad-hoc audits. The whole dev team runs Claude Code and this command is tracked in-repo, so everyone runs it themselves; there is intentionally **no PR/cloud path** for docs review. diff --git a/CHANGELOG.md b/CHANGELOG.md index b83781af..b79f5466 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,8 +11,19 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 ### Fixed +- **development.md & CONTRIBUTING.md no longer describe the pre-consolidation CI / review automation** (`docs/src/content/docs/development.md` §CI & review automation, `CONTRIBUTING.md`, `Makefile` comments): the contributor docs still referenced `pr-title.yml`/`Validate`, `Check`/`Build` status checks, `project-orchestrator.yml`, and `label.yml` — all replaced or deleted by the May 2026 workflow consolidation (`housekeeping.yml`) and #115 — and described card movement and reviewer re-requests the orchestrator no longer performs. Rewritten against the live config: required checks are `CI` (one job running `make ci`), `PR housekeeping` (Conventional Commits title + the previously undocumented 72-char cap, file-path labels via the labeler step, reviewer assignment on open/ready), and `Admin approval`; board placement is native Projects v2 workflows; the stale "Lint/Test not required (#57)" note is gone (those suites run inside the required `CI` check). Also corrects a misattribution this branch had propagated: `starlight-links-validator` does not use Chromium — only `rehype-mermaid` does (fixed in the prose and two `Makefile` comments), and `make clean`'s help text/targets table now mention `docs/.dev-dist/`. Same sweep, code-comment side: `admin-approval.yml`'s header claimed the ruleset's `required_approving_review_count` was `0` — the live ruleset says `1` (any collaborator), with the workflow's status check being what makes one of those approvals specifically an admin's — and AGENTS.md's `make clean` one-liner now lists the docs build outputs. + +- **Theme-adaptive favicon that actually displays** (`docs/astro.config.mjs`, `docs/src/components/Head.astro`, `docs/scripts/branding/generate.sh`, `docs/public/branding/favicon-{light,dark}.svg` (new)): the CSS-swap `favicon.svg` has carried a `prefers-color-scheme` flip since the branding pipeline landed, but no browser ever showed it — the docs final pass (#193) dropped the explicit `sizes="any"` SVG icon link, so Chromium selected the static `.ico`, and Chromium rasterizes an SVG favicon only once regardless (crbug.com/1208277). The head now declares the numeric-sized `.ico` + `sizes="any"` SVG pair, the brand kit gains statically-colored `favicon-{light,dark}.svg` variants (two new copy-out assets), and a `Head.astro` inline script live-swaps them on `prefers-color-scheme` changes, GitHub-style: replacing the link node each repaint (in-place `href` mutation is honored only transiently) and removing the `.ico` from the live candidate list, since Chromium's favicon scorer otherwise commits an exact-size `.ico` over a `sizes="any"` SVG (verified against the browser's profile `Favicons` DB rather than blog lore). No-JS consumers keep the full SSR markup (CSS-swap `favicon.svg` + `.ico`); Safari ≤18, which can't use SVG favicons, falls back to the root `/favicon.ico` auto-probe that the brand pipeline keeps in place. Supersedes the favicon wiring described in the branding-pipeline entry below (`favicon:` option + `.ico`/apple-touch head tags only). - **TS SDK no longer hardcodes `ORDER BY received_timestamp DESC` as the default query order, so `wh.from(table).fetch()` works on any schema** (`clients/ts/src/query-builder.ts`, `clients/ts/src/query-builder.test.ts`, `tests/e2e/sdk/query.test.ts`, `docs/src/content/docs/sdk.md`): closes #270. The query builder previously injected `ORDER BY received_timestamp DESC` as both the default query order (`_buildAST`) and the cursor-pagination column (`_fetchNext`), so a bare `.fetch()` against a bring-your-own-schema table lacking that column emitted invalid SQL → ClickHouse `Unknown expression identifier received_timestamp` → HTTP 500. The SDK now emits an `ORDER BY` only when the caller sets one via `.orderBy()`, and sends no implicit order otherwise. **Soft behavior change:** `.fetch()` still reports `hasMore` honestly from the row count, but cursor pagination's `result.next` is now `undefined` (rather than always defined when `hasMore` is `true`) unless the query has an explicit `.orderBy()`; callers paginating via `await result.next!()` must guard on `result.next` (the `sdk.md` / README examples already do). This also sidesteps the #175 default-cursor tie bug — there is no longer a default cursor to tie on. A backend-owned, per-table default sort order (designed together with server-side pagination, which would subsume #175) is tracked as a follow-up (#274). Stream dedup in `clients/ts/src/stream/live-query.ts` / `stream/sse.ts` still uses `received_timestamp` and is intentionally out of scope (the live ingest stream always carries that column). Builds on #199 (query-builder structure). +### Changed + +- **`make dev-docs` is now production-faithful: rebuild-on-save through the real Worker instead of `astro dev`** (`docs/scripts/dev.mjs` (new), `docs/package.json`, `docs/astro.config.mjs`, `Makefile`, `AGENTS.md`, `.gitignore`, `.vscode/launch.json`, `docs/scripts/screenshot.mjs`, `docs/src/content/docs/development.md`): the Astro dev server skips everything the Cloudflare Worker adds in production — `cloudflare-md-router` content negotiation (`.md` twins), the pagefind search index, and the `starlight-llm-tools` outputs only exist in real builds — so the de-facto docs workflow had become a manual `make build-docs && make preview-docs` cycle, restarted by hand per change. `pnpm run dev` (and therefore `make dev-docs`) now drives `docs/scripts/dev.mjs`: a debounced full `astro build` on every save to `src/`, `public/`, or a root build input (`astro.config.mjs`, `tsconfig.json`, `package.json`, `.env*` — but not `worker/index.ts`/`wrangler.jsonc`, which `wrangler dev` hot-reloads itself, and not `pnpm-lock.yaml`, which changes on `git pull` before `pnpm install` has run), with saves landing mid-build coalescing into one follow-up build, staged into a gitignored `docs/.dev-dist/` and synced in-place into `dist/` only on success (plain node fs, prune-then-copy — no rsync or any other external tool, so minimal WSL/container setups work) — a failed build prints a red banner + terminal bell and keeps serving the last good site rather than the emptied `outDir` a direct in-place build would leave — while `wrangler dev --live-reload` on :4321 (`DOCS_PORT` overrides; same default as before, so `docs/scripts/screenshot.mjs` and muscle memory still work; one-off `preview-docs` stays on :8787) picks up the asset changes live, new routes included, and refreshes the browser over its websocket. Each rebuild is a real production build with one deliberate exception: the loop sets `WAVEHOUSE_DOCS_WATCH=1`, under which `astro.config.mjs` drops `starlight-links-validator` — mid-edit prose always has dangling links, and failing every rebuild over them would mean never seeing the change being made; rendered output is identical, CI / `make build-docs` still enforce link validity, and `DOCS_WATCH_STRICT=1` keeps the validator on in watch builds for those who want broken links to fail loudly at edit time (the development.md tooling notes now spell out that split; build errors themselves — broken Mermaid, bad frontmatter, MDX errors — always fail the watch build loudly either way). The raw HMR dev server remains available as `pnpm --filter wavehouse-docs run start` for fidelity-insensitive iteration (e.g. CSS tweaking) — the VS Code launch config gains a second entry for it, with the existing `pnpm dev` entry relabeled to match its new behavior. + +- **Docs Mermaid diagrams render through a per-diagram disk cache** (`docs/astro.config.mjs`, `docs/package.json`, `pnpm-lock.yaml`; the cache itself ships in `astro-themed-mermaid` v0.2.0): diagram SSR runs headless Chromium via `rehype-mermaid` and re-rendered all 17 diagrams on *every* docs build — including builds that touched no diagram, i.e. almost all of them. The config now uses the package's new `mermaid.rehypeMermaid` export, which wraps `rehype-mermaid` with a content-addressed cache under `node_modules/.cache/astro-themed-mermaid/` (keyed on diagram source + render options + package versions, so theme and toolchain changes self-invalidate; entries are re-id'd to content-derived `mermaid-c` ids so cross-build entries can't collide on a page). A build whose diagrams all hit skips Chromium — and even the `rehype-mermaid`/playwright import — entirely: measured warm rebuilds drop from ~6–7s to ~3.7s, a single-diagram edit re-renders only its page (~5s), and output was verified byte-identical modulo SVG ids. Cold builds (fresh clone, CI, `make clean-tools`) render once and harvest; cache I/O is best-effort and degrades to a normal render, never a failed build. + +- **Docs-site analytics rebuilt: PostHog routed through the first-party relay, with CI-safe config and soft-nav-correct capture** (`docs/src/components/PostHog.astro` (new), `docs/src/components/HomepageCtaTracking.astro` (new), `docs/src/components/{Head,Hero,Footer}.astro`, `docs/src/content/docs/index.mdx`, `docs/astro.config.mjs`, `docs/.gitignore`, `docs/posthog-setup-report.md` (new), `.claude/skills/integration-astro-view-transitions/` (new, vendored), `scripts/docs-prose.sh`, `docs/src/content/docs/claude-code.md`): the hardcoded PostHog head snippet in `astro.config.mjs` (pointed straight at `us.i.posthog.com`) is replaced by a `PostHog.astro` component in the Starlight `Head` override, initialized behind a `window.__posthog_initialized` guard with `capture_pageview: 'history_change'` so ClientRouter soft navigations both survive re-init and capture pageviews (verified headless: `$pageview` fires with `navigation_type: pushState`). Analytics now route through the managed first-party reverse proxy `t.wave-rf.com` — the shared `*.posthog.com` ingest domains sit on ad-blocker lists — with `ui_host` keeping toolbar/app links on `us.posthog.com`. Configuration reads `PUBLIC_POSTHOG_PROJECT_TOKEN` / `PUBLIC_POSTHOG_HOST` (gitignored `docs/.env`) and falls back to committed values: CI builds the site with no PostHog env, so env-only wiring shipped a dead snippet to production — the committed `phc_` token is the public client token that ships in every served page by design, not a secret. Three click events are instrumented — `hero_cta_clicked` (`Hero.astro`), `footer_link_clicked` (`Footer.astro`), `homepage_cta_clicked` (`HomepageCtaTracking.astro`, extracted to a component because MDX parses `{` as JSX expression syntax and a raw ` +