Repository navigation
feat(adr-001 #4): surface witness/budget/cache primitives in estimateComplexityClass - #42
Merged
Merged
Conversation
…ComplexityClass PR #30 added the closure / single-entry / contrastive primitives to handleEstimateComplexityClass's lookup table. Six more primitives shipped after that (PRs #34, #38, #39, #40, #41) — none were wire-queryable. This lands the missing rows so MCP clients can predict any phase-2+ primitive's class: Method Class Edge-safe? solve-on-change-sublinear-auto SubLinear yes contrastive-solve-on-change-sublinear-auto SubLinear yes verify-sparse-solution SubLinear yes plan-budget-try-consume Logarithmic yes coherence-cache-build Linear no coherence-cache-update SubLinear yes delta-below-solve-threshold Logarithmic yes Each entry's `detail` mirrors the Rust Complexity::DETAIL on its corresponding Op marker or function-level doc comment so the wire contract and the Rust contract stay synced. Note: plan-budget-try-consume is O(1), but the taxonomy's cheapest slot is Logarithmic (rank 100). The detail string calls out the true cost explicitly. Co-Authored-By: claude-flow <ruv@ruv.net>
This was referenced May 19, 2026
ruvnet
added a commit
that referenced
this pull request
May 19, 2026
…trator The SubLinear orchestrator shipped in Rust (PR #29) had MCP preview primitives (coherenceScore, closureIndices, estimateComplexityClass) and a wire-callable witness (PR #52). But the orchestrator itself wasn't wire-callable — agents had to fall back to `solve` (which returns the full n-vector) instead of the closure-restricted entries the SubLinear path produces. This closes the gap with a pure-TS handler that chains: 1. closure_indices(matrix, delta.indices, closure_depth) 2. for each closure entry: truncated Neumann iteration restricted to the closure (mirrors src/entry.rs math) 3. return Vec<{row, value}> Lands in src/mcp/server.ts: - New `solveOnChangeSublinear` tool with x-complexity = SubLinear - Input schema: matrix, vector (b_new), delta_indices: number[], closure_depth (default 4), max_terms (default 32), tolerance (default 1e-8) - Dispatch case + handleSolveOnChangeSublinear method - Returns {entries: Array<{row, value}>, closure_size, max_terms, closure_depth, note} - Supports both dense and sparse-COO matrix formats Matches Rust solve_on_change_sublinear semantics exactly: - Early-exit when |delta_k[target]| < tolerance - Zero-diagonal in closure → InvalidParams - Empty closure → empty entries - note field warns when closure covers full matrix This completes the wire surface for the change-driven inner loop. Agents can now run the full pipeline over MCP: 1. coherenceScore (PR #53) — is the matrix solvable? 2. closureIndices (PR #54) — how wide is the work? 3. estimateComplexityClass (PRs #30, #42) — what class? 4. solveOnChangeSublinear (THIS PR) — actual SubLinear solve 5. verifySparseSolution (PR #52) — audit output All 5 tools are pure-TS. No Rust/WASM bridge required for any of them. Co-Authored-By: claude-flow <ruv@ruv.net>
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.
Summary
PR #30 added the first batch of phase-2 primitives to `handleEstimateComplexityClass`'s lookup table. Six more primitives shipped after that (PRs #34, #38, #39, #40, #41) — none were wire-queryable. This closes the gap.
New table entries
Each entry's `detail` mirrors the Rust `Complexity::DETAIL` on its corresponding Op marker or function-level doc comment so the wire contract and the Rust contract stay synced.
Note on `plan-budget-try-consume`: the true cost is `O(1)` (class-rank comparison + counter decrement). The taxonomy's cheapest slot is `Logarithmic` (rank 100); the detail string calls out the true cost explicitly.
Test plan
🤖 Generated with claude-flow