See how a program fits together.

01 / Organization

Replace three copies of a stock rule with one definition.

Watch the refactor step by step → Follow scripted actions in the real editor, then take control.

Cart, checkout, and support need the same stock-allocation rule. These abstraction maps show their compiled definitions and dependencies, as reported by api_abstraction_map.

This is a deliberately small teaching example of a maintenance problem. More layers alone do not mean better organization. Here the useful change is visible reuse: the same rule has one definition. The bounded execution comparison checks both versions against the same stock rule; it is not a proof of equivalence.

02 / Correctness

Fix a handler that reads the wrong user’s notes.

The Notes API’s owner-scoped table requires the caller’s user ID as its key. These figures show every operation reported by api_access_check. The recorded runs use Alice as the caller and the same seeded rows.

The dependency map alone does not expose this wrong-key bug. The access lens does. A green access result covers owner keys; the full Notes API also has read-then-write behavior whose concurrency checks depend on topology. See the full verification example.

03 / Explore a larger program

Find shared building blocks without opening every function.

A full dependency map becomes hard to scan as a service grows. The browser also groups definitions by their declared package and checked type. Names appear together in each group; select one to follow its direct users or dependencies. The full layered map remains available.

Try this with ProjectHub, the project's sync-service demo. Open the source below and choose Rebuild diagram. Search for respond to inspect the functions that use the response helper, or clear the search to compare groups of checked types. Follow Used by → Selected definition → Uses to see what a change might touch. Compiling starts only when you request it.

A shared checked type does not prove shared behavior or a permission policy. These edges connect user definitions; platform primitives and execution order belong to other lenses. Use an access check for owner keys, and read the lens guide for other questions.

Connect your agent to read or edit this example, rebuild its diagram, and inspect the same visible result with yichus_example_feedback and yichus_page_feedback.

Choose the question you want to answer.

Explore the Forum’s whole-program map → Expand nested groups, inspect their references, and compare runnable response-builder refactorings. The grouping is authored; membership identities and references are checked against the compiled source.

A dependency map, a recurring-pattern view, and an access check show different facts. Use the view that can answer your question.

What is built from what?

The dependency browser shows which definitions use a block and what it uses. The stack orders building blocks by their dependencies.

Which concepts and patterns recur?

Vocabulary shows declared types and the roles of their definitions. Conventions compares recurring function shapes and the blocks they use.

Which effects are connected?

The flow lens shows effect relationships and declared backing systems, with the properties derived from their configurations.

Does this operation follow its access rule?

The access lens checks supported database-access properties, such as the owner key in the Notes example. A dependency arrow alone cannot answer this.

What did the change alter?

The organization diff compares definitions, dependencies, families, and declarations between source versions.

The browser offers dependency navigation and the worked access examples. The lens reference lists which additional views are available through the CLI and MCP. The reader judges whether the resulting organization makes sense for the program.

How the views stay tied to the source.

Structural facts are generated from the compiled program or checked against it. A view’s scope matters: a dependency, a recorded execution, and an access verdict each support different conclusions.

Generated facts

Yichus analyzes the type-checked program to extract definitions, dependencies, types, and effect relationships. The browser’s package and type groups use those facts. Rebuilding after an edit analyzes the current source; a failed compilation clears the old result.

Checked author input

An author can declare families of definitions and a reading order. The organization tools compare those declarations with the program and report disagreements. An optional JSON view can choose order, emphasis, declared groups, and captions; its references and required facts are checked before it is added to the text lens. Free-form captions remain authored commentary. Try a checked view file →

Recorded examples

The stock and Notes figures use saved analysis results. The site build regenerates them from their linked source files and fails if the records differ. Their recorded executions show what happened on the stated inputs; they do not prove behavior for every input.

Generate diagrams for your own program.

1. Compile the source and choose the lens for your question.
2. Identify the definition, relationship, or failed property you want to change.
3. Edit the program, then repeat the same call and relevant behavior checks.

The stock and Notes examples include their complete source, raw result, recorded execution, and a request with the source already filled in. Ask a connected agent to run that request in the WebMCP workbench.

Those recorded results are reproduced from the linked files and checked for drift during the site build. The figures use those results directly. To reproduce them from a checkout:

nix-shell --run 'sbt -J-Xmx4G --no-server "mcpjs/fastLinkJS"'
nix-shell --run 'node scripts/diagram-examples.mjs --check'

Connect an agent · Read the other organization lenses