How each check is made

Nothing refused a file whose object holds one key twice. JSON Schema leaves the behaviour of such a document undefined, so it escapes the check that it matches its schema (§s-eferktypcj7njt5), and a tool reading it keeps the last of the two values alone.

The owner: the check of the specification refuses it, so a commit cannot carry it.

Five checks of the base's table had no row here, so no rule said which command makes them, and several rows did not say all their check does.

The owner: every check of the base's table has its row and its command, the new checks of terms, of names whatever their case and of capitals from three words included, so that the rule on the commands can refer to this table.

The check of data record variants checked a value only where its choosing field held a list of values, so a variant whose field held none passed with any value; nothing held a variant to the domain declaring its value, and the fields a field of type variant holds were not counted among those a variant inherits.

The owner: before the first release, 0.1.0, the tools read such values from the choosing field's own list alone, refuse a value not found there, and hold a variant to the part of the data record holding that field; how a project's own guidelines name another place for such values waits past 0.1.0, and the todo stays. Following the rows of §s-jau82aq9juv9zzh on variants, the row says all the check does.

The check of data record variants read a value from its choosing field's own list alone, held a variant to the part of the data record, and counted no fields of type variant, and no check followed an identifier to the field it takes its type from.

Following the owner's rulings of that day: the row reads the lists rules of domains define for a field of a data record in contracts (§s-xfu2gpzddjnmgks), holds a variant to the part declaring its value, and counts the fields of type variant; a row follows each identifier to the field identifying its data record. The todo on the other place is settled.

No row looked for a field of type one of holding no value, or followed an identifier past the first identifying field.

Following the two rows the base's table of checks gained that day: the identifiers are followed until a field of another type, and the values of each field of type one of are counted.

The row of generated copies did not name the refusal of a listed path that leaves the repository, which the tools make because each path of the list is taken from the root of the repository.

Carrying out the owner's rule on where the generated files are written (§s-pvzms7d8kxb8dk2): the row names that refusal.

The check before an edit did not look at an edit of the confirmations themselves.

Following the owner's ruling on §s-83ev4wwesbwnhnp: an edit of the confirmations' file is refused whatever it changes, sheriff confirm being what records a confirmation and its withdrawal.

The check resolved a test's sid against every node.

Following the owner's ruling on §s-rah8b37kytb682y: a test's sid is resolved against the rules and the terms.

No row said how an exempts link is checked or how a rule not implemented is found.

Following the owner's rulings on §s-6fw72j65jkqrfpf and §s-sn6au3vcr9uy5pm: validate reads where each exempts link stands, and binding reports each checked rule within §s-6fw72j65jkqrfpf lacking a tag or a test, a skipped test not counting.

No row said that the name of a file of the technical appendix is checked against the domains.

Following §s-vj7ercem526zd6v: each file of the technical appendix but the stack's and the technical debt's is named after a domain.

The check compared each kept generated copy with what the nodes produce now, while code generated from the nodes now waits for them to be checked.

Following the owner's ruling on §s-kh8qcd5kxgh9z3j: code generated from the nodes waits until every node it is generated from is checked, no commit changing it meanwhile, and its lag is reported.