← Corpus / augment-it / issue

Team-crawl accept drops the crawled links and leaves the staged row — double-save risk

`person.apply` writes `linkedin_profile_url` as a scalar only, so accept discards the crawl's links — and the staged row lingers.

Path
issues/Team-Crawl-Accept-Drops-Crawled-Links-And-Leaves-The-Staged-Row.md
Authors
Michael Staton
Augmented with
Claude Code on Claude Fable 5
Tags
Issue · Usability · Augment-It · Didi-Crawl · Persons · Org-Workbench

Team-crawl accept: links dropped, row lingers

The two symptoms (operator-confirmed, 2026-07-24 evening)

  1. Crawled links don’t save. The team crawl usually finds a LinkedIn URL (and often a bio page) per person. Accept runs person.apply + person.affiliate — and person.apply’s create branch writes linkedin_profile_url only as a scalar matching field (person-resolver.ts CREATE), never as a personal_links[] entry. The new person’s card shows zero links; the crawl’s best evidence is silently discarded.
  2. The accepted row stays staged. After accept the row flips to “added ✓” but remains in the staged list. The person now exists in the People list AND in the staged results — redundant state that invites a second save (via re-accept paths or operator confusion). An accepted row should be CONSUMED: it leaves the staged list; the person appearing in the People list above is the confirmation.

The fix (this doc precedes the implementation by minutes)

  • On accept, after apply + affiliate: add the crawled linkedin_url and bio_url to the person via the existing person.links.add — on created persons only (matched persons may already carry them; additive-not-duplicative, per [[Additive enrichment never overrides accepted|additive discipline]]). Link failures degrade soft — the person
    • affiliation are the core writes.
  • On success, remove the row from the staged list entirely (skip semantics). The “N staged” count and Done-clear affordance follow.