What is the difference between running a ZAP automation plan with -autorun and checking it with -autocheck?

## Two options, one loader The `automation` add-on contributes a small family of command-line options, and two of them take a plan: - **`-autorun <source>`** — run the plan. - **`-autocheck <source>`** — check the plan. They share the loading path entirely. Each parses the YAML, reads the environment, resolves every job's `type` against the registry the installed add-ons filled, verifies each job's parameters, and builds each job's tests. Everything that can be discovered from the file alone is discovered by both. They then diverge: 1. `-autorun` creates the environment — bringing the contexts and users described in `env` into existence — and executes the job list in order. 2. `-autocheck` stops. No environment, no jobs, nothing sent to the site under test. Both then set the exit value from what was recorded: an error gives the error value, a warning with no error gives the warning value, and a clean load or run gives a clean one. ## What a check catches, and what it cannot A check is a **static** verdict on the file against **this build**. It catches: - an unknown job type — that is, a job whose owning add-on is not installed here; - an unrecognised element inside `env`, or an environment with no contexts at all; - a job parameter the job does not recognise; - a test with a missing or invalid `onFail`, or an alert test on a job that cannot produce alerts; - a deprecated job, such as `addOns`, which contributes its warning during verification. It cannot tell you anything that only exists at run time: whether the target is reachable, whether the credentials work, whether the crawl finds anything, whether the run will take twenty minutes or four hours. A plan that checks clean can still scan nothing. ## The source may be a URL The argument is deliberately called a **source**, not a filename. If it parses as an `http` or `https` URL the add-on fetches it and treats the response body as the plan; a response that is not a success is itself a failure of the run. Anything else is treated as a path on disk. Two things follow that are easy to miss: - A plan fetched over the network is **whatever that server returned at that moment**. It is a control file for a tool that attacks a target, so where it comes from is a supply-chain question, not a convenience one. - Relative paths inside a plan normally resolve against **the directory holding the plan file**, which is what makes a plan portable between a workstation and a container. A plan fetched from a URL has no file on disk, so its relative paths fall back to the process working directory instead — the same plan, quietly resolving differently. ## The exit value needs a command-line run The framework sets a process exit value **only when ZAP is running as a command-line process**. Run a plan in the desktop or in a long-lived background instance and it still runs, still reports, still writes its output — but nothing sets an exit value for a pipeline to read. That is why the documented invocation pairs the two, as `-cmd -autorun plan.yaml`, and it is the first thing to check when a pipeline step reports success no matter what the plan did. ## Using them together | step | option | what it costs | what it proves | |---|---|---|---| | on every change to a plan | `-autocheck` | seconds | the plan is loadable and complete on this build | | on the schedule you scan | `-autorun` | the length of the scan | what the run actually found | A repository of plans benefits from the first as a fast gate: plans drift as add-ons change under them, and the failure mode of a stale plan is an expensive scheduled job that stops before it starts. The `-autogenmin` and `-autogenmax` options round out the family by writing a template built from the job types the running build actually registers — the honest starting point for a new plan, and the quickest look at what this build offers. One caution about what either option proves. A check and a run both validate the plan against **the build executing them**, so a plan that checks clean on a workstation says nothing about the image a pipeline uses, and the reverse is equally true. Run the check on the same image that will run the plan, or the gate is measuring the wrong thing.