docs(local): make `glab orbit local` the primary install path
What
Three Orbit Local pages still told users to "build from source until packaged binaries ship". They ship: glab orbit local --install --yes installs the managed orbit binary (v0.58.0) in glab 1.94+. This flips the install guidance and corrects the related glab orbit setup framing.
Changes
getting-started.md- drop "planned" from the access-method table; rewrite the 60-second quickstart note to describe the binary download on first use.access/cli.md- new Install section leads withglab orbit local --install --yesand the one-line installer; build-from-source demoted to a "Build from source" contributing note.access/glab.md- reframeglab orbit localandglab orbit setupas shipping today; add an Install section; replace the fictionalsetupflags (--agent/--skill-only/--mcp-only/--dry-run) with the real ones. Keepglab orbit local mcp serveandglab orbit local statusmarked planned - neither exists in the v0.58.0 binary._index.md- drop "(planned)" from the glab access row.
Verification
Verified against the shipping CLI (orbit v0.58.0, glab 1.101.0):
| Command | Result |
|---|---|
glab orbit local --install --yes |
works |
glab orbit local index / schema / sql / query |
work |
glab orbit setup |
ships (top-level command: verify access, install skill, install local binary) |
glab orbit local status |
unrecognized subcommand - left planned |
glab orbit local mcp serve |
unrecognized subcommand - left planned |
Existing sql/query examples kept as-is (they work). The originating issue suggested glab orbit local query -, but v0.58.0 takes the query JSON as a positional argument, not stdin via -, so that was not introduced.
mise run lint:docs passes on all four changed files (the 3 pre-existing vale errors are in unrelated files).
Out of scope (follow-up)
access/mcp.md has separate inaccuracies not touched here: it calls glab orbit setup "planned" (it ships) and tells users to run orbit mcp serve / glab orbit local mcp serve to serve the local graph - but neither subcommand exists in the binary. Worth a separate issue.
Closes #668 (closed)