get

How ki get works

ki get <uri> [<uri> …] fetches a node's metadata and content by uri. It's the retrieval end of the loop: ki search and ki outline hand you uris (and optionally some content in the case of ki search); ki get turns a uri into the actual text. For the profile/vault model it shares with the other read commands, see docs/scoping.md; for search, docs/commands/search.md.

---

1. What it takes, what it returns

• Input: one or more Document or Section uris (batch as many as you like).
• Output: a metadata shell per uri, plus content controlled by --type.

Only :Document and :Section uris are valid — those are the nodes that carry text. A :Folder or :Vault uri is a clear error with a redirect:

error: ki get is for text retrieval but you passed a Folder (my-notes/ideas).
       Use 'ki outline my-notes/ideas' to enumerate contents recursively under folder.

Use ki outline to enumerate a folder/vault; ki vault list to see vaults.

---

2. The three --type levels

--type controls how much content rides along on the metadata shell:

--type	Content returned	Use when
path	none (shell only — uri, name, path, …)	you just want the on-disk path / metadata, then read the file yourself
content (default-ish)	the node's own content — its preamble + uri: pointers to direct children	you want a shallow view and may drill further
full	the reconstructed reading-order body of the whole subtree	you want everything under the node in one shot

The content level reflects ki's Content Construction Rules (see docs/data-model/schema.md): a node stores only the body text directly under its own heading, followed by uri: pointer lines to its direct children. So --type content is shallow by design — child body text isn't included; you see pointers and can ki get those next.

The full level does that reconstruction for you, server-side, in one query (no client-side recursion):