Docs and tests are part of done

A change is finished when the docs, the tests and the whole suite agree with it. A change that leaves any of them behind is not finished.

Every change

Find the pages you affect. List the docs pages that describe the files you changed:
```
npm run docs:affected
```
It compares your work with dev (or the base you name with --base) and prints each page whose docs:sources overlaps a changed file.
Read those pages and fix what is now wrong, in the same change. If a screen changed, retake its screenshots. If the change adds something a developer or an admin will meet, add it to the page where they would look for it, or write a new page.
Say what happened in your report: which pages and screenshots changed, or why none needed to.
Add tests that would have caught the break. A change to behavior gets a test of that behavior. A change to something the docs list (a script, a feature, a config key, a function) gets, or already has, a docs check that fails when the list and the code disagree.
Run the whole suite:
```
npm run test
```
It type-checks the app and the functions too, which the specs alone do not: a change that passes its specs can still fail the production build. npm run typecheck runs only that check (see Type check).

When security rules changed, run the rules tests as well:
```
npm run test:rules
```
If anything fails, the change is not done. Fix it, or report it as unfinished with the failing output.

docs:affected only knows the pages that name a file in docs:sources. A change that no page names can still matter to a reader. When you add a file, a folder, a script or a setting, also check the page for the area it belongs to, and add the path to that page's docs:sources.

Running only the docs checks

While you write a page, the docs checks are quick and run on their own:

npm run check:docs

See Writing docs for what they check and how to add a page.

In an app built on Arc CMS

The same rule applies to the app's own work. The app's pages live in docs/custom/, and the rest of docs/ is core and is not edited in an app. A change that the core docs do not cover is a sign the app needs something core does not offer yet: say so, so it can become a general feature.