The analyzer reads one file at a time and reports what it can prove from it. Four checks cannot be made that way: each one needs several files open at once, or a judgement about what a piece of code is for. Nobody makes them unless you do.
They are not written as rules for that reason. A rule that can never run is a rule that reports nothing, and a silent rule reads as a rule that passed.
Make them when you write or review code in the area they cover — and when you have made them, say that you reviewed them. A review by a person is never reported as an analyzer pass.
Reuse an existing component before writing one
Duplicated markup looks exactly like original markup, so it is only found by looking.
Before writing a view, search the project's components for one that already renders what you need. Start with the design components, if the project has them: the ones called as <x-design::name>, found first in the product's own folder and then in the base's. The product's folder is its own catalogue of composed components, planned by /design-catalog, and a pattern belonging to this product lives there rather than among the shared base ones. When you have written one, search the rest of the views for its distinctive classes: the same three-line block sitting in two files is a component nobody extracted yet.
No check can catch this, because from inside one file the copy looks like the original.
Keep one-off work where it runs
A model method is vocabulary: something the application asks of a record, from anywhere, more than once. A bounded backfill is not. It runs once and is never called again, so it belongs inside the migration that runs it. One whose cost grows with the data (a loop over rows, file work, external calls) runs on the queue instead, as Heavy Data Work Goes Through the Queue in the Laravel Migrations standard (get_standard) states.
Before adding a method to a model, look for who else would call it. If the answer is only the migration, the job or the command you are writing right now, leave it there.
The file alone cannot answer this. The method is well written either way; what decides it is whether a second caller exists anywhere in the project.
Each observer handles its own model
A parent observer may write child rows. It must not run the child's own behaviour: a side effect caused by a child's state change belongs in the child's observer.
When a parent observer calls a method on a related model, open that method. If it does more than write the row — sends something, recalculates something, triggers something else — it belongs to the child.
This needs two files at once: the observer and the method it calls. Neither of them is wrong on its own.
A class names what it owns
A class name states its purpose, and everything inside it serves that purpose. A class that owns the referral programme does not hold a method about invoices.
Read the method names against the class name. If they do not answer to it, the code has not been placed yet — and a folder for application classes is not a home for code with no obvious home.
This is a judgement about intent. A machine can see that the method is there; it cannot see that it does not belong.
Where these sit next to a run
A clean run means the file passed the rules that apply to it, which is worth having and is not the same as the code being right. Read a run for what it proves — that is in Read a finding — and make these four yourself in the same pass.
Why a rule with no automated check stays out of the standards, and what happens when one gains a check later, is in Write a new rule.