Every FIX round previously re-ran the whole pipeline - PLAN, every
non-KEEP block's BLOCK_CONFIG, and CONNECTIONS - even when the only
problems were plain bean-validation errors scoped to one existing
block's own configuration (e.g. an overlong EndBlock outcomeLabel, or
the placeholder-naming/BranchRejoin-size violations added earlier this
session). That's wasted LLM calls and unnecessary churn risk on parts
of the flow that were already correct.
FlowAssistantService.assembleFlow now checks, per FIX round, whether
every reported error is cleanly scoped to an existing block and none
of them is in PLAN_SENSITIVE_ERROR_CODES (anything that could imply the
flow's shape needs to change - connections, dependencies, block/
container I/O, lanes, BranchRejoin fan-in, shared-session wiring, ...).
When that holds:
- PLAN is skipped entirely; the plan is rebuilt locally from currentFlow's
existing blocks (UPDATE for the flagged ones, KEEP for the rest) with
no LLM call.
- CONNECTIONS is skipped entirely; existing connections are carried
forward unchanged.
Only BLOCK_CONFIG still runs, and only for the flagged blocks - the
same targeting that already happened via KEEP/UPDATE, now extended to
skip the two other phases too.
This is deliberately conservative: any error outside the safe set, or
any error not attributable to one existing block, falls back to the
existing full-repair behavior unchanged. If a "safe" fix unexpectedly
changes a block's derived I/O anyway (e.g. a factory that derives ports
from placeholder text), the next round's validation will surface a
sensitive code and force a normal full repair - never worse than
before, just self-correcting one round later.
Added a regression test that only mocks BLOCK_CONFIG (not PLAN/
CONNECTIONS) for a block-scoped-only error, so it fails loudly if the
skip logic regresses.
Lucio Lelii
94ed6b245d