Engine
5 pages filed under Rules › Engine. A business rule is a condition the business imposes, with what it constrains and what happens when it is broken.
| Business rule | Severity | First line | Links |
|---|---|---|---|
| Accessibility | error | Every screen of the generated site gives a screen reader or keyboard user the same information as everyone else. Five guarantees hold on every page, and the build and the test suite verify them without a browser. | 74 |
| Relation typing | info | Every link between two notes ends up with a relation of the profile, decided on four rungs, the first that applies winning: a mapped section (a business object under ## Objects of a screen is accesses), a typed frontmatter attribute (reads is accesses in read mode), a type pair that admits a single relation (a markdown link or a plain mention between a rule and a screen is constrains, marked relation_origin: pair and turned around when the profile only allows it the other way), then related, kept with its confidence capped at 0.60 and reported by the ambiguous relation check. The first two rungs come from what the author wrote and are never overturned; a declared relation the profile does not allow between the two types is dropped by the relation outside the matrix check. The labels shown for a relation, in either direction, come from the profile alone. The architecture guide and the writing guide describe it. | 47 |
| Operation matching | warning | An operation note attaches to the operation imported from the contract of its API on three rungs, tried in order, the first that matches winning: the operation_id of the frontmatter against the operation identifier of the contract; the method and path pair (or port and the title for a SOAP operation) against the operation's; the title of the note in comparison form, spaces and punctuation ignored, against the operation title or its identifier. The note names its API in the api attribute or through a markdown link; a note that names none is a candidate for every API of its source that declares a contract. | 44 |
| Linter and build parity | error | The local lint says the same thing as the build. For the checks the linter computes in --scope repo, listed as LOCAL_CHECKS by the lint package (E-ENCODING, E-FM-INVALID, E-ID-DUP, E-ID-INVALID, E-LINK-BROKEN), concordance lint on a repository and concordance build on a configuration that declares it as a source produce the same findings: same check, source, path, line and entity, same severity, message and remediation. The build reports more, never less: the checks that need the whole model only exist there. | 35 |
| Disabled plugin | warning | A declared plugin needs a system tool that is not installed on the machine that builds: the build ran the detection command of every system dependency of the manifest, one answered nothing, and the plugin was not registered, so that none of its readers, converters, sources, inference methods, checks, projections or components took part in the build. An optional dependency yields the same finding as info and the plugin stays registered. The fix is the tool on the PATH of the build, or the plugin removed from plugins:; a project whose conversions must run raises the severity to error. | 20 |
5 engine of 5 — pagination by twenty. The Links column counts the related pages, which brings the most central engine of the journey to the top.