CodeSampleX

Explain what the network knows about a package (optionally one symbol) in a given environment, from locally cached compatibility shards. Observation evidence (USAGE_OBSERVATION) and verification evidence (SAMPLE_VERIFICATION) are reported separately and never summed.

Local CodeSampleX stats: mode, cached samples, pending uploads, then two separate layers — retrievalQuality (Layer 1: hits, misses, hit rate, failure matches, detours offered) and outcomeValue (Layer 2: adoptions, post-hit build reports and pass rate, reported failures avoided). estimatedReasoningAvoided is an estimate and is labeled estimated; a rate with nothing measured behind it is absent, not 0.

Fetch a cached public sample by id: manifest plus file contents (each file capped at 64KB, binaries skipped). Samples are MIT-0 community artifacts; adapt them to the project instead of pasting blindly.

List recent local search hits with their grades and adoption outcomes. These rows are local dashboard data: the query, the packages and the environment they hold never leave the machine. In community mode a hit separately queues an anonymous count — grade, how many results were shown, and the public sample id — under a daily-rotating id.

Start a clean-room public sample proposal: builds a sanitized spec (public packages, symbols, goal — never project source or paths), and returns generation instructions plus a workspace directory already containing spec.json, PROMPT.md and a csx.json manifest scaffold whose contract you fill in. If the workspace cannot be created the call fails with isError and structuredContent.error — never write sample files or invent a csx.json in that case. This tool CANNOT publish: publishing requires the user's explicit approval via the csx CLI.

Report a CONCRETE, reproducible disagreement between what CodeSampleX returned and what you actually observed locally — for example the network served a passing conclusion for a package/version/symbol and the same coordinate failed on your machine, or a returned symbol signature is not what the public package exports. This is a VERIFICATION REQUEST, not a bug report and not a finding: it is queued for an independent re-run and only a signed receipt can confirm it. Use it ONLY when you have a measured local outcome; "this looks wrong to me" is refused, and so is a NO_SAFE_MATCH with no reproducible public failure attached. Put your explanation in llmHypothesis — it is stored separately and never decides the verdict. Never describe a submitted report as a confirmed or fixed bug.

Report a REPRODUCIBLE defect in CodeSampleX the product, as distinct from its data: an answer that displaced or hid the failure you were actually looking at, a recommendation from an ecosystem the question never mentioned, a tool contract that made you behave wrongly, a response contract that breaks inconsistently on the same input, a broken internal reference, or runtime behaviour like a retry loop. Use `report_anomaly` instead when the disagreement is about a PACKAGE rather than about this product. This is opt-in: there is no expectation that you call it after a failure, and a week with no reports is normal. It creates no ticket and confirms nothing — a person triages it. Never tell the user a bug has been filed, accepted or fixed. Taste, wording preferences and "this seems off" are not reports.

Report whether a sample from search_known_solution was actually applied, and whether the build passed afterwards. Records ADOPTION_EVIDENCE — the network optimizes post-hit success rate, so honest reports matter.

Run a shell command wrapped in the csx evidence loop (like `csx run`): the project is scanned, the command runs with its exit code passed through, and anonymous USAGE_OBSERVATION evidence is recorded for public packages only. On failure, the local exit code and bounded stdout/stderr tails are returned first as primary evidence, and the sanitized error is built from whichever stream carried the diagnosis; only sanitized error fingerprints may leave the machine. The network lookup is a separate secondary recommendation: LOW/reference results are labeled REFERENCE_CANDIDATE rather than automatic-fix evidence, and a candidate with no nameable link to the failure — no shared package, symbol, tool, structured error or subject, only the environment both happen to run in — is reported as NO_RELEVANT_MATCH with the sample named but not rendered as an answer.

Search the CodeSampleX network cache for a community-verified solution before solving from scratch. Results are graded for YOUR environment (EXACT/COMPATIBLE/ADAPTATION_REQUIRED/REFERENCE_ONLY); NO_SAFE_MATCH means solve it fresh. A hit lists what that sample's contract PROVED — the assertions it ran offline in a pinned container and passed, which is where the per-overload, per-option behaviour is: which argument shapes are accepted, what is raised instead, which setting decides. Evidence keeps observation counts and verification counts separate — compile observations are never execution proof, and the counts pool every call shape, so a specific call is answered by the contract lines rather than by the numbers. A result reaches this answer only when a concrete link to your case can be named — a package or symbol you gave, the tool you ran, the same structured error, a question that names it, or a goal that describes what you asked for — and the Relevance: line says which one it was. Sharing a language, a runtime version or an architecture is not one of those links: those say where a sample can run, never what it is about. When nothing qualifies the answer is NO_SAFE_MATCH, not the nearest neighbour.