The run contract

Detection by execution is right the vast majority of the time. The run contract is what you reach for the rare time it is not, without dropping to a Dockerfile.

What it is

When an app goes green, its resolved plan is promoted to a user-editable contract: the app’s kind, runtime, run command, environment, backing services, build steps, and static directory. You can view it in the app and, if the platform inferred something wrong, correct it.

How it behaves

• It is keyed by the app name, so a fix survives redeploys of new code versions.
• It sits at the top of the resolution ladder: an applied contract is used before the frozen plan, the rules, or the model.
• It is re-validated on every deploy. If a later code change breaks the pinned contract, the platform says so and falls back to fresh detection rather than shipping something broken.
• Applying a contract pins the kind deliberately, so the platform trusts your declaration instead of re-classifying.

When to use it

• The wrong kind was inferred (e.g. your job was classified as a worker).
• The run command needs an extra flag or a different entrypoint.
• An environment variable must be set at launch.
• A backing service you need was not detected.

Clearing it

Clearing the contract removes the override and drops the frozen plan, so the next deploy re-resolves purely by detection, as if you had never touched it.

You can edit the contract from the app UI, and the Jollop agent can apply one for you in natural language.