Mirror of https://github.com/roostorg/coop
github.com/roostorg/coop
1{
2 "mappings": [
3 {
4 "paths": [
5 "server/models/**/{ContentTypeModel,ActionModel,RuleModel,PolicyModel}.ts"
6 ],
7 "triggers": ["declare"],
8 "items": [
9 "If you're adding/removing fields from this model, did you update the corresponding history tables and their triggers?"
10 ]
11 },
12 {
13 "paths": ["db/src/scripts/**"],
14 "triggers": ["create table", "add column", "alter column"],
15 "items": [
16 "Are as many columns marked NOT NULL as possible? If some columns can sometimes be null, but _not_ when another column is filled in, have you considered normalizing the schema further (see https://www.guru99.com/database-normalization.html)? If that's not viable/desirable, are there adequate SQL CHECK constraints to capture the relationships between column values (e.g., which can be null together), and are these also captured using unions in the associated kysely types?"
17 ]
18 },
19 {
20 "paths": ["server/services/signalsService/signals/**/*.ts"],
21 "triggers": ["async run\\("],
22 "items": [
23 "If you're creating a new signal, did you check all the potential error cases, and classify, for each one, whether it should be thrown as a permanent error (not subject to retry) or just a normal error (which will lead the signal to being retried and the error value not cached)? **NOTE**: in our data model, any case in which the signal can not determine the score for the provided input should result in a SignalPermanentError."
24 ]
25 }
26 ]
27}