The reference section states the exact surface of Helix: every CLI command and flag, every helix.config.ts key, every method on the function context, and every function signature. Come here when you know what you’re looking for and need the precise answer. For task-oriented walkthroughs, use the guides.
What lives here
CLI. Every shipped helix command, grouped by what you’re doing: project setup and login, local development, authentications, and deploy. Each page gives the synopsis, the exact flags, and a runnable example. Start at the CLI overview. Only shipped commands are documented: if you have seen a command in platform design material and it isn’t there, it isn’t in the CLI.
Configuration. The helix.config.ts file: the project name, projectId, workspaceId, environment, and the authentications map your functions reference by alias. The page also marks the config blocks that belong to the platform design rather than the shipped CLI. See the configuration reference.
Context API. The ctx object passed to every function. Shipped today: ctx.kv(), ctx.http, ctx.log, and the request members. Not on the context object today, and not documented here: ctx.db(), ctx.queue(), ctx.files, and ctx.ai(). Start at the ctx overview.
Functions. defineFunction, file-based routing under functions/, and input and output schemas. HTTP is the only trigger today, so defineSchedule, defineAppTrigger, and defineQueueConsumer are design. See function definitions and limits and roadmap.
How reference pages relate to guides
Guides walk one task from start to finish and make choices for you; reference pages enumerate everything a command or API accepts, with no narrative. The two link to each other: a guide names the commands it uses, and each reference page points back to the guide that shows the command in a real workflow. If a fact about a flag, default, or limit appears in both, the reference page is the authoritative version.