struct literal construction fix by Leonte-Tudor · Pull Request #2 · mareurs/codescout

Leonte-Tudor · 2026-03-29T13:11:52Z

rmcp 1.3.0 marked StreamableHttpServerConfig as #[non_exhaustive], breaking
struct literal construction with ..Default::default(). Switch to the builder
API (.with_cancellation_token()) which works across all rmcp 1.x versions.

What

fix: use builder pattern for StreamableHttpServerConfig (rmcp 1.3.0 compat)

Why

"cargo install codescout" fails with:
error[E0639]: cannot create non-exhaustive struct using struct expression
--> /home/leon/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/codescout-0.7.1/src/server.rs:521:17
|
521 | / StreamableHttpServerConfig {
522 | | cancellation_token: ct.child_token(),
523 | | ..Default::default()
524 | | },
| |_________________^

Testing

cargo fmt
cargo clippy -- -D warnings
cargo test

…ompat) rmcp 1.3.0 marked StreamableHttpServerConfig as #[non_exhaustive], breaking struct literal construction with ..Default::default(). Switch to the builder API (.with_cancellation_token()) which works across all rmcp 1.x versions.

Four-tier cleanup batch after I1 wrap. Tier 1 — Tool-misbehavior promotion (overdue per CLAUDE.md MANDATORY): - docs/issues/bug-tracker.md: added #2 (read_file json_path on array elements), #3 (read_file line range past midpoint), #4 (grep on @tool_ buffer false-negatives). All promoted from F-1/F-2/F-11 in i1-session-friction.md. - i1-session-friction.md Index + per-entry statuses flipped to promoted-to-bug-tracker with bug-tracker.md pointers. Tier 2 — librarian(audit_doc_refs) ran on 5 files. 113 refs / 41 resolved / 58 broken / 13 unknown. This session's shipped artifacts (eval, template, CLAUDE.md additions) scanned clean — only 1 cross-repo ref + 1 notation false-positive flagged. Tier 3 — memory writes (outside repo, not in this commit): ~/.claude/projects/.../memory/concurrent-work-rules.md, eval-before-rewrite-discipline.md, two-concretes-threshold.md + MEMORY.md pointers. Tier 4 — eval expansion 7 → 15 cases: - docs/evals/reconnaissance-trigger.md: added 8 new cases (refactor-shape- named, refactor-internal, compile-error, completion-claim, multi-file integration, test-for-scouted-symbol, plan-status query, architectural decision). - Re-ran empirical baseline against fresh general-purpose subagent. Score: 12/15 (80%, below 87% threshold). 3 FAILs: Case 6 + Case 14 (refactor / multi-task-work unanchored), Case 15 (case-design questionable — subagent routed to brainstorming, defensible). - Iteration log row added. Refactor + plan-context phrases now have TWO concretes per the two-concretes rule (see ~/.claude memory) — v0.2 description rewrite is now earned but deferred to a focused session. Plus — earlier in session but uncommitted: - CLAUDE.md ### Concurrent-Work Rules: graduates W-7 (reflog recovery) + F-13 (reset race) into a permanent project rule. Never git reset to a relative ref during concurrent work; always quote SHA after git reflog in the same command.

…/edit_code Per-request workspace= pinning had two gaps in the LSP-backed tools: - Defect #1 (path): references/symbol_at/call_graph resolved their relative `path` via the unpinned resolve_read_path -> "path not found" when pinned to a foreign workspace. Switched to resolve_read_path_for(workspace_override); removed the now-dead resolve_read_path wrapper + fixed its doc/test caller. - Defect #2 (LSP root): get_lsp_client resolved the LSP root via the unpinned require_project_root(), so every pinned LSP op (incl. edit_code writes) silently queried the ACTIVE project's LSP. Threaded workspace_override through get_lsp_client + retry_on_mux_disconnect + all 13 call sites. Verified live against a backend-kotlin worktree: a pinned `references` returns 26 cross-file refs from the pinned workspace's own LSP (was 0 / "path not found"). Tests: 4 regression tests (3 tool path-pin + 1 get_lsp_client root-pin via a recording LspProvider). Also carries this session's trackers (F-17/F-18/W-13, R-24). clippy --all-targets clean; full lib suite green. Bug: docs/issues/2026-06-11-lsp-tools-ignore-workspace-pin-path.md Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…sions, 1 move Apply the get_or_start trait-move template to client.rs (2b35f2a): re-scan auto-closed all 10 LspClient/* collisions. Backlog now 29 open, 13 closed. Body re-rendered (F-8: render still manual — 2nd hand-render this session). W-4 promote-when MET at 2 datapoints. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Ran the deferred live e2e against the rebuilt binary (post-c8746b70) on a throwaway rust workspace, isolated from the live kotlin muxes. All four liveness states pass: happy (held flock + healthy socket), fresh spawn (free flock), wedged (held flock + dead socket → actionable mux_socket_unreachable error + fuser hint), and recovery (holder cleared → round-0 respawn). The wedged case also live-confirmed defect #3's production fallback-refusal guard. Defects #1/#2/#3 are now fixed AND verified; status open → fixed. closed: date + archive move deferred to the master ship (Standard Ship Sequence step 4). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Design for bug #3 (prevention) and the cleanup half of #2/#3. Two components: persistence-gated refuse of temp-dir artifact writes into a file-backed catalog (in-memory-catalog tests unaffected, env-var escape hatch); and a batch dry-run prune over doctor-identified dead roots using a "parent-also-gone" derivation rule, reusing the existing guarded prune_dead_root primitive (no new deletion semantics). Ongoing GC lifecycle (missing_since / hide-from-find / auto-prune / status surfacing) explicitly deferred to a follow-up spec. Pruning the real global catalog is a separate, explicitly-approved step. Relates docs/issues/2026-07-17-tmp-probe-artifacts-pollute-global-catalog.md Relates docs/issues/2026-07-17-catalog-dead-rows-no-gc.md Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…d vs unrouted The tool-surface audit found 10 tools carrying 19.2% of the per-request payload for 38 calls in 30 days, and the data cannot say why. Zero calls is ambiguous evidence: either the tool is dead weight, or nothing routes to it. src/prompts/README.md rule 7 states the second reading explicitly — "if a tool has near-zero calls despite being useful, the prompt isn't surfacing it" — and trimming on the first reading would save bytes while foreclosing the fix. There is a correlation worth testing rather than assuming: no tool with zero lifetime calls is named anywhere in server_instructions. references is named and has 128 calls; call_graph serves the same domain, is arguably more useful for impact analysis, is named nowhere, and has 0 — across four projects' usage.db, 26,361 calls, including the most navigation-shaped workload available (researcher, whose #2 tool is symbols). So route them and watch. Two quickref lines, +93 chars; the static slice goes 1,654 -> 1,747 against its 1,900 cap, leaving 153. If the experiment concludes "dead", the lines come back out and the budget is repaid. Pre-registration, baseline, decision rule and the known weaknesses are filed as F-3 in docs/trackers/prompt-surface-compaction-session-log.md, with Status: open so the 14-day verify-open cadence surfaces it when it is due — an experiment nobody re-reads is not an experiment. The fixture was regenerated without the usual UPDATE_PROMPT_SNAPSHOTS run, because a concurrent session had the working tree red (mid-implementation of rendezvous, missing a CodeScoutServer field initializer). It was derived by replicating build.rs::extract_surface, first validated byte-identical against the committed pair on two independent surfaces (server_instructions 1,654 chars, onboarding_prompt 18,997), then confirmed by running the real suite in a detached worktree at HEAD: 66 prompts:: tests and 82 server::tests green, including the snapshot itself, source_md_under_cap, production_render_fits_the_client_channel and prompt_surfaces_reference_only_real_tools. No ONBOARDING_VERSION bump: server_instructions is injected fresh at every MCP session start and has no cached artifact of its own. It goes live for the next NEW conversation against a rebuilt binary, not for a /mcp reconnect inside this one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

A test-escape mechanism the existing five do not cover: the assertion is exactly right, but the fixture cannot reach the code path, so the assertion never runs against the case its name claims. Distinct from #2 (weak assertion) — here the assertion is precise and the data never reaches it. I-3 prescribes diff-scoped mutation testing, and that scoping is what lets this through: the mutant is killed by the test you just wrote, the run comes back clean, and the pre-existing tests asserting the same property are never observed. I-8 is the procedure that closes it — when a mutation kills your new test, re-run it against every test naming the same property, by filtering on the shared phrase in the test name rather than the single test. Measured this session: two tests in read_file.rs named ..._chunk_fits_the_threshold_it_is_measured_against assert exactly the property a live defect violated, and BOTH stay green with the defect present, because their 1200-short-line fixture can never reach the single-oversized-line valve. Whole-family mutation run: 2 passed / 1 failed. Records a sibling instance from codescout-97's BL-47 work in librarian/filter.rs, attributed to them, because it is the worse shape and I would not have found it: a DIFFERENTIAL test whose fixture table has no array column, so two-engine agreement could not reach the branch under test. A test's form is no evidence about its reach. Also names the limit of the claim: three instances across three subsystems, all found by running a mutation and none by reading, but nothing here measures how often the family run finds a blind sibling when the diff-scoped run is already green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…w a cost no caller can reach R1 (marius, 2026-09-01) settles the shell half of design surface #4 and unblocks #7. Strategy C's headline advantage was "pipefail = set -o pipefail in shell wrapper, no Rust state machine", and set -o pipefail is not POSIX sh while src/platform/unix.rs:71-86 execs Command::new("sh"). The review flagged the bash-ism at Confidence: medium and nobody had checked which shell. How it fails is what makes it worth ruling rather than discovering: on this host /bin/sh -> bash, so pipefail passes locally and on every local run; Debian and Ubuntu ship dash as /bin/sh, where it errors. Same shape as the lean-lane trap in CLAUDE.md -- green on the author's host, red only in a matrix cell they do not run. Half the ruling is already shipped. src/platform/windows.rs:182-193 has been exec'ing git_bash_path() with -c all along, for the reason its own doc comment gives: "the shell is the same POSIX shell on every platform ... under cmd.exe none of those binaries exist, so the guidance codescout ships was unrunnable on Windows." R1 extends that platform's existing principle to Unix for one call shape rather than opening a new dependency direction. One new obligation, with an exact precedent: shell_unavailable_hint() returns None unconditionally on Unix (src/platform/unix.rs:67-69) because "POSIX guarantees /bin/sh" -- a guarantee that does not extend to bash. The pipeline path needs a bash probe and a RecoverableError naming the requirement, mirroring the Windows twin that already answers Some(hint) for a missing Git Bash. One consequence recorded as accepted rather than solved: single-command run_command stays sh -c on Unix, so the tool execs two shells by call shape and a bashism works as stage 0 while failing bare. The ruling was NOT widened to move all Unix shell use to bash -- that makes bash a hard dependency for every call rather than the one shape needing it. Revisit-when is written into the entry. Not settled by R1: #4's pipefail semantics, and #7's C-vs-A/B choice, whose remaining real cost is per-stage timeout only. Withdraws per-stage cancellation as a cost of Strategy C, with a note in the tracker so the next reader does not re-derive the error. It is not a requirement: run_command exposes no per-stage control surface, the MCP call is request/response with no mid-flight channel, #2 makes pipeline mutually exclusive with run_in_background, and the existing intent is explicitly the opposite -- src/tools/run_command/inner.rs:436-439 kills "the entire pipeline ... not just the shell" on future-drop, by design. The SIGPIPE behaviours callers rely on survive under C; unix.rs:80 resets SIGPIPE to SIG_DFL in pre_exec precisely so they do. Adds design-backlog-session-log:F-4 (med), which records two defects from one turn: The analysis error. Everything published about Strategy C was quoted accurately from the review; what was added was the use case, and a use case is a claim about the world the source never made -- more persuasive, less checked. The tell was that no caller exercising it could be named, and naming one was not attempted. Found by the user asking why anyone would want it, which is the first correction this session from a reader's doubt rather than a scout -- the population CLAUDE.md notes is structurally unrecorded, because a reader who re-checks and finds nothing produces no artifact. This one found something. The worse one. The message announcing the finding ended "Logged as F-4" and no append_entry call had been made. A wrong analysis is checkable and got checked; a false completion claim is believed by default, and had the session ended there it would have left a citation pointing at an entry that does not exist. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Session-Id: 72abb1c0-0e5f-4cfa-8f50-20cb4af5474d

…ut not to exist R2 (2026-09-02, marius) -- design surface #2, mutual exclusivity, adopted as written. A pipeline call cannot co-exist with run_in_background, interactive, or an @ack_* handle as the command. Refusal is a RecoverableError naming the conflicting flag, raised before any stage runs, since a refusal arriving at stage 2 has already had side effects. All three excluded modes verified at path:line rather than trusted -- this tracker is 106 days old and F-3 was its substrate rotting: spawn_background_command (inner.rs:89-144), run_command_interactive (interactive.rs:25-238), the acknowledge_risk flow. Completeness was DERIVED, not assumed: the review enumerates nine dispatch modes, six of which are gates and transforms every call passes through (resolve_refs, dangerous-cmd gate, source-file block, shell-mode check, tee injection, foreground exec) and which a pipeline must also pass through rather than exclude. Exactly three are alternative execution modes a caller selects. There is no fourth candidate. Also records two measurement blocks that reclassify three other surfaces and dissolve a fourth. #4, #5 and #8 are NOT "decidable as written". Two reasons, both measured: Bare `set -o pipefail` returns 141 on `seq 1 100000 | grep 5 | head -3`, a fully successful run -- head closes the pipe and SIGPIPEs upstream, and pipefail inherits the rightmost non-zero. That is the shape IL-3 exists to redirect and therefore the shape pipeline= is built to serve: the feature would report failure on its own primary use case. The tracker's own Tests needed happy path is `seq 1 100 | grep ^5 | wc -l`, and wc consumes all input, so no early close, no SIGPIPE, and the suite passes whether or not the bug is present. Monotone under the defect it would need to catch. "Stop on first non-zero" and #5's "truncated stages array" describe an event that does not occur in a shell pipeline, where every stage starts at once. Under C, stopped_at is derived after the fact from PIPESTATUS rather than observed, and reporting every stage's code is strictly more information than the original envelope. Remedy available only because R1 gave us bash: read PIPESTATUS (Ubuntu's dash answers `Bad substitution`) and treat SIGPIPE on a non-final stage as success. "Per-stage timeout impossible (single shell process)" is FALSE, and it was C's last remaining cost. Measured: `echo hi | timeout 1 sleep 30 | cat` gives PIPESTATUS=0 124 0 -- a middle stage bounded independently and killed at 1s while both neighbours completed normally. Per-stage timeout is `timeout <n> <stage>` composed into the shell string, the same layer Concern 1 already uses for per-stage cwd. No Rust handle, no second buffering mechanism, no change to the single-shell model. Filed as design-backlog-session-log:F-7. The claim was true of the wrong subject: Concern 1 reasoned about Rust -- one child, one tokio::time::timeout, therefore Rust cannot bound a stage -- which is correct and does not imply the capability is unavailable, only that Rust is the wrong layer. "Impossible by construction" is a claim about one construction. Second time in two days a cost attributed to Strategy C evaporated, and the two failed differently, which is what makes it a pattern rather than a repeat. F-4's per-stage cancellation had no caller: unreachable AND unwanted, found by "name the caller and the surface". F-7's per-stage timeout is wanted and available, at a layer the reviewer was not looking at, found by running it. Neither heuristic catches the other; what catches both is refusing to carry a stated cost forward until it has been exercised or disproved. Not established, and recorded as not established: `timeout` is GNU coreutils and its presence on Windows Git Bash was NOT verified. The same package supplies grep/head/tail/sed, which src/platform/windows.rs:182-193 already depends on by design, so it is likely -- and design-backlog-session-log:F-5 is this session's record of what reasoning about another system costs when the measurement was available. The check is one command on a Windows host. If absent, per-stage timeout degrades to unavailable-on-Windows, not unavailable-everywhere. Both findings compose into one rule now stated in the tracker: a timed-out stage exits 124 and its downstream neighbours then see a clean EOF and exit 0, so the pipeline reads successful unless PIPESTATUS is consulted -- decide from PIPESTATUS, never from the pipeline's aggregate status. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Session-Id: 72abb1c0-0e5f-4cfa-8f50-20cb4af5474d

…er than only closing #7 R3 (2026-09-02, marius): design surface #7 ruled Strategy C -- shell-pipeline rewrite with per-stage tee taps, generalizing inject_tee from "tee the penultimate stage" to "tee every stage". A and B stay rejected on Concern 1's and Concern 2's original grounds. Recorded as a CONFIRMATION rather than a trade-off, and the entry says why. When #7 first went to a human it carried a real cost -- "per-stage timeout and per-stage cancellation become impossible by construction" -- and was framed as the one irreversible choice in the set. Both halves were falsified first, on separate days by separate methods: per-stage cancellation withdrawn because no caller can reach it (design-backlog-session-log:F-4, found by naming the caller and the surface), and per-stage timeout shown available in the shell rather than in Rust (design-backlog-session-log:F-7, found by running it -- PIPESTATUS=0 124 0 on a bounded middle stage). C was therefore ruled with no established cost remaining, and Concern 1's positive argument -- one mechanism rather than two -- carried it unopposed. Concern 1's "now harder" list is superseded by R3 and kept as the dated record that argued for it, with the measurement block marked as current. R3 RE-OPENS a surface rather than only closing them. #3 (timeout policy) asked "total or per-stage?" and leaned total partly BECAUSE per-stage was believed impossible. F-7 removed that constraint, so the old lean now rests on nothing but simplicity. Both are implementable. Recorded as task T7 rather than left to inherit a lean whose support is gone -- a falsified constraint does not only unblock the decision it blocked, it can un-justify a neighbouring decision that was quietly leaning on it. The recommendation on #3 is still total, on different grounds: no caller wanting per-stage timeout has been named, which is the same test that retired per-stage cancellation. Total is correct until one is, not because the alternative is impossible. Unblocks #4/#5/#8 (all encoded sequential stages; under C they follow from PIPESTATUS) and #9. Revisit-when unchanged from Concern 1: a streaming-output requirement breaks the single-shell-process assumption; backgrounded pipelines re-open #7, not #2. Confidence high on the choice, medium on one input -- `timeout` on Windows Git Bash is unverified. That bears on #3, not on R3: C's selection does not depend on it, since total timeout works on both platforms via the existing tokio::time::timeout. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Session-Id: 72abb1c0-0e5f-4cfa-8f50-20cb4af5474d

…he source-gate bug's own caveat R7 settles design surface #6 and prescribes the fix for docs/issues/2026-09-01-source-gate-refuses-the-whole-compound-command.md in one move, because they are the same defect from two directions: that bug is the shipped instance, #6 is the unbuilt one. The rule: a gate's predicate is per-command. Evaluate it per-command, refuse the whole call, and name the offender. For #6 concretely, every stage runs is_dangerous_command, check_source_file_access AND detect_il3_violation; any offending stage refuses the whole pipeline before any stage runs, matching R2's pre-execution refusal and for the same reason. Per-stage @ack_* stays deferred. Substrate check discharges a caveat the bug file left open about itself. It records "the gate source has not been read yet, and this file's claim is therefore about observed behaviour only." Read now: detect_il3_violation mod.rs:211 decomposes -- strip_heredoc_bodies, pipeline_segments is_dangerous_command inner.rs:298 whole string check_source_file_access inner.rs:315 whole string The behavioural inference was right about the what and wrong about the cost. The Fix section's "one splitter, not two" requirement is ALREADY SATISFIED: pipeline_segments (src/util/path_security.rs:1111-1123) splits on &&, ||, ; and newline, quote-safe via split_outside_quotes which tracks quote state across line breaks, and carries its own archived bug for the newline case. strip_heredoc_bodies is at :911. All three gates live in the same module as both helpers, so the repair is two more call sites for a private function already beside them -- no new parser, no plumbing, nothing to keep in sync. CLAUDE.md's Parsers Over a Namespace counts four independent shell gates in this process each separately mis-parsing a heredoc; reusing this one is how that count stops at four. Also narrows the bug's own Root cause. It says "both gates evaluate a per-command property over a per-string scope". IL-3 does decompose and does name its offending segment; what it shares with the source gate is only the all-or-nothing REFUSAL, which the Fix section argues is correct and should stay. So the live defect is narrower than stated: two gates that do not decompose, one of which also does not name. Bug file updated in place with the reading, the narrowing, and the running firing count -- six across two sessions, two of them on this session's own commands. And R6 makes the pipeline case free: stages: [str] arrives already decomposed, so no parser runs at all for a pipeline call and per-stage gating is a for loop over a list that exists. A second, unplanned argument for the XOR schema -- it does not merely keep the gates sighted, it removes the parse they would otherwise need. Out of scope, adopting the bug file's own reasoning: do not run the permitted clauses anyway. Partial execution of a refused command is a worse contract than refusing all of it, because the caller cannot tell which side effects happened. Task list updated: T4, T7 and T8 closed. Seven of the ten design surfaces are now ruled (#1 R6, #2 R2, #3 R5, #4/#5/#8 R4, #6 R7, #7 R3), plus R1 on the shell. Remaining: #9, which is Rust rather than judgement. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Session-Id: 72abb1c0-0e5f-4cfa-8f50-20cb4af5474d

My own test, shipped hours ago, and the same defect class I spent the last hour fixing in someone else's fixture. a_nested_independent_checkout_is_walked_through_not_reported compared relative paths against forward-slash literals without normalising separators. Its sibling four lines away DID normalise. On Unix both pass — '\' never appears in a tempdir path — so the omission was invisible locally and on every ubuntu and macos lane: windows-latest: [".worktrees\\wt-a", "checkout\\inner-wt", "deep\\a\\b\\c\\wt-b"] compared against "checkout/inner-wt" IC-9 again: an assertion whose haystack embeds environment-controlled text — here the platform separator — satisfied by coincidence. The remedy is not remembering the .replace; it is leaving one place where it can be written. rel_slash() is now that place and both callers use it. WHAT THIS COST, and it is a method error not a typo: I had been treating "four Windows lanes failing" as one problem. It was three. 1. LockFileEx access mode 19 tests fixed 6d89a69 2. JSON escape in a fixture 2 tests fixed 52cb093 3. this separator comparison 1 test this commit I only ever opened the `default` lane, where #3 was buried under the other 21. The no-features and local-embed lanes each had exactly ONE failure — this test — and had said so for two runs. That is the same error as the 2-of-21 sample that produced the retracted diagnosis earlier tonight: examine a subset, generalise, be wrong about the rest. Twice in one investigation. Windows-gnu (wine 11.16) is GREEN as of run 33577436407, which verifies #1 and #2. 5 config_propagation tests green locally. Committed by pathspec: another session's 7 bug files, the cluster ledger and a session log are staged in the shared index. Session-Id: 0771abbc-d120-45e6-81a5-292ab6611969

mareurs force-pushed the master branch from 4e6b6b2 to c87068d Compare March 29, 2026 13:25

mareurs merged commit dd64bbf into mareurs:master Mar 29, 2026

Navigation Menu

struct literal construction fix - #2

struct literal construction fix#2
mareurs merged 1 commit into
mareurs:masterfrom
Leonte-Tudor:master

Leonte-Tudor commented Mar 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Leonte-Tudor commented Mar 29, 2026

What

Why

Testing

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants