What an application has to get right before Ithibati works, asked one question at a time.
Something already refuses each of these: Ithibati.Config when a setting is read,
Ithibati.Migration when it builds, Postgres when a ceremony writes. The trouble is when.
Each of those speaks at the first request that needed it, about the one thing that request
touched, in the words of whichever layer noticed. An application can be wrong in three ways and
hear about the first only.
So the doctor asks all of them at once, before anybody signs in, and answers about each. It changes nothing and writes nothing, because every question is a read.
The wording comes from the code that already refuses, because Ithibati.Config.repo/0 and its
siblings raise sentences worth showing. A second set of sentences written here would drift from
the first the day either was corrected.
Summary
Functions
Every question, in order, as {subject, {status, detail}}.
Whether a table's key column is the type Ithibati was configured for, and carries the unique index a foreign key needs to point at it.
Functions
Every question, in order, as {subject, {status, detail}}.
A status is :ok, :error, or :skip. :skip marks a question that could not be asked: an
application with no repo configured cannot be asked what is in its database, and saying so is a
better answer than an exception from three layers down.
app is the application being examined. It is an argument rather than something read here
because nothing in Ithibati can derive it: Mix.Project.config/0 knows, and Mix is not there
in a release. Only the question about routes uses it.
Whether a table's key column is the type Ithibati was configured for, and carries the unique index a foreign key needs to point at it.
This function is public because it is the one question here with an answer worth testing
against a table made for the purpose. examine/1 asks it about the account table.