{"id":45871211,"url":"https://github.com/jasisz/aver","last_synced_at":"2026-04-25T21:06:38.320Z","repository":{"id":340444719,"uuid":"1166048660","full_name":"jasisz/aver","owner":"jasisz","description":"Aver is a programming language for auditable AI-written code: verify in source, deploy with Rust, prove with Lean/Dafny ","archived":false,"fork":false,"pushed_at":"2026-04-22T10:19:51.000Z","size":8721,"stargazers_count":28,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2026-04-22T11:32:12.667Z","etag":null,"topics":["ai-code","dafny","effect-system","formal-verification","lean4","programming-language","rust","spec-tests","transpiler"],"latest_commit_sha":null,"homepage":"https://averlang.dev","language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jasisz.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":"AGENTS.md","dco":null,"cla":null}},"created_at":"2026-02-24T20:31:07.000Z","updated_at":"2026-04-22T10:19:55.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/jasisz/aver","commit_stats":null,"previous_names":["jasisz/aver"],"tags_count":28,"template":false,"template_full_name":null,"purl":"pkg:github/jasisz/aver","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jasisz%2Faver","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jasisz%2Faver/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jasisz%2Faver/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jasisz%2Faver/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jasisz","download_url":"https://codeload.github.com/jasisz/aver/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jasisz%2Faver/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32274987,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-25T18:29:39.964Z","status":"ssl_error","status_checked_at":"2026-04-25T18:29:32.149Z","response_time":59,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["ai-code","dafny","effect-system","formal-verification","lean4","programming-language","rust","spec-tests","transpiler"],"created_at":"2026-02-27T10:15:42.494Z","updated_at":"2026-04-25T21:06:38.307Z","avatar_url":"https://github.com/jasisz.png","language":"Rust","readme":"\u003cp align=\"center\"\u003e\n  \u003cpicture\u003e\n    \u003csource media=\"(prefers-color-scheme: dark)\" srcset=\"docs/logo-dark.svg\"\u003e\n    \u003csource media=\"(prefers-color-scheme: light)\" srcset=\"docs/logo-light.svg\"\u003e\n    \u003cimg alt=\"aver\" src=\"docs/logo-dark.svg\" width=\"360\"\u003e\n  \u003c/picture\u003e\n\u003c/p\u003e\n\n# Aver\n\nAver is a statically typed language designed for AI to write in and humans to review, with a bytecode VM for runtime execution, a Rust backend for deployment, a WASM backend for browser and embedded targets, Lean proof export for pure logic and classified effectful laws, and Dafny verification for automated law checking via Z3.\n\nIt is built around one idea: the risky part of AI-written code is usually not syntax, it is missing intent. Aver makes that intent explicit and machine-readable:\n\n- effects are part of the function signature\n- decisions live next to the code they explain\n- pure behavior lives in colocated `verify` blocks\n- selected effectful behavior can be verified with explicit stubs and trace assertions\n- effectful runs can be recorded and replayed deterministically\n- `aver why` scores every function's justification coverage: description, verify, decisions\n- `aver audit` runs all three axes — static checks, verify execution, format compliance — as a single CI gate\n- `aver context` exports the contract-level view of a module graph for humans or LLMs\n- `aver compile` turns an Aver module graph into a Rust/Cargo project or a standalone WASM module\n- `aver proof` exports the pure subset of an Aver module graph to a Lean 4 proof project (default) or Dafny verification file (`--backend dafny`)\n\nThis is not a language optimized for humans to type by hand all day. It is optimized for AI to generate code that humans can inspect, constrain, test, and ship.\n\nWebsite: [averlang.dev](https://averlang.dev)  \nBrowser playground: [averlang.dev/playground](https://averlang.dev/playground/)\n\nRead the [Aver Manifesto](https://jasisz.github.io/aver-language/) for the longer argument, [Common Pushback](docs/pushback.md) for questions and objections, or [intent-trace](https://github.com/jasisz/intent-trace) for an empirical benchmark comparing Aver's legibility against Python variants across 108 AI-reviewed code changes.\n\n---\n\n## Quickstart\n\n### Install from crates.io\n\n```bash\ncargo install aver-lang\n```\n\nThen try it with a tiny file:\n\n```bash\ncat \u003e hello.av \u003c\u003c'EOF'\nmodule Hello\n    intent =\n        \"Tiny intro module.\"\n    exposes [greet]\n\nfn greet(name: String) -\u003e String\n    ? \"Greets a user.\"\n    \"Hello, {name}\"\n\nfn runCli() -\u003e Unit\n    ? \"Starts the CLI.\"\n      \"Prints one rendered response.\"\n    ! [Args.get, Console.print]\n    Console.print(\"todo\")\n\nverify greet\n    greet(\"Aver\") =\u003e \"Hello, Aver\"\n\nfn main() -\u003e Unit\n    ! [Console.print]\n    Console.print(greet(\"Aver\"))\nEOF\n\naver run      hello.av\naver run      hello.av --self-host\naver verify   hello.av\naver verify   hello.av --json\naver check    hello.av\naver check    hello.av --json\naver audit    hello.av\naver audit    hello.av --json\naver why      hello.av\naver context  hello.av\naver compile  hello.av -o out/\n(cd out \u0026\u0026 cargo run)\n```\n\n`aver run`, `verify`, `check`, and `replay` use the bytecode VM by default. The old\n`--vm` flag is gone.\n\n`Unit` is Aver's \"no meaningful value\" type, roughly like `void` and rendered as `()` in diagnostics. `main` often returns `Unit`, but it can also return `Result\u003cUnit, String\u003e`; `aver run` treats `Result.Err(...)` from `main` as a process failure.\n\n### Build from source\n\n```bash\ngit clone https://github.com/jasisz/aver\ncd aver\ncargo install --path . --force\n\naver run      examples/core/calculator.av\naver run      examples/core/calculator.av --self-host\naver verify   examples/core/calculator.av\naver check    examples/core/calculator.av\naver audit    examples/core/calculator.av\naver why      examples/core/calculator.av\naver context  examples/core/calculator.av\naver compile  examples/core/calculator.av -o out/\n(cd out \u0026\u0026 cargo run)\naver proof    examples/formal/law_auto.av -o proof/\n(cd proof \u0026\u0026 lake build)\naver run      examples/services/console_demo.av --record recordings/\naver run      examples/core/calculator.av -e 'safeDivide(10, 2)' --record recordings/\naver replay   recordings/ --test --diff\naver replay   recordings/ --test --check-args\naver replay   recordings/ --test --json\n```\n\nRequires: Rust stable toolchain.\n\n### Editor support\n\nFor editor integration:\n\n```bash\ncargo install aver-lsp\n```\n\nThen install the VS Code extension `Aver.aver-lang`, or configure your editor to start the `aver-lsp` binary directly. See [editors/README.md](editors/README.md) for VS Code, Sublime Text, and manual LSP setup notes.\n\n---\n\n## Small example\n\n```aver\nmodule Payments\n    intent =\n        \"Processes transactions with an explicit audit trail.\"\n    exposes [charge]\n\ndecision UseResultNotExceptions\n    date = \"2024-01-15\"\n    reason =\n        \"Invisible exceptions lose money at runtime.\"\n        \"Callers must handle failure — Result forces that at the call site.\"\n    chosen = \"Result\"\n    rejected = [\"Exceptions\", \"Nullable\"]\n    impacts = [charge]\n\nfn charge(account: String, amount: Int) -\u003e Result\u003cString, String\u003e\n    ? \"Charges account. Returns txn ID or a human-readable error.\"\n    match amount\n        0 -\u003e Result.Err(\"Cannot charge zero\")\n        _ -\u003e Result.Ok(\"txn-{account}-{amount}\")\n\nverify charge\n    charge(\"alice\", 100) =\u003e Result.Ok(\"txn-alice-100\")\n    charge(\"bob\",   0)   =\u003e Result.Err(\"Cannot charge zero\")\n```\n\nNo `if`/`else`. No loops. No exceptions. No nulls. No implicit side effects.\n\n---\n\n## Deliberate constraints\n\nAver is intentionally opinionated. These omissions are part of the design, not missing features:\n\n- no `if`/`else` — branching goes through `match`\n- no `for`/`while` — iteration is recursion or explicit list operations\n- no exceptions — failure is `Result`\n- no `null` — absence is `Option`\n- no closures — functions are top-level and explicit\n- no async/await, streams, or channels — `(a, b)?!` declares independent computations; the runtime handles the rest. See [docs/independence.md](docs/independence.md)\n\nThe point is to remove classes of implicit behavior that are easy for AI to generate and annoying for humans to audit.\n\nFor the fuller language rationale, see [docs/language.md](docs/language.md).\n\n---\n\n## Why Aver exists\n\nLLMs can produce function bodies quickly. They are much worse at preserving the information reviewers actually need:\n\n- what a function is allowed to do\n- why a design was chosen\n- what behavior must keep holding after a refactor\n- what a new human or model needs to understand the codebase without reading everything\n\nTraditional languages usually push that into comments, external docs, stale tests, or team memory. Aver makes those concerns part of the language and tooling.\n\nThe intended workflow is explicit: AI writes Aver, humans review contracts and intent, and execution happens through the bytecode VM during development, with deployment through Rust code generation or WASM compilation.\n\n---\n\n## Execution modes\n\n### Default (VM)\n\n```bash\naver run hello.av\n```\n\nAll commands use the bytecode VM. For VM internals, see [docs/vm.md](docs/vm.md).\n\n### WASM\n\n```bash\n# Compile to .wasm (requires --features wasm)\naver compile hello.av --target wasm\n\n# Compile with WASI adapter for standalone wasmtime\naver compile hello.av --target wasm --adapter wasi\n\n# Run via built-in WASM host\naver run hello.av --wasm\n```\n\nSee [docs/wasm.md](docs/wasm.md) for ABI, memory model, and browser hosting.\n\n### Native Rust\n\n```bash\naver compile hello.av              # generates Rust/Cargo project\naver compile hello.av --policy embed   # bake aver.toml into binary\naver compile hello.av --policy runtime # load aver.toml at runtime\n```\n\nSee [docs/rust.md](docs/rust.md) for the generated code model.\n\n### Self-hosted\n\n```bash\naver run hello.av --self-host\n```\n\nRuns through the Aver interpreter written in Aver itself, compiled to Rust and cached on demand. See [self_hosted/README.md](self_hosted/README.md).\n\n---\n\n## What Aver makes explicit\n\n### Effects\n\n```aver\nfn processPayment(amount: Int) -\u003e Result\u003cString, String\u003e\n    ? \"Validates and records the charge. Pure — no network, no disk.\"\n    match amount\n        0 -\u003e Result.Err(\"Cannot charge zero\")\n        _ -\u003e Result.Ok(\"txn-{amount}\")\n```\n\n```aver\nfn fetchExchangeRate(currency: String) -\u003e Result\u003cHttpResponse, String\u003e\n    ? \"Fetches live rate from the ECB feed.\"\n    ! [Http.get]\n    Http.get(\"https://api.ecb.europa.eu/rates/{currency}\")\n```\n\nEffects such as `Http.get`, `Disk.readText`, and `Console.print` are part of the signature. Missing declarations are type errors. The runtime enforces the same boundary as a backstop.\n\nEffects can be granular or namespace-wide:\n\n- `! [Http.get]` allows only `Http.get`\n- `! [Http]` covers all `Http.*` effects\n\n`aver check` suggests narrowing a broad namespace effect when a function only needs a smaller subset.\n\nRuntime policy can narrow the allowed destinations further via `aver.toml`:\n\n```toml\n[effects.Http]\nhosts = [\"api.example.com\", \"*.internal.corp\"]\n\n[effects.Disk]\npaths = [\"./data/**\"]\n\n[effects.Env]\nkeys = [\"APP_*\", \"PUBLIC_*\"]\n```\n\nThink of this as two separate controls:\n\n- code answers: what kind of I/O is allowed?\n- policy answers: which concrete destinations are allowed?\n\nGenerated Rust can use the same scoped runtime machinery when you compile with `--with-replay`; see [docs/rust.md](docs/rust.md).\n\n### Decisions\n\n```aver\ndecision UseResultNotExceptions\n    date = \"2024-01-15\"\n    reason =\n        \"Invisible exceptions lose money at runtime.\"\n        \"Callers must handle failure — Result forces that at the call site.\"\n    chosen = \"Result\"\n    rejected = [\"Exceptions\", \"Nullable\"]\n    impacts = [charge, refund, settle]\n    author = \"team\"\n```\n\n`decision` blocks are first-class syntax, colocated with the code they explain.\n\nQuery only the decision history for a module graph:\n\n```bash\naver context decisions/architecture.av --decisions-only\n```\n\n`impacts`, `chosen`, and `rejected` accept either validated symbols or quoted semantic labels.\n\n### Context export\n\n```bash\naver context examples/core/calculator.av\n```\n\nAver walks the dependency graph and emits a compact context summary: module intent, public signatures, effect declarations, verify samples, and decisions. The goal is not to dump the whole source tree; it is to export the contract-level view that another human or LLM needs first.\n\nBy default, `aver context` uses `--depth auto --budget 10kb` with priority scoring: elements with more verify coverage, spec references, and decisions are included first. `--depth N` and `--depth unlimited` bypass that budget. Long verify examples are skipped rather than bloating the artifact.\n\nUse `--focus \u003csymbol\u003e` to build context around a specific function — its callees, types, verify blocks, and decisions are prioritized within the budget:\n\n```bash\naver context examples/data/json.av --focus fromString\n```\n\nThis makes token budget a navigation primitive. Another human or model can start with a small architecture map, zoom into the modules that matter, or focus on a single function's dependency cone.\n\nIf you want a larger export for a medium project, raise the budget explicitly:\n\n```bash\naver context projects/workflow_engine/main.av \\\n  --module-root projects/workflow_engine \\\n  --json \\\n  --budget 24kb \\\n  --output projects/workflow_engine/CONTEXT.json\n```\n\nWhen `--output` is used, Aver also prints a short selection summary to stdout, for example:\n\n```text\nmode auto, included depth 2, used 22622b, budget 24kb, truncated, next depth 3 would use 40739b\n```\n\nThe same selection metadata is embedded in JSON output so you can see whether the export stopped because of the budget.\n\nExample shape:\n\n```markdown\n## Module: Calculator\n\u003e Safe calculator demonstrating Result types, match expressions, and co-located verification.\n\n### `safeDivide(a: Int, b: Int) -\u003e Result\u003cInt, String\u003e`\n\u003e Safe integer division. Returns Err when divisor is zero.\nverify: `safeDivide(10, 2)` → `Result.Ok(5)`\n\n## Decisions\n### NoExceptions (2024-01-15)\n**Chosen:** Result — **Rejected:** Exceptions, Nullable\n```\n\n### Verify\n\n```aver\nverify charge\n    charge(\"alice\", 100) =\u003e Result.Ok(\"txn-alice-100\")\n    charge(\"bob\",   0)   =\u003e Result.Err(\"Cannot charge zero\")\n    charge(\"x\",    -1)   =\u003e Result.Ok(\"txn-x--1\")\n```\n\n`verify` blocks stay next to the function they cover. `aver check` treats a missing `verify` block on a pure, non-trivial, non-`main` function as a contract error.\n\nRegular verify:\n\n```aver\nverify add\n    add(1, 2) =\u003e 3\n    add(0, 0) =\u003e 0\n```\n\nLaw verify:\n\n```aver\nverify add law commutative\n    given a: Int = -2..2\n    given b: Int = [-1, 0, 1]\n    add(a, b) =\u003e add(b, a)\n```\n\n`verify ... law ...` is deterministic, not random sampling. Cases are generated as the cartesian product of explicit domains, capped at `10_000`.\n\nFor the proof-oriented style where a law relates an implementation to a pure spec function, see [docs/language.md](docs/language.md) and [docs/lean.md](docs/lean.md).\n\nOracle laws for classified effects:\n\n```aver\nfn fairDie(path: BranchPath, n: Int, min: Int, max: Int) -\u003e Int\n    ? \"Deterministic Random.int stub.\"\n    4\n\nfn pickOne() -\u003e Int\n    ? \"Rolls once.\"\n    ! [Random.int]\n    Random.int(1, 6)\n\nverify pickOne law usesOracle\n    given rnd: Random.int = [fairDie]\n    pickOne() =\u003e rnd(BranchPath.Root, 0, 1, 6)\n```\n\n`verify \u003cfn\u003e law \u003cname\u003e` is the proof-oriented Oracle form: `aver proof` lifts the effectful function to a pure function with explicit oracle parameters and can emit a universal theorem over that oracle. Use cases-form `verify \u003cfn\u003e trace` when you want runtime assertions over `.result` and `.trace.*`, such as `trace.contains(Random.int(1, 6))`. See [docs/oracle.md](docs/oracle.md) for the full model.\n\n### Replay\n\nUse deterministic replay for stateful, interactive, or external effectful code:\n\n1. run once against real services and record the effect trace\n2. replay offline with no real network, disk, or TCP calls\n3. use `--diff` and `--test` to turn recordings into a regression suite\n\n```bash\naver run    examples/services/console_demo.av --record recordings/\naver replay recordings/rec-123.json --diff\naver replay recordings/ --test --diff\n```\n\nUse Oracle laws when classified effects should become proof obligations over explicit stubs. Use `verify \u003cfn\u003e trace` when you need runtime assertions over `.result` or `.trace.*`. Use replay when the flow depends on ambient state, persistent TCP sessions, terminal modes, or server callbacks.\n\n---\n\n## Common commands\n\n```\naver check   file.av\naver run     file.av\naver verify  file.av\naver context file.av\naver compile file.av -o out/\n```\n\n`aver verify` runs only the example cases from `verify` blocks and fails on mismatches or example errors. `aver check` handles static contract diagnostics such as missing `verify` blocks and coverage-style warnings. Both `check` and `verify` accept `--deps` to walk transitive `depends [...]` modules.\n\nFor recursive code, `aver check` also warns when a recursive function still contains non-tail recursive calls after TCO. Tail-recursive code remains the preferred shape for large linear traversals; the warning is there to point out where accumulator-style rewrites may matter.\n\n`aver context` defaults to `--depth auto --budget 10kb` with priority scoring. Use `--focus \u003csymbol\u003e` to zoom into a function's dependency cone, `--budget 24kb` for a larger export, or `--depth unlimited` for the full graph.\n\nFor replay, formatting, REPL, and the full command surface, use `aver --help` and the docs below.\n\n---\n\n## Language and runtime\n\nAver is intentionally small. The core model is:\n\n- immutable bindings only\n- `match` instead of `if`/`else`\n- `Result` and `Option` instead of exceptions and `null`\n- top-level functions only, with no closures\n- explicit method-level effects\n- module-based structure via `module`, `depends`, and `exposes`\n- automatic memoization and tail-call optimization for eligible code\n\nFor the surface-language guide, see [docs/language.md](docs/language.md).\n\nFor constructor rules and edge cases, see [docs/constructors.md](docs/constructors.md).\n\nFor namespaces, effectful services, and the standard library, see [docs/services.md](docs/services.md).\n\n## Execution and proof backends\n\nAver has four backend paths:\n\n- VM-based workflow for `run`, `check`, `verify`, `replay`, and `context`\n- Rust compilation for generating a native Cargo project with `aver compile`\n- Lean proof export for pure core logic, Oracle-lifted classified effectful laws, and `verify` / `verify law` obligations with `aver proof`\n  Supported law shapes become real universal theorems; the rest stay as\n  executable samples or checked-domain theorems instead of fake proofs.\n- Dafny verification for automated `verify law` checking via Z3 with `aver proof --backend dafny`\n\nThe VM and generated Rust share practical behavior through `aver-rt`: list teardown, deep `append -\u003e match` paths, and string helpers such as `String.slice` are intentionally centralized there so one runtime fix can improve both execution paths.\n\nTypical Rust flow:\n\n```bash\naver compile examples/core/calculator.av -o out/\ncd out\ncargo run\n```\n\nTypical Lean flow:\n\n```bash\naver proof examples/formal/law_auto.av --verify-mode auto -o out/\ncd out\nlake build\n```\n\nTypical Dafny flow:\n\n```bash\naver proof examples/data/fibonacci.av --backend dafny -o out/\ncd out\ndafny verify fibonacci.dfy\n```\n\nRust is the deployment backend. Lean and Dafny are complementary proof backends:\n\n- **Lean** handles `verify` cases via `native_decide` (100% success on concrete examples) and supported `verify law` shapes via hand-crafted tactic strategies\n- **Dafny** emits `verify law` blocks as lemmas and lets Z3 attempt automated proofs — no tactic authoring needed, but limited on concrete computation\n\nFor backend-specific details, see:\n- [docs/rust.md](docs/rust.md) for Cargo generation and deployment flow\n- [docs/lean.md](docs/lean.md) for proof export, formal-verification path, and current Lean examples\n- [docs/dafny.md](docs/dafny.md) for Dafny verification and Z3-powered law checking\n- [docs/oracle.md](docs/oracle.md) for Oracle laws, classified-effect stubs, and trace assertions\n\n---\n\n## Examples\n\nShared examples under `examples/` resolve from `--module-root examples`.\nThey are grouped by role:\n- `core/` for language and syntax tours\n- `data/` for pure data structures and parsers\n- `formal/` for Lean-oriented proof examples\n- `modules/` for import and module-root examples\n- `services/` for effectful adapter demos\n- `apps/` for small multi-file applications under the shared examples root\n- `games/` for interactive terminal games (Snake, Tetris, Braille Doom)\nStandalone multi-file showcase projects live under `projects/` and use their own local module roots.\n\nRepository layout rule:\n- files under `examples/` share one root: `--module-root examples`\n- each folder under `projects/` is its own root, for example `--module-root projects/workflow_engine`\n\nTypical commands:\n\n```bash\naver check examples/modules/app.av --module-root examples --deps\naver check projects/workflow_engine/main.av --module-root projects/workflow_engine --deps\naver check projects/payment_ops/main.av --module-root projects/payment_ops --deps\n```\n\nCurated shared examples:\n\n| File | Demonstrates |\n|------|-------------|\n| `core/hello.av` | Functions, string interpolation, verify |\n| `core/calculator.av` | Result types, match, decision blocks |\n| `core/shapes.av` | Sum types, qualified constructors (`Shape.Circle`), match on variants |\n| `data/fibonacci.av` | Tail recursion, records, decision blocks |\n| `formal/law_auto.av` | Lean proof export, `verify law`, conservative universal auto-proofs plus sampled/domain fallback |\n| `formal/spec_laws.av` | Implementation-vs-spec laws (`verify foo law fooSpec`) and Lean spec theorems for supported shapes |\n| `formal/oracle_trace.av` | Oracle laws and trace assertions for classified effects with explicit stubs |\n| `apps/mission_control.av` | Command parser, pure state machine, effectful shell |\n| `games/wumpus.av` | Hunt the Wumpus: cave exploration, match-driven control flow |\n| `modules/app.av` | Module imports via `depends [Data.Fibonacci]` |\n| `services/console_demo.av` | Console service and replay-friendly effectful flow |\n| `services/http_demo.av` | HTTP service with sub-effects: `Http.get`, `Http.post` |\n| `services/weather.av` | End-to-end service: `HttpServer` + `Http` + `Tcp` |\n| `apps/notepad/app.av` | Multi-file HTTP app under the shared `examples` module root |\n| `games/snake.av` | Terminal Snake: immutable state, TCO game loop, Terminal service |\n| `games/tetris/main.av` | Modular Tetris: sum types, 2D grid, collision, line clearing (4 modules, 66 verify cases) |\n| `games/checkers/main.av` | Checkers with alpha-beta AI: cursor UI, forced capture, decision trace (5 modules, 144 verify cases) |\n| `games/doom/main.av` | Braille Doom: raycasting FPS with Unicode Braille rendering, procedural levels, 3 enemy types with AI, shooting, wall textures (7 modules) |\n| `core/test_errors.av` | Intentional `aver check` failures: type errors + verify/decision/effect diagnostics |\n\nStandalone projects:\n\n| File | Demonstrates |\n|------|-------------|\n| `projects/workflow_engine/main.av` | Explicit app/domain/infra flow, event replay, derived events, verify-driven orchestration |\n| `projects/payment_ops/main.av` | Dirty payment backoffice flow: provider normalization, replay, settlement reconcile, manual-review cases, audit trail |\n| `self_hosted/main.av` | Full self-hosted interpreter: lexer, parser, resolver, evaluator — all 55 examples pass. Compiles to native via `aver compile` and powers `aver run --self-host`. |\n\nSee `examples/` and `projects/` for the full set.\nFor repository self-documentation via decision exports, see `decisions/architecture.av`.\n\n---\n\n## Documentation\n\n| Document | Contents |\n|----------|----------|\n| [docs/language.md](docs/language.md) | Surface-language guide: syntax, semantics, modules, and deliberate omissions |\n| [docs/formatting.md](docs/formatting.md) | Formatter behavior and guarantees |\n| [docs/constructors.md](docs/constructors.md) | Constructor rules and parsing contract |\n| [editors/README.md](editors/README.md) | VS Code + LSP setup and Sublime Text support |\n| [docs/services.md](docs/services.md) | Full API reference for all namespaces (signatures, effects, notes) |\n| [docs/oracle.md](docs/oracle.md) | Oracle: effectful laws, trace assertions, and proof export for classified effects |\n| [docs/vm.md](docs/vm.md) | Bytecode VM design note: execution model, `NanValue`, opcodes, effects |\n| [docs/types.md](docs/types.md) | Key data types (compiler, AST, runtime) |\n| [docs/extending.md](docs/extending.md) | How to add keywords, namespace functions, expression types |\n| [docs/transpilation.md](docs/transpilation.md) | Overview of `aver compile` and `aver proof` |\n| [docs/rust.md](docs/rust.md) | Rust backend: deployment-oriented Cargo generation |\n| [docs/wasm.md](docs/wasm.md) | WASM backend: ABI, memory model, browser hosting |\n| [docs/lean.md](docs/lean.md) | Lean backend: proof export and formal-verification path |\n| [docs/dafny.md](docs/dafny.md) | Dafny backend: Z3-powered automated law verification |\n| [docs/independence.md](docs/independence.md) | Independent products: the semantic model behind `?!` and `!` |\n| [docs/research.md](docs/research.md) | Narrow related work for effects, Oracle, independent products, and proof targets |\n| [docs/pushback.md](docs/pushback.md) | Common pushback: questions, objections, and honest answers |\n| [docs/decisions.md](docs/decisions.md) | Decision export generated via `aver context --decisions-only` |\n","funding_links":[],"categories":["Uncategorized"],"sub_categories":["Uncategorized"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjasisz%2Faver","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjasisz%2Faver","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjasisz%2Faver/lists"}