# Project Retrospectives

Store one retrospective per project, experiment, or substantial design cycle.
Do not append unrelated projects to one large file.

## Recommended Structure

```text
project-root/
├── AGENTS.md
├── README.md
├── MATLAB_STYLE.md
└── retrospectives/
    ├── README.md
    ├── YYYY-MM-DD-short-project-name.md
    ├── YYYY-MM-DD-short-experiment-name.md
    └── ...
```

Example:

```text
retrospectives/2026-07-29-dg5000-pro-demo.md
```

Use a new file when the work has a different technical goal or a substantially
different set of decisions. Update an existing retrospective when continuing
the same design cycle.

## What to Record

Capture design judgment rather than the complete code:

- the challenge;
- an attempted approach;
- why that approach was unsatisfactory;
- the resolution that worked;
- the reusable lesson;
- important limitations or project-specific details.

Short code excerpts are appropriate when they make a method clearer. Do not
copy an entire program merely to preserve context.

## Reuse

At the end of a project, ask an AI coworker to review the code changes and the
retrospective together. Broadly useful and verified lessons may then be
promoted into:

- `MATLAB_STYLE.md` for general MATLAB working practices;
- `references/MATLAB_SIGNATURE_METHODS.md` for distinctive analysis methods;
- a project `README.md` or `AGENTS.md` for hardware-specific behavior.

Retrospectives remain the historical explanation of how and why a decision
was reached, even after a condensed lesson is promoted.
