Add zero-learning search phase trackers

This commit is contained in:
master
2026-03-07 17:50:44 +02:00
parent 601d6f24be
commit a2218d70fa
2 changed files with 157 additions and 0 deletions

View File

@@ -0,0 +1,85 @@
# Sprint 20260307-020 - FE Overflow Answer Consumption and Chip Viability
## Topic & Scope
- Consume the additive unified-search response contract so the UI presents current-scope results first and out-of-scope overflow only when warranted.
- Stop rendering dead page chips when backend coverage says the active corpus cannot answer them.
- Keep search zero-learning: no explicit scope selector, no explicit mode selector, and no recover panel.
- Working directory: `src/Web/StellaOps.Web`.
- Expected evidence: Angular unit tests, Playwright search UX tests, updated UI docs, and a scoped commit.
## Dependencies & Concurrency
- Depends on `SPRINT_20260307_019_AdvisoryAI_implicit_scope_weighting_and_suggestion_viability.md`.
- Safe parallelism: unrelated Web feature work can continue as long as it does not touch `global-search` or unified-search API contracts.
## Documentation Prerequisites
- `docs/modules/ui/search-zero-learning-primary-entry.md`
- `docs/modules/advisory-ai/unified-search-architecture.md`
- `docs/modules/advisory-ai/knowledge-search.md`
## Delivery Tracker
### FE-ZL-001 - Consume primary and overflow search sections
Status: TODO
Dependency: none
Owners: Developer (Frontend)
Task description:
- Update the unified-search client and search bar component to consume backend primary/overflow cards and answer metadata.
- Present current-scope-biased cards first and clearly label overflow results without asking the user to manage scope manually.
Completion criteria:
- [ ] The frontend consumes additive overflow/coverage fields without breaking legacy fallback behavior.
- [ ] Primary cards render before overflow cards when both exist.
- [ ] Overflow results are visually subordinate and only shown when present.
### FE-ZL-002 - Use backend answer framing instead of frontend heuristics
Status: TODO
Dependency: FE-ZL-001
Owners: Developer (Frontend)
Task description:
- Replace the current frontend-only answer heuristics with backend-provided answer status, summary, citations, and follow-up questions.
- Preserve a deterministic fallback when the backend omits the new answer frame.
Completion criteria:
- [ ] Search answer panels prefer backend answer data.
- [ ] Frontend fallback logic remains available for older or degraded responses.
- [ ] `Did you mean` remains directly under the input/result header.
### FE-ZL-003 - Suppress dead contextual chips using backend coverage
Status: TODO
Dependency: FE-ZL-001
Owners: Developer (Frontend)
Task description:
- Preflight contextual/page chips against backend coverage so suggestions that cannot execute are not rendered.
- Preserve useful fallback chips only when the backend confirms a non-empty relevant corpus or candidate set.
Completion criteria:
- [ ] Contextual chips are hidden when coverage says their domain/query family is empty.
- [ ] Clicking any rendered contextual chip yields visible results or a backend-issued clarify frame.
- [ ] Search history still records only successful result-bearing searches.
### FE-ZL-004 - Targeted frontend verification
Status: TODO
Dependency: FE-ZL-003
Owners: Test Automation
Task description:
- Add unit and Playwright coverage for overflow sections, backend answer consumption, and chip suppression.
Completion criteria:
- [ ] Angular tests cover overflow rendering and backend answer consumption.
- [ ] Playwright covers chip suppression and mixed primary/overflow result presentation.
- [ ] Execution log records commands and outcomes.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-07 | Sprint created to consume backend zero-learning search contracts in the Web primary entry. | Project Manager |
## Decisions & Risks
- Decision: chip viability is enforced from backend coverage signals, not static page metadata alone.
- Decision: backend answer framing is preferred, with frontend heuristics retained only as backward-compatible fallback.
- Risk: mixed deployments may return older unified-search payloads during rollout.
- Mitigation: keep all new frontend contract usage additive and optional.
## Next Checkpoints
- 2026-03-09: Start FE-ZL-001 and FE-ZL-002 after backend phase 2 lands.
- 2026-03-09: Add Playwright coverage for overflow and viable-chip rendering.

View File

@@ -0,0 +1,72 @@
# Sprint 20260307-021 - FE Live Search Suggestion Reliability Matrix
## Topic & Scope
- Prove that surfaced search suggestions are reliable against a live ingested corpus, not only mocks.
- Add corpus preflight so the live suggestion suite can fail for real ingestion gaps before UI assertions begin.
- Verify the zero-learning interaction end to end across search entry, suggestion execution, answer framing, overflow results, and AdvisoryAI handoff.
- Working directory: `src/Web/StellaOps.Web/tests/e2e`.
- Expected evidence: Playwright specs, documented live setup commands, execution logs, and a scoped commit.
## Dependencies & Concurrency
- Depends on `SPRINT_20260307_019_AdvisoryAI_implicit_scope_weighting_and_suggestion_viability.md`.
- Depends on `SPRINT_20260307_020_FE_overflow_answer_consumption_and_chip_viability.md`.
- Safe parallelism: other UI E2E suites can run in parallel if they do not mutate the shared AdvisoryAI live corpus.
## Documentation Prerequisites
- `docs/modules/ui/search-zero-learning-primary-entry.md`
- `docs/modules/advisory-ai/knowledge-search.md`
- `src/AdvisoryAI/__Tests/INFRASTRUCTURE.md`
## Delivery Tracker
### QA-ZL-001 - Add live corpus preflight and rebuild checks
Status: TODO
Dependency: none
Owners: Test Automation
Task description:
- Before UI assertions, verify the live AdvisoryAI corpus is ingested enough to support the tested page suggestions.
- Fail with explicit setup diagnostics when the corpus is empty or stale instead of producing misleading UI failures.
Completion criteria:
- [ ] The live suite checks rebuild/readiness before suggestion assertions.
- [ ] Failure output distinguishes ingestion failure from UI failure.
- [ ] Setup docs reference compiled CLI and HTTP rebuild fallbacks.
### QA-ZL-002 - Prove every surfaced suggestion succeeds
Status: TODO
Dependency: QA-ZL-001
Owners: Test Automation
Task description:
- Execute every contextual chip surfaced in the tested pages and assert a visible success state: grounded answer, clarify frame, or result cards.
- Include pages that rely on current-scope weighting and overflow fallback.
Completion criteria:
- [ ] The live suite iterates through each surfaced suggestion on the covered pages.
- [ ] Every rendered suggestion produces a visible non-dead-end state.
- [ ] Previously failing suggestion paths are covered explicitly.
### QA-ZL-003 - Verify search-to-chat consolidation
Status: TODO
Dependency: QA-ZL-002
Owners: Test Automation
Task description:
- Verify the compact chat launcher and answer-panel handoff preserve query, page context, and evidence after the search redesign.
Completion criteria:
- [ ] Search is the tested primary entry in all covered flows.
- [ ] AdvisoryAI opens as a secondary deep-dive from search with inherited context.
- [ ] Execution log records the final full-pack commands and outcomes.
## Execution Log
| Date (UTC) | Update | Owner |
| --- | --- | --- |
| 2026-03-07 | Sprint created for live corpus-backed suggestion reliability and zero-learning search verification. | Project Manager |
## Decisions & Risks
- Decision: live reliability gates are required because static mocks cannot prove suggestion viability against real corpora.
- Risk: local environments may have partially ingested or empty corpora, especially in Doctor/knowledge projections.
- Mitigation: add explicit corpus preflight and rebuild guidance so the suite fails with actionable diagnostics.
## Next Checkpoints
- 2026-03-09: Land live corpus preflight before broadening the suggestion matrix.
- 2026-03-10: Run the final live suggestion pack and capture exact outcomes in the execution log.