Project-defined stages, declared in .quality.exs under custom:.

A project with a house check, a schema linter, a custom mix task or a shell script gate could have ExQuality's parallelism, timing, report and printer, or it could have its own check, but not both. Custom stages are the way to have both, and a check that runs inside mix quality is a check the JSON report can route on.

Two layers, one mechanism:

custom: [
  # A command. This is the case most projects want.
  [
    key: :nullability,
    name: "Nullability",
    command: "mix",
    args: ["schema.nullability", "--format", "json"],
    env: [{"MIX_ENV", "test"}],
    kind: :reader
  ],

  # A module, for anything the command form cannot express.
  [key: :house_rules, name: "House rules", module: MyApp.Quality.HouseRules]
]

Every entry is a keyword list with key and name, plus either module or command. Registration data lives in the entry rather than in callbacks on a module so that the config file alone says what a run will contain: a stage that only announces itself once it has run cannot be reported as skipped, and a run that says nothing about a stage reads as a run where the stage passed.

Module entries

module: names a module exporting run/1 and returning an ExQuality.Stage.result(), which is the contract every built-in stage already satisfies. It may also export stage_kind/1; a module that does not is a :reader. See ExQuality.Stage.

Command entries

command: is run by ExQuality.Stages.Command, which documents the options and the JSON finding contract.

What custom stages are not for

Filling gaps in built-in stages. Routing a second mix credo config through a custom command would work and would be a mistake: the output comes back as text instead of per-check findings, and per-check routing is the reason the JSON report exists. If a built-in stage cannot express something its tool supports, that is a bug in the stage.