Repository navigation
capabilities: the broker answers a harness's initialize asking another MCP version with its own 2025-06-18, as MCP's version negotiation says (decision 0065 slice two, U9b1c) - #940
Queued
valentinyanakiev wants to merge 3 commits into
Conversation
…r MCP version with its own 2025-06-18, as MCP's version negotiation says (decision 0065 slice two, U9b1c) Claude Code opens with initialize asking 2025-11-25, and the broker refused any version but its own, so a real Claude seat dropped the server and never saw the tools it was granted (the controller's real-harness check, R1). MCP 2025-06-18's lifecycle says a server that does not support the version asked answers with one it does (https://modelcontextprotocol.io/specification/2025-06-18/basic/lifecycle). The broker now greets any string version with its own 2025-06-18 result and holds the session to it: a method that version does not admit still refuses, every bound stays, and an initialize with a missing or non-string version still refuses as invalid. The harness-facing version refusal had no other consumer and goes; a child server off 2025-06-18 keeps its cause. MB3's text says so. The new enabled/negotiation.rs drives the real binary: a harness asking 2025-11-25 is answered 2025-06-18, as one asking 2025-06-18 is, lists the granted tools, is refused an unadmitted method and a non-string version exactly, and completes a call whose retained response opens through inspect. The commission's design and tasks for U9b1c ride with this commit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… broker refuses at compile with the driver's own cause (decision 0065 slice two, U9b1c) A Codex seat holding a brokered grant compiled on Linux and then parked at dispatch, the driver refusing "provider 'codex' has no measured strict MCP configuration for 'brokers'" (the controller's real-harness check, R2). By U7d's design Codex's fragment and dsh's engine-only home carry no broker, so the driver always refuses such a set for them. Past the lifted fence, the compile now refuses that site in its own words with the driver's StrictCause, named by AdapterKind and matched exhaustively, before its SI2 verdict, as the driver orders them. A Claude site compiles holding the grant; a site holding no MCP is unchanged; while the fence stands, as on macOS, nothing moves. The compile's MCP tests gain one case per harness through the real pass, and the pass test's shape and resolver setup becomes shared builders. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
… broker held at Handoff through real dispatch (decision 0065 slice two, U9b1c) U9b1b landed with 46.1 open: its windows ended every startup window three ways but Handoff, which only the startup deadline ended (third review, M1; operator ruling 2026-10-31, "B"). windows.rs now holds Handoff by what establishes it, not by a store read: the bootstrap stopped by the tracer inside its execve of the server, which it enters only once it has the whole binding frame and its end, holding past its standard streams exactly one descriptor, a pipe the broker holds too, its status pipe. At that window the harness's death ends the broker before its deadline, with inspect keeping the seat's result unrecorded and no call row, and the engine's timeout parks the run on its own words. Nothing below the broker remains either way. The deadline-bound check now runs for every window where the startup deadline still stands, because TEARDOWN (30 s) is the whole startup and no longer tells a cancellation from the deadline. Settlement after the harness's death allows for the tracer's delayed exec, which ends a process killed in it only when the delay ends. The module text again claims every window. 46.1 and 46.3-46.5 are ticked; evidence/U9b1c.md records each exact assertion, compiling removal and restored pass, the gates and what stays pending (exact coverage, macOS CI, the controller's real Claude seat), and evidence/U9b1b.md's Tasks paragraph says 46.1 closed here. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
valentinyanakiev
enabled auto-merge
November 1, 2026 03:59
valentinyanakiev
added this pull request to the merge queue
Nov 1, 2026
Any commits made after this event will not be merged.
This branch has not been deployed
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.
Slice two unit U9b1c of decision 0065 (openspec/changes/decision-0065-capabilities-slice-two/design.md, "Slice two units"; decision 0077). Delivered by the run below through the full engine council; its evidence is in the change's tasks.md and its evidence file.
The unit commit's full subject: capabilities: the broker answers a harness's initialize asking another MCP version with its own 2025-06-18, as MCP's version negotiation says (decision 0065 slice two, U9b1c)
Brokkr-Run: 0065-slice-two-unit-u9b1c-see-th-60e69132
Ruling: controller, 2026-10-31, under the operator's standing ruling of 2026-10-28 ("take the recommended option"), on the findings of the real-harness check that ruling F1 of U9b1b asked for: R1, the MCP broker answers a harness's
initializethat asks another protocol version with its own 2025-06-18 result, as MCP 2025-06-18's version negotiation says, instead of refusing it, so a real Claude seat (which asks 2025-11-25) reaches its granted tools; the session stays held to 2025-06-18 and every bound stands. R2, the compile refuses a brokered grant on a provider whose fragment carries no broker (Codex, dsh) with the driver's own cause, instead of parking at dispatch. Both are this small unit's, after U9b1b and before U9b2. The holds of 2026-10-30 stand until it lands.Ruling: operator, in chat, 2026-10-31 ("B", on U9b1b's second run, parked REVIEW-REFORGE-EXHAUSTED-MEDIUM): U9b1b landed by hand with task 46.1 open, and this unit carries its remainder as task 46.5, the harness's death and the engine's timeout through real dispatch at the Handoff window, then ticks 46.1; crates/brokkr-cli/tests/capability_broker/enabled/windows.rs joins this row.
Ruling: operator, in chat, 2026-11-01 ("A", after #933 fell out of the merge queue on hosted-runner timing): the enabled suite's teardown bounds in windows.rs become one 30 s constant, test-only, so a hosted runner's slower teardown does not fail a window's proof; no product bound changes.
🤖 Generated with Claude Code