Skip to content

Commit e28db4d

Browse files
mpstatonclaude
andcommitted
new(context-v, issues): the search column holds stale results — new agent searches don't reload it
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UvYzx7vDWeafnkAi2nEQeb
1 parent da85b8a commit e28db4d

1 file changed

Lines changed: 67 additions & 0 deletions

File tree

Lines changed: 67 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,67 @@
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

Comments
 (0)