Feature Reference

Keybindings

Every key below can be rebound — press ? for the in-place editor, or open Settings → Shortcuts. See Shortcut scope for how a rebind here relates to the board.

In the trail selector

The selector has two panes. On the left, a search box above the list of trail titles; on the right, the details of the highlighted trail: its owner task, scope, recorded freshness, when it was generated, the tasks it shares with other trails and, for a trail that could not be loaded, the error and its recorded versions. The search box keeps the keyboard focus, so you can type at any time.

In the detail screen

In the linked-trails dialog

In the jump confirmation

Shown before the switch when the jump has something to tell you — the other project runs an older aitasks, or its session was started under a fallback name.

What each refresh reads

None of r, d, s and the tab keys writes anything to the task data or the trails. A scan keeps what it found in .aitask-cache/ in the project and checks it against the content of the task files, archive bundles and stored trails every time, so a repeat scan re-reads only what changed and is quick. The cache belongs to this checkout and is safe to delete. r re-reads the task files for every tab, not only the active one: the other tabs show the new statuses when you switch to them. The statuses of cross-repo dependencies are checked together with the freshness check — when a trail opens and on d; r and the tab keys reuse the last results. For the costs of each key and the drift reasons a card can show, see By-Trail in the board reference — the view is the same.

Tabs

Every trail you open from the selector gets its own tab, in the row under the title bar. Trails found by a scan are only listed in the selector; they get a tab when you open them. A tab reads <number> <title> <freshness>:

Switching tabs reads nothing: no task files, no stored trail, no freshness check. Each tab keeps its last freshness result and the card you last focused in it. Click a tab to switch to it.

Closing the active tab shows the tab to its right, or to its left when it was the last one. Closing the only tab returns to the no trail selected — press s state.

When a scan (s, or Ctrl+R in the selector) finds a newer stored version of a trail that is open in a tab, that tab is updated and its freshness is re-checked.

R keeps watching for the new version after you switch to another tab, and reloads that trail’s tab when the version lands. Only one R refresh is watched at a time: starting R for a second trail stops watching the first, so press d on the first trail once its refresh has finished. Closing a trail’s tab stops the watch for that trail.

Not available here

These keys belong to the board’s By-Trail view and do nothing in ait trails:

Shortcut scope

The trail keys are the board’s own shortcuts: ait trails registers under the board scope and uses the same bindings, so an override such as

shortcuts:
  board:
    trail_select: o

in aitasks/metadata/userconfig.yaml rebinds the key in both ait trails and the board’s By-Trail view. p works the same way: shortcuts.board.pick_task rebinds pick in ait trails and everywhere in the board.

The ? editor inside ait trails lists the board rows this TUI uses — the trail keys, p (pick), navigation and quit — plus the shared actions. To rebind a key that only the Kanban board uses, open the editor from ait board or use Settings → Shortcuts.

Launch and environment

• Task directory — read from TASK_DIR (default aitasks).
• Read-only — the TUI never writes a trail, a task, or board_config.json; a project without a board configuration file is left without one. T, R and p launch code-agent workflows, and those workflows write only after their own confirmations. L may start a tmux session for another project and open a trail in its ait trails, but writes nothing.
• Jump target — inside the aitasks tmux server, a running ait trails accepts a trail sent by an L jump from another project and switches to it, opening a tab when the trail is not open yet. When several run in that session, only one of them — the first in window order — receives it. If a dialog is open at that moment, the trail opens when the dialog closes (Trail <handle> opens when this dialog closes); an open trail selector is closed instead.
• Separate selection — the open tabs are independent of the trail the board’s By-Trail view shows; switching TUIs does not carry them across, and they are not kept when you quit.