stella-ops.org/git.stella-ops.org
1
0
Fork 0
Code Issues Pull Requests Actions 3 Releases Wiki Activity

Simplify the primary search surface

Browse Source
This commit is contained in:
master
2026-03-07 20:58:52 +02:00
parent 8ee5dcf420
commit 437d26c47c
14 changed files with 276 additions and 327 deletions
Download Patch File Download Diff File Expand all files Collapse all files

14
docs/modules/ui/search-chip-context-contract.md
View File

@@ -21,13 +21,12 @@
- `key` / `fallback` for the executable query text
- `reasonKey` / `reasonFallback` for the visible "why this suggestion" line
- optional `kind` (`page`, `recent`, `strategy`) when page teams need non-default styling/priority
- optional `preferredModes` (`find`, `explain`, `act`) when a chip should rank higher for a specific operator intent
- Suggestion arrays must stay deterministic and bounded:
- at most 3 base chips per page context
- short, action-oriented text
- no tenant/user secrets in fallback text
- keep the query label distinct from rationale text so suggestion clicks always submit the intended query only
- fallback copy should still make sense after mode-aware reordering; do not encode mode-specific rationale into the raw query text
- fallback copy should stand on its own; do not encode hidden ranking or workflow instructions into the raw query text
## Source of truth
- Contract and registry:
@@ -48,12 +47,11 @@
- Generated chips must also expose rationale metadata:
- `recent` chips explain they came from last-page actions
- `strategy` chips explain they came from recent intent on the same page scope
- Mode-aware ranking:
- the shared `SearchExperienceModeService` owns the active operator mode
- chips marked with `preferredModes` are ranked ahead of otherwise-equal chips for that mode
- page teams should use this sparingly to express clear intent differences, not to create large per-mode chip forks
- Ranking behavior:
- chip order is driven by page context, recent scoped actions, deterministic rotation, and backend viability
- page teams should not create hidden forks that assume the user chose an internal search mode
- Search-surface control rule:
- buttons inside the search surface (mode switch, scope toggle, rescue cards, filters) are part of the same command workspace
- buttons inside the search surface (assistant launcher, correction suggestions, starter chips, answer follow-ups, card actions) are part of the same command workspace
- focus transitions into those controls must not collapse the search panel
- teams adding new controls inside the panel must preserve this containment rule in tests
@@ -61,7 +59,7 @@
1. Add/adjust a context in `SEARCH_CONTEXT_DEFINITIONS`.
2. Ensure page component exposes the same `searchContextId` (implements `SearchContextComponent`).
3. Define or update `presentation` copy for the context rail.
4. Add or update `reasonFallback` text and any `preferredModes` metadata for each base chip.
4. Add or update `reasonFallback` text for each base chip.
5. Add/adjust unit tests in `ambient-context.service.spec.ts`.
6. Add/adjust Playwright tests for route chips + action-driven chips.
7. If the page adds custom controls inside the search panel, add focus-containment coverage so those controls do not dismiss the panel.