АРЧ АП11 - Архитектура после ге :

docs/ARCH/11 - architecture_turnaround/08 - current_status_audit_2026-04-17.md

@@ -20,29 +20,33 @@ This snapshot is based on:
 - current owner modules in `llm_normalizer/backend/src/services/`
 - current scenario acceptance scripts under `scripts/`
 - current AGENT semantic source catalog under `docs/orchestration/`
+- live replay comparison between:
+  - `address_truth_harness_phase5_company_selection_and_activity_age_live_20260417_iter6`
+  - `address_truth_harness_phase7_meta_domain_mix_live_20260417`
+- [10 - regression_breakpoint_analysis_2026-04-17.md](./10%20-%20regression_breakpoint_analysis_2026-04-17.md)
 
 ## Graph Snapshot
 
 Latest graph rebuild:
 
-- `5287 nodes`
-- `11407 edges`
-- `135 communities`
+- `5312 nodes`
+- `11408 edges`
+- `136 communities`
 
 Most relevant current god nodes for turnaround `11`:
 
 1. `resolveAddressIntent()`  
 2. `ChannelRegistry`  
 3. `CanonicalStore`  
-4. `composeFactualReplyBody()`  
-5. `compactWhitespace()`
+4. `compactWhitespace()`
+5. `ExecuteQueryParams`
 
 The relevant conclusion is not that every god node is part of turnaround `11`.
 
 The relevant conclusion is:
 
 - `resolveAddressIntent()` remains the main unresolved domain-intent concentration point;
-- `composeFactualReplyBody()` still carries answer-shaping pressure, but it is no longer a top-3 god node after the latest extractions;
+- `composeFactualReplyBody()` no longer appears in the top god-node slice after the latest compose extractions, which means the central answer-shaping pressure has materially dropped;
 - `assistantService` still appears as a large coordinator-heavy community rather than a thin shell.
 
 ## What Is Already Real In Code
@@ -126,7 +130,13 @@ This is enough to build targeted semantic packs that are not single-domain toy s
 
 ## Honest Phase Status
 
-Estimated overall turnaround completion: `~92%`
+Turnaround implementation progress: `~88%`
+
+Pre-expansion readiness: `~62%`
+
+This split is intentional.
+
+The codebase already contains most of the required architectural objects, but the mixed saved-session runtime is still not stable enough to justify aggressive domain expansion.
 
 ### Phase 0. Shared Baseline
 
@@ -148,22 +158,23 @@ Reason:
 
 ### Phase 2. State And Transition Contracts
 
-Status: `92%`
+Status: `74%`
 
 Reason:
 
-- root, selected-object, same-date, and carryover classes are materially operational;
+- root, selected-object, same-date, and carryover classes exist as real owner seams;
 - transition policy is extracted;
-- scenario acceptance now evaluates continuity explicitly.
+- scenario acceptance evaluates continuity explicitly.
 
 Remaining debt:
 
-- legacy transition helpers still physically exist inside `assistantService.ts`;
-- not every follow-up family is represented as equally clean first-class transition taxonomy.
+- there is still no single authoritative continuity contract for live mixed sessions;
+- continuity priority is still split across route policy, transition policy, recap policy, navigation state, and coordinator glue;
+- the mixed replay can still lose the active frame and fall into clarification or wrong-family reuse.
 
 ### Phase 3. Capability Contracts
 
-Status: `89%`
+Status: `91%`
 
 Reason:
 
@@ -189,16 +200,18 @@ Reason:
 - reply-packaging mechanics are now explicitly split into `address_runtime/replyPackaging.ts` instead of staying fully in `composeStage.ts`.
 - named reply contracts and answer semantics presets now also live in `address_runtime/replyContracts.ts` instead of being rebuilt inline across major factual branches.
 - inventory answer construction now has an explicit owner in `address_runtime/inventoryReplyBuilders.ts` instead of staying inline inside `composeFactualReplyBody()`.
+- counterparty / lifecycle / value / contract-profile factual replies now also have an explicit owner in `address_runtime/counterpartyAnalyticsReplyBuilders.ts` instead of staying inline inside `composeFactualReplyBody()`.
+- `composeStage.ts` is now down to about `4305` lines after the counterparty analytics extraction and duplicate-body cleanup.
 
 Remaining debt:
 
-- `composeFactualReplyBody()` is still a major concentration point, but its graph pressure is lower than in the previous snapshot;
+- `composeFactualReplyBody()` is still not fully decomposed, but it is no longer one of the top graph pressure points in the current snapshot;
 - humanized blocked/limited semantics are not yet fully separated from answer semantics across all paths;
-- `composeStage.ts` still remains too large even after packaging extraction and inventory-family extraction.
+- `composeStage.ts` still remains too large even after packaging extraction, inventory-family extraction, and counterparty analytics extraction.
 
 ### Phase 5. AssistantService Extraction
 
-Status: `82%`
+Status: `78%`
 
 Reason:
 
@@ -209,8 +222,8 @@ Reason:
 Remaining debt:
 
 - `assistantService.ts` is still about `5050` lines;
-- runtime uses extracted owners, but legacy bodies and fallback branches still live in the coordinator file;
-- code review still sometimes requires reading `assistantService` together with extracted owners.
+- runtime uses extracted owners, but priority and fallback seams still cross the coordinator boundary;
+- code review still requires reading `assistantService` together with extracted owners to understand real behavior.
 
 ### Phase 6. Provider / Runtime Axis Hardening
 
@@ -227,7 +240,7 @@ Remaining debt:
 
 ### Phase 7. Scenario Acceptance As Primary Gate
 
-Status: `90%`
+Status: `68%`
 
 Reason:
 
@@ -237,8 +250,25 @@ Reason:
 
 Remaining debt:
 
-- semantic replay remains intentionally tool-driven and script-driven rather than promoted to a mandatory UI-first loop;
-- coverage breadth should continue to grow as new domain slices are hardened.
+- narrow packs and seam tests are much stronger than before, but mixed saved-session runtime is still under-protected;
+- the current phase7 mixed replay fails on continuity-critical edges, so acceptance cannot yet be treated as expansion-safe;
+- coverage breadth should continue to grow as new domain slices are hardened, but stability of the existing mixed runtime is the immediate gate.
+
+## Current Breakpoint Evidence
+
+The strongest current architectural reading is not "a few routes regressed".
+
+It is:
+
+- `phase5_company_selection_and_activity_age` is green end-to-end;
+- `phase7_meta_domain_mix` still fails on root inventory, selected-object continuity, same-date restore, and cross-domain same-date pivot;
+- therefore the core capability families still exist, but mixed-session continuity authority is not stable.
+
+In practical terms, the active breakpoint is now:
+
+- owner extraction has progressed far enough to split decisions across multiple layers;
+- saved-session mixed runtime still does not have one governing continuity authority;
+- clarification and recap can therefore outrank or outrun the real grounded business thread.
 
 ## What Has Improved Relative To The Original State
 
@@ -254,29 +284,45 @@ Compared with the pre-turnaround baseline, the system is now materially better i
 - reply formatting and reply-type classification now have an explicit owner outside `composeStage.ts`;
 - confirmed-balance and heuristic-candidate reply contracts now have explicit builders instead of repeated inline `semantics` objects in major compose branches;
 - inventory factual replies are now owned by a dedicated module rather than embedded directly in the central compose body;
+- counterparty analytics, lifecycle, customer/supplier value rankings, and contract-value factual replies are now owned by a dedicated module rather than embedded directly in the central compose body;
 - inventory intent classification now has a dedicated owner instead of being only an inline segment inside the central address intent resolver;
 - counterparty / contract / documents intent classification now also has a dedicated owner instead of being only an inline segment inside the central address intent resolver;
 - architecture regressions can now be localized to route, transition, truth gate, coverage/evidence, boundary, or meta/memory layers.
 
 ## What Still Remains The Main Architectural Debt
 
-### 1. `assistantService.ts` is still too large
+### 1. Mixed-session continuity still has no single authority
+
+The project now has real route, transition, recap, and boundary owners, but the live session still does not resolve:
+
+- active root frame
+- selected object
+- organization scope
+- temporal carryover
+- clarification state
+- recap source of truth
+
+from one governing contract.
+
+This is the highest-risk debt before domain expansion.
+
+### 2. `assistantService.ts` is still too large
 
 The extracted owners are real, but the coordinator has not yet been fully reduced to a thin orchestration shell.
 
-### 2. `resolveAddressIntent()` is still too central
+### 3. `resolveAddressIntent()` is still too central
 
 Intent resolution remains one of the most connected business nodes in the graph.
 
 This means capability and contour growth still concentrate pressure there.
 
-### 3. `composeFactualReplyBody()` is still too central
+### 4. `composeFactualReplyBody()` is still too central
 
 Truth contracts are now explicit, and reply packaging, reply contracts, and the inventory answer family have all started moving into their own owners, but final answer-shaping still retains too much architecture weight.
 
 This is the main remaining reason why user-facing humanization and limitation semantics are not completely isolated yet.
 
-### 4. Coverage breadth is stronger, but still selective
+### 5. Coverage breadth is stronger, but still selective
 
 The project is now strong on:
 
@@ -292,10 +338,12 @@ But not every business family has reached the same contract maturity.
 
 The next honest architecture slice should be:
 
-1. continue reducing `assistantService.ts` to a thinner coordinator;
-2. continue isolating answer semantics further away from `composeFactualReplyBody()` now that reply packaging and reply contracts have their own owner seams;
-3. keep extending AGENT packs with mixed business + meta + interruption patterns instead of single-family smoke tests;
-4. keep using scenario acceptance as the main sign-off rather than unit-test green status alone.
+1. finish one authoritative continuity contract for live mixed sessions;
+2. subordinate clarification to restored business continuity instead of letting it act as a default escape hatch;
+3. continue reducing `assistantService.ts` to a thinner coordinator;
+4. continue isolating answer semantics further away from `composeFactualReplyBody()` now that reply packaging and reply contracts have their own owner seams;
+5. keep extending AGENT packs with mixed business + meta + interruption patterns instead of single-family smoke tests;
+6. keep using mixed scenario acceptance as the main sign-off rather than unit-test green status alone.
 
 ## Bottom Line
 

docs/ARCH/11 - architecture_turnaround/09 - pre_expansion_cut_2026-04-17.md

@@ -25,12 +25,51 @@ The system already has:
 
 The remaining problem is different now:
 
+- the project is in a hybrid extracted state;
 - quality risk is concentrated in a small number of central pressure points;
 - these pressure points will amplify regressions once many new domains are added.
 
 ## Must Close Before Mass Domain Expansion
 
-### 1. Intent concentration in `resolveAddressIntent()`
+### 1. One continuity authority for live mixed sessions
+
+Why it matters:
+
+- the same capability family can pass in a narrow scenario and fail in a nearby mixed scenario;
+- current runtime continuity is still split across route policy, transition policy, memory recap policy, navigation state, and coordinator glue;
+- domain expansion on top of split continuity ownership will multiply regressions faster than route extraction can contain them.
+
+What "done enough" means:
+
+- one governing session continuity contract resolves active root frame, selected object, organization scope, date scope, clarification state, and recap source;
+- route, recap, and clarification decisions read the same continuity object instead of reconstructing state independently;
+- selected-object, same-date, and cross-domain root pivots stop drifting across different owners.
+
+Current status:
+
+- the underlying contract vocabulary already exists across runtime contract registries and state-transition adapters;
+- owner modules are real, but continuity state is still not yet governed from one place.
+
+### 2. Clarification precedence must stop outranking continuity
+
+Why it matters:
+
+- current regressions often appear as repeated company clarification even after a nearby business answer already succeeded;
+- this is not a pure intent failure, it is clarification winning too often when continuity confidence was lost;
+- if this precedence remains unstable, new domains will feel scripted even when the route exists.
+
+What "done enough" means:
+
+- clarification becomes the last meaningful step, not the default escape hatch;
+- restored business continuity outranks template clarification whenever the active frame is sufficient;
+- repeated clarification no longer breaks selected-object or same-date follow-ups.
+
+Current status:
+
+- company clarification already has explicit owner seams;
+- mixed live replay still shows clarification outranking restored business context.
+
+### 3. Intent concentration in `resolveAddressIntent()`
 
 Why it matters:
 
@@ -48,9 +87,9 @@ Current status:
 
 - inventory signal-family is now delegated to `addressInventoryIntentSignals.ts`;
 - counterparty / documents / contracts / open-items signal-family is now also delegated to `addressCounterpartyIntentSignals.ts`;
-- this reduces ownership pressure, even though the old inline bodies still remain as cleanup debt.
+- the central resolver now delegates these hot families through owner modules instead of carrying them only as inline branches.
 
-### 2. Answer semantics pressure in `composeFactualReplyBody()`
+### 4. Answer semantics pressure in `composeFactualReplyBody()`
 
 Why it matters:
 
@@ -64,7 +103,13 @@ What "done enough" means:
 - blocked / limited / humanized fallback semantics are explicit for the most important contours;
 - user-facing replies no longer expose internal route/capability/debug jargon on critical business paths.
 
-### 3. Business-first quality guard on hot contours
+Current status:
+
+- inventory factual replies already live in `address_runtime/inventoryReplyBuilders.ts`;
+- counterparty analytics / lifecycle / value / contract-value factual replies now also live in `address_runtime/counterpartyAnalyticsReplyBuilders.ts`;
+- `composeStage.ts` is materially smaller than before, but blocked / limited semantics still need one more hardening pass on the hottest contours.
+
+### 5. Business-first quality guard on hot contours
 
 Why it matters:
 
@@ -109,20 +154,28 @@ Promoting every replay step into a more polished UI loop can happen later.
 
 ### Pass 1
 
-- continue extracting the highest-risk signal families out of `resolveAddressIntent()`;
-- keep business behavior stable through focused regression packs;
+- finish the first authoritative continuity contract and wire it into route / recap / clarification hot paths;
+- prove that mixed replay stops losing active frame authority;
 - treat this as the main pre-expansion hardening track.
 
 ### Pass 2
 
-- reduce remaining answer-semantics pressure in `composeFactualReplyBody()`;
-- harden blocked / limited / humanized response semantics on the hottest business contours;
+- subordinate clarification to restored business continuity and remove repeated template escapes;
+- harden recap truthfulness so it can only summarize verified session facts;
 - confirm with AGENT replay that user-facing answers stay business-first.
 
+### Pass 3
+
+- continue extracting the highest-risk signal families out of `resolveAddressIntent()`;
+- reduce remaining answer-semantics pressure in `composeFactualReplyBody()` and `composeStage.ts`;
+- confirm with AGENT replay that technical scaffolding no longer leaks into the user-facing answer.
+
 ## Practical Exit Condition
 
 Turnaround `11` can be considered "ready for domain expansion" when:
 
+- one continuity authority governs mixed live sessions;
+- clarification no longer wins against valid restored business context;
 - the main route-collision pressure in `resolveAddressIntent()` is materially reduced;
 - the hottest user-facing answer families are protected from technical leakage;
 - AGENT replay confirms stable business usefulness on the core mixed chains;

docs/ARCH/11 - architecture_turnaround/10 - regression_breakpoint_analysis_2026-04-17.md

@@ -0,0 +1,328 @@
+# 10 - Regression Breakpoint Analysis (2026-04-17)
+
+## Purpose
+
+This note records the current best architectural reading of where the live assistant started to regress during turnaround `11`.
+
+It is not a blame note and not a patch log.
+
+It is the breakpoint analysis that answers:
+
+- at what stage the system stopped behaving like the older stable mixed-session assistant;
+- why the regression looked sudden even though many extractions were individually "correct";
+- what is the real architectural break, as opposed to surface symptoms in specific questions.
+
+## Short Answer
+
+The system did not break at one isolated question and not at one isolated line.
+
+The system started to break at the moment when the old monolithic decision cluster was already partially extracted into owner modules, but the new shared runtime continuity contract was still not consolidated into one governing layer.
+
+In practice, the breakpoint appears after the late pre-expansion extraction passes, when all of the following became true at the same time:
+
+- intent recognition started to move out of the old central resolver into separate signal owners;
+- transition and carryover logic started to move into dedicated policies;
+- reply shaping and recap logic started to move into dedicated builders and policies;
+- but saved-session mixed runtime still depended on old assumptions about how these layers stay synchronized.
+
+That is the point where the project entered a hybrid state:
+
+- the old monolith no longer fully owned the decisions;
+- the new extracted architecture did not yet fully own the decisions;
+- continuity priority was therefore split across several places.
+
+This hybrid state is the real breakpoint.
+
+## What Worked Before
+
+Before the regression wave, the assistant was structurally dirtier but behaviorally more coupled.
+
+That older state had serious architecture debt, but it also had one practical advantage:
+
+- root intent resolution;
+- selected-object continuity;
+- same-date carryover;
+- company clarification;
+- recap behavior;
+- and final answer shaping
+
+were still located closer to each other inside a narrower monolithic runtime path.
+
+Because these decisions lived close together, they could remain mutually consistent even when the code was oversized and hard to reason about.
+
+So the older system was not "more correct" architecturally.
+
+It was more behaviorally coherent because fewer contracts crossed file and ownership boundaries.
+
+## What Changed During Turnaround `11`
+
+Turnaround `11` did the right high-level thing: it started separating concerns.
+
+The project extracted or hardened real owner layers such as:
+
+- `assistantRoutePolicy.ts`
+- `assistantTransitionPolicy.ts`
+- `assistantBoundaryPolicy.ts`
+- `assistantMemoryRecapPolicy.ts`
+- `addressInventoryIntentSignals.ts`
+- `addressCounterpartyIntentSignals.ts`
+- `address_runtime/inventoryReplyBuilders.ts`
+- `address_runtime/counterpartyAnalyticsReplyBuilders.ts`
+- `address_runtime/replyPackaging.ts`
+- `address_runtime/replyContracts.ts`
+
+Architecturally, this was necessary.
+
+The problem is that behavior did not move as a single closed package.
+
+It moved in slices.
+
+This created a dangerous intermediate state where:
+
+- intent ownership was partially new;
+- route arbitration was partially new;
+- selected-object and same-date carryover were partially new;
+- recap logic was partially new;
+- final user-facing response shaping was partially new;
+- but the full saved-session runtime contract was still not enforced centrally.
+
+## The Actual Breakpoint
+
+### Breakpoint Definition
+
+The true breakpoint is the transition from:
+
+- `monolithic but behaviorally coupled`
+
+to:
+
+- `partially extracted but behaviorally split`
+
+without a single authoritative continuity/arbitration contract for live mixed sessions.
+
+### Why It Felt Like "Everything Broke At Once"
+
+Once the system entered this hybrid state, regressions no longer stayed local.
+
+A small drift in one layer immediately propagated into others.
+
+For example:
+
+1. A root inventory question could lose the intended inventory frame.
+2. A later same-date follow-up could then reuse the wrong active family.
+3. A selected-object follow-up could then trigger a generic clarification template instead of continuing the object thread.
+4. A recap question could then summarize the wrong or incomplete thread.
+5. Reply shaping could present this as a confident-looking business answer or a polished template.
+
+That chain is why the regressions felt broad and sudden.
+
+The system was no longer failing only at route detection.
+
+It was failing at cross-layer state coherence.
+
+## The Best Current Architectural Reading Of "When"
+
+The best current reading is:
+
+- the foundations did not collapse during the early baseline and layer-separation work;
+- the visible regression wave begins during the late pre-expansion extraction and stabilization passes;
+- specifically when high-pressure families were extracted from the old central bodies, but the saved-session runtime path still relied on distributed priority decisions.
+
+In practical turnaround terms, the break appears after the project had already reached the following state:
+
+- policy owners are real;
+- truth and coverage/evidence contracts are real;
+- `assistantService` is partially decomposed;
+- `resolveAddressIntent()` is partially extracted;
+- `composeStage` is partially extracted;
+- AGENT replay exists;
+- but continuity and business-first arbitration are still spread across multiple owners and legacy remnants.
+
+This is why the regression was not visible as "one bad refactor."
+
+It was the cumulative point where enough ownership moved to break the old implicit coherence, while not enough of the new explicit coherence had been installed yet.
+
+## The Four Structural Fault Lines
+
+### 1. Continuity Arbitration Split Across Layers
+
+The biggest fault line is that continuity is not yet governed from one place.
+
+It is currently spread across:
+
+- intent signal owners;
+- route policy;
+- transition policy;
+- decompose/runtime stages;
+- recap policy;
+- coordinator glue in `assistantService`.
+
+This means the answer to questions like these is not always decided by one authoritative contract:
+
+- are we still inside the same root frame?
+- are we still working on the selected object?
+- do we carry the same date?
+- do we preserve organization scope?
+- should we recap facts or continue the last action thread?
+
+When these decisions are distributed, mixed sessions become fragile.
+
+### 2. Saved-Session Runtime Was Less Protected Than Narrow Packs
+
+The second fault line is acceptance asymmetry.
+
+The project got much better at:
+
+- targeted truth harnesses;
+- narrow scenario packs;
+- exact-lane semantic acceptance;
+- seam tests around extracted owners.
+
+But the broader saved-user-session runtime path remained less protected.
+
+That path is exactly where real users mix:
+
+- smalltalk;
+- company scope;
+- counterparty questions;
+- inventory pivots;
+- selected-object follow-ups;
+- recap;
+- account analytics.
+
+So the architecture improved in slices faster than the real mixed runtime was being revalidated.
+
+### 3. Clarification Logic Became Too Template-Strong
+
+The third fault line is that clarification logic gained too much priority in ambiguous moments.
+
+This shows up when the assistant does one of these:
+
+- asks for company selection again even though the active thread should already be sufficient;
+- falls into "not supported / clarify company" language even when a business route previously existed;
+- prefers a safe template over context continuation.
+
+This is not the clarification policy being "wrong" in principle.
+
+It is clarification winning too often because continuity confidence is not stably preserved.
+
+### 4. Recap And User-Facing Packaging Became More Structured Than Truthful
+
+The fourth fault line is answer-shape drift.
+
+During extraction, recap and packaging became more explicit, which is good.
+
+But in the unstable hybrid phase, explicit packaging sometimes outran explicit truth assembly.
+
+That produces the most dangerous kind of regression:
+
+- not a crash;
+- not a blank answer;
+- but a smooth, template-like answer that sounds coherent while not accurately reflecting what was truly established in the session.
+
+This is why recap hallucination and canned follow-up language became such an important warning sign.
+
+## Surface Symptoms That Are Not The Root Cause
+
+The following things look like the problem, but they are mostly surface symptoms:
+
+- a specific wording like `какие остатки на складе на март 2021`;
+- one particular company like `Альтернатива Плюс`;
+- one particular counterparty like `Чепурнов`;
+- one particular selected object like `Столешница 600*3050*26 альмандин`;
+- one particular recap phrase like `а что мы уже выяснили по этой позиции?`
+
+These questions exposed the break.
+
+They did not create it.
+
+The root cause is not "we forgot a phrase."
+
+The root cause is that the runtime stopped having one coherent authority over:
+
+- frame continuity;
+- scope continuity;
+- selected-object continuity;
+- clarification precedence;
+- recap truthfulness;
+- and business-first answer packaging.
+
+## Why Full Rollback Is Not The Right Default
+
+A full rollback would restore some older behavioral coupling, but it would also throw away real architecture gains from turnaround `11`.
+
+That would hide the breakpoint, not resolve it.
+
+The correct reading is:
+
+- extraction itself is not the mistake;
+- incomplete extraction with split continuity ownership is the mistake.
+
+So the right response is not "go back to the old monolith."
+
+The right response is:
+
+- finish the continuity contract;
+- reduce hybrid priority conflicts;
+- prove behavior on real mixed saved-session runs;
+- only roll back isolated seams if a specific extraction is shown to be unrecoverable.
+
+## What Must Be Fixed To Exit This Breakpoint
+
+The project does not need general beautification to recover.
+
+It needs a narrow set of structural completions.
+
+### 1. One Source Of Truth For Runtime Continuity
+
+The system needs one authoritative contract for:
+
+- active root frame;
+- selected object;
+- active company scope;
+- temporal carryover;
+- same-date restore;
+- recap vs continue behavior.
+
+Until that exists, mixed sessions will remain vulnerable to drift between policies.
+
+### 2. Clarification Must Become A Last Meaningful Step, Not A Default Escape Hatch
+
+The system should ask for company clarification when the business frame is genuinely underdetermined.
+
+It should not do so simply because cross-layer continuity was lost.
+
+### 3. Recap Must Be Built From Verified Session Facts
+
+Recap must summarize what was truly established:
+
+- selected object;
+- supplier;
+- purchase date;
+- documents found;
+- organization chosen;
+- date boundary actually used.
+
+If these facts are missing, the answer must say so honestly.
+
+It must not backfill a neat template.
+
+### 4. Saved-Session Mixed Runtime Must Become A First-Class Acceptance Gate
+
+Narrow harnesses remain useful, but they are not enough.
+
+The mixed runtime path has to become a primary architectural acceptance gate before mass domain expansion.
+
+## Final Conclusion
+
+Everything did not break because one feature was removed.
+
+Everything started to break when the project crossed from old monolithic coherence into hybrid extracted coherence without yet finishing the new runtime contract.
+
+That is the breakpoint of turnaround `11`.
+
+In one sentence:
+
+the project broke at the moment when decision ownership became distributed faster than continuity ownership became explicit.
+
+That is the main architectural fact to remember before continuing the final stabilization passes.

docs/ARCH/11 - architecture_turnaround/11 - continuity_stabilization_plan_2026-04-17.md

@@ -0,0 +1,157 @@
+# 11 - Continuity Stabilization Plan (2026-04-17)
+
+## Purpose
+
+This note defines the recovery plan for the current pre-expansion breakpoint.
+
+The goal is not to patch individual failing prompts.
+
+The goal is to finish the missing runtime authority that should govern mixed live sessions after the turnaround `11` owner extractions.
+
+## Current Reading
+
+The strongest current evidence is:
+
+- narrow and company-selected scenarios can pass end-to-end;
+- mixed saved-session runtime still fails on root inventory, selected-object continuity, same-date restore, and cross-domain same-date pivot;
+- therefore the architecture is not missing only routes;
+- it is missing one governing continuity authority.
+
+In one sentence:
+
+- decision ownership became distributed faster than continuity ownership became explicit.
+
+## What This Plan Stabilizes
+
+This plan is specifically about one system object:
+
+- `assistant_session_continuity_v1`
+
+That object should become the shared authority for:
+
+- active root frame
+- active selected object
+- active organization scope
+- active date scope
+- active clarification state
+- active answer object / reusable bundle
+- recap source of truth
+
+## Target Runtime Rule
+
+Before any of the following decisions are made:
+
+- route arbitration
+- company clarification
+- selected-object follow-up routing
+- same-date restore
+- recap answer generation
+
+the runtime must first resolve one continuity snapshot for the active session.
+
+Those downstream owners may interpret the snapshot differently, but they must not reconstruct competing versions of the session state independently.
+
+## Immediate Passes
+
+### Pass A. Install shared continuity snapshot
+
+Scope:
+
+- create one shared continuity resolver for session items and grounded address context;
+- centralize extraction of active item, organization, date, root frame, and recap-eligible grounded context;
+- stop allowing recap and adjacent meta logic to build over ungrounded or clarification-only state.
+
+Exit condition:
+
+- recap can only trigger over verified grounded address context;
+- selected-object memory cannot be reconstructed from failed clarification turns;
+- route and memory layers consume the same continuity snapshot.
+
+### Pass B. Reduce clarification priority conflicts
+
+Scope:
+
+- move clarification behind restored continuity when the business frame is already sufficient;
+- stop repeated company clarification from interrupting same-family continuation;
+- make clarification state explicit and resumable instead of re-discovered ad hoc.
+
+Exit condition:
+
+- repeated clarification no longer appears after adjacent grounded business answers in the same thread;
+- selected-object and same-date follow-ups stop falling into generic company templates.
+
+### Pass C. Re-ground recap and answer packaging
+
+Scope:
+
+- recap must summarize verified session facts only;
+- answer packaging must not sound more certain than truth assembly;
+- technical scaffolding must not leak into the top block of user-facing answers.
+
+Exit condition:
+
+- recap cannot claim supplier/date/document facts that were never grounded;
+- meta boundary replies no longer expose `MCP`, `read-only`, route ids, capability ids, or debug labels;
+- user-facing top blocks remain business-first.
+
+### Pass D. Lock mixed runtime as the primary gate
+
+Scope:
+
+- promote mixed saved-session runtime to the main architecture gate before domain expansion;
+- keep narrow harnesses and seam tests, but do not let them overrule mixed replay;
+- evaluate critical user paths rather than isolated route green status.
+
+Exit condition:
+
+- the core mixed replay is green on direct answer, selected-object continuity, same-date carryover, recap truthfulness, and technical cleanliness;
+- no unresolved `P0` remains on the primary user path.
+
+## Anti-Goals
+
+This stabilization pass is not:
+
+- a rollback to the old monolith
+- a case-by-case regex patch sweep
+- a prompt-only wording cleanup
+- a UI-only improvement pass
+
+## Practical Sequence
+
+1. Finish the continuity snapshot and wire it into the hot route / recap path.
+2. Rework clarification precedence so it becomes a last meaningful step.
+3. Harden recap and boundary presentation against ungrounded and technical output.
+4. Rerun the mixed AGENT replay until the critical continuity edges are green.
+5. Only then continue deeper intent extraction and wider domain expansion.
+
+## Current Pass Status
+
+Completed in the current working pass:
+
+- shared continuity snapshot is already wired into recap and adjacent route memory logic;
+- grounded address history can now restore `active organization scope` instead of depending only on explicit company-selection metadata;
+- early organization clarification no longer outranks item-focused inventory follow-up paths when the session already carries a strong object frame;
+- meta boundary replies were already cleaned from technical `MCP` / `read-only` leakage.
+- early `non_domain` arbitration no longer suppresses a positive L0 address-lane decision for colloquial but supported exact routes;
+- foreign-accounting pivots over inventory drilldown now preserve root-scoped carryover instead of dropping continuity before root-frame sanitation;
+- the wide `assistantAddressFollowupContext` regression pack is green again, including month-only VAT follow-up and inventory -> VAT pivot sanitation.
+- counterparty document root wording is now recovered through unicode-safe exact signals instead of depending on mojibake-sensitive legacy phrases;
+- declined Russian account wording like `по счёту 60` now restores account scope inside polarity/runtime guards instead of collapsing into `other_numeric`;
+- exact address intents can now stay in the address lane even if the semantic guard overflags deep investigation without an actual investigative user request;
+- live replay `address_truth_harness_phase7_meta_domain_mix_live_20260417_post_arch_fix_rerun2` is accepted end-to-end with `14/14` steps green, including the previously broken `step_01_counterparty_documents` and `step_04_open_items_account_60`.
+
+Still open after this pass:
+
+- mixed continuity is now strong enough for the current phase7 gate, but it still needs broader saved-session proof before domain expansion can be treated as low-risk;
+- the next architecture pass should move from one repaired mixed replay to a wider saved-session set and multi-domain acceptance pack;
+- remaining work should focus on keeping the unified continuity authority stable under new real user paths, not on wording-only polish or isolated route greens.
+
+## Ready Signal
+
+The project can leave the current breakpoint when:
+
+- mixed live sessions no longer depend on distributed guesswork about active context;
+- clarification does not outrank valid restored business continuity;
+- recap is grounded and business-useful;
+- technical scaffolding is removed from user-facing meta answers;
+- the primary mixed replay is green for the real user path, not only for narrow packs.

docs/ARCH/11 - architecture_turnaround/README.md

@@ -26,12 +26,15 @@ This package answers the next question:
 6. [06 - phase_acceptance_matrix.md](./06%20-%20phase_acceptance_matrix.md)
 7. [07 - external_reference_appendix.md](./07%20-%20external_reference_appendix.md)
 8. [08 - current_status_audit_2026-04-17.md](./08%20-%20current_status_audit_2026-04-17.md)
+9. [09 - pre_expansion_cut_2026-04-17.md](./09%20-%20pre_expansion_cut_2026-04-17.md)
+10. [10 - regression_breakpoint_analysis_2026-04-17.md](./10%20-%20regression_breakpoint_analysis_2026-04-17.md)
+11. [11 - continuity_stabilization_plan_2026-04-17.md](./11%20-%20continuity_stabilization_plan_2026-04-17.md)
 
 ## Current Status Snapshot (2026-04-17)
 
 This package is no longer planning-only.
 
-It now documents a turnaround that is already partially operational in code:
+It now documents a turnaround that is already operational in code but still inside a pre-expansion stabilization breakpoint:
 
 - route, transition, boundary, meta, memory, and provider policy owners exist as separate modules;
 - exact-lane truth and coverage/evidence contracts exist as explicit runtime artifacts;
@@ -40,16 +43,25 @@ It now documents a turnaround that is already partially operational in code:
 
 Current honest status:
 
-- estimated overall completion: `~85%`
-- graph snapshot after latest rebuild: `5228 nodes`, `11338 edges`, `133 communities`
+- turnaround implementation progress: `~88%`
+- pre-expansion readiness: `~62%`
+- graph snapshot after latest rebuild: `5312 nodes`, `11408 edges`, `136 communities`
+- current breakpoint:
+  - mixed saved-session runtime still fails on continuity-critical edges;
+  - clarification can outrank restored business context;
+  - recap and user-facing packaging can remain smoother than the actual grounded thread.
 - main remaining architectural pressure:
-  - `resolveAddressIntent()`
-  - `composeFactualReply()`
+  - no single authoritative continuity contract for live mixed sessions
   - residual coordinator/legacy pressure inside `assistantService.ts`
+  - central domain-intent pressure inside `resolveAddressIntent()`
+  - remaining answer-semantics pressure inside `composeStage.ts`
 
 For the detailed audit, current percentages, and remaining debt, read:
 
 - [08 - current_status_audit_2026-04-17.md](./08%20-%20current_status_audit_2026-04-17.md)
+- [09 - pre_expansion_cut_2026-04-17.md](./09%20-%20pre_expansion_cut_2026-04-17.md)
+- [10 - regression_breakpoint_analysis_2026-04-17.md](./10%20-%20regression_breakpoint_analysis_2026-04-17.md)
+- [11 - continuity_stabilization_plan_2026-04-17.md](./11%20-%20continuity_stabilization_plan_2026-04-17.md)
 
 ## Architectural Objects Of Planning
 
@@ -76,6 +88,9 @@ Read in this order:
 7. `06 - phase_acceptance_matrix.md`
 8. `07 - external_reference_appendix.md`
 9. `08 - current_status_audit_2026-04-17.md`
+10. `09 - pre_expansion_cut_2026-04-17.md`
+11. `10 - regression_breakpoint_analysis_2026-04-17.md`
+12. `11 - continuity_stabilization_plan_2026-04-17.md`
 
 ## Planning Rules
 
@@ -95,10 +110,12 @@ and start being described as:
 
 - "a stateful exact-data assistant with explicit transition contracts and isolated truth gating."
 
-As of `2026-04-17`, the project is already materially closer to the target description, but not fully there yet.
+As of `2026-04-17`, the project is already materially closer to the target description, but mixed-session continuity is still not governed by one runtime authority.
 
 The biggest remaining blockers are:
 
+- split continuity ownership across route / transition / recap / coordinator glue;
+- clarification precedence still too strong in mixed sessions;
 - residual `assistantService` overload;
-- central answer-shaping pressure in `composeFactualReply()`;
-- central intent pressure in `resolveAddressIntent()`.
+- central intent pressure in `resolveAddressIntent()`;
+- remaining answer-semantics pressure in `composeStage.ts`.