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

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.