Render clarify search prompts as guidance only
This commit is contained in:
@@ -42,7 +42,7 @@
|
||||
- `clarify`
|
||||
- `insufficient`
|
||||
- `grounded` states must expose visible evidence summary plus citations or top-result references.
|
||||
- `clarify` states must offer narrowing questions instead of a blank panel.
|
||||
- `clarify` states must offer narrowing guidance instead of a blank panel.
|
||||
- `insufficient` states must explain the lack of grounding and still provide credible next questions or next searches.
|
||||
|
||||
## Runtime behavior
|
||||
@@ -53,7 +53,7 @@
|
||||
- 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
|
||||
- `clarifyingQuestions[]` as non-executable narrowing guidance when no grounded answer exists
|
||||
- "Related searches" remains driven by contextual chip logic so pages do not need to define a second parallel action system.
|
||||
|
||||
## Optional telemetry hooks
|
||||
@@ -85,7 +85,7 @@
|
||||
2. Add unit coverage for answer-state rendering in `global-search.component.spec.ts`.
|
||||
3. Add Playwright coverage for:
|
||||
- grounded answer
|
||||
- clarify recovery
|
||||
- clarify guidance rendering
|
||||
- answer-to-AdvisoryAI handoff
|
||||
- priority-route rollout journeys (`findings`, `policy`, `doctor`, `timeline`, `releases`)
|
||||
4. Keep route and API behavior mocked/deterministic; no live network dependencies.
|
||||
|
||||
@@ -18,12 +18,14 @@
|
||||
- The current history contract cannot reliably remove old failed searches after reload because the local store still accepts legacy bare-string entries with no result outcome attached.
|
||||
- `Did you mean` is still visually tied to the results surface rather than the input correction moment. It needs to live immediately below the search field.
|
||||
- Suggestions are still too easy to surface without enough corpus proof. Search must treat corpus readiness and suggestion executability as a product requirement, not a test-only concern.
|
||||
- Clarify prompts can still be mistaken for executable searches when they are phrased like literal user queries. Those prompts must behave as narrowing guidance, not dead-end starter searches.
|
||||
|
||||
## What still fails after direct operator usage
|
||||
- Search and assistant still feel like sibling products in some flows. The operator should always start from search; assistant is a secondary detail view opened from that same surface.
|
||||
- Any visible "scope" mechanic is wrong for the default path. Current route, visible entities, and recent actions should weight results automatically. If the best answer is outside the current page, show it as overflow only after trying the current page first.
|
||||
- The product still risks teaching internal mechanics through labels, panels, and helper copy. The operator should not need to learn Stella structure, search science, or result modes just to get a useful answer.
|
||||
- Suggestions are not acceptable unless they execute. A surfaced starter chip that leads to zero useful results is a product defect even when the service is healthy.
|
||||
- Clarify text must not look like an executable starter search unless the backend has explicitly grounded it. Guidance such as "add an environment or release" belongs in the answer panel as guidance, not as a clickable query.
|
||||
- When multiple high-confidence results are close, search should summarize them automatically. The assistant exists to expand and deepen the answer, not to compensate for a weak primary result.
|
||||
|
||||
## Product rules
|
||||
|
||||
Reference in New Issue
Block a user