Install ontoref

The command

curl -fsSL https://ontoref.dev/public/install.sh | sh

Somewhere other than ~/.local:

curl -fsSL https://ontoref.dev/public/install.sh | sh -s -- --prefix ~/.local

Linux and macOS, amd64 and arm64. No account, no token, no oras.

That command is not written here for illustration. Before a release is announced, a gate fetches that URL, installs into a throwaway HOME and a throwaway prefix with none of the author’s environment, and then asks the installed product to do three things that cannot succeed if the data layer did not arrive:

✓ ontoref setup
✓ ontoref describe project
✓ ontoref describe capabilities

If the page and the gate ever disagree, one of the two is wrong — and the disagreement is detectable, which is why they are the same string.

What just happened

The installer verifies the bundle’s sha256 before laying anything out, and then places three separate things:

The daemon is an optional accelerator, never a runtime dependency (ADR-029). Its binary is in that list, and nothing you are about to do starts it. What you have installed is tier-0: declarations in Nickel, and a CLI that reads them. It answers on a laptop with no service running and no network.

One external runtime dependency: Nushell (≥ 0.110). If you have none, the bundle carries a fallback and says so; your own nu always takes precedence. If ~/.local/bin is not on your PATH, the installer tells you that too.

Make an instance of your own

Tier-0 is not a thing you read, it is a thing your project carries. From inside a project of yours:

cd /path/to/my-project
ontoref setup

That writes Layer 1 — the project describing itself:

.ontology/core.ncl        axioms, tensions, practices, edges
.ontology/state.ncl       where the project is vs where it wants to be
.ontology/gate.ncl        the boundaries that gate a transition
.ontology/manifest.ncl    metadata, layers, capabilities
adrs/                     decisions, with their constraints typed
reflection/qa.ncl         accepted knowledge, as typed Q&A
reflection/backlog.ncl    open questions, routed
reflection/modes/         your own procedures, as step DAGs
.ontoref/project.ncl      identity
.ontoref/config.ncl       runtime configuration

It is idempotent, it installs a post-commit and a post-merge hook, and it registers the project in ~/.config/ontoref/projects.ncl — one CLI serves several projects. --kind Library | Service | DevWorkspace | PersonalOntology picks the scaffold; Service is the default.

Ask it something

Do not take the previous section on faith. Run this, in that project:

ontoref describe project

On a scaffold you have not filled in yet, it answers — and answers almost nothing. That is correct, and it is the most useful thing this page can show you: the tool holds what you declared, so at minute one it holds a skeleton.

This one is more eloquent about the shape of what you have:

ontoref describe capabilities

CAPABILITIES  bounded — 15 sections · 193577 bytes if full
  ontoref_commands   48 items
  reflection_modes    1 items
  adrs                0 items
  feature_flags       0 items
  ...

Forty-eight verbs available, zero decisions recorded, zero flags declared. The inventory is bounded on purpose — it tells you its own size instead of pouring 190 kB into your terminal. Everything at 0 is work you have not done, stated as a number rather than implied by silence.

What this does not do

The honest part, and it belongs here rather than in a footnote.

This is not a recipe from A to B. Nothing above configured, deployed or migrated anything. setup created files; it did not decide what goes in them. The declaring is yours, and it is the actual work — the CLI only makes what you declared queryable, and tells you when it stopped being true.

No determinism is promised. ontoref does not guarantee your project ends up where you said it was going. It guarantees something narrower and checkable: what you left stated, someone else can verify — without cloning your repository and without holding your whole system in their head.

The daemon changes none of that. It caches and shares context; it is not the protocol. If someone tells you that you need a service running to get value out of tier-0, they are describing a different product.

A quickstart cannot argue the core. Two axes, the witness seam, the habitability of the plane — none of it is here, deliberately. Install it, ask it something, and decide whether the answer was worth the two minutes.

Other routes, and what each of them costs you today

Access and verification are deliberately different routes. The installer above fetches the bundle as a plain file over HTTPS from this domain — that is the access route, and it is why it needs no account and no oras. The signed and attested artifact lives in an OCI registry, which is the verification route.

The rest of this section is written the way the section above was: only what has been executed, with the failures named.

Read the source. The repository clones anonymously over HTTPS:

git clone https://repo.jesusperez.pro/ontoref/ontoref-code.git

A bare clone does not build yet. Measured, not assumed: cargo fails before compiling anything, because the workspace declares a required path dependency on a sibling checkout a stranger does not have. So the clone is a route to read the code today, not a route to install it — and the one-line command above is not a convenience over building from source, it is currently the way in.

The registry is not anonymous-pull. GET /v2/ontoref/dist/tags/list answers UNAUTHORIZED, and so does the daemon image. oras pull and docker run against this registry need a credential you do not have yet; asking for one is a conversation, not a command, and no signing key is published for you to check a bundle against on your own. Naming that is more useful than printing a command that would fail in your terminal.

So: the verifiable route exists and you cannot walk it unaided today. The integrity check you do get, unaided, is the sha256 sidecar the installer verifies before it lays out a single file — and the gate at the top of this page, which is the strongest claim on offer here: someone with no access to this machine’s state installed exactly what you are about to install, and it answered.

If something goes wrong

sh install.sh --uninstall removes the binaries; --purge also removes the data and the config.

A platform can be supported by the installer and still have no bundle published for a given version. The installer names which platform and which version rather than failing bare, and then suggests --version, a source build or the container — two of which, per the section above, are not open to you unaided today. If you land there, say so: the gap is a real one and known, not a mystery to debug on your side.