Verbs, subjects, and affordances
Hypermake's CLI is one grammar, not a pile of commands: a small set of shared verbs applied to typed subjects. You do not memorize 150 commands — you learn 11 verbs, and every answer names the next useful command. Every behavior described on this page was run against this project.
One grammar
The general form is hypermake <verb> <subject>. The subject can be a target path (rendered/public/docs/protocols.html), a browser URL path (/docs/protocols.html), a protocol address (public://_hypermake/site/commands.json), or a command subject like concept://target. The resolver canonicalizes whatever you hand it: inspecting the URL path and inspecting the rendered target answer with the same canonical target.
The shared verbs, quoted from the registry
This table is generated at build time from hypermake commands --json — the same registry agents read. It cannot drift from the binary.
| Verb | Registry summary |
|---|---|
inspect | identify target, URL, route, owner, authority, and next affordances |
explain | explain recipe ownership, freshness, and buildability |
check | validate diagnostics/readiness for a target, source, or scope |
build | materialize graph-owned targets |
serve | serve graph-backed output and optional live inspector runtime |
profile | measure target/runtime performance and write evidence |
compare | compare reports, evidence runs, images, or artifacts |
prove | run a promotion proof or canary and persist evidence |
edit | inspect source-owned edit guidance for a subject |
sync | synchronize state between authorities |
clean | prune explicitly scoped derived state |
The verbs carry an evidence policy from the command-surface contract: profile and compare write evidence by default because their results are naturally measurements; prove is incomplete without evidence; the rest attach evidence on request. Evidence lands in the project-local store that hypermake evidence status reports.
How affordances chain
Every command answers with the same envelope: the resolved subject, the authority that answered (one-shot CLI, resident daemon, or dev service), a typed reason code, and — the part that makes the surface navigable — a next block naming the follow-up commands. You rarely need to know the next command in advance; the previous answer names it. A typical read-only investigation of one page of this site:
hypermake inspect /docs/protocols.html hypermake explain rendered/public/docs/protocols.html hypermake graph rendered/public/docs/protocols.html hypermake check rendered/public/docs/protocols.html hypermake edit rendered/public/docs/protocols.html
What each step answered with (run against this project)
| Step | What the answer carries |
|---|---|
inspect | Canonical target for the URL path, the build target, physical path, source candidates (template, components, config), policy band, and freshness with a reason code such as fresh.proof_verified. |
explain | The owning recipe (src/rendered/public/{path}.html.make), the matched pattern, the discovered prerequisite list, and a human summary of why the target is fresh or stale. |
graph | The dependency neighborhood: each node with its state and owning recipe, down to discovered inputs like component files and icon targets. |
check | Diagnostics scoped to the subject — template, component, and writer-conflict findings — plus a profile of what was validated. |
edit | Authorship: which source spans produced the output, which candidates are editable (editable=yes only for proved src/ and data/ files), and a concrete next-action. |
Building is the same grammar. hypermake public builds the aggregate target; hypermake build <target> is the explicit verb form. A settled graph answers a build request with a no-op — built=0, everything up-to-date — which is the normal, desirable steady state.
Three command classes
The registry classifies every command: 11 shared verbs (the product surface above), 33 specialists, and 106 developer commands. Specialists are the named tools a workflow still reaches for directly — doctor, watch, daemon, evidence, branches, scaffold — most of them compatibility aliases that fold into a shared verb's family. Developer commands are internal plumbing for recipes and migrations: real, invocable, but not a product workflow. The generated registry page lists all three classes from the live registry.
The registry is itself a command
hypermake commands --json projects the full command registry as hypermake.commands.v1: every command's name, class, and — for the 44 help-visible commands — a one-line summary, subcommand list, or usage shape. This is the agent-facing index: a tool that wants to know what this binary can do asks the binary, and gets a complete (complete: true) machine-readable answer. The command registry page on this site is rendered from that projection at build time, so the site's list and the binary's list cannot disagree.
The standalone lzr CLI
The template engine ships as its own binary, lzr, alongside hypermake. Hypermake recipes call it directly — this site's own page recipe runs lzr render-page for every rendered page. Its subcommand surface (compile, render, validate, package, format, email, and legacy-migration families) is enumerated by the binary itself: run lzr with no arguments and it prints the full usage line. Most workflows never call it by hand; the graph owns those invocations.
hypermake commands hypermake commands --json hypermake inspect /docs/cli-verbs.html hypermake explain rendered/public/docs/cli-verbs.html hypermake clean cache