Documentation / Getting started

Opening a card

Cards are the live processes of the board — terminals, browser, files, notes, media. There are two doors to create them.

A card is where the work happens: a live process on screen, with a PTY, that dies when you close it. Opening a card has two doors.

The rail

The left rail is the linear door. Each button creates the corresponding card on the board, at the point the canvas works out. It is the direct path when you already know what you want.

The radial menu

Right-click on the canvas background — or tap and hold, on touch — opens a radial menu at the clicked point. Besides creating the card there, the radial switches tools without dropping the pointer.

The card types

Each kind has its own component, and all of them share the same chrome for moving, resizing, selecting and stacking:

Card What for
terminal a real process behind each card
browser a page embedded in the canvas
files explorer of the working directory
changes git status of that directory
note a message on the board, with color as category
media image or PDF attached to the canvas
drawing freehand stroke
chat multi-provider conversation
remote window control of an external OS window

Adding a new type requires no database migration: the kind is loose text in the schema, so a card of an unprecedented type keeps opening old boards.

Close, archive, delete

Closing a card archives it: the row leaves the board (which filters out archived ones) and stays in the database. It is that row that carries the label, the kind and the link to the board — and it is what sustains the reports, the participations and the verdicts that point at that card. Before this, the close gesture erased the row, and what survived became an anonymous orphan: out of 236 ids that no longer existed in cards, 423 reports from 134 cards remained — with no name to show, because the label existed only there.

Only an explicit request deletes: an agent’s delete_card, or the owner’s action on an already archived card. Closing, by itself, was never a request to destroy anything.

An archived card can be restored, and the app says what comes back: the session resumed by the resume_id, or the card back without a process. The archive list opens from the session popover in the Topbar, shows kind, label or id, provider and when it was archived, and the delete asks first — naming what goes (the card, the connectors, the close trail) and what stays (tasks, reports).

The card’s screen is not saved by default. What stays is the identity and the registry facts: when it died, whether it died from quota, whether the kill was requested. Metadata is not screen, and the reason is one of regime: the screen is a real work screen, with paths and code excerpts, and persisting that shifts “ephemeral pixels on your monitor” to “durable text, read by any agent that can open the board database”. Persistence, when enabled, comes with secret redaction — but the redaction is by pattern, not by semantics, and whoever enables it takes on the burden.

The task chip in the header

The card header shows, live, that card’s task links: role and short id, at most two inline, with +N for the rest. Zero links draw nothing. The chip is a button — clicking opens the task in the Queue, when it exists in the loaded board.

Duplicate and rename

Ctrl+D duplicates the selected card on top, with the same provider and the same directory. 2×click on the header tag renames. The full list is in Shortcuts.