These are two related concepts designed to keep experimental work separate from critical tasks.
Scratch projects
A scratch project is a standard project you plan to discard later. Use one to trial Coroid on an unfamiliar codebase, test a policy change before rolling it out widely, or explore an approach you are not fully committed to.
The main benefit is isolation. Experiments in a scratch project will not affect the task history, metrics or context of projects your team relies on.
Delete them once you are finished. If a scratch project persists for six months, it has quietly become a proper project, without the necessary configuration care it requires.
Preview environments
A preview displays your updated application in action, built from the branch generated by a task.
This is important because some aspects cannot be judged just by viewing a diff. Whether a page renders correctly, whether a workflow functions end to end, or whether a change looks right — these can only be confirmed when the app is running.
Previews are what browser tests run against, and what reviewers open when a screenshot alone cannot settle the matter.
How previews reach your pull request
If you already have preview deployments — from your hosting provider or CI — Coroid can link them as review evidence, so the link appears alongside the change rather than requiring you to search for it elsewhere.
The aim is to ensure verification evidence and the code it relates to 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 work together: a scratch project can include previews just like any other project.