Blocks are the plan
Before the week starts, block time against a project. That block is a commitment made while you still have perspective — not a reconstruction assembled on Friday from memory and optimism.
Blocks are deliberately coarse. The aim is an honest claim about which project gets which evenings, not a calendar simulation of a day that never happens that way.
Evidence, in order of strength
Tracked work is the first evidence: it says you were in the app, on that project, for that long. It is real, and it is also the easiest kind to flatter yourself with.
Commits are the strongest evidence. Once a repository is connected, DevDeck reads pushes and knows something was actually produced — not merely that time passed with the project open. Evidence you did not have to remember to record is the only kind that survives a busy week.
The gap is the product
Plan-vs-actual puts the two side by side per project. Four blocks planned and one evening of commits is not a bug in the tool; it is the fact the tool exists to show you. Most planning software quietly discards the plan once the week is over, which is precisely when it becomes informative.
The screen is meant to be uncomfortable occasionally. A week where plan and actual match perfectly usually means the plan was written to be met rather than to be useful.
Reminders
Blocks can carry local reminders. They are prompts, not guarantees: notification permissions, battery optimization, a device restart or a time-zone change can delay or drop one. Nothing in DevDeck should be the only thing standing between you and something time-critical.
Where it stops
DevDeck does not score you, does not compute a productivity rating and does not report anywhere. It shows the plan, shows the evidence, and leaves the conclusion to the person who made the plan.