MinimalFilter silently drops valid code lines containing // or /* anywhere in the line (contains vs starts_with)

Summary

MinimalFilter uses trimmed.contains(start) to detect block-comment opening markers (/*, //). Because it matches anywhere in the line rather than at the start, any code line that happens to contain // or /* as a substring is treated as a comment and silently dropped. This includes string literals with URLs, regex patterns, and inline end-of-line comments — lines the agent needs to read the file correctly.

A second related bug: when a line contains both the opening and closing block-comment markers on the same line (e.g. /* inline */), the state machine sets in_block_comment = true then immediately resets it to false, but continue still executes and the line is dropped.

These two bugs together cause the agent to silently receive an incomplete view of source files, which manifests as the "fabricated field names" and "file content that doesn't match the real file" symptoms reported in #2360 and #2176.

Environment

rtk 0.42.3, Linux (Claude Code PreToolUse hook).

Reproduction

Create a Rust file with URL-containing lines:

$ cat > /tmp/example.rs <<'RUST'
const API: &str = "http://example.com/v1";  // endpoint
let re = regex::Regex::new(r"https?://\w+").unwrap();
/* single-line block comment */
fn foo() {}
RUST

Run through the hook (or inspect the filter path directly):

$ rtk read /tmp/example.rs --level minimal
fn foo() {}

Lines 1, 2, and 3 are all dropped:

• Line 1: contains :// which matches //
• Line 2: contains :// in the regex literal
• Line 3: same-line /* ... */ still triggers continue

Expected output: all four lines, since none are actually inside a block comment.

Cause

Location: src/core/filter.rs, MinimalFilter block-comment detection block

// Bug 1: contains instead of starts_with
if !in_docstring
    && trimmed.contains(start)   // ← should be starts_with(start)
    && !trimmed.starts_with(...)
{
    in_block_comment = true;
}

// Bug 2: same-line open+close still drops the line
if in_block_comment {
    if trimmed.contains(end) {
        in_block_comment = false;  // reset...
    }
    continue;                      // ...but continue runs unconditionally
}

trimmed.contains(start) matches /* or // anywhere in the line. Real block-comment openers only appear at the start of a trimmed line (or after ) / { in languages that allow trailing block comments, which are handled separately). Changing to starts_with constrains the match to genuine comment openers.

The same-line fix requires checking whether the closing marker also appears on the same line before setting in_block_comment = true and before the unconditional continue.

Impact

An agent using rtk hook claude reads a source file via the hook. The file is returned with field definitions, constant declarations, and function signatures missing — because those lines happened to contain :// or /* as part of string literals or regex patterns. The agent has no way to detect the omission; it treats the filtered output as the complete file and makes edits or decisions based on the truncated content.

This explains the "content fabrication" symptoms in #2360 and #2176: the model isn't hallucinating, it's reasoning from an incomplete file view produced by this filter bug.

Expected

Lines are only dropped when // or /* appear at the start of the trimmed line (i.e. the line is actually a comment). String literals, URL values, and regex patterns that happen to contain these character sequences are passed through unchanged.

Start in src/core/filter.rs at the MinimalFilter block-comment detection block, then run the provided rtk read /tmp/example.rs --level minimal reproduction. Done means lines containing URLs, regex patterns, or same-line /* ... */ comments are preserved, while genuine comment lines are still filtered.