Reference
Documentation Generator
Zornux reads the # comments above your declarations and turns
them into a browsable set of API docs — Markdown or self-contained HTML —
with a single command: zornux doc.
Writing documentation comments
The run of # lines directly above a declaration is its
documentation. Plain prose is the summary; a few tag words add structure.
# Calculates sales tax from a product price.
# param price The pre-tax product price.
# returns The tax owed on that price.
# example
# show calculate_tax(100)
public function calculate_tax with price
give back price * 0.1
end
Tags
| Tag | Meaning |
|---|---|
param <name> <text> | Documents a parameter. |
returns <text> | Documents the return value. |
example | A code example — on the same line, or the lines below. |
security <text> | A security note. |
deprecated <text> | Marks the symbol deprecated, with guidance. |
Generating docs
zornux doc # Markdown into docs/api
zornux doc --format html # self-contained static HTML
zornux doc --format openapi # an OpenAPI (Swagger) spec of your services
zornux doc --output docs/api # choose the output folder
zornux doc --include-private # also document non-public symbols
zornux doc --include-tests # document tests as specifications
zornux doc --include-packages # include dependency public symbols
zornux doc --fail-on-missing-comments
docs/api/
index.md
modules/
Products.md
classes/
Product.md
services/
ProductAPI.md
Only public symbols are documented — that's your published API surface. Use --include-private to surface module-private and private declarations.
Security & controllers
For controllers and routes, any require role guard or
restrict to <Role> guard is surfaced in the docs as
Requires role: <Role>, so the authorization model
is visible alongside each endpoint.
controller Products at "/products"
require role "admin"
# Adds a product. Restricted to administrators.
# security Only the Admin role may create products.
on POST "/" with request_data
give back created message "Product created!"
end
end
The generator builds a format-independent model first, then renders it — so
Markdown, HTML, and the OpenAPI spec all stay in step. The
--format openapi output (alias swagger) describes
every controller route — methods, paths, and status
responses — so your API plugs straight into OpenAPI tooling. See the
command-line reference.