# Norms for rules

Because rules are source code or shell commands, they don't come with a lot of
built-in guardrails.  Rules are expected to behave themselves, which in a nutshell means:

* Rules should be idempotent
* Regarding files in repo
  * Only modify (or create or delete) files under the working dir they're started in
  * Only read the files they declare as inputs (regardless of scope)
  * Only write the files they declare as outputs (regardless of scope)
* Regarding **external** state (that is, outside the repo including state held
  in other services or elsewhere on disk)
  * Read whatever external state you want
  * Write external state only when the env var `ICK_APPLY` is set -- this disables
    much of the parallelism in the name of getting the semantics right, because
    we don't know if there's a way to undo.

Ick promises that once a rule starts running, the working copy won't be further
modified **by ick**.  You might have multiple simultaneous runs of the same
`scope=file` rule in the same working copy, if there's reason to.