I usually work on infrastructure as code, and I usually swap out the third layer of the design for the first layer of the implementation. You need a fully-specced functional design and a high-level technical design, but I've found that in many cases the technical implementation details can change as the project is developed, and that means either the low-level technical design and the implementation go out of sync, or there a heavy bureaucratic process in place to prevent that -- but the natural solution is to have the low-level design and the high-level implementation to live in the same place.
That still requires the rest of your process, and perhaps even places more emphasis on those documents. The infrastructure implementation needs to follow from the high-level technical design which needs to follow from the functional specification. Because as you say, the implementation needs to be reviewed against a specification. What are you reviewing if the spec is incomplete?
I see the third section as more of a feasibility assessment and for people to comment on whether the technical design is sufficient and extensible or to look for alternatives. It's ok if the design diverges from the implementation but I'd still look for it in a design review so people can point out any flaws or security/scalability issues proactively.
1. If you're a developer, then you're probably using sqlite to store data and having a GUI for checking/modifying the database is probably handy.
2. Most application by other developers (even massive companies) use sqlite to store data under the hood even if the file doesn't appear to be named `.sqlite`. So if you want to tweak certain settings that aren't exposed to the end user, then you can use this to do that in a more user friendly way rather than crack out a command line tool for sqlite changes.