If I make a mistake building my web app, then it will either not matter, or someone will notice the bug in production.
And then when someone notices the bug in production, it can be fixed. If nobody notices it, then I guess it wasn't very important to begin with and can be left "broken".
Implementation bugs are the EASY part, and don't matter a lot of the time.
Or here is a better scenario.
Lets say I am writing a feature, and I think of a way to implement the feature much quicker, but isn't 100% "correct" according to the spec. The quick and dirty, but "incorrect" way to implement it may actually be a better thing to do, because now I can spend my time working on other stuff that is more important.
Purposefully doing the "incorrect" thing according to spec, may actually be the right decision.
Your notion of correct does not apply to everyone: for many of my projects, the implementation that goes against the spec but has higher traction is implemented correctly, and the implementation that follows the spec but has lower traction is implemented incorrectly. The spec is just someone's idea of what will have the highest traction - it doesn't make code that follows it correct.
No, you just don't understand the definition of correctness as it relates to software. Correctness -- like safety -- is formally defined. You might want to look it up.
It's both, though. You also can't tell if you've implemented them correctly if you don't have a formal spec.