/orient-roadmap

Computes a fresh, honest read of where the work is going — the increment arc (built → current → next), what is shipping now, the gates, the next increment's clusters (the paramount one starred), and the runway of stage boxes (now → gated-next → future) plus the deferred lanes — and returns it as one ephemeral bundle (a structured YON record + a human markdown read + a small visual). It is the orient- family's forward-horizon lens: where /orient-map looks back (delta + topology) and /orient-status reports the node you stand on, orient-roadmap looks ahead across multiple horizons. Emits the roadmap slice 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 roadmap / the runway / what's next" on a project, repo, plan, or task — you want the forward horizons, not the node you're on.
• "What are the increments and the lanes" — you want the built → current → next arc, the next increment's clusters, and the runway of gated stages laid out as one board.
• "What's the plan from here" — the prospective board (increments not yet reached, the runway of gated stages, the deferred lanes), not the retrospective delta.

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

orient-roadmap 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 horizon-first: the forward increments and the runway lead; the retrospective delta is /orient-map's job, not this one's.

1. Take the north-star / intent and the last-look anchor as inputs, never prompt for them. Intent (the goal / what the arc is aiming at) gates the whole board: if intent can't be grounded, render what exists but cap every intent-dependent horizon to guessed and never emit a confident runway from the void. The anchor (a git ref, a PLAN.md, a HEAD@time) is caller-supplied or git-inferred, never written to disk. Never fabricate a north-star or an anchor.