code-teardownlisted

# Code Teardown Reads someone else's codebase to answer one question: what do they do that WE should do? Same contract as `app-teardown` (live apps); this one targets repos and reads code. Output is a decision artifact with verdicts, not an architecture tour — for "how does X work" documentation use `doc-and-modernize`. ## Use When - An external repo should be mined for architecture/pattern/DX/tooling ideas for one of our projects. - User names a repo, OSS project, or codebase and asks what to learn, adopt, or steal from it. - Evaluating a trending project ("should we care about X?") — the negative outcome is captured too. ## Do Not Use When - Target is a live product to browse → `app-teardown`. - You will contribute to or modify the target repo → `adt-repo-intake`. - Documenting OUR OWN system → `doc-and-modernize`. ## Inputs / Prereqs - Target repo (URL or local path). Clone shallow to `${DEV_ROOT}/<repo>` (storage policy; never `$HOME`, never internal disk). - OUR context lock: which project the ideas land in, its stack and constraints. - Memory state-check FIRST: `reference_<target>_evaluated_*` exists → surface prior outcome and stop unless the revisit condition is met. - Target is read-only: no issues, no PRs, no edits there. ## Workflow 1. **Scope + constraint capture** — why does their design work FOR THEM (scale, team size, ecosystem, age, funding model)? Record upfront; feeds the cargo-cult gate. 2. **Shallow clone + intake sweep** — `git clone --dep