ci: fold the ts-rs drift gate into the job that already built it (delete a duplicate 9-min compile) - #2331
Merged
Merged
Conversation
joelteply
added a commit
that referenced
this pull request
Aug 16, 2026
…im (evaluator <10ms flake) (#2333) `test_all_gates_pass_normal_message` failed CI at 10.72971ms against a hardcoded `decision_time_ms < 10.0`. The gates did not regress — the runner was busy. It is red on PR #2331, whose diff is CI workflow config and cannot possibly have touched persona gating. A correctness test that a loaded machine can fail is not measuring the code, it is measuring the machine. Worse, it spends the reviewer's trust every time it flakes: the next red is assumed to be noise, and eventually a real one is. The performance claim is real and worth keeping, so it is NOT deleted — it MOVES to a `#[cfg(feature = "stress-tests")]` block (CLAUDE.md § test rules, item 2), where default `cargo test` does not run it and a quiet machine can. The stress version also takes the MEDIAN of 50 runs instead of trusting one sample, since a single timing of a live system is not a fact about it — one scheduler hiccup is not a regression. The correctness test keeps its correctness assertion (`should_respond`) and now asserts nothing about the clock. Same treatment as the grounding-cost flake in PR #2330 — second instance of this class, so it is a missing constraint, not two bugs. Surveyed the rest of the tree: 3 siblings exist (command_executor <500ms, rag/engine <250ms, sentinel/parallel <180ms). Deliberately NOT touched — none is failing and each has 20-50x more headroom than the 10ms budget that broke. Named in a comment at the fix site so the next person has the map instead of rediscovering it. cargo test persona::evaluator: 33 passed, 0 failed. cargo check --features stress-tests --profile test: clean (the gated block builds). Claude-Session: https://claude.ai/code/session_01LoTjvf5j3Ez13g6k8mRkFo Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
…lete a duplicate 9-min compile The drift guard was its own ubuntu job that checked out the repo, installed the same apt deps, restored the same shared rust-cache, and compiled continuum-core — all to run `cargo test -p continuum-core --lib export_bindings`, a strict SUBSET of the `cargo test … --lib` the sibling job runs one workflow over. That job already regenerates every ts-rs binding as a side effect of the same tests. So the second compile bought nothing. The gate is the `git diff` over protocol/typescript/, not the build; it belongs where the build already happened. Moved the verification step into cargo-test-continuum-core (unchanged wording, same error message and fix instructions) and deleted the workflow. Added protocol/typescript/** to the tests workflow's path filter so an edit to a generated .ts alone still trips the gate — the deleted workflow watched that path and the surviving one did not. Net: one fewer ubuntu runner and ~9 min of duplicate compile per PR; the guard itself is unchanged and still fails loud with the same remediation text. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LoTjvf5j3Ez13g6k8mRkFo
joelteply
force-pushed
the
ci/fold-ts-rs-drift-into-test-job
branch
from
August 17, 2026 00:28
d632a47 to
f48b486
Compare
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.
What was redundant
ts-rs-binding-drift-guard.ymlwas a second ubuntu job that:Swatinem/rust-cacheshared-key: continuum-rust-1.95…in order to run
cargo test -p continuum-core --lib export_bindings— a strict subset of thecargo test -p continuum-core --libthatcontinuum-rust-tests.ymlruns on the very same trigger. That job already regenerates every ts-rs binding, because writing the .ts file is the side effect of theexport_bindings_*tests.So the second compile produced nothing the first hadn't. Measured on PR #2330:
cargo test --lib10m19s,ts-rs binding drift detector8m41s.The fix
The gate is the
git diff protocol/typescript/, not the build. Moved that step intocargo-test-continuum-core, right after the test run that regenerates the bindings, and deleted the workflow.protocol/typescript/**to the surviving workflow'spaths:filter — the deleted workflow watched that path and the surviving one did not, so an edit to a generated .ts alone would otherwise have skipped the gate.Net effect
One fewer ubuntu runner and ~9 min of duplicate compile per Rust PR. Critical path is unchanged (it was never the long pole —
cargo testand the windows check both run longer). The guard's behaviour is identical.🤖 Generated with Claude Code
https://claude.ai/code/session_01LoTjvf5j3Ez13g6k8mRkFo