feat(brand-claims): trigger prerequisite audits before an on-demand claims run (LLMO-7263)

[akshaymagapu]

What

When a trial customer requests an on-demand Brand Claims run (POST /sites/:siteId/llmo/brand-claims/request, LLMO-7263), fire the offsite-brand-presence and wikipedia-analysis audits before the brand-claims trigger, so mystique has fresh inputs when it runs claims extraction.

All three enqueue to AUDIT_JOBS_QUEUE_URL. The prerequisites are plain audit triggers ({ type, siteId, auditContext }); only the claims trigger carries onDemand: true. The audit-worker delays the on-demand claims ready-signal (850s) so the prerequisites land first - see adobe/spacecat-audit-worker#2943.

Coordination

No deploy-order dependency with the audit-worker change:

• If this ships first, claims simply runs without the added delay.
• If the audit-worker ships first, a claims run with no prerequisites is merely delayed 850s for nothing.

Neither order breaks.

Testing

• test/controllers/llmo/brand-claims.test.js and test/controllers/llmo/llmo.test.js - updated for the 3 sends, assert order (offsite-brand-presence, wikipedia-analysis, brand-claims), and that only the claims trigger carries onDemand. Existing cooldown/Slack paths unchanged.
• Tests passing, eslint clean. IT (test/it/postgres/brand-claims-request.test.js) does not exercise the 202 happy path, so no IT change.

🤖 Generated with Claude Code

[github-actions]

This PR will trigger a minor release when merged.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[MysticatBot]

Hey @akshaymagapu,

⚠ Degraded review - no spec document was found for this change (searched the PR links, the touched repos' docs, the architecture/guidelines docs, and linked Jira). This review covers code-level quality but could not validate the change against an agreed design, so confidence is reduced. Add a spec link (PR template section 4) and re-request review for a full-confidence pass.

Verdict: Request changes - one blocking finding on error-path observability for the new multi-send flow.
Complexity: MEDIUM - small diff; API surface signal.
Changes: Fires two prerequisite audit triggers (offsite-brand-presence, wikipedia-analysis) before the on-demand brand-claims trigger so mystique has fresh inputs (3 files).
Note: CI checks are currently failing (semantic-release, deploy-stage, branch-deploy) - resolve before merge.

Must fix before merge

1. [Important] Partial enqueue failure logs a generic error without naming which messages already landed - src/controllers/llmo/brand-claims.js:240 (details inline)

Non-blocking (1): minor issues and suggestions

• suggestion: Add a test where sqsSend resolves on the first call then rejects on the second, asserting 500 and verifying the partial-send path is covered - test/controllers/llmo/brand-claims.test.js

---

_{Skill: pr-review | Model: us.anthropic.claude-opus-4-6-v1[1m] | Duration: 4m 28s | Cost: $3.56 | Commit: 70f261835e28185e5f9467618cd133a66564f7c1
If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[MysticatBot]

issue (blocking): The three sendMessage calls are sequential inside one try/catch. If the first prerequisite succeeds but a later send fails, the catch returns 500 - but the error log says "failed to enqueue audit" without naming which messages already landed on the queue. An operator investigating a partial failure has no signal about what was sent.

Track which messages were sent before the failure:

let enqueuedTypes = [];
try {
  for (const type of BRAND_CLAIMS_PREREQUISITE_AUDIT_TYPES) {
    await sqs.sendMessage(queueUrl, {
      type, siteId: site.getId(),
      auditContext: { trigger: 'on-demand-brand-claims' },
    });
    enqueuedTypes.push(type);
  }
  await sqs.sendMessage(queueUrl, { /* claims trigger */ });
  enqueuedTypes.push('brand-claims');
} catch (sqsError) {
  log.error(`Brand Claims on-demand: failed after enqueuing [${enqueuedTypes.join(', ')}] for site ${site.getId()}: ${sqsError.message}`);
  return internalServerError('Brand Claims on-demand is temporarily unavailable');
}

The orphaned prerequisite audit is harmless (idempotent, no onDemand flag), so the external contract does not need to change - only the error log needs to reflect what actually happened.