The whole Renyi language on one page (docs/cheatsheet.md): syntax, types, effects and the library. Read it before writing Renyi.

Find standard library declarations by name or by a few words (case-insensitive; every word must occur in the module name, the signature or the purpose). Each match is given with its signature, effects and purpose. Use it before calling a library function, so that names and arguments are not invented.

The project map of the served directory: one record per module and per definition with signature, purpose, effects, failures, edges, metrics and content hash. module narrows it to one module; json gives the JSON shape of renyi index --json instead of the one-line-per-definition text.

One definition's record and its source text, by qualified name: module.name, module.Type.method, module.Ability for Target, module.test:name; a bare name works when it is unique in the project.

The transitive effect and failure graph under a definition: every project definition it reaches, each with its declared and reachable effects and failure types, and the library primitives at the leaves with their declarations.

Parse, type-check and effect-check a program and report its diagnostics as renyi check --json prints them (an empty list is clean). Give path, a file under the served directory, or source, the text of a module (with path naming the file it would be, so that its imports resolve).

The canonical layout of Renyi source text, what renyi format writes; the parse diagnostics when it does not parse.

Check a program and run its main on the VM with the arguments, under the grant it declares narrowed by the options (the same as renyi run). Answers with what the program printed and how it ended. Its effects really happen unless replay names a recording.

Run every example: line and test block of a program, replays tests answered from their recordings (the same as renyi test), and answer with the report.

What changed in the served project since a base: a saved map (a file renyi index --json or project_map with json wrote) or a git revision such as HEAD or v1.2.0. One entry per changed definition with the changes (added, removed, renamed, signature, visibility, effects, failures, body), the definitions each change reaches, and the version bump the changes force (the same as renyi index --diff).

The served project as chunks for retrieval by embedding, as renyi index --chunks writes them: JSON Lines, a first line with the project, the revision, the toolchain and the counts, then one object per module and per definition with id (the SHA-256 of its text, which changes exactly when the text does), text (a header from the record, then the canonical source) and metadata (the map's id and text hash, module, package, kind, effects, edges, location). The host embeds; the toolchain only writes. module narrows it to one module; language gives the language's own documents instead (the cheat sheet's and the reference's sections, the library's modules and public declarations, the same shape), for a host that embeds the language beside the project.