Distinguish a real user-dismiss from a pipeline regeneration (status=deleted conflates them)

[mikkeline-elleby]

Severity: 🟠 inflates the "dismissed" count
Group C — Postgres prompts

Problem

The prompts table has one status=deleted flag that mixes (a) a customer really rejecting a prompt with (b) the pipeline regenerating and superseding an old prompt with a near-duplicate. Any acceptance dashboard reading status=deleted as "dismissed" over-counts rejections.

Evidence

Both the user-dismiss and the pipeline-regeneration go through the same two functions, with no reason recorded — which is exactly why they're indistinguishable:

• softDeletePrompt → src/support/prompts-storage.js:1287 .update({ status: 'deleted', updated_by })
• bulkSoftDeletePrompts → src/support/prompts-storage.js:1331 (same update)

Independent detection (from analysis): superseded deletions sit at cosine ≈1.00 to a still-kept prompt; for some brands the deleted rows are dominated by regeneration.

Implementation

Add a deleted_reason (user_dismiss | superseded) — or a superseded_by / superseded_at pointer — param to those two functions, and have the regeneration caller pass superseded while the UI dismiss passes user_dismiss. Precedent already in this repo: superseded_at is used on another entity (src/dto/audit-policy.js:76).

Retrieval impact

The true dismiss count isn't retrievable — status=deleted returns real rejects + pipeline regenerations mixed together, inflating "dismissed".

Definition of done

A dismissed-because-rejected prompt is distinguishable from a regenerated one; acceptance metrics count only real dismisses.

---

Related epic: adobe/project-elmo-ui#3108.

[aliciadriani]

Review — distinguish a real user-dismiss from a pipeline regeneration

Verdict: right problem, but the discriminator already exists server-side — this should be "persist the actor/reason we already compute," not "add a new mechanism." I checked against the current prompts code and the delete path.

The signal isn't missing — it's just not on the row

• logPromptDeleteEvent already captures the actor (SITES-50099, src/support/serenity/prompt-delete-log.js) — every delete emits callerId, outcome, and alreadyGone, and origin-derivation already classifies human vs service principal at the write boundary. So user-dismiss vs pipeline-regen is computed today and thrown away into CloudWatch instead of written to Postgres. 👍 for the diagnosis; the fix is narrower than the title implies.
• PR feat(serenity): reliable Semrush workspace access-check endpoint (LLMO-6747) #2994 is the home. The dismiss-reason enum already in flight is where this belongs — fold this in rather than opening a parallel path.

Constraints to bake in

• ⚠️ Don't overload status. It's a 3-value enum (active | pending | deleted) and every list read filters .neq('status', 'deleted') (src/support/prompts-storage.js:678) — adding dismiss/regen values to status breaks those filters. Use a separate reason/actor column.
• Forward-only. Existing deleted rows can't be retro-classified, so the historical dismissed-count stays polluted after ship — worth stating so the dashboard side doesn't expect a clean back-series.

Suggested acceptance criterion

• A dismissed prompt and a regenerated-away prompt land with distinguishable reason codes on the row, sourced from the same actor classification the delete log already emits (assert the two agree).

Two questions:

1. Do you want the reason on the prompt row itself, or on a separate decision/audit row that also carries decided_at (ties into chore: retire the legacy Semrush proxy host from examples, tests, and docs #3109)?
2. Should this ride PR feat(serenity): reliable Semrush workspace access-check endpoint (LLMO-6747) #2994, or stay separate and depend on it?