/orient-map

Computes a fresh, honest read of the shape of the work — what changed since your last look, and the done → here → next trajectory rendered as a path on the trunk or a TREE on a branch — and returns it as one ephemeral bundle (a structured YON record + a human markdown read + a small visual). It is the orient- family's topology lens: it owns branch detection and the diff-of-trees so its siblings don't recompute them. Emits the trajectory + delta slices of the shared record at orient-spec/orient-record.yon.

Structured execution spec: protocol.yon. Read it for the canonical steps, rules, and gates; this file is the human-readable, self-sufficient explanation. The two must stay in sync — if you edit one, update the other and refresh the @STAMP date.

When to use

• "Show me the map / what's the shape / done-to-here-to-next" on a project, repo, plan, or task.
• "What changed since I last looked" — the delta is the headline; you want the diff-of-trees, not a fresh full read.
• "How deep down a branch / side-quest am I" — you need the branch stack and the fork point, not a flat file list.

How it works (self-sufficient — works without protocol.yon)

orient-map delegates the gathering to a bounded, read-only subagent so the calling session (a human's, or an agent orienting itself) never sees the search/inference noise — only the result bundle comes back. Nothing is stored; every call recomputes from current reality. It is delta-first: the change since your last look leads, and the raw file-tree is demoted (the IDE already owns that).

1. Take the last-look anchor and intent as inputs, never prompt for them. The anchor (the reference endpoint the delta is measured from — a git ref, a timestamp, a HEAD@time) is caller-supplied or git-inferred, never written to disk. Intent (the goal / what "done" means) gates the trajectory: if intent can't be grounded, render the path but cap every intent-dependent node to guessed and never emit a confident tree from the void. Never fabricate a goal or an anchor.