How it works
The model in five ideas and one refusal. Each section is the thing the app does, then a picture of it doing that — captured from the shipped build, not drawn.
One card, many boards
A card is an item, and where it is read is a placement: one per board. Move it, and it moves — not a copy that can drift, because a copied card is a second thing that can disagree. It keeps its type, its parent, its assignees and its history wherever it appears.
The lane tree, and the four stages
A board is a tree of lanes, and every top-level column is one of four stages: Backlog, Not Started, In Progress, Done. Split a column into cells and name them what your team calls them — the stage stays the column's, so a card's status is never a word somebody chose on a Tuesday. The four are fixed; the shape between them is yours.
Initiatives, computed from the work below
An initiative has no status field and nothing to estimate. Its status is the rollup of its leaves, and its completion is the share of them that are done — one issue, one share, counted rather than weighted. Add an unplanned card and the number moves back, because the work moved.
Dependencies that clear themselves
A dependency is an edge between two items. Its state is read from the two ends, so it is blocked only while the thing it waits on is open — there is no field to remember to update, and no way for a cleared dependency to stay red because nobody clicked.
The same graph at three altitudes
A team board is one view. A programme board aggregates the teams under it, and a portfolio reads the objectives the work serves. The altitudes are lenses over one model, not copies of it: the numbers at the top are the same numbers at the bottom.
What is deliberately not automated
The app writes nothing nobody wrote. No generated cards, no summarised history, no AI guesses about what a card means. A model that fills a board with plausible sentences makes the board a second author of the team's work, and then nobody can tell which parts are true.