АРЧ АП11 - Архитектура: вынести inventory intent-family из resolveAddressIntent и зафиксировать pre-expansion cut

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

@@ -25,9 +25,9 @@ This snapshot is based on:
 
 Latest graph rebuild:
 
-- `5261 nodes`
-- `11347 edges`
-- `134 communities`
+- `5284 nodes`
+- `11402 edges`
+- `138 communities`
 
 Most relevant current god nodes for turnaround `11`:
 
@@ -126,7 +126,7 @@ This is enough to build targeted semantic packs that are not single-domain toy s
 
 ## Honest Phase Status
 
-Estimated overall turnaround completion: `~90%`
+Estimated overall turnaround completion: `~91%`
 
 ### Phase 0. Shared Baseline
 
@@ -163,12 +163,13 @@ Remaining debt:
 
 ### Phase 3. Capability Contracts
 
-Status: `86%`
+Status: `88%`
 
 Reason:
 
 - critical inventory/address capabilities are materially contract-driven;
 - selected-object and root capability behavior is much more explicit than before.
+- inventory intent-family now has an explicit owner in `addressInventoryIntentSignals.ts` instead of staying only as inline signal pressure inside `resolveAddressIntent()`.
 
 Remaining debt:
 
@@ -251,6 +252,7 @@ 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;
+- inventory intent classification now 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

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

@@ -0,0 +1,128 @@
+# 09 - Pre-Expansion Cut (2026-04-17)
+
+## Purpose
+
+This note freezes the practical cutoff for turnaround `11` before mass domain expansion.
+
+The goal is not architectural perfection.
+
+The goal is to separate:
+
+- what must be closed before large-scale domain growth;
+- what can be consciously deferred without putting expansion quality at risk.
+
+## Current Read
+
+As of `2026-04-17`, the architecture is no longer in the "foundations are unstable" state.
+
+The system already has:
+
+- extracted route / transition / boundary / meta / memory owners;
+- explicit truth and coverage/evidence contracts;
+- scenario acceptance artifacts;
+- live AGENT semantic replay practice;
+- materially stronger selected-object and temporal continuity than in the baseline state.
+
+The remaining problem is different now:
+
+- 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()`
+
+Why it matters:
+
+- this is still the main domain-intent concentration point in the graph;
+- new domain slices will increase route collisions and accidental cross-triggering;
+- follow-up-heavy contours will become harder to reason about if raw signal families stay mixed in one resolver body.
+
+What "done enough" means:
+
+- the most stressed signal families are delegated to dedicated owners;
+- inventory, counterparty/documents, and high-risk settlement families are no longer all encoded inline in one body;
+- targeted regression packs exist for each extracted family.
+
+Current status:
+
+- inventory signal-family is now delegated to `addressInventoryIntentSignals.ts`;
+- this reduces ownership pressure, even though the old inline bodies still remain as cleanup debt.
+
+### 2. Answer semantics pressure in `composeFactualReplyBody()`
+
+Why it matters:
+
+- this still controls too much user-facing behavior;
+- technical leakage, limitation phrasing, and answer-shape instability can spread into new domains quickly;
+- every new domain added on top of a still-heavy compose body increases presentation inconsistency risk.
+
+What "done enough" means:
+
+- the hottest answer families are routed through dedicated builders/presentation owners;
+- 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
+
+Why it matters:
+
+- mass expansion will multiply edge cases faster than humans can manually spot them;
+- if hot contours still leak technical junk or weak follow-up logic, the problem will scale with every new domain.
+
+What "done enough" means:
+
+- AGENT semantic runs continue to validate mixed business chains;
+- core hot contours are checked for direct-answer usefulness, selected-object continuity, temporal honesty, and no technical leakage;
+- enablement gaps are treated as contour-extension work, not dismissed as "unsupported".
+
+## Can Be Deferred After Expansion Starts
+
+### 1. Full `assistantService.ts` beautification
+
+This still matters, but it is no longer the primary pre-expansion blocker.
+
+As long as runtime-critical policy ownership is already externalized, some coordinator-local legacy bodies can remain temporarily.
+
+### 2. Full elimination of every residual helper duplicate
+
+If ownership has already moved and regression coverage exists, residual historical helper bodies are cleanup work, not expansion blockers.
+
+They should be removed during later hardening passes, but they do not all need to be gone before domain growth begins.
+
+### 3. Long-tail micro-polish in reply tone
+
+Minor phrasing improvements can be postponed if:
+
+- the business answer is already truthful;
+- no technical internals leak to the user;
+- answer shape remains useful and stable.
+
+### 4. UI-first acceptance ergonomics
+
+The current script-driven acceptance loop is good enough for pre-expansion gating.
+
+Promoting every replay step into a more polished UI loop can happen later.
+
+## Recommended Final Turnaround Sequence
+
+### Pass 1
+
+- continue extracting the highest-risk signal families out of `resolveAddressIntent()`;
+- keep business behavior stable through focused regression packs;
+- 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;
+- confirm with AGENT replay that user-facing answers stay business-first.
+
+## Practical Exit Condition
+
+Turnaround `11` can be considered "ready for domain expansion" when:
+
+- 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;
+- remaining debt is mostly cleanup debt, not architecture debt that can multiply regressions during expansion.