Entwurf · Issue 09e87ba

Ein Issue ist über seine Id auffindbar

Entwurf zu Issue 09e87ba, zu docs/plans/09e87ba-an-issue-is-findable-by-its-id.md. Jedes Urteil unten ist ein echtes Suchergebnis aus lib/unified-search.ts, beim Rendern gerechnet.

Die Id ist die eine Schreibweise eines Issues, die jedes Terminal-Kommando, jedes Ketten-Artefakt und jedes Gate-Urteil druckt — und sie war das eine Feld, das die Suche des Boards nicht kannte. Wer ein Oid-Präfix einfügte, bekam nichts; und die Leerstelle behauptete dann, das Repository habe noch gar keine Issues. Zwei Lügen für den Preis einer Suche.

01Die Id ist Suchtext, keine Facette

Der lokale Adapter matcht freien Text über Substrings — ein Feld id im Register des Boards genügt, damit jedes Präfix eines Oid sein Issue findet. Eine Facette wäre die falsche Form: fünfzig Oids als Checkboxen zählt niemand ab. Der Feldausdruck id:… kommt gratis mit, weil die Query-Sprache dieselben Feld-Ids liest.

  • hältdas Präfix "09e87ba" findet genau sein Issue
  • hältder Feldausdruck "id:55ba307" findet genau seines
  • hältein fremdes Präfix findet nichts

02Die Leermeldung hört auf zu lügen

SmartGrid zeigte die empty-Zeile des Aufrufers bei jedem leeren Ergebnis — aber diese Zeile beschreibt ein leeres REPOSITORY, nicht eine erfolglose Suche. "No issues yet — open the first one" ist eine Einladung zum Anlegen, und sie ist falscher Rat, wenn die Leere vom eigenen Filter kam. Das Grid kennt den Unterschied selbst: Query und Facetten sind sein eigener Zustand.

  • Einmal im Organismus, nicht einmal pro Aufrufer — jede Liste mit eigener empty-Zeile trug dieselbe Lüge; der Artikel-Grid genauso wie das Board. Ein gerechneter Knoten in SmartGrid.tsx heilt alle, ohne dass sich eine Aufrufer-Schnittstelle ändert.
  • Was diese Seite nicht sehen kann: der Wechsel zwischen den beiden Meldungen ist Client-Zustand im laufenden Grid. Die Mechanik des Adapters hält lib/unified-search.test.ts; die Leer-Unterscheidung liest man in SmartGrid.tsx an einer Stelle.