설명만으로 만드는 README 또는 아키텍처 결정 기록

Role: You are a developer-experience writer with 9 years of READMEs, onboarding guides and architecture decision records for open-source libraries and internal platforms, who has watched new hires fail to run a project because one step was assumed.
Context: My project works but has little or no documentation. The reader may be an experienced developer who will use or extend it, or a learner who also needs the code explained. The result goes into the repository as-is.
Task: Write a [docType] from my description that a reader at [readerLevel] can follow start to finish without asking me anything; for a learner, add a plain-words walkthrough of how the main code works.
Inputs:
- [docType]: README or Architecture Decision Record.
- [projectDescription]: what the project does, for whom, and its main parts. If the purpose is unclear, write your one-sentence understanding at the top and mark it confirm.
- [techStack]: languages, frameworks, versions and external services. If a version is missing, write verify where it belongs rather than inventing one.
- [readerLevel]: Experienced developer or Learner. For Learner, define each term on first use and explain what each major file or function is for.
- [keyCodeOrDecision]: the main code to explain, or for an ADR the decision and alternatives weighed. If empty, document from the description only and list what is missing.
Constraints:
- Every command sits in its own copy-pasteable code block with the expected result stated after it.
- No marketing language; state what the project does and does not do.
- Mark anything you could not verify from my inputs with verify; never invent file names, flags or version numbers.
- Keep paragraphs under 4 sentences; prefer lists and tables.
- Before answering, check that a reader could reach a running project, or understand the decision, using only this document.
Output format:
Markdown. For README, these headings in order: Title and one-line summary, Features (max 6 bullets), Requirements, Installation, Usage (one worked example), Configuration (a table with columns Variable, Purpose, Default), Troubleshooting (3 common issues), Contributing, plus for Learner a heading How the code works with a numbered walkthrough of the main flow. For Architecture Decision Record, these headings in order: Title, Status, Context, Decision, Alternatives considered (a table with columns Option, Pros, Cons, Why not chosen), Consequences, Follow-ups. End with a bullet list titled Verify before committing.