chore(opencode.lock): pin to v1.17.3-amicode.12 - #230
Merged
Conversation
Three chat fixes from opencode#99, all one root cause — the assumption that amicode work always arrives as an amicode_* tool part: - the shell row no longer renders agent prose where a command belongs - entity chips appear on shell-driven sessions (bash + amico-run), which is the shape a cloud solve actually takes - the amico mark stays active during a running solve Verified on the tagged commit: unit + typecheck green, e2e at the pre-existing 2/7 baseline with nothing new.
Rchari1
added a commit
that referenced
this pull request
Aug 6, 2026
…ith real output
Diagnosis of three cloud failures in two days. Every one was a script that did not
come from the template, and that single fact explains BOTH symptoms — the failures
and the empty Run Inspector:
x-gate-transmon-56 authored from memory: CubicSplinePulse kwargs, CallbackLogger,
get_fidelity — none exist
x-gate-transmon-hpc REUSED a Jul-28 script verbatim; ZeroOrderPulse into
SplinePulseProblem, which Piccolo 1.19 rejects outright
x-gate-transmon-hpc-3 authored from memory: CubicSplinePulseProblem (undefined),
AltissimoOptions(intermediate_callback=…) (no such field)
Each reproduced locally and each symbol checked with isdefined/fieldnames, not
assumed. Note the middle one: ~/.amico/problems/<slug>/solve.jl persists across
sessions and the agent reuses it, so template improvements never reach an existing
slug.
A correction to my own earlier claim: cloud streaming does NOT need aws-infra#230.
The template's emit() appends to run.log whenever TASK_ID is set, and the runner
sets TASK_ID — so a template-derived script streams today. All three of these wrote
run.log zero times, which is the entire reason nothing reached the Inspector. The
evidence is in the run itself: /frames reports iter: 60 for a solve whose /stats was
empty. It ran 60 iterations and wrote 60 frames; only the numbers were lost. #230
remains worth deploying — it captures stderr, which is why these failures presented
as a bare "failed, exit 1" — but it is not the streaming blocker.
So: a cloud telemetry preflight. A remote launch whose script never writes run.log
is refused in about a second, naming the cause and the fix, instead of costing ten
minutes and naming nothing. A refusal rather than a warning because it is a
certainty, not a risk, and stderr warnings have not changed the behaviour. Gated on
hasCloudConfig() so the missing-connection error keeps precedence — it is the more
fundamental problem. Local runs are untouched: LocalExecutor pipes the child's
stdout into run.log itself (local_executor.ts:293), which is why local has always
worked and why this must be remote-only.
Verification, and the reason it is worth trusting this time: FakeCloud now derives
BOTH /stats and /pulse from ONE run.log through the deployed lambda's own transform
(statsFromRunLog is a line-for-line port), so tests see the records the live service
actually returns — {raw: "iter=7 f=…"}, key=value, never pre-parsed JSON. Seeding
what the CLIENT expects is how three drift bugs shipped green. The end-to-end test
drives a run.log CAPTURED from a real Altissimo solve on Piccolissimo 0.3.1
(test/fixtures/altissimo_cloud_run.log) and asserts all four iterations arrive with
the real objectives, plus the pulse meta.
Chain status: template+TASK_ID → run.log (verified, real solve); S3 sync (proven in
production — frames arrive this way); /stats grep (verified against the live lambda);
client {raw} parse → local run.log (verified); tailer → Inspector (verified with
captured output). Every link but the S3 sync exercised locally.
948 amico-run + 903 extension tests pass.
Co-Authored-By: Claude Opus 5 (1M context) <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.
Bumps the vendored fork
v1.17.3-amicode.11→v1.17.3-amicode.12.3 commits, all from opencode#99 — three separately-reported symptoms that turned out to be one design assumption: "amicode work always arrives as an
amicode_*tool part."command ?? title ?? description. A pending bash part has noinput.command, so it fell through to the model's free-textdescriptionand rendered prose where users read a command — for the command's whole duration (1m55s observed). Nothing had failed; the solve was on iteration 29 with frames on disk.part.tool.startsWith("amicode_"), so a session doing its amicode work through the shell showed no chips at all — despite having created a problem workspace, written a solvespec, and driven a solve to iteration 29 viabash+amico-run.amicode_*test, so the H-mark read inactive during that same running solve.Both rules are now pure tested modules (
rail-gate.ts,shell-row.ts); the gate has one definition and three call sites. The refetch key is deliberately not widened — shell parts don't mutate the problem view through the tool seam.Why this matters for the cloud-solve path: a solve driven through
amico-runin the shell is precisely the case all three bugs hit. On.11that session shows no entity chips, an inactive amico mark, and a stale prose sentence sitting where a command belongs.Verification
Fork CI on the tagged commit
3a1f6b9c:Release build: both assets published, UI gate asserted ON in each.
Locally from this pin:
The
refresolved automatically — no--refneeded, courtesy of #222.