# Recover and Document — the paste-into-your-AI workflow

**How to use this file:** decompile your build first (see README.md for the
route). Then copy everything between the lines below into your AI chat, and
attach or paste the recovered code (in chunks if it's large — the prompt
handles that). The AI does the reading; you get back two documents that make
the project yours again.

**The fence:** this workflow is for software **you own or are authorized to
analyze** — your own builds, work you're permitted to do, open-source, or
legitimate security research. The prompt itself carries the fence; keep it in.

---

Copy from here:

---

You are helping me recover a project from its compiled build. I own this
software / am authorized to analyze it. The source code is lost or stranded;
what I have is decompiler output — real logic, but with generic names
(variables like `var3`, functions like `FUN_00401230`) and no comments.

Work in three passes. Do not skip ahead.

**Pass 1 — Inventory.** List every file/class/function in the recovered code.
For each: its decompiled name, its size, and one line on what it appears to
do. Do not rename anything yet. Mark anything you cannot classify as UNKNOWN
rather than guessing.

**Pass 2 — The map.** Write `program-map.md` in plain language:
- What this program is for, in two sentences a non-programmer would follow.
- The main parts and how they connect (what calls what, what data flows where).
- Every constant that looks like a rule of the program — prices, rates,
  thresholds, limits, timeouts, file paths, URLs, format strings — quoted
  EXACTLY as it appears in the code, in a table: value | where it appears |
  what it most likely means.
- Every string the program shows a user, quoted exactly.
- Entry points: where the program starts, what inputs it takes.

**Pass 3 — The reconstruction.** Write `reconstruction.md`: a spec a fresh
build session could continue this project from. Structure: purpose; parts
list (for each part: job, inputs, outputs, the rules/constants it enforces);
data shapes; open questions. Where you infer a name for something the
decompiler left generic, propose the name but tag it [INFERRED]. Where
behavior is unclear from the code, write OPEN QUESTION — never invent
behavior to fill a gap.

Rules that bind all three passes:
- Quote code values exactly; never round, tidy, or "correct" a constant.
- Distinguish three kinds of statement and label them when it matters:
  IN THE CODE (you can point at it), INFERRED (your best reading), UNKNOWN.
- If the recovered code is too large for one message, say which chunk you
  need next and keep a running inventory; never pretend to have read a part
  you haven't seen.
- If any part of the code appears to be third-party library code (not the
  project's own), say so and summarize it in one line instead of mapping it.

When all three passes are done, finish with: what could NOT be recovered
from the build (names, comments, structure the compiler erased), and what
you would need from me to close the remaining OPEN QUESTIONs.

---

Stop copying here.

---

## What you do with the output

- `program-map.md` is the document you read. It's also what a helper, a
  collaborator, or a future you reads to understand the lost project in
  minutes instead of days.
- `reconstruction.md` is the document a build session reads. Dropped into a
  continuation or rescue flow, it stands in for the missing spec/state: a
  fresh AI session can rebuild or extend the project from it without ever
  having seen the original source.
- Keep both next to the recovered code. The recovered code is evidence;
  the map is the explanation; the reconstruction is the way forward.