Conversation
- prefer Pi's confirmed toolName and input fields while retaining legacy fallbacks - normalize PreToolUse and PostToolUse through the same bridge mapping - keep malformed and unserializable inputs fail-open without collapsing fingerprints - add Pi bridge regressions for event mapping, socket failures, and breaker behavior
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
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 & why
Pi's live
tool_callandtool_resultevents expose tool identity throughtoolNameandinput, while the generated Pi bridge was still reading the earliername/tool.name/argsshapes.PostToolUsealso dropped the input entirely, which could collapse different tool calls into the same CircuitBreaker fingerprint and incorrectly constrain a healthy agent.This follows the direction validated in the issue: preserve Pi's confirmed
toolNameandinputon both tool boundaries. The bridge now prefers those confirmed fields while keeping the existing legacy fallbacks, and bothPreToolUseandPostToolUseshare the same Pi-local normalization path.The change stays scoped to the generated Pi bridge. It does not change CircuitBreaker fingerprinting, HookServer behavior, or any other provider bridge.
Closes #502.
Type of change
Evidence
Before
Current
main, running the new Pi bridge regression against the unrepaired generated bridge:toolName/inputmapping failsAfter
The same regression on this branch:
name,tool.name, andargsfallbacks remain supported'',false, and0are preservedconstrainedHow I tested it
Result:
The focused Pi regression exercises the actual generated bridge through Node VM and a mocked socket, then feeds the resulting
PostToolUseevents through the real CircuitBreaker.Existing CircuitBreaker coverage also passes:
Additional validation:
I also ran:
The full focused suite is not completely green on my Windows environment. The remaining failures are in existing Windows-specific symlink permission, HOME/path resolution, and source assertion cases outside the files changed by this PR. The new Pi bridge regression passes in full.
Checklist
npm run typecheckpasses.npm run test:focusedpasses.npm run buildsucceeds.DESIGN.md/tokens.tsbecause this PR adds no UI.ATTRIBUTION.mdbecause this PR adds no art.