What aspects of the development department should be documented?

Question

Documentation

I am interested in what points should at least be documented in the development department, so that when a new employee appears, provide a document for review to be poured into the project. Or use it as a reference document when making a decision when introducing any new features.
For example, you need to document:
1. Deploy
2. Raising hosts (for example, I encountered the fact that hosts on dev are cardinally raised in different ways to production, the result is a waste of time)
3. Syntax agreement
4. Project structure (for granted)
5. The work of individual scripts that solve problems, for example, with database synchronization.
6. The nuances of working with the application admin panel
What else needs to be documented as instructions for action?
I would also like to add this question to the treasury of information for this question . CI scheme for building and publishing projects, right?

Answer 1

The more, the better (your points are more than suitable), but without fanaticism, so that work does not turn into reading christomathies.
Where can there be plugs or difficulties - I wrote instructions for local deployment while installing the company's projects for 2 weeks - maybe 3 out of 4 projects with plugs and the help of
was required ,
it is not required , and what is not possible (due to religion or rahdolbaystvo) to test, but it is important to pay attention

Answer 2

stack used in your developments
minimum versions, rules for loading other people's frameworks, plugins and fonts
if you check the code for safety, then the process and terms

Answer 3

It is a sin for the development department not to strive for self-documentation. Your department is growing so fast that there is no time to explain to a newcomer in tech. a couple of hours how is everything arranged? Or do you have a development / deployment process poured out of granite, what kind of obsolescence / updating documentation do you not take a steam bath?
1. Jenkins Pipeline (or Gitlab) - an example of a self-documenting deployment
2. similar to point 1
3. There are already a bunch of ready-made ones, just give a link
4. Show and explain verbally to immediately remove possible questions / criticism / misunderstandings
5. The only thing that makes sense document (which rarely changes) - architectural features. Each script must either have comments inside it, or the code must be self-documenting. If you need to describe the "glue", then why not use Ansible / Chef for these purposes?
6. "Never press that red button..." - you know what followed.