Write an onboarding guide to your codebase for new engineers

Write an onboarding guide to our codebase for engineers in their first two weeks on {{team}}, so that a new engineer can run the system, find their way around the code and ship a first small change without having to ask the basic questions.

The repository's folder tree, two levels deep:
"""
{{folder_tree}}
"""

The README and any architecture notes:
"""
{{docs}}
"""

Setup steps that work today, as the team runs them:
"""
{{setup_steps}}
"""

How we work (branches, reviews, tests, deploys): {{how_we_work}}
Who to ask about what, by area (handles as the team uses them, or roles): {{contacts}}
Good first tasks, if we keep a list: {{first_tasks}}
Internal terms a newcomer will hear: {{terms}}

Use these sections, with Markdown headings:
1. What the system does, in 3 or 4 sentences.
2. Architecture: the main parts and how a typical request or job moves through them, as a short text diagram followed by one line per part.
3. Where things live: a table with the columns Folder, What is in it, How often new engineers touch it.
4. Run it locally: numbered steps, only from the setup steps above, with the commands in code blocks.
5. How we work: branches, reviews, tests and deploys, from what I gave.
6. Your first week: up to 5 first tasks from my list, smallest first.
7. Who to ask: a table with the columns Area, Who, Where.
8. Glossary: up to 10 internal terms, one line each.

Keep it under 1,200 words, not counting code and tables. A good guide is one a new engineer still keeps open in their second week, because it is short and every command in it works.

Do not invent folders, commands, services, people or rules; describe only what the material shows. Do not include passwords, tokens or internal links that are not in the material. Leave out general advice such as "ask lots of questions".

If the purpose of a folder is not clear from the tree and the docs, list it in the table with [ASK: purpose] rather than guessing from its name. If the setup steps and the README disagree, follow the setup steps and note the difference at the end for the team to fix.