Keep the two-checkout parity harness working across a moved bridge - #2240
Closed
SawyerHood wants to merge 1 commit into
Closed
Keep the two-checkout parity harness working across a moved bridge#2240SawyerHood wants to merge 1 commit into
SawyerHood wants to merge 1 commit into
Conversation
A parity run spawns the SAME provider from an older checkout, so a bridge module that moved must still be found there. The ACP plugin's host entry became src/host.ts when the bridge moved into the published kit, and the old leg then spawned nothing: every acp-cursor cell reported 0 events and three stalls, which reads exactly like a broken change under test. FIRST_PARTY_BRIDGE_MODULES now names where a bridge lived before, and the launch resolves the first path that exists in that checkout. Also allowlists the last intended acp-cursor diff class: a command that printed nothing no longer shows its rawOutput envelope (#2234), which the approval-allow cell exercises with . Co-Authored-By: Claude <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.
Stacked on #2238.
What was wrong
pnpm parity --old <main-worktree> --new .spawns the same provider's bridge from two checkouts.FIRST_PARTY_BRIDGE_MODULESnames one path per bridge, resolved against each checkout root — so a bridge module that moves makes the old leg spawn nothing.#2228 moved the ACP bridge into the published kit and repointed the harness at the plugin's new one-line host entry (
plugins/provider-acp/src/host.ts). That file does not exist in a pre-migration checkout, so every acp-cursor cell came back:Zero events on the old leg, three stalls, ten cells "failing" — which reads exactly like a badly broken change under test. It cost me a full debugging pass to notice the old leg was the broken one, and it would have cost the next person the same.
What changed
FIRST_PARTY_BRIDGE_MODULESentries may namelegacyModulePaths, andresolveBridgeLaunchpicks the first path that exists in that checkout (falling back to the current path when none do, so a genuinely missing module still fails loudly instead of replaying nothing). The ACP entry lists its pre-kit location.Also adds the last intended acp-cursor allowlist class, attributed to the layer that caused it: #2234 stopped showing a command's
rawOutputenvelope when the command printed nothing, andapproval-allowexercises that withtouch approved.txt.How I verified
Two-checkout A2 against a
mainworktree, on a quiet machine, at this stack tip:acp-cursorcodexclaude-codeBefore this fix the same acp-cursor command reported 0 passed / 10 failed with three stalls per cell.
pnpm exec turbo run test --filter=@bb/provider-parity --force: 43/43.