Re-analyzing a single-report campaign (no sibling report exists yet) fell through to "create new campaign" because every tier query self-excludes the report's own row, so matchCampaignId stayed null and the report's still-valid campaign was abandoned in favor of a duplicate campaigns row sharing the same campaign_key. Add a guard that runs only when no sibling matched and the report already has campaign_id: recompute the report's current tier keys once, look up its own campaign row, and reuse it (created:false) when the stored campaign_key still matches. Falls through to create-new unchanged when the campaign row is gone or the signal has genuinely diverged. D-08 sibling upgrades are untouched (guard only runs when no sibling matched). - Tests A/B reproduce the exact CR-03 duplicate-campaign scenario and failed against the pre-fix code (confirmed during RED) - Tests C/D guard the create-new no-regression and signal-diverged fall-through paths |
||
|---|---|---|
| .. | ||
| hooks | ||
| services | ||
| types | ||
| utils | ||
| auth-client.ts | ||
| auth-utils.ts | ||
| auth.ts | ||
| bootstrap.ts | ||
| permissions.test.ts | ||
| permissions.ts | ||
| status-registry.ts | ||
| utils.ts | ||