Per repository, never per account
DevDeck connects through a GitHub App that you install on specific repositories. It is not an account-wide OAuth grant, and it does not enumerate everything you can see. You choose the repositories; GitHub enforces the boundary; you can revoke it from GitHub at any time without opening the app.
This is a deliberate constraint rather than a limitation waiting to be lifted. A planning tool has no business holding a key to every repository you have access to, including the ones that belong to an employer.
Read-only means read-only
The integration reads pushes. It does not commit, branch, tag, open pull requests, comment, or change a setting. Nothing DevDeck does can alter the contents of your repository — which also means nothing it gets wrong can.
Naming a task in a commit
Put the task id in the commit message. DevDeck records the link between that commit and that task, and closes the task the commit finished.
This is the load-bearing habit of the whole product. The commit link is what gives plan-vs-actual its evidence and what release notes are drafted from. An id left out of the message is not a small omission — it is a task that never closes and work that leaves no trace in the version it shipped in.
Why commits and not a timer
A timer records intent. A commit records output. Both are useful, but only one of them is still true a week later, and only one of them cannot be produced by leaving an app open on a second monitor.
Where it stops
DevDeck does not build, test, deploy or publish anything. It reads what landed and maps it onto the plan. Whether the commit was any good remains, as always, between you and code review.