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

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.