Lucio Lelii
fad1eaf4b4
Two more issues found retesting the same live prompt after the
guardSubFlow-redaction fix (confirmed working: no more guard-scaffold
names leaking into prompts).
1. The model kept declaring the same logical step both as a top-level
block AND as a container's own inner block (e.g. "check completion"
as both b4 and c1-b1), then tried to wire the orphaned top-level
duplicate to the container via malformed connections (dotted
qualified names, null toInput) - all silently dropped as invalid,
but leaving the duplicate disconnected/deadlocked instead of fixing
the real problem. Added an explicit NO DUPLICATION rule to the plan
prompt: a step belongs in exactly one place, top-level or inside one
container, never both - only the container's own exposed I/O is
what the rest of the flow should connect to.
2. Separately, a fresh model response put a container type
("LoopContainer") as an entry in the flat "blocks" list instead of
"containers". Block assembly has no catalog descriptor for a
container type, so this threw as an unrecoverable 502 with no
retry - unlike degenerate JSON or a missing required field, which
already get a structured-repair retry. Moved the check into
validateAndNormalizePlan, inside the plan's own retry-wrapped parser
callback, so this now gets the same self-correction chance instead
of hard-failing the whole request.
Verified by mutation testing: reverting the container-type check
reproduces the exact live 502 in the new test; restoring it fixes it.
Full suite: 441/441.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
||
|---|---|---|
| .mvn/wrapper | ||
| src | ||
| .gitattributes | ||
| .gitignore | ||
| Dockerfile | ||
| mvnw | ||
| mvnw.cmd | ||
| ollama-preloaded-docker | ||
| pom.xml | ||