chore(sync): develop → main — core-integration gate shape + LV-26 - #141
Merged
Conversation
… Core (#139) Step 5 reported "no gates" against a Core that had evaluated six of them. The Core was right; the assertion was wrong. The canonical `EvaluationResult` nests per-kind results under `results` (`gate`, `artifact`, `compliance`). It is the TRACKER's own DTO that flattens them to `gates`, and this robot reaches the Core THROUGH the gateway, so it receives the canonical shape and never the flattened one. A second defect sat in the same helper and would have survived the first fix: `summarizeVerdict` compared each verdict against `'failed'` while the Core emits `FAIL`. Even given the right array it would have reported zero failures on a run where all six gates failed — a green-looking summary over a red result, which is worse than no summary at all. Verified against a captured REST response rather than argued, and run against the UNFIXED helper first so the change is known to matter: before gates=0 · failed=0 (and the check said "no gates") after gates=6 · failed=6 Checked for the same shape elsewhere in robosoft/: no other robot reads `.gates` or compares against a lowercase verdict. Found while running this robot against a live two-cluster stack for the first time — it is excluded from the default runner and had never executed. The same run found a real product defect (the MCP chart's runAsUser, fixed in evolith#425); this one was the instrument. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
#140) * fix(robosoft): core-integration read the Tracker's gate shape off the Core Step 5 reported "no gates" against a Core that had evaluated six of them. The Core was right; the assertion was wrong. The canonical `EvaluationResult` nests per-kind results under `results` (`gate`, `artifact`, `compliance`). It is the TRACKER's own DTO that flattens them to `gates`, and this robot reaches the Core THROUGH the gateway, so it receives the canonical shape and never the flattened one. A second defect sat in the same helper and would have survived the first fix: `summarizeVerdict` compared each verdict against `'failed'` while the Core emits `FAIL`. Even given the right array it would have reported zero failures on a run where all six gates failed — a green-looking summary over a red result, which is worse than no summary at all. Verified against a captured REST response rather than argued, and run against the UNFIXED helper first so the change is known to matter: before gates=0 · failed=0 (and the check said "no gates") after gates=6 · failed=6 Checked for the same shape elsewhere in robosoft/: no other robot reads `.gates` or compares against a lowercase verdict. Found while running this robot against a live two-cluster stack for the first time — it is excluded from the default runner and had never executed. The same run found a real product defect (the MCP chart's runAsUser, fixed in evolith#425); this one was the instrument. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs(gaps): register LV-26 — an upstream 401 reaches the caller as 502 `AgentRuntimeGateway` throws with the upstream status. The executor flattens it to a string so the failed turn is still recorded — that intent is right — but the status does not survive: `Translate` re-derives one from the string, matches no case, and falls through to `_ => ("AgentRuntime.Failed", 502)`. Two things are lost at once: the upstream 401, and the specific code, rewritten to the generic one. A CREDENTIAL problem is therefore reported as an AVAILABILITY problem. 502 sends the operator to check whether the runtime is up; it was up, and answering 401 in 88ms. The endpoint's own comment already recognises that collapsing to an HTTP code erases the story and that the trace keeps it — but the caller has no trace, and the caller is who acts. Observed on 2026-08-04: `core-integration` reported `POST /assistant/converse → 502` against a live two-cluster stack. The cause was AGENT_RUNTIME_API_KEY differing between the Tracker's secret and the runtime's. Only the tracker-api log carried the 401. Aligning the key turned the step green, so the diagnosis is confirmed and the mis-mapping is what cost the time. Registered P2/XS with the fix scoped to the ERASURE, not the number: 502 is arguably right (the caller's own auth succeeded, the failure is upstream) — what is wrong is that the body cannot tell an auth failure from an unreachable runtime. Found running this robot against a live stack for the FIRST time; it is excluded from the default runner. The same run found a real Core defect (evolith_arch32#425) and one in the robot itself (#139). NOTE, pre-existing and untouched: the board's declared counters are stale by five rows. Before this change the header said 174 done / 17 pending while the table held 179 DONE / 12 PENDING; the same offset holds after. This row follows the existing convention (total and pending both +1) rather than silently re-baselining numbers it has not reconciled row-by-row. Worth its own pass — the Core repo has a guard for exactly this and this board has none. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two commits from the first-ever live run of the
core-integrationrobot against a two-cluster stack.gatesoff the Core, which nests them underresults.gate. It reported "no gates" against a Core that had evaluated six. A second defect in the same helper compared verdicts against'failed'while the Core emitsFAIL, so even the corrected path would have reported zero failures on a fully-failed run.LV-26: an upstream 401 reaches the caller as 502 with the specific code overwritten, so a credential problem reads as an availability problem.The same run also found a real Core defect (beyondnetcode/evolith_arch32#425). Of the three findings, one was the product here, one was the product there, and one was the instrument.
After this the robot passes 13/13 against the live stack.
🤖 Generated with Claude Code