Архитектура: централизовать temporal carryover precedence в continuity policy и transition glue
This commit is contained in:
+6
@@ -428,6 +428,12 @@ Still open after the accepted phase12 replay:
|
||||
- this matters because `inventoryRootFrame`, `current_frame_kind`, and `root-scoped` filter precedence now converge through one authority layer before `root_context_only` pivots are decided, which reduces another hidden chance for state drift when new domains or new follow-up families are added;
|
||||
- targeted `assistantContinuityPolicy` and `assistantTransitionPolicy` suites are green after the move, with explicit coverage for root-frame hydration from navigation scope and for previous-date precedence over a stale inventory root frame;
|
||||
- a fresh live rerun of `address_truth_harness_phase12_wider_saved_session_pool` on `2026-04-19` remained semantically stable on all repaired continuity paths and again failed only on the already-known date-sensitive `today` expectations, not on the new shared root-frame state owner.
|
||||
- the next continuity-authority pass now centralizes temporal backfill precedence for follow-up filters:
|
||||
- transition no longer holds a service-local block of `shouldBackfillPreviousDateScopeFromNavigation + six field-level ifs` for `as_of_date / period_from / period_to`;
|
||||
- shared continuity now owns that merge via `applyTemporalCarryoverFilters(...)`, while `shouldUseNavigationTemporalCarryover(...)` keeps the intent-family boundary explicit in one place;
|
||||
- this matters because navigation date scope and continuity temporal scope are now merged through one owner before transition decides pivots, instead of being backfilled ad hoc inside the hot path;
|
||||
- targeted `assistantContinuityPolicy` and `assistantTransitionPolicy` suites are green after the move, with direct helper coverage for navigation-first temporal precedence and for non-applicable intent families staying untouched;
|
||||
- a fresh live rerun of `address_truth_harness_phase12_wider_saved_session_pool` on `2026-04-19` stayed semantically stable and again failed only on the already-known date-sensitive `today` expectations, not on the new shared temporal carryover authority.
|
||||
|
||||
## Next Execution Slice (2026-04-18)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user