Context
The team already believes that a rule without a blocking check is a suggestion. What is usually missing is the same standard applied to the rules governing the work itself, rather than only to the code.
A project where CI decides what is acceptable
Integration is gated, and a claim about the code is expected to have a test and a pipeline behind it.
Fits when
- A completion claim should require verification that actually ran, with its exit code recorded
- Public capability claims are expected to name their implementation and their test
- The pipeline must fail when a declared rule stops being invoked
Does not fit when
- Checks are advisory by policy and a red pipeline is routinely merged past
- There is no CI, in which case the lifecycle commands still work but the last link of every chain is missing
Both lists are required. An entry declaring only what it fits is refused by the generator and by majordomus doctor.
What you would do here
- Decide whether finished work is actually finishedEvaluate a contract line by line instead of accepting a sentence that says the work is done.described finish · question · check
- Prove a rule is actually enforced, not merely written downAnswer "is this rule real?" with a command rather than a reading of the source.described doctrine · doctor · check
- Prove the tool is fast, not assume it, and refuse a regressionMeasure every public command and every capability of the executable against a committed baseline, and let the check fail on a regression rather than a reviewer noticing later.described bench · doctor
- Add a use case and let the tool prove itScaffold a draft for an uncovered command, validate it, run its scenario against the real tool, and see the coverage move.described usecase · doctor
- Check the version before trusting a diagnosisPrint the version every other surface derives from, and see the argument it refuses.described version
- Keep the plan as milestones and issues the tool can validateDeclare milestones as outcomes and issues as execution contracts, and let the tool say what is ready and what is blocked.described plan
- See which rules apply here and what enforces themList the effective rule set, read one rule as the tool reads it, and see which of them the tool enforces and from where.described rules · doctrine
- Block acceptance on a question nobody has answeredOpen a question against the task, watch finish refuse completion while it is unresolved, resolve it with the answer, and only then complete.described question · finish · check
- Complete an issue only when its evidence existsSee an issue refuse completion while a required piece of evidence is missing, read the roadmap the milestone state derives, and keep the GitHub projection a projection.described plan
- Gate CI on the tool itself, with an exit code that is a contractRun the checks CI runs, read every finding with the command that reproduces it, and rely on exit codes that mean one thing each: no code means warn and continue.described doctor · watch · doctrine · check
- Trust the policy and the profiles only after they are validatedProve that the canonical policy parses with every key it needs declared, that every profile parses and the default exists, and that what the policy declares as enforced is what actually runs.described doctor · check