I somewhat doubt the "fairly mechanical" claim. I think when you actually turn it into real programming language code, that's when lots of the edge cases become apparent and then you will face a lot of new questions, that the natural language or the pseudo code didn't cover.
I think those are mostly technical issues (accidental complexity) and those are either documented or there should be someone experienced with the technology on your team (even if that experience came from trying it out).
Critical thinking is essential for nailing down your essential complexity (the core solution of the problem). You can try to define invalid and edge cases alongside the happy path in the pseudo code diagrams version, even if it's a TODO comment.