Review what changed

Use these read paths when you return to work and need to see what moved. They cover the recent activity feed, one node’s edit history, a commit’s graph references, and the status of a whole workstream.

Recent changes

spor changes shows recent graph activity: one entry per node, newest change in range first.

spor changes --since '12 hours ago' --project billing

Each entry is tagged as human-written or machine-written, with machine sources such as capture, distill, and the gardener. That makes the feed useful after agents worked overnight.

--since accepts a commit sha or any date or relative phrase git understands, such as '12 hours ago' or 2026-06-15.

The full CLI entry is in Reading the graph. From MCP, use the recent_changes tool.

One node’s history

spor history <id> shows the commit history for one node: who edited it, when, and what changed.

spor history dec-tidefall-billing-retries --limit 10

Pass a revision sha to show that revision’s diff and change type. Add --content when you also need the full node at that revision.

History matters because the visible author field in node frontmatter re-stamps to the last editor on every write. Git history is the durable record of the full chain of editors.

The full CLI entry is in Reading the graph. From MCP, use the node_history tool.

From commit to reasons

spor blame <sha> reverse-lookups a git commit to the decision, task, and issue nodes that reference it in their commits: field.

spor blame 4f2a91c --repo billing

Use it after ordinary git blame: blame a line, then ask Spor why that commit exists. The sha can be abbreviated or full, from 7 to 40 hex characters, and matching is prefix-aware. An empty result is normal for a commit linked to no node, and exits 0.

The commits: field is populated automatically when Spor is wired into a coding agent. A hook watches for commits made during a session and links them to related nodes, so nobody annotates commits by hand. See What happens automatically for the hook path.

The full CLI entry is in Reading the graph.

Program view

For a whole workstream, use the program view. There is no CLI verb for it; the view is served by the render_program MCP tool with {id, max_depth?, max_nodes?} and by GET /v1/program/{id}. On MCP-Apps-capable hosts, it renders as an interactive view.

Start from a root node that other work blocks, or that other work declares member-of-program to, such as an umbrella task or a milestone. At each node the walk prefers inbound member-of-program edges — the dedicated, pure-topology membership edge — falling back to inbound blocks only where a node declares no membership edges, so an unmigrated or partially migrated program still renders. The server buckets each member from the same truth the queue uses:

• done — terminal status, superseded, or retired by a live resolves or answers edge. This counts even while the status field lags.
• blocked — gated by the node’s own live blockers.
• active — live, unblocked, and started.
• open — live, unblocked, and not started.

The result includes progress totals, percent complete, and the gating tree. Shared blockers render once and repeat as marked leaves. If depth or node caps skip anything, the response reports what it skipped.

A root with no inbound blocks or member-of-program edges is a successful empty result. It means the program needs modeling: add blocks and/or member-of-program edges from the work that belongs to it.

For example, the tidefall team hangs the billing retry-flow rollout under task-tidefall-retry-rollout. Member tasks such as task-tidefall-retry-emails carry blocks edges to that umbrella task, gating its completion — a non-gating member of the same rollout would carry only a member-of-program edge instead. The program view of task-tidefall-retry-rollout shows how far the rollout has moved. member-of-program ships as a graph-resident schema pending activation — spor schema member-of-program reports whether it’s live in a given graph yet.

See the queue for the status rules the view reuses, and Lenses, program view, and workflows for the model. Use lenses when you need a saved view rather than a program progress tree.