Stop re-researching the same person every tick

[ralyodio]

#61 had a defect I only saw in production. Automating the approval turned a visible backlog into an invisible loop.

A refresh_research card is proposed because we have nothing to say about someone. Approving it re-reads their company's site. If that still yields nothing, the next pass proposes the same card again.

While a human had to click, those cards piled up — production held 179 — and at least the waste was in plain sight. Closing the loop turned it into crawl traffic nobody watches.

Measured in prod, minutes after the deploy

auto-approvals	211
max cards for one person	3
crawl jobs queued	195

The backlog dropped 152 → 7, then climbed 7 → 15 → 25 → 35 on successive samples. That is the loop.

The fix

A person researched inside the last 24 hours has their card closed rather than approved, and no crawl is spent.

skipped, not approved — approving would claim we went and looked, and the status already means "over without having been acted on".

Counted from actions rather than crawl jobs, which matters twice: a card a human approved an hour ago suppresses the automatic re-run too, and a person whose company has no domain — whose card therefore never produced a job — is still covered.

24 hours because that is the shortest interval over which a company website plausibly changes. Shorter re-reads the same bytes; much longer delays picking up a real change.

Two existing tests changed, and both were wrong rather than the code

• one inserted an actions row without the NOT NULL recommendation_id
• one asserted five cards for a single person all approve — now one approval and four cooldowns, which is the correct new behaviour

Verification

• bun test — 1367 pass, 0 fail across 90 files
• typecheck and format:check clean
• 4 new tests, including the loop itself: approve → card returns → second pass spends no crawl and closes it

🤖 Generated with Claude Code