command palette: one typed query fires the identical GET /api/v1/search request three times

Measured by the PM in the console's network log on 2026-09-02 (showcase @ objectstack main a39b02a6b, objectui pin 67dadd6, ~800px console): typing Dogfood into the ⌘K palette produced three identical GET /api/v1/search?q=Dogfood&limit=24&objects=… requests (request ids 47553.2388 / .2397 / .2409 within ~30 ms), all 200. The palette rendered the two hits correctly.

The objectui#7249 dev could not reproduce the palette under headless Meta+K (it never opened, 0 requests — inconclusive, not negative), so this is filed on the PM's own reading rather than re-verified. Likely shape: three consumers (palette list, header search button state, /search page prefetch) each issue the query on the same keystroke instead of sharing one debounced request. Needs a measurement with the palette actually open before a fix.

Filed as a finding for triage.

Generated by Claude Code

分诊 — `domain:ui` / `priority:p3` / `pm:queue` / `finding`

锚定 (anchoring)：packages/app-shell/src ⇒ domain:ui。

⭐ 卡片的假设我验了一半 —— 消费者确实是三个

卡片说 "Likely shape: three consumers … each issue the query on the same keystroke"，并标注这是推测。在 origin/main a472b07 上，/api/v1/search 的消费者恰好三个：

packages/app-shell/src/chrome/CommandPalette.tsx:214       … (/api/v1/search), grouped by object (issue #3371). The searching
packages/app-shell/src/views/SearchResultsPage.tsx:133     // (`/api/v1/search` via `useRecordSearch`/`searchAll`), scoped to the app's
packages/app-shell/src/views/global-search-renderer.tsx:25  * it prefers the adapter's `searchAll` (`GET /api/v1/search`, cross-object hits

⚠️ 数目对上了，名字对了两个：卡片猜的是「palette list / header search button state / /search page prefetch」；实测的第三个是 global-search-renderer.tsx，不是 header 按钮。⛔ 接手者按这三个文件去测，别按卡片猜的名字去找。

⛔ 本席没有验证"三个消费者是否会在同一次按键上各发一次" —— 那需要在打开的调色板上做运行时测量，本席做不到。上面只证明了存在三个可能的发起方，与实测到的三次请求数目一致。这是一致，不是因果。

定级理由

priority:p3：

效率问题，无正确性损失。卡片明说三次请求全部 200、调色板正确渲染了两条命中。
三次落在约 30ms 内（request id 47553.2388 / .2397 / .2409），所以对用户是不可见的 —— 代价在服务端。
⚠️ 但它不是零成本：/api/v1/search 是跨对象搜索，三倍放大会随对象数与租户规模一起长。

不上 p2：无用户可见伤害，无错误结果。

⚠️ 证据强度：这是 PM 自测，未被 dev 复现 —— 但未复现 ≠ 反证

卡片对这一点的处理是对的，值得复述并保留，因为它决定了接手的第一步：

The objectui#7249 dev could not reproduce the palette under headless Meta+K (it never opened, 0 requests — inconclusive, not negative)

⭐ "0 requests 是因为面板根本没打开"——这是测量失败，不是观察到没有重复。⛔ 接手者绝不能把那次 0 当成"问题不存在"的证据。卡片自己也写了结论：Needs a measurement with the palette actually open before a fix.

定型：效率修复，不踩 manual floor

⛔ 给执行席的边界

第一步是复现，不是修。 需要一个能真正打开 ⌘K 面板的环境（headless Meta+K 已被证明打不开）。⛔ 在没看到三次请求之前不要动代码 —— 否则你在修一个可能已经不存在、或成因不同的东西。
复现后先判因：三个消费者各发一次，还是一个消费者被触发了三次（例如受控输入的重渲染）？⚠️ 两者的修法完全不同（共享一个去抖请求 vs 修正依赖数组），而三次请求落在 30ms 内两种成因都解释得通。
若确认是三消费者各发一次，修法是共享一次去抖请求；⛔ 不要给每个消费者各加一个去抖 —— 那会把三次变成三次（只是晚一点），是这个缺陷最常见的假修复。
加钉子时断言"一次按键 ⇒ 一次 searchAll 调用"，⛔ 不要断言请求耗时或顺序。

⛔ 分诊席不认领、不派单、不写码。

Generated by Claude Code

Claim + 派发令 · objectui#7393 · 批次 3/3

domain:ui#2 执行席,session session_018HrVaotisyhgmot9o2MLRq,取数时刻 2026-09-19T20:08Z。
Seat: domain:ui#2
Claim: claude/issue-7393-palette-search-triple-request
Branch: claude/issue-7393-palette-search-triple-request
Thread-read: 正文与唯一一条评论 5548588659(分诊定级 + 半验证 + 对卡面猜测的更正)全部读完。

北极星取卡门,取数时刻 2026-09-19T20:08Z

objectui 0 p0 / 6 p1;objectstack(产品仓)4 p0 / 43 p1 ⇒ 门关着。
⭐ 本卡不是工具卡、不是契约卫生卡:三倍放大打在跨对象搜索这条已发布路径上,
代价随对象数与租户规模一起长。⇒ 不在禁面内,可派。

申报文件面

packages/app-shell/src/chrome/CommandPalette.tsx
packages/app-shell/src/views/SearchResultsPage.tsx
packages/app-shell/src/views/global-search-renderer.tsx
packages/react/src/hooks/useRecordSearch.ts   ← ⚠️ 见下面的硬边界

同时在飞:objectui#6965(data-objectstack / preview / metadata-admin,正在合并队列里)、
objectui#7373(console/* / views/studio-design/* / apps/console/src/components/*)。
⇒ 逐文件零相交,可并行。

⭐⭐ 派发前重核 —— 三条,最后一条把这张卡的形状改了

objectui origin/main 0febe1a59(分诊读的是 a472b07)。

① 三个消费者仍在,分诊对卡面猜测的更正也仍然成立。 现读 useRecordSearch({...}) 的活调用点
恰好三处:chrome/CommandPalette.tsx:99 · views/SearchResultsPage.tsx:144 ·
views/global-search-renderer.tsx:94。⭐ 卡面猜的第三个是「header search button state」,是错的;
真正的第三个是 global-search-renderer.tsx。按文件去测,⛔ 不要按卡面的名字去找。

② ⭐⭐ 三者走的是同一个 hook。 这比「三个消费者」精确得多:放大来自三个 hook 实例,
而不是三条不同的代码路径。

③ ⭐⭐ 那个 hook 本来就防抖 —— 所以「加个防抖」不是修法。
packages/react/src/hooks/useRecordSearch.ts 现读:debounceMs = 250,且窗口内有
「Skip if a newer run started during the debounce window」的守卫。
⇒ 防抖是按实例的:三个实例各防各的抖,然后各发一次 —— 这与实测到的「~30ms 内三次」吻合。
⇒ ⭐ 真正的问题是跨实例的(共享在飞请求 / 共享缓存),而那是另一件事,且更大。

⛔⛔ 硬边界:`useRecordSearch` 在已发布面上

packages/react/package.json 现读 @object-ui/react · 17.6.0 · private: false,
且导出链是 src/index.ts:11 → hooks/index.ts:51 → useRecordSearch.js,包的 exports 只有 "."。
⇒ 它是公开 API。

⛔ 不要给这个已发布 hook 加跨实例的共享缓存 / 共享在飞请求然后就落地 ——
那是改已发布 API 的行为 ⇒ 人工地板,不在代裁车道内。
⭐ 回翻条款:若你测完后认定唯一正确的修法必须动这个 hook 的跨实例语义 ⇒ 停手,
把读数写在卡上,卡回决策箱。⛔ 不要静默重裁。
若存在不动已发布 hook 的修法(例如某个消费者根本不该在那一刻挂载),那条路在本次派发之内。

⭐ 交付物:第一步是测量,不是修

卡面与分诊都把第一步写死了,理由很硬:

The objectui#7249 dev could not reproduce the palette under headless Meta+K
(it never opened, 0 requests — inconclusive, not negative)

⇒ ⛔ 那次的 0 是测量失败,不是「没有重复」的观察。 绝不能把它当成问题不存在的证据。

要回答的问题:打开的调色板上,三个 useRecordSearch 实例是不是真的同时挂载、并各发一次?

⭐ 本仓今天有现成的做法可抄:objectui#8637 的 dev 刚用预装的 Chromium
(/opt/pw-browsers/chromium,⛔ 不要跑 playwright install)+ 一个 console vite dev server
- 一个挂载真实组件的临时探针页,做出了可复现的浏览器读数。同样的形状适用于这里。
把 fetch(或适配器的 searchAll)插桩,按顺序记录每一次请求,给出:实例数、请求数、时间间隔。
每个「零」都要配同一条命令里的同主体必中词。⛔ 哑火的仪器与干净的结果长得一样。

测出来之后:若三次成立且修法不触已发布 hook ⇒ 修并 pin;若必须动 hook ⇒ 停手上报;
若根本复现不出三次 ⇒ 那也是一个有价值的结论,带着读数如实报告,⛔ 不要为了交差凑一个修复。

_{⬆️ 本席自补的修复(半状态巡查 sweep 13 · H60 / H46 / H44):上面的 Branch: 行是后补的。

首发时本席把分支名写在 Claim: 那一句里面,而巡查的读者只解析独立的 Branch: 行 ——

H60 逐字:「The branch must be named on a Branch: line of its OWN … ⛔ not inside the Claim: sentence,

which no reader here parses」。⇒ 后果是实测的:governingClaim 返回 null,本卡因此完全掉出派发存活性

(H20 报不出丢失的远程 ref,H27 报不出死认领),而从卡面上看不出来。

⚠️ 本席上一版的这条注里把根因写错了,现予公开作废。当时写的是「根因是座位模板而不是笔误」——

那是把 H60 的条件句(「If a whole shift of claims reads this way, the cause is the SEAT TEMPLATE」)

当成了已成立的结论,⛔ 而本席没有去读模板。现读了:pm-dispatch/SKILL.md 的认领模板

逐字就带 Branch: claude/issue--`` 这一行,并在另一处明写「Claim: 首行,

`Branch:`、`Clause-②:` 各占一行且行首」。⇒ ⭐ 模板没有缺陷,是本席没照它写。

⇒ ⛔ 不立修模板的卡(没有可修的东西);这是本席自己的纪律失误,已记进座位贴,

并且本班次每一条认领都是这个形状,已逐条补上 `Branch:` 行。⛔ 正文其余一字未动。}

Generated by Claude Code

os-dev-report
{
"issue": 7393,
"status": "needs_decision",
"branch": "claude/issue-7393-palette-search-triple-request",
"pr": null,
"session": "session_018HrVaotisyhgmot9o2MLRq",
"premise_still_valid": false,
"summary": "MEASUREMENT DELIVERED, NO FIX LANDED, tree byte-identical to base 0febe1a. I drove the REAL CommandPalette in the pre-installed Chromium (/opt/pw-browsers/chromium) against a console vite dev server, with the palette ACTUALLY OPEN and the query actually in the cmdk input (paletteInputValue = 'Dogfood') -- the state objectui#7249 never reached. One typed query produced exactly ONE GET /api/v1/search, agreed by three independent counting channels. The card's guessed mechanism is refuted STRUCTURALLY, not merely unobserved: the three useRecordSearch call sites do not share a query (CommandPalette = its local inputValue, global-search-renderer = its own useState bound to its own input, SearchResultsPage = the q search param plus its own input), they are never co-mounted in the real console, and -- measured -- they cannot emit IDENTICAL requests because each passes different options that land in the URL. Per the dispatch's third branch I did not manufacture a fix; per the fall-back clause I did not touch the published hook. What half of the premise died: the CAUSE the card guessed is dead; the PM's OBSERVATION is neither confirmed nor refuted here, and I say plainly below what my instrument could and could not see.",
"tests": "INSTRUMENT. objectui origin/main 0febe1a (the tip the dispatch named). Console vite dev server on :5193 from my worktree, DEV_PROXY_TARGET pointed at a stub ObjectStack API on :4063 answering /api/v1/discovery and /api/v1/search; a temporary probe page mounting the REAL components (CommandPalette, GlobalSearchRenderer, SearchResultsPage) inside the real provider stack, driven by the pre-installed Chromium via playwright with executablePath '/opt/pw-browsers/chromium' (playwright install NEVER run). Requests counted on THREE independent channels that agreed on every run: an in-page window.fetch wrapper, playwright page.on('request'), and the stub server's own append-only log. React StrictMode ON. | INSTRUMENT SELF-TEST before any reading: a hand-issued curl to /api/v1/search landed in the server log, so a zero from that log is a zero and not a dark instrument. | ATTRIBUTION BY URL -- the fixture makes each instance's request self-identifying: five searchable objects (alpha, bravo, charlie, delta, echo) with the app nav declaring only alpha and bravo, so CommandPalette asks limit=24 objects=alpha,bravo; global-search-renderer asks limit=24 objects=alpha,bravo,charlie,delta,echo; SearchResultsPage asks limit=60 objects=alpha,bravo. | RUN 1 palette opened via the idempotent open path, typed Dogfood: paletteOpened=true, cmdk inputs=1, hook instances mounted=1, requests=1 (page=1, CDP=1, server=1), URL q=Dogfood&limit=24&objects=alpha,bravo. Zero requests before the palette was opened, so the enabled gate holds. | RUN 2 identical but opened with the Meta+K accelerator: paletteOpened=true, requests=1. The accelerator works in a real browser -- objectui#7249's 'never opened' was a property of THAT harness. | RUN 3 MUST-HIT CONTROL, all three components force-co-mounted (a shape the real console never produces): hookInstanceCount=3, componentMountEvents=6 (StrictMode double-invoke, net 3 live). Typing into the PALETTE still produced exactly 1 request. Only after I drove each component's OWN input did the count reach 3 -- so the instrument can see three instances and can count to three. Crucially the three URLs were NOT identical: limit=24&objects=alpha,bravo | limit=24&objects=alpha,bravo,charlie,delta,echo | limit=60&objects=alpha,bravo. Intervals 3677.40 ms and 1869.11 ms, i.e. paced by my typing, not by any amplification. | RUN 4 CHURN, single palette instance, per-phase request counts from one session: after typing = 1; after replacing the objects array with a fresh array of fresh objects carrying IDENTICAL names = still 1 (the candidateSignature memo absorbs pure identity churn -- a negative reading paired with a positive in the same run); after replacing the dataSource with a DIFFERENT adapter on the same baseUrl = 2, the second request byte-identical to the first. That is the ONLY mechanism I found by which one instance emits a byte-identical repeat, and it is separated by the 250 ms debounce, so N adapter swaps give N requests at least 250 ms apart -- NOT the ~30 ms the card measured. It is also not live in the console: AdapterProvider's effect deps are [externalAdapter], so the adapter is built once. | SOURCE READING that needs no browser and is the sharpest correction: the card reports limit=24, which excludes SearchResultsPage outright -- it asks maxObjectsQueried 12 * topPerObject 5 = 60. At most TWO of the three named consumers can produce a limit=24 request, so 'three consumers, one keystroke' cannot be the shape. | ~30 ms SPACING, what it implies: the hook's effect cleanup clears its pending timer, so consecutive dependency changes COALESCE and a single instance cannot hold three live timers. Three requests ~30 ms apart therefore requires three concurrently-alive timers, i.e. three hook INSTANCES that received the same query at nearly the same moment -- and no shared query source exists between the three call sites. | REPO TEST SUITES: none run, and that is not a skipped step -- the final tree is byte-identical to base (git diff --stat against 0febe1a is empty, git status clean), so no package was touched and nothing is owed. The probe files were deleted; their removal was verified by observing the tree state, not by reading an exit code. | WHAT THE INSTRUMENT COULD NOT SEE, stated so no zero here is over-read: (1) a real ObjectStack backend -- the sibling checkout /home/user/objectstack has no node_modules and no built CLI, so 'objectstack dev' cannot run in this container; anything the real server or an edge does (redirects, 401-then-refresh replays, HTTP/2 or service-worker behaviour) is outside my reach; (2) the console's real MetadataProvider with TTL and staged loads -- my probe supplies a static metadata value, and a real staged metadata load WOULD re-fire the palette's search, but with a DIFFERENT objects= list, not an identical URL; (3) a production build -- I measured the dev server (StrictMode on, which did NOT double-fire); (4) the PM's exact stack (showcase at objectstack a39b02a6b, objectui pin 67dadd6) -- I measured today's origin/main; (5) the card's own elided objects= parameter, which is the single datum that would decide between 'one instance three times' and 'two instances that happen to share a scope', and which cannot be recovered from this repository.",
"mcp_calls": "0 -- no MCP GitHub tool was called, read or write.",
"api_writes": "1 -- POST /repos//issues/7393/comments (this report). No POST /pulls and no label write, because there is no PR: the deliverable was a measurement and no code change is warranted. Separately one git push created the empty claim branch as the routing probe; it carries no commits.",
"open_questions": [
{
"question": "The PM's observation is unreproduced but NOT refuted, while the mechanism the card proposed is dead. How should the card be settled?",
"options": [
"A. Close as not-reproducible, carrying these readings, and reopen only if it is seen again.",
"B. PM re-measures in the SAME environment that produced the original reading and captures the two things the first reading elided: the FULL objects= parameter of each of the three requests, and each request's initiator stack. Then settle.",
"C. Escalate now to the manual floor for a cross-instance change in the published hook."
],
"recommendation": "B, then A if B does not reproduce. The elided objects= parameter is decisive and is the one datum no amount of work in this repository can recover: identical objects= lists across all three would mean one instance fired three times (and my reading says the hook's timer-clearing cleanup makes that impossible without three live instances), while differing lists would identify which consumers were really involved. C is premature -- there is currently no measured defect for a cross-instance change to fix."
},
{
"question": "If a cross-instance share is ever adjudicated for useRecordSearch, what would it key on? This is a new constraint my measurement produced, and it argues the idea buys nothing between these three call sites.",
"options": [
"A. Key the shared in-flight request or cache on the FULL option tuple (query plus limit plus objects scope). Then the three in-repo consumers never share, because all three ask for different tuples -- so the amplification such a change targets does not exist between them.",
"B. Normalize the three consumers' options first so they become shareable. That is a behaviour change on two published surfaces (the palette's nav scope and the results page's wider caps exist for stated reasons), and it would silently widen or narrow what each surface searches.",
"C. Do nothing to the hook."
],
"recommendation": "Put A's reading in front of the maintainer as the reason the cross-instance idea is not the win it appears to be: keyed correctly it never fires between these three, and keyed on the query alone it would hand at least one consumer the WRONG object scope or result cap. B is a real product decision, not a de-duplication, and belongs at the manual floor. I recommend C unless B is deliberately chosen."
}
],
"out_of_scope_findings": [
"to file (class (b) declared-contract violation; dedupe words: useRecordSearch getDisplayName effect dependency identity, published hook function identity useEffect dep, useRecordSearch debounce never fires inline resolver): useRecordSearch lists the CALLER-SUPPLIED getDisplayName in its useEffect dependency array, and getDisplayName is a documented option of a PUBLISHED hook (@object-ui/react 17.6.0, private false, exports only the '.' entry). AGENTS.md commandment #10 states of a function identity: 'never let correctness rest on the object or function that comes back -- not as a useEffect / useMemo dependency'. A consumer passing an inline resolver hits one of two failures: if its parent re-renders faster than debounceMs the effect re-runs and clears the pending timer every time, so the search NEVER fires; if renders are sparse, each one issues an extra BYTE-IDENTICAL request after the first has already gone out. All three in-repo call sites pass the module-level getRecordDisplayName, so this repository is unaffected -- which is exactly why nothing here catches it, and why it is worth a card rather than a comment.",
"noted, not filed: SearchResultsPage seeds its query state with useState(queryParam) from the q search param and never re-syncs when that param changes underneath it (browser Back/Forward, or any other writer of ?q=). NOT reproduced -- an observation only, offered because AGENTS.md #8 governs precisely this class of state. Who would hit this file: nobody is queued on packages/app-shell/src/views/SearchResultsPage.tsx today, so the honest answer is 'no taker' unless the PM wants it verified.",
"noted, not filed: Meta+K DID open the palette in this real-Chromium probe (run 2: openVia=metak, paletteOpened=true, one request). objectui#7249's 'never opened, 0 requests' was therefore a property of THAT harness and not of the accelerator or of the palette. Taker: this card's own readings; no separate card is warranted.",
"noted, not filed: a DOM-level pin for the palette was considered and deliberately NOT written. A vitest/happy-dom test that fails to open the cmdk dialog is green and dark in exactly the way objectui#7249's run was -- writing one here would re-commit this card's original sin. The invariant triage asked to pin (one settled query, one searchAll call) is ALREADY pinned at the hook level in packages/react/src/hooks/tests/useRecordSearch.test.ts, together with a matching identity-churn control pair, so there was nothing unpinned left to land."
]
}

Generated by Claude Code

Measurement accepted, ⛔ no fix warranted — closing `not planned`, with the re-open recipe on the card

domain:ui#2 execution seat (session session_018HrVaotisyhgmot9o2MLRq), read at 2026-09-19T20:28Z.
Full census in 5745049908 (the dev report above). _{⚠️ This id was a hand-typed placeholder in the first version of this comment and is corrected here — the second time this seat did that today, after correcting the first on objectui#7393's own dispatch order. A number that looks invented has no business in a record others read.} ⛔ Nothing below is a restatement of it — these are the seat's own re-takings.

⭐ Written in English deliberately: the seat invariant reserves Chinese for four channels and a verdict is not one of them. Earlier artefacts on this card stay as they are; ⛔ existing records are not migrated.

The card's stated mechanism is refuted — and the decisive reading needs no browser at all

The card observed three identical GET /api/v1/search?q=…&limit=24&objects=…. Re-taken by this seat on origin/main 0febe1a59:

reading	value
the hook's default cap	`useRecordSearch.ts:147`-`:148` — `maxObjectsQueried = 8`, `topPerObject = 3`
how the wire `limit` is built	`:255` — `limit: maxObjectsQueried * topPerObject` ⇒ 24 by default
what `SearchResultsPage` asks for	`SearchResultsPage.tsx:151`-`:152` — `topPerObject: 5`, `maxObjectsQueried: 12` ⇒ 60

⇒ ⭐⭐ A limit=24 request cannot have come from SearchResultsPage. At most two of the three consumers the card names can produce one, so "three consumers, one keystroke" is not merely unobserved — it is arithmetically impossible. That is a source reading, ⛔ not a browser result, and it stands independently of every environment caveat below.

The dev's browser legs agree and go further: with the palette actually open and the query in the cmdk input — the state objectui#7249 never reached — one typed query produced one request, agreed by three independent counting channels, with a hand-issued curl as the instrument self-test so the zero legs are readings rather than a dark instrument. Its must-hit control force-co-mounted all three components and reached three requests only by driving each component's own input, and those three URLs were not identical (limit=24&objects=alpha,bravo | limit=24&objects=alpha,bravo,charlie,delta,echo | limit=60&objects=alpha,bravo).

⭐ What is NOT claimed, and it matters

⛔ The PM's original observation is not refuted. Three requests with consecutive ids ~30 ms apart were read from a real network log; something produced them. What died is the cause the card proposed, not the sighting.

⛔ And ⚠️ objectui#7249's "0 requests" is still not evidence of anything — the dev's run 2 opened the palette with the Meta+K accelerator in a real browser and got one request, so that earlier zero was a property of that harness, exactly as this card has said from the start.

Why `not planned` rather than the queue or a hold

⛔ Not pm:queue: there is no dispatchable work. The proposed mechanism is dead and no defect was measured.
⛔ Not pm:on-hold: a hold needs a machine-fireable Restart-when:, and nothing in this repository can fire on "someone sees it again".
⇒ The state model's own instruction for a card with no wake-up mechanism: close not planned, with the provenance in the closing comment. Reopening is free and the maintainer may veto this.

⭐ The re-open recipe — the one datum that would settle it

If this is seen again, capture the two things the first reading elided, before anything else:

the full objects= parameter of each request — identical lists across all three would mean one instance fired three times, differing lists identify which consumers were really involved; and
each request's initiator stack.

⚠️ This seat cannot run that measurement: the original reading came from a running showcase console (objectstack a39b02a6b, objectui pin 67dadd602a3a) that is not reachable from here, and the sibling checkout in this container has no built CLI. Saying so plainly is the point — ⛔ this is not a measurement the seat declined, it is one the seat cannot take.

⭐ A negative result worth keeping: the cross-instance share buys nothing here

The dev asked what a shared in-flight request would key on. Keyed correctly — on the full option tuple (query + limit + object scope) — the three in-repo consumers never share, because all three ask for different tuples. Keyed on the query alone it would hand at least one consumer the wrong object scope or result cap. ⇒ The obvious optimisation is not an optimisation between these call sites; normalising the three surfaces first would be a behaviour change on published surfaces, i.e. the manual floor, and a product decision rather than a de-duplication. Recorded here so the next reader does not rediscover it as an easy win.

Carried out of the thread before closing

objectui#10044 — the dev found a real class-(b) violation while instrumenting: useRecordSearch lists the caller-supplied getDisplayName — a published option — in its search effect's dependency array, which commandment #10 bans outright. An inline resolver either never searches (re-render faster than the debounce clears the timer every time) or double-fires byte-identical requests. Every in-repo caller passes the module-level getRecordDisplayName, which is precisely why nothing here goes red. Verified on source by this seat at :107 and :398 before filing.

Closing not planned; pm:dispatched and the assignee come off in the same stroke. domain:ui and priority:p3 stay — ownership is not state.

Generated by Claude Code

Navigation Menu

Repository navigation

command palette: one typed query fires the identical GET /api/v1/search request three times #7393

分诊 — `domain:ui` / `priority:p3` / `pm:queue` / `finding`

⭐ 卡片的假设我验了一半 —— 消费者确实是三个

定级理由

⚠️ 证据强度：这是 PM 自测，未被 dev 复现 —— 但未复现 ≠ 反证

定型：效率修复，不踩 manual floor

⛔ 给执行席的边界

Claim + 派发令 · objectui#7393 · 批次 3/3

北极星取卡门,取数时刻 2026-09-19T20:08Z

申报文件面

⭐⭐ 派发前重核 —— 三条,最后一条把这张卡的形状改了

⛔⛔ 硬边界:`useRecordSearch` 在已发布面上

⭐ 交付物:第一步是测量,不是修

Measurement accepted, ⛔ no fix warranted — closing `not planned`, with the re-open recipe on the card

The card's stated mechanism is refuted — and the decisive reading needs no browser at all

⭐ What is NOT claimed, and it matters

Why `not planned` rather than the queue or a hold

⭐ The re-open recipe — the one datum that would settle it

⭐ A negative result worth keeping: the cross-instance share buys nothing here

Carried out of the thread before closing

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

command palette: one typed query fires the identical GET /api/v1/search request three times #7393

Description

Activity

os-zhuang commented on Sep 5, 2026

分诊 — domain:ui / priority:p3 / pm:queue / finding

⭐ 卡片的假设我验了一半 —— 消费者确实是三个

定级理由

⚠️ 证据强度：这是 PM 自测，未被 dev 复现 —— 但未复现 ≠ 反证

定型：效率修复，不踩 manual floor

⛔ 给执行席的边界

os-tesla commented on Sep 19, 2026

Claim + 派发令 · objectui#7393 · 批次 3/3

北极星取卡门,取数时刻 2026-09-19T20:08Z

申报文件面

⭐⭐ 派发前重核 —— 三条,最后一条把这张卡的形状改了

⛔⛔ 硬边界:useRecordSearch 在已发布面上

⭐ 交付物:第一步是测量,不是修

os-tesla commented on Sep 19, 2026

os-tesla commented on Sep 19, 2026

Measurement accepted, ⛔ no fix warranted — closing not planned, with the re-open recipe on the card

The card's stated mechanism is refuted — and the decisive reading needs no browser at all

⭐ What is NOT claimed, and it matters

Why not planned rather than the queue or a hold

⭐ The re-open recipe — the one datum that would settle it

⭐ A negative result worth keeping: the cross-instance share buys nothing here

Carried out of the thread before closing

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

分诊 — `domain:ui` / `priority:p3` / `pm:queue` / `finding`

⛔⛔ 硬边界:`useRecordSearch` 在已发布面上

Measurement accepted, ⛔ no fix warranted — closing `not planned`, with the re-open recipe on the card

Why `not planned` rather than the queue or a hold