Conditions:

• stable legacy prod system
• no Software Devs of the system are available anymore
• app is maintained by technical users, such as DevOps Engineers, who have limited Software Dev experience in general and none for that specific system
• there are issues requiring debugging of the code
• not enough documentation usable for debugging and maintenance purposes of is available
• code repository is the only reliable source of technical documentation for this case
• only limited effort to improve documentation for this system is allowed (something like 80/20 rule)
• format of the solution needs to be "portable" enough so that it can also be applied to other projects with the same conditions
• solution needs to be able to not lose its value with time. When it is applied to a non-legacy system, it would still be sufficient, once it becomes legacy

Question:

What specific tools, practices, or methodologies that have been successfully implemented in similar legacy environments can be used to create and update technical documentation to be minimal yet effective, when limited by all of the above conditions?

So far the below is the best method I managed to come up with:

• gradually go through each file
• try to understand what it does
• apply the Scout Rule ("leave everything cleaner than you found it") like described in https://softwareengineering.stackexchange.com/a/137953/440463 AND put a header on top of each source code file like described in https://stackoverflow.com/a/49438334/3853744 basically shows a "table" with various metadata about the source code file written as a text on top of the file, containing among others creation date, description, affected, usage and parameters, summary of changes with time, author and comments)
• Put a README file in the top level directory of the core repo, which will inform how to navigate to find the technical documentation in that repo
• Put another txt file in each "major" directory of the code repo, where any other technical info is placed, if it does not belong to just one source code file header
• Since it is undesired to have long comments surrounding actual source code, use some sort of "KB1234" or "0x12345" numbers for the role of tags or labels in the text files and source code for each major component. It will allow to quickly find things that are related, for example with grep. These have to have a format that is unique enough that it does not generate too much incorrect finds

Background context, can be ignored if doesn't help with the answer.

My experience tells me that Do not rely on links from source code to Jira or Confluence. The limited documentation that was present was in the form of links from source code to Jira and Confluence. Unfortunately, all links stopped working, after these have been migrated from on-prem to cloud which made them extremely time consuming to find by hand because of for example the following: DependenciesCheck.sql was an abomination and should be called DoItAll.sql instead.

Since it is legacy, bringing the documentation in line with current trends and best practices is unfortunately not an option here as only limited effort will be allowed to be put into it, making the unfortunate reality that the source code repository is the only reliable place with any technical documentation for it.

Update: Reformatted the text to improve clarity