Go doc

Our Go modules keep their manual and their reference in the source: the package comments explain how the pieces fit, the doc comments every exported identifier. Each release tag publishes the HTML built from them under /godoc/. The table below always shows the newest published version. The Ruby gems do the same with RDoc.

Published modules

Each module keeps its ten newest versions; /godoc/inkwell/latest/ always points at the newest, and the version switcher at the top of every page moves between them.

The rule: everything documented

The module's CLAUDE.md says it and CI enforces it: a push fails if revive (the exported rule, revive.toml in the repo) finds an exported type, function, method, constant or variable without a doc comment.

• The comment starts with the identifier's name and says what it does, what it takes and returns, the errors and the state it changes. The reason for a change goes in the commit, not the comment.
• Go doc syntax, not Markdown: [Name] and [pkg.Name] links, # Heading sections in package comments, lists with -, code as an indented block.
• Every package has its package comment in doc.go; the manual — how to build a game, with examples — lives there. The README.md only links here.

How it gets here

1. A release tag runs the module's pipeline: build, vet, the documentation gate, then doc2go builds the HTML and a meta.json (version, commit, date).
2. The pipeline uploads godoc.tar.gz as a Gitea generic package in the engines org, named after the module with a -godoc suffix.
3. The Gitea package webhook calls the wiki-fetcher, which also looks every ten minutes. It unpacks the new version, gives it the wiki look, moves latest and rewrites /godoc/index.json.
4. The table above reads that index in the browser, and the engine pages link to latest, so a release needs no wiki edit.

If a round fails, the wiki-fetcher's /health turns red. Details: fetcher/README.md in services/wiki-pages.