iteratelisted

# Iterating A finished cycle is not a finished project. This is how the next one starts **without throwing away what the last one learned** — which is the whole reason the record, the decisions and the audits were kept. ## 1. Is this actually an iteration? Three different things, and picking the wrong one is expensive: | The client says | It is | Do | |---|---|---| | "one more thing" — an addition inside the existing goals | **an amendment** | add requirements to the current charter, plan, build. No new cycle | | "now that I've used it…" — the goals were right and something under them was wrong or missing | **an iteration** | this skill | | "actually I need something else" — the goals themselves were wrong | **a new project** | a fresh charter. Say so; do not iterate a charter into a different product | **The distinguishing question is whether the goals survive.** If they do, iterate. If G-1 has to change to describe what the client now wants, that is a new charter wearing an old one's clothes, and pretending otherwise buries the history of both. ## 2. Read the last cycle before asking anything The client's time is the scarce resource, and most of what you need is already written. Read, in this order: 1. **`CHARTER.md`** — the goals, and what was explicitly out of scope 2. **`checkpoints/`, last first** — especially the final one. What did it say was left undone, and why? 3. **`DECISIONS.md`** — every decision is **still binding** until superseded 4. **`audits/`**