pub fn sidecar_search(
log: &ReductionLog,
minted_view: &[ChatMessage],
recorded: Option<&[ChatMessage]>,
query: &str,
) -> Result<SidecarSearchResult>Expand description
Resolve the sidecar_search(query) agent intrinsic (SPEC.md TR-1
dev/04): substring/regex search over content CURRENTLY reduced out of the
view — every Reduction in log, restricted to its hidden_span so
a still-visible portion (e.g. ToolOutputTruncated’s kept prefix) is
never matched. “The same string visible in the live view is not
double-reported” is upheld entirely from the log’s own records — this
still never inspects the live view: for most kinds the hidden span is a
pure function of the reduction itself, and for
ReductionKind::DuplicateOutput (TR-2, whose content is byte-identical
to a canonical instance that is usually still fully visible) visibility
is decided by whether any OTHER log record reduces the canonical’s
address — no per-message record there and no enclosing TurnsCleared
range means the canonical is fully visible, so the duplicate’s content is
not hidden and search skips it (hidden_span returns None). See the
module doc comment for the minted_view/recorded two-source contract.
An empty (or all-whitespace) query is an error, not a match-everything
wildcard: the empty pattern compiles as a regex that matches at every
position, which is never what a caller meant and used to make the result
size explode.
query is tried as a case-insensitive regex first; a query that fails to
compile as one (e.g. literal text with an unbalanced [/(, common in
file paths or code) falls back to a plain case-insensitive substring
search, so both “search for this exact snippet” and “search with a
pattern” work without the caller ever needing to escape anything.