fix(revenue-analytics): Add guardrails for revenue analytics setup prompt#107
Conversation
client_reference_id as posthog distinct_id
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
gewenyu99
left a comment
gewenyu99
left a comment
There was a problem hiding this comment.
1 more thing to ask for. @arthurdedeus what do you want this wizard skill to do if they have stripe but don't have stripe properly set up?
Should the wizard try to fix it for them or do nothing?
|
Added this to help lock down on invalid integration starting points |
|
|
||
| ## 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. No newline at end of file |
There was a problem hiding this comment.
Yah, tested and works pretty reliably. I think there are times where running til completion will cause the wizard to try its hardest to complete the task. It should really just give up xD instead of hallucinating stripe
| Follow these tenets for every decision: | ||
|
|
||
| 1. **Never fabricate the value.** If the PostHog distinct_id is not available in the current scope, do NOT substitute another identifier (Stripe customer ID, internal user ID, org ID, etc.). A wrong value is worse than no value — it corrupts metadata and blocks correct identification downstream. | ||
| 1. **Never fabricate the value.** If the PostHog distinct_id is not available in the current scope, do NOT substitute another identifier (Stripe customer ID, internal user ID, org ID, etc.). A wrong value is worse than no value — it corrupts metadata and blocks correct identification downstream. Bring in the exact same identifier as used in the PostHog integrations. |
There was a problem hiding this comment.
Intriguing. but what about the case where the identifier is not available? The saga of useEffect is instructive here: no amount of scolding mattered until we gave it a redirect.
perhaps in this case: "If no identifier is available, insert an obvious placeholder for the user to fix"
unless that condition is genuinely not going to ever hit?
There was a problem hiding this comment.
Oh I can add that. The wizard should generally be able to find identifiers easily. It would be wild for an app to not have the relevant ids readily available where they implement payments
|
|
||
| 4. **Follow existing Stripe abstraction patterns.** If the codebase wraps Stripe calls behind a utility/service layer, modify that layer. Don't call the Stripe API directly from business logic just to set metadata. | ||
|
|
||
| 5. **Never refactor unrelated existing code.** The only parts of the codebase that should be changed are the ones immediately related to getting PostHog distinct_id into Stripe calls. All remaining code should be left as is regardless. |
4 participants
We noticed some gaps/erros after the test run, so this PR should cover them