Life used to be simple.
Client wrote down what they wanted, programmers translated it to code, testers validated that against what clients had written down.
Now we have tickets, where BA's (but most of the time developers, really) write down the lore that is told in numerous meetings.
Tickets are supposed to be ephemeral but never really aren, that's why we keep some of the lore in Wikis. Except Wikis are good for text, not so good for everything else, that's why the lore spreads to Figma, Excalidraw and Google Sheets (if you are lucky, xls documents on Sharepoint if you are not).
Now we start coding. Some of the lore get's solidified into code, which is good, some turns into tests which is good too, if you are lucky some turns into formal spec a tool can check.
But, there is always something left that gets spread evenly - more or less - across regular comment, doc comments, commit messages and various md files, most notoriously the README.md.
Which brings me to user documentation which again is often spread over the whole oeuvre of documents and systems we mentioned. Not to mention the confusion of most documentation about its intended target group. Is it for user documentation for the user really? Rarely!
Oh and then changelog that really wants to be release notes, but isn't, at least not entirely. Which is generated automatically, but isn't, at least not entirely.
> The gods confound the man who first found out how to distinguish hours!
And then you get enterprise search to tie them all. Slap an MCP on it and all your tools can talk to each other again.
> Client wrote down what they wanted
I have never seen this. Most of the time clients don't know what they really want.