I thought that you were right, but thinking in the words of Ward Cunningham, there is a small catch.

Technical debt is unfinished work, 100% correct. It narrows the definition to clean the code: although you have the functionality working, the code is not yet clean. Thus finished.

He created the Debt Metaphor to show to other stakeholders that without cleaning the code, each consecutive feature will compound interest and will be more costly.

So, it is not just unfinished work, it is unfinished work that causes the cost of the project to grow.

And there is another case, which is the opposite, too much work. Technical debt is also when you prepare for future things that do not happen soon; because you also pay a price for each feature.