Keep an affiliate's removal sticky so they are not notified again

[gumclaw]

Stages

• Scope
• Design
• Build
• QA
• Shipped
• Market
• Sell

What

Ending a direct affiliation because the affiliate asked to be removed left no record on the row: a
soft-deleted DirectAffiliate is indistinguishable from one that never existed. So when the same
person is added again — by the seller in the dashboard, or by a bulk pass — AffiliateMailer mails
them again as if it were a first-time add, and there is nothing to point at when someone says
"please remove me and do not add me again".

Fix

• removed_at_request flag on Affiliate, using the existing affiliates.flags column (bit 4, no
  migration).
• DirectAffiliate#mark_removed_at_request! records it on the row being removed; the flag survives
  the soft delete, because nothing in the model hides deleted rows.
• DirectAffiliate#reassignment_blocked? is true when any row for the same
  (seller_id, affiliate_user_id) carries it, so it holds across a re-add and tells a repeat
  requester apart from a first-time one.
• AffiliateMailer returns early for the three "here is your affiliation" mails when it is true:
  direct_affiliate_invitation, notify_direct_affiliate_of_updated_products,
  notify_direct_affiliate_of_new_product.

Deliberately not changed, so a reviewer can disagree with the scope rather than discover it:

• A re-add is flagged, not refused. Refusing is seller-visible and a product call; the person's
  request is honoured by not mailing them.
• The seller's own remove does not set the flag — that is the seller ending a relationship, not the
  person opting out. Suppressing on it would silently drop people from later launches.
• Sale notices and the removal notice still send: they are transactional, and the person can still
  earn.

Before / After

Backend-only, no rendered surface: the observable is the mailer's return value, asserted as
ActionMailer::Base::NullMail in the specs below.

Test Plan

• Added regression test for this bug
• Existing tests still pass
• Manual verification of the fix

CI=1 bin/bundle exec rspec spec/models/direct_affiliate_spec.rb spec/mailers/affiliate_mailer_spec.rb

Local: 101 examples, 7 failures — the same 7 as origin/main in a fresh worktree of the same
commit range (92 examples, 7 failures): #notify_affiliate_of_sale (5), #product_sales_info and
#products_data, all unrelated to this diff and failing without it. Everything this PR touches
passes, including the 9 new examples (6 model, 3 mailer). rubocop on the five touched files: no
offenses.

QA

• Mutation probes: (a) forcing DirectAffiliate#reassignment_blocked? to false fails 4 of the 7
  new examples (7 examples, 4 failures) — the three that still pass are the negative cases (another
  seller, another person, nobody removed); (b) reverting mark_removed_at_request! to update!
  fails the legacy-row example (1 example, 1 failure). The specs bite.
• No rendered surface — the observable is the mailer return value, so specs plus rubocop are the
  evidence; nothing to screenshot.

Premerge review: clean @ 273afe2 — panel, codex gpt-6-astra
(thinking high) 0 findings, claude claude-fable-5-1 0 findings, overall: patch is correct (0.98).

Risk Assessment

Low — on every path this can only remove a recipient from three mails; no send becomes newly
possible, and no seller-visible behaviour changes. The blast radius is affiliate mail to
(seller, person) pairs that someone explicitly recorded as asked-to-be-removed.

---

AI disclosure

🤖 Generated with deepseek-v4.1-flash (DeepSeek, via OpenRouter), running an autonomous
product-development session.
Prompts/instructions given: the standing autonomous product-dev workflow, applied to the observed
behaviour above; all code, tests and this body were written by the agent.

[greptile-apps]

Confidence Score: 4/5

The PR is not yet safe to merge because the production self-removal path still soft-deletes the affiliation without recording the removal request.

Findings

1.  Removal Flag Is Never Set ▶

Fix with agent prompt

### Issue 1
app/models/direct_affiliate.rb:160-163
`mark_removed_at_request!` is never called by the production self-removal flow. `Products::AffiliatedController#destroy` soft-deletes the affiliation by updating only `deleted_at` and `updated_at`, so the new flag is not recorded. If the seller later re-adds that affiliate, `reassignment_blocked?` remains false and the invitation and product-update emails are sent again. The tests miss this because they set the flag directly instead of exercising the real removal flow.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

This PR adds a persistent affiliate removal-request flag and suppresses affiliation emails after a matching seller-affiliate relationship is recreated. The latest change bypasses model validations while recording that flag on legacy rows.

• Adds removed_at_request to the existing affiliate bit flags.
• Checks historical matching affiliations before sending invitation or product-assignment emails.
• Adds model and mailer coverage for persistent opt-outs and validation-invalid legacy rows.
• The production self-removal flow still does not call the new flag-recording method.

Diagram

sequenceDiagram
  participant Affiliate
  participant Controller as Products::AffiliatedController
  participant Record as DirectAffiliate
  participant Mailer as AffiliateMailer

  Affiliate->>Controller: Request removal
  Controller->>Record: Soft-delete affiliation
  Note over Controller,Record: removed_at_request is not recorded
  Controller->>Mailer: Send removal confirmation
  Note over Record: Seller later recreates affiliation
  Mailer->>Record: reassignment_blocked?
  Record-->>Mailer: false
  Mailer-->>Affiliate: Affiliation email sent again

Loading

_{Reviews (2) · Last reviewed commit: "fix(affiliates): record the opt-out with..."}

[greptile-apps]

Removal Flag Is Never Set

mark_removed_at_request! is never called by the production self-removal flow. Products::AffiliatedController#destroy soft-deletes the affiliation by updating only deleted_at and updated_at, so the new flag is not recorded. If the seller later re-adds that affiliate, reassignment_blocked? remains false and the invitation and product-update emails are sent again. The tests miss this because they set the flag directly instead of exercising the real removal flow.

Prompt To Fix With AI

This is a comment left during a code review.
Path: app/models/direct_affiliate.rb
Line: 160-162

Comment:
**Removal Flag Is Never Set**

`mark_removed_at_request!` is never called by the production self-removal flow. `Products::AffiliatedController#destroy` soft-deletes the affiliation by updating only `deleted_at` and `updated_at`, so the new flag is not recorded. If the seller later re-adds that affiliate, `reassignment_blocked?` remains false and the invitation and product-update emails are sent again. The tests miss this because they set the flag directly instead of exercising the real removal flow.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.