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.