DEV Community

Ordewell
Ordewell

Posted on Originally published at ordewell.ai

Where the plan lives when the terminal closes

#ai #opensource #devtools #programming

Most agent work lives in a conversation, and a conversation is as durable as the tab you have open. Close it, reboot, come back in the morning, and the context is gone. The plan you spent an hour agreeing on is a scrollback you no longer have.

The alternative is to treat the plan as a stored artifact, and then the interesting questions are about coming back: how you find the plan again, what state it is in, and what happens to the work that was in flight when you left.

Disclosure first: I build Ordewell, so this is the shape of the tool rather than a survey of tools. It is free and Apache 2.0, and the questions are worth asking whether or not you install it.

The plan is not the conversation

In Ordewell the plan is a graph of tasks with dependencies, each task carrying its own runner, model, mode and a completion marker. It is stored as a named session by the local daemon, which means the plan outlives the process that created it. The conversation that produced the plan is a separate thing and is not the state you come back to.

That has a consequence worth stating plainly: the thing you reopen is not a transcript, it is a work queue. Tasks have statuses, the graph has an order, and every task's verdict is on the record next to the evidence for it. A transcript gives you the mood of the work. A queue tells you what is left.

# every plan in this workspace, newest state first
ordewell sessions list

  3d41ab9f  approved     9 tasks  2026-09-29T14:02  wire the billing retry path
  77c0e2a1  completed    4 tasks  2026-09-26T09:18  add the CSV export flag
* a19f8b02  running      6 tasks  2026-09-30T08:44  move auth to the new table
Enter fullscreen mode Exit fullscreen mode

The listing is per workspace, which is the honest boundary: sessions belong to a repository directory, not to the machine, so a plan does not follow you into an unrelated checkout.

Coming back to a plan

Loading a past session is one command, and it does two things rather than one. The CLI repoints its own notion of the current session, and it hands the session to the daemon as well, because a daemon can only execute a plan it currently holds. Skipping the second half is how you get a command that looks right and then says it cannot find the plan.

# pick the plan back up
ordewell sessions load a19f8b02

# what is done, what failed, what is still owed
ordewell status

# continue: tasks already verified are not run again
ordewell run
Enter fullscreen mode Exit fullscreen mode

Resuming is not restarting. A completed task is not re-dispatched on the next run, so the cost of coming back is the work that is actually left, which is the property that makes leaving safe in the first place. If you closed the laptop halfway, the half that finished stays finished.

If you are not sure which plan you want, the id is enough to ask: the session record carries the goal text, the task count, the status and the creation time. A workspace with a dozen plans in it is navigable rather than a pile.

The work you left behind, and how to land it

Tasks are one thing to come back to. Their output is another. When a plan runs isolated, each task gets its own worktree and branch, and the run finishes by leaving one branch standing for the whole run. That branch is the thing you review, and it is the piece most likely to be forgotten, because it lives in git rather than in the tool.

The handoff command is the terminal counterpart of the same actions the TUI exposes, and it has four moves:

# what the run actually changed, against the base it started from
ordewell handoff review

# land it on the branch you have checked out
ordewell handoff merge

# throw the run away, branches included
ordewell handoff discard

# remove the worktrees, keep the run branch for later
ordewell handoff cleanup
Enter fullscreen mode Exit fullscreen mode

Merge and discard are the two steps that cannot be undone, so both ask before they act, and --yes is the explicit way to say you have already answered. That is a small design point with a large practical effect: the commands you type absent-mindedly are the safe ones.

Review prints the diff between the run branch and its base, and if the run produced nothing it says so in one line rather than printing an empty page. A multi repository run reports per repository, and merge refuses rather than half landing: either every repository can take the branch, or nothing is merged. Afterwards the run's worktrees and task branches are removed, which is the cleanup you would otherwise do by hand some time next week.

Honest limits

  • A handoff needs an isolated run. If the run was never isolated there is no run branch to review or merge, and the command says so instead of inventing one. Landing the work is then the ordinary git work you were doing anyway.
  • Nothing resumes inside a task. The task is the only checkpoint. A task interrupted mid flight is a task you retry from the start, on a fresh session for that task, with the repeated work that implies.
  • Sessions are local and per workspace. There is no cloud copy and no sync. A plan stored under one repository directory is not visible from another, and a machine that is wiped takes its plans with it.
  • Merge is not resolution. If the branch conflicts with the branch you are on, the conflict is surfaced rather than solved for you, and the decision about whose change wins is yours.
  • Kept worktrees accumulate. A failed task keeps its worktree so you can inspect it, which is useful exactly once and clutter afterwards. Nothing prunes them on a timer.

Reading the code instead of trusting the description

The session store and the handoff actions are ordinary local state, which is why I would rather point at the source than describe it: the session commands and handoff commands live in the CLI package, and the isolation decision behind the run branch is written up as an ADR in the repository.

Top comments (0)