Reference
Documentation
Where should I go for current installation, operation, and source documentation?
The live opentendril/opentendril repository is the source of truth for current commands and procedures.
Website pages explain the system. Repository guides contain executable instructions. This site does not fork operational walkthroughs into static copies that will drift.
Recommended path
Suggested reading order on current main. Each link opens the
file in the product repository.
-
1
Installation
docs/GUIDE-INSTALL.md: governed and single-user installation models.
-
2
First governed session
docs/GUIDE-QUICKSTART.md: credential, grant, first call.
-
3
Git connection
docs/GUIDE-GIT-CONNECTION.md: connecting Substrates and Git identity.
-
4
Capability and authorization model
CAPABILITIES.md: Core registry authority, governed commands versus views and control-plane operations, interface parity, delegation grants, and current capability families.
-
5
Current architecture
ARCHITECTURE.md: authoritative current implemented architecture; see also the architecture page.
-
6
Current Objective
OBJECTIVE.md: the capability being tested; see also the experiment page.
-
7
Terminology
GLOSSARY.md and SYNTHETIC-TAXONOMY.md, or the website’s Taxonomy overview.
-
8
Greenhouse (observation UI)
-
9
Engineering and governance
AGENTS.md and GUARDRAILS.md: contributor and governance rules for the product repository.
Installation models
Two deployments are not equivalent. The install and quick-start guides are authority; this is only the distinction:
- Governed Stem runs as its own OS principal. Callers use governed transport and Pollinator credentials. Principal separation is the point.
- Single-user Stem runs under the user’s own authority. Convenient for local use; it does not provide the same principal-separation property.
Follow GUIDE-INSTALL.md and GUIDE-QUICKSTART.md rather than copying commands from this page.
Hardiness
tendril hardiness reports deployment posture: whether this
Terroir’s conditions allow the intended delegation boundary to be
enforced rather than merely recorded.
It reports; it does not gate. It is not certification, not a security score, and not an acceptance decision. See the install guide for how to read the report.
MCP transport
tendril mcp is a governed command surface and stdio bridge
If a governed other-user Stem is reachable and a durable Pollinator credential is available, it forwards MCP frames to that Stem. Authorization and Pollen derivation then happen at the governed Stem.
If an other-user governed Stem is reachable but no credential is available, it refuses rather than silently creating a competing local Stem. Otherwise it can operate in-process, including when explicitly forced.
Credential lookup and MCP configuration belong in GUIDE-QUICKSTART.md; this page is not a client config file.
Interface parity
CLI, MCP, and REST command surfaces project the same Core capability
registry. Parity is test-enforced in the product repository against
CapabilityNames(). View authority such as
sprout.watch, and observation surfaces such as
/ws, are outside governed command parity.
Structure and trust boundaries: current architecture.
Documentation authority
Not every Markdown file in the repository has equal authority.
For current operational behaviour, prefer the current Objective, implementation, canonical taxonomy, and named operational guides. Explanatory documents may lag implementation; when they conflict, current implementation and higher-authority canonical files control.
ARCHITECTURE.md is the authoritative current implemented architecture document. The public /architecture page is the current high-level architecture explanation for readers, grounded in implementation. Capability and authorization detail lives in CAPABILITIES.md. Vocabulary overview: /taxonomy.
Website explanation pages
Problem and experiment pages (not operational runbooks):