Yichus

Guide

Static binding traces and saved source

Explorer and the debugger daemon inspect typed program structure. A generated daemon trace now uses the same canonical binding provenance as the trace dossier, across every loaded input package. It does not execute the program. Literals have static origin; other bindings are marked not evaluated.

Code & run Run the pipeline’s validator

Use the Explorer guide for supported Matchless queries. Use the daemon quick start when you already have a generated or saved trace.

Navigate the complete loaded program

The pipeline files below form one program. Supply all of them together. The Explorer daemon reuses its retained compile bundle when generating a trace; it does not recompile the first file or silently read a newer disk revision.

Five source packages in the Explorer target

  • types.bosatsu: Record, ValidationResult
  • ingest.bosatsu: IO reads from database
  • transform.bosatsu: Pure data transforms
  • validate.bosatsu: State-dependent and constant validation paths
  • pipeline.bosatsu: Orchestrator

Static questions to run in Explorer

  • IO ingest and pipeline have real IO operations
  • pure transform is fully pure, with no IO
  • signal inspect the constant hardcoded_pass path

The labels name the intended static question. Their colors repeat the text and carry no additional status.

Inspect the compiled workspace

Run this command from the repository root. It returns structural binding records; inspect the actual output for the current fixture.

yichus explore demos/pipeline/*.bosatsu --search kind:binding --limit 20

Keep a binding-navigation session

yichus daemon generate demos/pipeline/*.bosatsu -o pipeline.trace.json
# Run the server in another terminal:
yichus daemon start pipeline.trace.json
# Then inspect the nodes and select a focus:
yichus daemon list --values
yichus daemon focus n0
yichus daemon explain
yichus daemon snippet n0 --context 3
yichus daemon stop

These are commands to run, not a recorded transcript. Choose a node from the actual list. Node IDs belong to that generated trace; the default focus is the first binding in package/name order, not a runtime result. path TARGET follows dependencies from your selected focus; an empty path means the target is outside that dependency cone. Each input needs a package header.

What the trace establishes

Binding dependencies

Explain, dependencies, usages, focus, and path traverse canonical static references between input bindings. This is not an execution order or a local expression history. Use Explorer trace-flow for finer structural questions. Library implementations are outside this input binding graph.

Explicit value origins

static-literal means a compiler-known constant; not-evaluated means no execution value is available. The value command returns an error for an unevaluated binding. Imported recorded values carry their producer's claim; older values without an origin remain unspecified.

Saved source snapshots

Snippet reads the source used to build the trace, with one-based line and column positions. Later file edits do not change it. Imported traces without snapshots report that source is unavailable. Reload the workspace or regenerate the trace to inspect a new revision.

Old trace files remain readable with their original nodes. Regenerate them to obtain canonical binding structure and saved source. The daemon does not evaluate expressions in a node's scope; daemon eval reports unsupported. For a single portable answer instead of a session, use the trace dossier.

The binding-navigation evaluation compares independent artifact and source readers on the pipeline, and records its narrow task scope, raw answers, and byte-based cost method.

For actual runtime behavior, run a generated application and use its dedicated runtime diagnostics; for static provenance, continue with the Explorer operations and query examples.

Where this fits

What this is about: Fact Tooling

Do it

Measure it