Raven keeps user documentation and development records in the same repository,
but only an explicit user-facing subset is published by DocFX. The publication
list is defined in docfx.json; adding a Markdown file under
docs/ does not publish it automatically.
Public documentation should help someone learn or use Raven. It should explain what a feature does, when to use it, and show representative Raven examples.
- Choose your learning path
- Raven in 60 seconds
- Install and run Raven
- Introduction
- Raven for absolute beginners
- Raven for C# developers
- Metaprogramming in Raven
- Authoring Raven macros
- Language docs
- Domain modeling
- Compiler and command line
- Target platforms
- Project system
- Extend a Raven project
- Metaprogramming in Raven
- VS Code extension
The compiler API is published for analyzer, generator, refactoring, and tooling authors, but it is kept separate from the language-feature documentation.
Compiler architecture, implementation designs, investigations, test guidance, and language proposals are retained for contributors but are not part of the published user manual or the compiler API section. If compiler-development documentation is published later, it should have its own top-level section. These documents live primarily under:
docs/compiler/architecture/docs/compiler/design/docs/compiler/development/docs/design/docs/investigations/docs/lang/proposals/docs/testing/
The Playground architecture document describes the browser editor, compiler worker, sample-link contract, security boundaries, and build and test workflow.
The macro source shapes inventory categorizes existing macro carriers and future syntax candidates.
Do not link to these areas from published pages. When a proposal becomes part of the language, move its user-relevant behavior into the specification and learning material rather than publishing the proposal as the feature guide.