frontend/generate-runtime-config.sh (1)

20-20: 💤 Low value

Consider logging the enablePosthog value for debugging parity.

The echo statement logs logoUrl but not the new enablePosthog setting. Adding it would help operators verify PostHog state at container startup.

🔧 Suggested enhancement

-echo "Runtime configuration generated successfully with logo URL: ${VITE_CUSTOM_LOGO_URL:-${REACT_APP_CUSTOM_LOGO_URL:-<not set>}}"
+echo "Runtime configuration generated successfully with logo URL: ${VITE_CUSTOM_LOGO_URL:-${REACT_APP_CUSTOM_LOGO_URL:-<not set>}}, enablePosthog: ${VITE_ENABLE_POSTHOG:-${REACT_APP_ENABLE_POSTHOG:-<not set>}}"

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/generate-runtime-config.sh` at line 20, Update the runtime config
echo to also print the PostHog enable flag for startup debugging: read the
enablePosthog value from the same env precedence used elsewhere (e.g.,
VITE_ENABLE_POSTHOG with fallback to REACT_APP_ENABLE_POSTHOG) and append it to
the existing log message that currently prints the logo URL (the echo line).
Ensure the message clearly labels the flag (e.g., "enablePosthog: <value>") so
operators can verify PostHog state at container startup.

frontend/src/hooks/usePostHogEvents.js (2)

67-69: ⚡ Quick win

Add a defensive guard when both email and IDs are unavailable.

If email is falsy and either orgId or userId is undefined, the distinctId becomes malformed (e.g., "undefined:undefined"), which would merge all such edge-case users into one PostHog person and corrupt analytics.

Consider early-returning or logging if no usable identifier exists:

Suggested guard

+    if (!email && (!orgId || !userId)) {
+      // Insufficient identity data; skip PostHog identification
+      return;
+    }
     const distinctId = email || `${orgId}:${userId}`;

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/hooks/usePostHogEvents.js` around lines 67 - 69, The distinctId
logic in usePostHogEvents.js can produce "undefined:undefined" when email is
falsy and orgId/userId are missing; update the hook (usePostHogEvents) to
defensively check before building distinctId: require either a truthy email or
both a non-empty orgId and userId, and if neither condition holds, early-return
(skip sending/posting events) and log a warning via the same logger used in this
hook; ensure all places that reference distinctId use the validated value so
malformed identifiers are never sent to PostHog.

---

85-93: ⚡ Quick win

Wrap PostHog calls in try-catch for consistency.

setPostHogCustomEvent already guards posthog.capture with a try-catch (lines 97-101), but identify and register are unguarded. If PostHog is disabled at runtime or the SDK is in an unexpected state, these calls could throw. Apply the same defensive pattern here.

Suggested change

-    posthog.identify(distinctId, personProperties);
-
-    // Super-properties ride on every captured event, enabling org-level
-    // breakdowns without the group analytics add-on
-    posthog.register({
-      org_id: orgId,
-      org_name: orgName,
-      software,
-    });
+    try {
+      posthog.identify(distinctId, personProperties);
+
+      // Super-properties ride on every captured event, enabling org-level
+      // breakdowns without the group analytics add-on
+      posthog.register({
+        org_id: orgId,
+        org_name: orgName,
+        software,
+      });
+    } catch {
+      // PostHog tracking is non-critical, safe to ignore
+    }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@frontend/src/hooks/usePostHogEvents.js` around lines 85 - 93, Wrap the
unguarded posthog.identify(distinctId, personProperties) and
posthog.register({...}) calls in the same defensive try-catch pattern used by
setPostHogCustomEvent so SDK errors don't bubble up; locate the calls in
usePostHogEvents.js (the posthog.identify and posthog.register lines), surround
each (or both together) with try { ... } catch (err) { /* log the error
similarly to setPostHogCustomEvent — e.g., console.error or existing logger with
context */ } to mirror existing error handling.