# where this comes from

this is a personal handbook built from using coding agents on real repositories,
then checking the product details that can change underneath those experiences.
examples support the tips. they are not a badge of authority.

## what i actually use

i link the repository, commits, screenshots, failures, and source material that
shaped a recommendation when those receipts are useful. some advice comes from
repeated use. some comes from an official product update i have not reproduced
yet. the label beside the source list keeps that distinction visible without
taking over the page.

## how current claims get checked

date sensitive product claims begin with an exact date. the source registry
points to official documentation, release notes, repositories, and papers. a
weekly read only check looks for upstream changes. a person still reviews the
meaning before public copy changes.

| label | what it means |
|---|---|
| tested | i reproduced it in a named environment |
| official source | the current product documentation or source states it |
| analysis | this is my conclusion from the examples shown |
| open question | the current evidence is incomplete |

## how tested claims are recorded

when i mark a claim as tested, i keep the task, pass condition, environment,
result, and limitations close enough to inspect. incomplete testing remains an
open question. a product claim stays labeled as an official source until i have
reproduced the behavior myself.

## what this does not settle

one successful task does not establish the best agent, model, or workflow.
vendor benchmarks describe a release under their own conditions. the guidance
here becomes stronger when the same practice survives different repositories,
machines, and failure modes.