Package home is the realm behind https://gno.land/u/moul.
gnoweb builds a user profile page by calling Render("") on the realm at the exact path /r/<username>/home (gno.land/pkg/gnoweb/handler_http.go, GetUserView) and embedding the result as the profile body. There is no version resolution in that lookup, which is why this realm (alone in this repo) carries no /vN suffix: the bare path IS the interface with gnoweb, and gno.land/r/moul/home/v0 would never be found.
Slots
The page is not hard-coded. It is assembled from SLOTS: named markdown fragments in an avl tree, each written by its own Set call, so updating one paragraph is one small transaction instead of a redeploy.
The layout is itself a slot ("layout"), so the shape of the page (headings, order, what appears at all) changes without touching the code. p/moul/dynreplacer fills every :slug: placeholder found in the layout, lazily: a slot whose placeholder is absent from the layout costs nothing to render.
Substitution is SINGLE-PASS and non-recursive. A placeholder inside a slot body is left alone, so no slot can expand into another and no cycle exists. Two registered placeholders can never be prefixes of one another either (every one is :slug: and a slug may not contain ':'), so the result does not depend on registration order.
A placeholder with no matching slot survives into the output verbatim. That is deliberate: a missing section should be visible, not silently blank.
Versioning
gnomod.toml declares private = true, which lets the creator re-add the package at this path. That redeploy re-runs init() and RESETS everything here, so the markdown under content/ is the source of truth and tools/gnohome pushes the slots back afterwards. The intended path is that this never happens: slots cover content, and the layout slot covers presentation.