MVP Abstract Generator

You are a senior engineer documenting the journey of a finished MVP. Your task is to create an `abstract.md` file at the project root that captures NOT the final state of the code, but the path that led there. Think of it as the older, wiser sibling of CLAUDE.md: it preserves context, lessons, and dead ends so future contributors (human or AI) understand WHY the code looks the way it does.

### PROJECT CONTEXT
{{Project Context: if used in an AI agent use the current project}}

### TARGET AUDIENCE
The document will be read by: {{Audience: Future Me, A New Developer, An AI Coding Agent, Stakeholders}}
Match the tone, terminology, and level of technical depth to this audience.

### LEVEL OF DETAIL
{{Detail Level: *Deep Dive, Balanced Overview, Concise Summary}}

### INSTRUCTIONS
Analyze the entire codebase, commit history, comments, TODOs, deprecated files, and any existing documentation. Then produce an `abstract.md` with the following sections:

1. **What This App Does** — A plain-language description of the MVP's purpose and core value proposition. No marketing fluff.
2. **The Original Vision vs. What Shipped** — How the initial idea evolved. What was cut, what was added, what changed direction.
3. **Architecture As-Is** — A short, honest description of the current architecture, including the parts that are clean and the parts that are duct-taped.
4. **What Was Tried and Failed** — Concrete approaches, libraries, frameworks, or designs that were attempted and abandoned. For each, explain WHY it failed.
5. **Dead Ends and Rabbit Holes** — Specific problems that consumed disproportionate time. Include what the trap looked like and how it was escaped (or worked around).
6. **Key Decisions and Trade-offs** — The 5–10 most consequential decisions, each with the alternatives considered and the reasoning behind the choice.
7. **Known Debt and Smells** — Code, structure, or dependencies that work but should not survive a rewrite. Be brutally honest.
8. **What I Would Throw Away** — If starting fresh tomorrow, which parts of this MVP would not make it into v2, and why.
9. **Lessons Learned** — Hard-won insights, both technical and product-related, that should not be forgotten.
10. **Open Questions** — Unresolved problems, untested assumptions, and areas where the team flew blind.

### STYLE
- Use first-person singular ("I") or plural ("we") consistently.
- Prefer short paragraphs and bullet points over walls of text.
- Cite specific files, commits, or modules where relevant.
- Do not sanitize failures. Dead ends are the most valuable part of this document.

### OUTPUT
Write the final result directly to `abstract.md` at the project root. Do not return the content in chat — create the file.