Concepts
The model behind Linkar.
Start here if you want to understand what Linkar is for. These pages explain the tension between customization and reuse, the role of templates and bindings, and why packs and projects are intentionally separate.
Why Linkar exists
Linkar is for the tension between customization and reuse: turning useful analysis resources into reusable building blocks without making them rigid.
Packs, bindings, and projects
Packs distribute reusable templates and bindings. Projects record local runs and working context without absorbing the reusable assets.
Template runtime contract
The `linkar_template.yaml` contract, `run.command` versus `run.sh`, and what render and run do.
Project lifecycle
A practical end-to-end view of how projects move from initialization to cleanup.
Params, bindings, and resolution
How Linkar resolves values, what bindings are for, and how warnings and placeholders fit into the model.
Project runs and metadata
What lives in `project.yaml`, what lives under `.linkar/`, and how run adoption, render, collect, and remove fit together.
CLI, API, and MCP interfaces
The same runtime semantics are exposed to humans, local API clients, and agent tooling.
Reproducibility and versioning
What Linkar records, what it leaves to the wrapped tool, and how packs should think about pinned versus floating upstreams.
Local API reference
A practical reference for Linkar's local HTTP API, including auth, discovery, route conventions, and the resolve-confirm-run flow.
Discovery layers and site packs
Keep Linkar generic by putting site-specific data discovery next to the pack instead of inside core runtime semantics.