Simplify the primary search surface

docs/modules/ui/search-chip-context-contract.md

@@ -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.

docs/modules/ui/search-self-serve-contract.md

@@ -14,7 +14,6 @@
 - Question entries must provide:
   - `key` / `fallback` for the executable question text
   - optional `kind` (`page`, `clarify`, `recent`)
-  - optional `preferredModes` (`find`, `explain`, `act`)
 - Question arrays must stay deterministic and bounded:
   - at most 3 base common questions per page
   - at most 2 base clarifying questions per page
@@ -32,15 +31,14 @@
 
 ## Runtime behavior
 - Empty-state search uses `commonQuestions[]` for page-owned "Common questions".
-- The active mode (`Find`, `Explain`, `Act`) reorders questions via `preferredModes`.
 - A recent-action question may be prepended from the latest meaningful page action:
-  - `Find` -> related discovery question
-  - `Explain` -> why-it-matters question
-  - `Act` -> what-to-do-next question
+  - opened/used result -> why-it-matters question
+  - search/chat expansion -> what-to-verify-next question
+  - fallback -> related follow-up question
 - Result-state answer panels use:
   - `commonQuestions[]` as follow-up questions when grounded evidence exists
   - `clarifyingQuestions[]` when no grounded answer exists
-- "Search next" remains driven by contextual chip logic so pages do not need to define a second parallel action system.
+- "Related searches" remains driven by contextual chip logic so pages do not need to define a second parallel action system.
 
 ## Source of truth
 - Page registry and interfaces:

docs/modules/ui/search-zero-learning-primary-entry.md

@@ -110,7 +110,8 @@
 - Implemented before and during the corrective phases: explicit scope/mode/recovery controls were removed from the main search flow, implicit current-scope weighting and overflow contracts were added, and suggestion viability preflight now suppresses dead chips before render.
 - Implemented before the corrective phases: the live Doctor suggestion suite now rebuilds the active corpus, fails on empty knowledge projections, iterates every surfaced suggestion, and verifies Ask-AdvisoryAI inherits the live search context.
 - Implemented from the corrective phases: backend overflow is now narrow enough that clear in-scope winners suppress out-of-scope spillover, blended summaries only appear for genuinely close evidence clusters, and `SearchTelemetryEnabled` cleanly disables analytics/feedback/sink emission without affecting retrieval or history.
-- Still pending from the corrective phases: removal of hidden FE mode dependencies, a structured success-only history contract that purges failed legacy entries on load, stricter suggestion/corpus readiness gating across more routes, and broader live-page matrices.
+- Implemented from the operator-correction pass: FE search contracts no longer depend on hidden `Find / Explain / Act` metadata, starter chips wait for backend viability before rendering, `Did you mean` is the first in-panel cue under the search field, and successful recent history now uses a structured `stella-successful-searches-v3` contract that ignores legacy bare-string entries on load.
+- Still pending from the corrective phases: stricter backend viability states across more domains, broader live-page matrices, and explicit client-side telemetry opt-out.
 
 ## Execution phases - operator correction pass
 ### Phase 1 - Search-first primary surface cleanup