chore(build): dev build tooling — gitignore artifacts + PostHog bundle verification

[aafre]

Summary

Two small, independent improvements to dev build/test tooling, broken out of the v3.25.0 release prep so they can ship on their own schedule.

Commit 1 — .gitignore

• Ignore test-screenshots/ and .playwright-mcp/ — these directories accumulate during MCP-driven browser testing and should not be tracked.

Commit 2 — scripts/build-dev.{ps1,sh}

• Better env output: section header + aligned columns + color coding (PowerShell). Easier to spot missing values at a glance.
• Show truncated values for VITE_SUPABASE_PUBLISHABLE_KEY, SUPABASE_URL, SUPABASE_SECRET_KEY — confirms they're set without leaking the full secret.
• Flag VITE_POSTHOG_KEY missing as a build-time warning (red text in PowerShell, asterisks in bash).
• Verify PostHog in JS bundle after build: greps the built static/assets/*.js for "posthog" and warns if not found. Catches the silent-regression class where VITE_POSTHOG_KEY is empty at build time and analytics fail to ship — exactly the kind of thing that's invisible until prod.

Why now

While prepping the v3.25.0 release (PR #463), it became obvious the dev build script wasn't surfacing enough information to catch env-var problems early. These changes don't gate on the release — shipping them now means the next dev rebuild already benefits.

Why not bundled into #485 / #486 / #488 / #489 / #471

None of those PRs are about build tooling. Per CLAUDE.md commit style ("If changes touch multiple concerns, split into multiple commits") — and applying the same logic at PR scope.

Test plan

• .gitignore works: git check-ignore test-screenshots/foo.png returns the path
• PowerShell: run scripts/build-dev.ps1 locally → verify formatted env output, color-coded PostHog status
• Bash: run scripts/build-dev.sh in WSL/Linux → same checks
• Build with VITE_POSTHOG_KEY empty → confirm red/asterisk warning + post-build "PostHog NOT FOUND" message
• Build with VITE_POSTHOG_KEY set → confirm green/check + "PostHog FOUND in JS bundle"

[gemini-code-assist]

Code Review

This pull request updates the .gitignore file and enhances the development build scripts for both PowerShell and Bash. The changes improve the visibility of environment variables during the build process and add a verification step to confirm that PostHog is correctly bundled in the Docker image. The review feedback highlights potential runtime exceptions in the PowerShell script when using .Substring() on short or null strings and suggests using regex for safer truncation. Additionally, a correction was suggested for the Bash script to prevent host-side glob expansion when running grep inside a Docker container.

I am having trouble creating individual review comments. Click here to see my feedback.

scripts/build-dev.ps1 (63)

Calling .Substring(0, 16) on a string that is shorter than 16 characters or is null will cause a PowerShell runtime exception, crashing the build script. A safer way to truncate is using a regex replace which handles short or null strings gracefully and only adds ellipses if truncation actually occurs.

Write-Host "  VITE_SUPABASE_PUBLISHABLE : $($VITE_SUPABASE_PUBLISHABLE_KEY -replace '^(.{16}).*$', '$1...')"

scripts/build-dev.ps1 (68)

Similar to the previous issue, .Substring(0, 12) will throw an exception if the key is shorter than 12 characters. Using a regex replace is safer.

    Write-Host "  VITE_POSTHOG_KEY          : $($VITE_POSTHOG_KEY -replace '^(.{12}).*$', '$1...')" -ForegroundColor Green

scripts/build-dev.ps1 (73)

This line will also crash if SUPABASE_SECRET_KEY is null or shorter than 12 characters.

Write-Host "  SUPABASE_SECRET_KEY       : $($SUPABASE_SECRET_KEY -replace '^(.{12}).*$', '$1...')"

scripts/build-dev.sh (82)

The glob /app/static/assets/*.js is not quoted, meaning the host shell (bash) will attempt to expand it before passing the command to docker run. Since these files likely do not exist on the host at that path, the glob will either fail or pass a literal *.js to the container, causing grep to fail. It is safer to point grep -r to the directory directly, as done in the PowerShell version of this script.

if docker run --rm "$IMAGE_NAME:$TAG" grep -rl "posthog" /app/static/assets/ > /dev/null 2>&1; then