|
| 1 | +--- |
| 2 | +title: "The search column holds stale results — a new agent search doesn't reload it" |
| 3 | +lede: "The identity-links crawl fills the third column and that's the right home for results — but the column then just stays there. Fire the people/team crawl next and the column keeps showing the previous search's candidates while the new results land somewhere else (or nowhere visible). One results surface, always showing the latest search, is the expectation." |
| 4 | +date_created: 2026-07-24 |
| 5 | +date_modified: 2026-07-24 |
| 6 | +authors: |
| 7 | + - Michael Staton |
| 8 | +augmented_with: |
| 9 | + - Claude Code on Claude Fable 5 |
| 10 | +semantic_version: 0.0.0.1 |
| 11 | +tags: |
| 12 | + - Issue |
| 13 | + - Usability |
| 14 | + - Augment-It |
| 15 | + - Search-And-Add |
| 16 | + - Didi-Crawl |
| 17 | + - Org-Workbench |
| 18 | +status: Open · Jotted |
| 19 | +--- |
| 20 | + |
| 21 | +# The search column doesn't follow the latest search |
| 22 | + |
| 23 | +## The symptom (operator-reported, 2026-07-24 evening) |
| 24 | + |
| 25 | +1. 🤖 crawl on identity links → the Search & Add column opens with |
| 26 | + candidates. Good — that column is where results belong. |
| 27 | +2. Fire the next agent search — the people/team crawl — and the column |
| 28 | + **keeps the old identity-links results**. Nothing tells the operator |
| 29 | + they're looking at a previous search; the new search's activity isn't |
| 30 | + reflected there at all. |
| 31 | + |
| 32 | +## Why (two designs colliding) |
| 33 | + |
| 34 | +- The links/streams crawls ride the Search & Add envelope |
| 35 | + (`augment-it:search-request`), so a NEW envelope does reload the column — |
| 36 | + but only those targets send one. |
| 37 | +- The **team crawl deliberately bypasses the column**: its candidates stage |
| 38 | + on the workbench's People section (`StagedPeople`), per the accept-gate |
| 39 | + design. Nothing clears or re-labels the Search & Add pane, so it sits |
| 40 | + frozen on the last envelope — stale results masquerading as current. |
| 41 | + |
| 42 | +The operator's mental model is simpler and better: **the third column is |
| 43 | +THE results surface; whatever agent search ran last is what it shows.** |
| 44 | + |
| 45 | +## Direction (jotted) |
| 46 | + |
| 47 | +- Either route team-crawl results into the column too (person-shaped rows |
| 48 | + with the same accept gate the staged section has — the column becomes the |
| 49 | + one home for every crawl's candidates), or |
| 50 | +- Keep the split but make the column state honest: a new agent action |
| 51 | + anywhere (team crawl included) clears or visibly supersedes the pane |
| 52 | + ("results from a previous search — re-crawl to refresh"), and the pane |
| 53 | + header always names the search that produced what's shown (target + org + |
| 54 | + when). |
| 55 | +- Either way, results want a timestamp/provenance line — "identity links · |
| 56 | + Quell Foundation · 5:35pm" — so stale can never impersonate fresh |
| 57 | + (the day's recurring stale-state theme; |
| 58 | + [[Crawl-Progress-Is-A-Black-Box-Needs-Traces-The-Operator-Can-Watch]] is |
| 59 | + the sibling on the same pane). |
| 60 | + |
| 61 | +## Open questions |
| 62 | + |
| 63 | +- [ ] Do person-shaped candidates belong in ResultRow (url-centric today) or |
| 64 | + does the column grow a second row type? (The component-library issue |
| 65 | + looms here.) |
| 66 | +- [ ] Should the column auto-clear when its launching org card changes |
| 67 | + (roster click elsewhere), independent of new searches? |
0 commit comments