Two related ideas that both exist to keep experimental work away from work that matters.
Scratch projects
A scratch project is a normal project you intend to throw away. Use one to try Coroid against an unfamiliar codebase, test a policy change before applying it broadly, or explore an approach you are not committed to.
The value is isolation. Experiments in a scratch project do not pollute the task history, metrics or context of a project your team relies on.
Delete them when you are done. A scratch project that survives six months has quietly become a real one, with none of the configuration care that implies.
Preview environments
A preview is your changed application actually running, built from the branch a task produced.
This matters because some things cannot be established by reading a diff. Whether a page renders correctly, whether a flow works end to end, whether a change looks right — these need the thing running.
Previews are what browser tests run against, and what reviewers open when a screenshot would not settle the question.
How previews reach your pull request
Where you already have preview deployments — from your hosting provider or CI — Coroid can attach them as review evidence, so the link appears alongside the change rather than somewhere you have to go looking.
The point is that verification evidence and the code it verifies should arrive together.
When to use which
- Trying out Coroid, or an approach you may discard → scratch project
- Checking that a specific change behaves correctly → preview
They compose: a scratch project can have previews like any other.