Why Kyndium keeps one record per task

Open a project in Kyndium and switch between the Board, the Checklist and the Timeline. Nothing loads, nothing syncs, and the task you just moved to Done is ticked in the list and green on the chart. People assume there is a clever synchronization layer behind that. There isn't. There is one table.

One table, one flag

Every task, sub-task, milestone and note in a project is a row in a single work_items table. The row carries everything any view could want: a title, notes, a priority, a start, an end and a due date, progress, completion, an assignee, points, labels and a position. The only thing that says "this is a board card" is one column, the lane it sits in. A row with no lane is a checklist or timeline item. A row with a lane is also a card.

That is the whole trick. The Board shows the rows that have a lane, grouped by lane. The Checklist shows the rows in checklist order, and lists the ones with a lane under a small "On the board" tag so nothing hides. The Timeline shows every row with dates, and draws a marker for rows that only have a due date, because a task that is invisible on one view is a task that gets forgotten.

What it costs

A single row has to satisfy every view, so the table is wide, and every view has to cope with rows that were made somewhere else. The Board needs a place for tasks that have no lane yet; it shows a "Not on the board yet" lane. The Timeline needs to say something about an undated task; it offers a one-click Set dates. The Checklist needs an order for rows the Board positioned; it keeps its own position column and adopts a row the first time you drag it into the list.

Completion is the hardest part. Each view has its own idea of done: the checkbox, the Done lane, the bar at 100%. We made the database own it. The is_complete flag is set by whichever view you used, and a trigger stamps completed_at; application code never writes that timestamp. Moving a card into a lane marked done completes it; moving it out reopens it; ticking it in the Checklist moves the card. Every path ends in the same column, so every view reads the same answer.

What it buys

Nothing drifts. There is no moment where the board says one thing and the timeline another, because there is no second copy to disagree. There is no import step between views, no "sync now", no reconciling before a review.

It also makes the later features cheap. Live updates are one subscription on one table, and every view refreshes from the same row. Imports from Trello, Asana and Jira land in one place and appear everywhere at once. Timeline Studio reads milestones from the same rows and stays linked to them. Filters and saved views apply to the Board, the Checklist and the Timeline with one implementation, because they filter the same list.

The rule we keep

When we add a view, it reads from the table and writes to the table. It never keeps its own copy of a task, even a cached one that is "almost always right". Almost always is how plans drift. The Workload view, the Calendar, the Sprints board and the Activity feed were all added under that rule, and switching between any of them is still just a different way of looking at the same rows.