Yichus

Workbench

Yichus Explorer Playground

Edit Bosatsu in the browser and query its compiled dependency graph
Loading sample...
Current structural-analysis step

Loading Explorer Lesson and Evidence Route

The guided workbench will appear after the first sample finishes loading.

Technical purpose: input connectivity

Explorer helps you check whether an output is actually connected to real inputs or only looks like it is.

The tools can identify ignored inputs and literal-derived results. Those findings do not establish who wrote the code or whether an intentional constant is a defect.

You edit Bosatsu. Bosatsu checks recursion and pattern coverage; Yichus supplies explicit IO operations through its runtime. Those checks do not establish the behavior of arbitrary external implementations. Yichus is this site's static-analysis toolkit (overview). It compiles Bosatsu in your browser to Matchless IR, the compiled typed form the checkers read, and it answers queries over the compiled program's dependency graph.

The queries report connectivity facts, not verdicts: an output with literal-only ancestry can be a legitimate constant (load the Pure computation sample to see that case), and a connected output can still be wrong. The judgment stays with you. Same vocabulary as input connectivity and the fact tools.

Takeaway: use this workbench to inspect typed structure, then make the correctness judgment with domain context. The Explorer guide recipe gives the matching CLI route.

Lesson mode

Do It lets you perform each action in the workbench. Watch UI Agent presents the same lesson as scripted browser actions. Watch Terminal Agent presents scripted CLI and MCP calls (MCP is the tool protocol the browser and Node engines speak); it does not start an autonomous agent. All three modes use the current sample and lesson definitions in explorer-lessons.js.

When a lesson says Make the judgment, pause and make a mental prediction before reading the evidence. The page has no answer-recording control; the prediction is for comparison with the explanation that follows.

Lesson map
Recovery and free play

Replay lesson reloads the lesson sample at its worked binding and opens the guide. Back to worked example reloads the same sample and focus without opening the guide. Free play keeps the lesson context while allowing edits and sample changes; its button returns to guided flow. Takeaway: any experimental edit has a one-click route back to the committed sample in the demo source directory.

Sample Source and Compiled Scope

Takeaway: the editor contains the exact Bosatsu package sent to the in-browser compiler. Each preset comes from the committed Explorer samples.

Work with your agent

WebMCP connects your agent to this page. Connection and tool instructions. Use yichus_page_feedback to read the current editor and displayed feedback. The agent can use yichus_page_edit to update the current source and yichus_page_action to run a listed button, then read feedback for completion and diagnostics. Autocomplete suggestions remain available for you to accept with Tab.

Analysis and navigation run in a background worker. Editing, resetting, or switching samples clears the previous results and cancels pending work. After Analyze, wait for “Analysis complete” before reading the new results. A failed analysis leaves no program available for navigation.

Loading syntax highlighting… Tab inserts two spaces. Cmd/Ctrl+Enter analyzes. Agent autocomplete via WebMCP: pause typing or press Ctrl+Space, then Tab to accept.

Compiler Diagnostics

Takeaway: fix the reported file, line, and column before interpreting any Explorer result. The browser compiler route is implemented by ExplorerCompileService.

    Matchless Explorer Results

    The rendered explorer uses the same analysis pipeline as the yichus CLI: both read Matchless, the compiler's post-typecheck intermediate form, so a browser query and the matching CLI query report the same facts. Takeaway: start with the plain-language evidence, then open the raw payload when you need exact nodes and edges. The compile service owns the browser analysis entry point.

    Package -
    Bindings -
    Mode In-browser

    Selected Binding Evidence Prompt

    Analyze a sample and the guided workbench will tell you what to look for first.

    Focus binding -
    waiting-for-analysis Need analysis

    Load a sample, analyze it, and the workbench will surface one plain-language explanation before the raw payload.

    The next useful move will appear here once the focused binding is known.

    Takeaway: the sentence is a reading aid over the structured result, while the raw payload remains the source of exact field values. The Explorer recipe explains how to reproduce the trace from the CLI.

    Explorer Query Operations and Typed Paths

    Drive the same in-browser explorer state through `overview`, `explore`, `connections`, `search`, `path`, `trace`, and `traceFlow` without leaving the page.

    Takeaway: each operation asks one graph question and retains the raw payload for inspection. The navigator source defines these operations.

    Recovery. If an operation fails, read the navigator status and open the raw payload for its exact message. Analyze the current sample again to rebuild the graph; if analysis fails, fix the Compiler Diagnostics above first. If a custom query stops compiling, reload the page to restore the minimal query, then keep its entry point and target defaults while changing one branch at a time.

    Reference: paths, edge kinds, filters

    Node paths are slash-separated: Package/binding reaches a binding (Demo/Counter/increment); append /io:N for one of the binding's IO sites, using the site number shown in explorer output (Demo/Counter/increment/io:1).

    Edge kinds (the kind filter in connections): dependency = one binding's value uses another's; causal = ordering induced by effect sequencing; io_chain = successive IO operations in one flat_map chain. Each upstream edge also carries an influence tag: return-data (carries data into the return value), guard-only (gates control flow, e.g. a match discriminant, but contributes no data), or detached (declared but unused). followEdges: return-data-only in trace/traceFlow keeps only the first kind. Trace output can also include a read-origin edge: it links an IO read site to a binding whose value originates at that read.

    Search filters combine key:value terms, e.g. kind:io_site primitive:write (also primitive:read). depth/maxDepth count graph hops from the start node; limit caps returned landmarks.

    The same queries run outside the browser: yichus explore --trace-flow <path> <files> et al. The full recipe is in docs/explorer-guide-recipe.md.

    `overview(path, overlay, limit)`

    Scan a package or binding neighborhood and surface landmarks: effect hotspots, bindings carrying signal tags (for example literal-root), or boundary crossings.

    `explore(path, depth)`

    Zoom from the system root down to one package, binding, IO site, expression, or source node.

    `connections(path, direction, kind)`

    Inspect incoming and outgoing edges such as `dependency`, `causal`, or `io_chain` around one node.

    `search(query, scope)`

    Query IR-derived structure with filters like `kind:io_site primitive:write` instead of reading source text.

    `path(from, to, maxDepth)`

    Route between two bindings to see how one point in the graph connects to another through dependency edges.

    `trace(binding, maxDepth, followEdges)`

    Walk upstream from one binding and get a compact summary of the nodes that feed it.

    `traceFlow(binding, maxDepth, followEdges)`

    Inspect explicit upstream edges so you can see which dependencies carry return data and which only guard control flow.

    `query(source, entryPoint, target)`

    Compile a Bosatsu `ProgramData -> ClassifyResult` query against the in-browser explorer workspace and inspect the classification result.

    The textarea starts with a minimal compiling query package. Leave its source unchanged, keep the entry point as classify and the target as playground, then click Run query. To narrate one result: select Pure computation and Analyze first. The query sees that the workspace has no IO binding, returns the pure-computation label, and gives pure computation as its reason. Edit one branch at a time to create a custom classifier. The available fields and helper signatures are defined in Yichus/Explorer/Query, and the committed query corpus provides larger examples.

    Raw explorer payload

    Where this fits

    What this is about: Catch code that ignores its inputs