• Spec — does the code faithfully implement the leaf's

  spec.md

  and the Task's acceptance criteria?
• Standards — does it follow the repo's conventions, cover its units the way the framework requires, and stay clear of the smell baseline?

• One integration test, at the Spec's seam. A test parked at a lower or more convenient seam — a helper, an internal function, a place that was simply easier to wire — is a finding even when it passes.
• Every unit the diff modified has a unit test. A unit merely read is out of scope; pulling it in metastasises the suite.
• Each unit test asserts behaviour at its unit's boundary — what it returns, what it emits, what it calls on its collaborators. Apply the rename test: a test that would break when a symbol is renamed or a helper extracted is testing implementation, and it is rejected. Assertions on private state, call counts of internal helpers, and snapshots of internal shape fail the same way.

• The repo and the Spec override. Where either endorses the shape a smell would flag, suppress it — they are the authority, this list is the backstop.
• Always a judgement call, labelled as one ("possible Feature Envy") rather than reported as a breach, and never blocking. Skip anything the repo's lint and typecheck already enforce — the gates ran before this review.

• Mysterious Name — a function, variable or type whose name does not reveal what it does or holds. → rename it; if no honest name comes, the design is murky.
• Duplicated Code — the same logic shape in more than one hunk or file of this diff. → extract the shape, call it from both.
• Feature Envy — a method reaching into another object's data more than its own. → move the method onto the data it envies.
• Data Clumps — the same few fields or params travelling together, a type wanting to be born. → bundle them into one type, pass that.
• Primitive Obsession — a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.
• Repeated Switches — the same

  switch

  or

  if

  -cascade on the same type recurring across the change. → replace with polymorphism, or one map both sites share.
• Shotgun Surgery — one logical change forcing scattered edits across many files in the diff. → gather what changes together into one module.
• Divergent Change — one file edited for several unrelated reasons. → split so each module changes for one reason.
• Speculative Generality — abstraction, parameters or hooks added for needs the Task does not have. → delete it; inline back until a real need shows.
• Message Chains — long

  a.b().c().d()

  navigation the caller should not depend on. → hide the walk behind one method on the first object.
• Middle Man — a class or function that mostly delegates onward. → cut it, call the real target direct.
• Refused Bequest — a subclass or implementer ignoring or overriding most of what it inherits. → drop the inheritance, use composition.

spec.md

Report: (a) acceptance criteria or Spec requirements that are missing or only partly built; (b) behaviour in the diff nobody asked for — scope creep, or work reaching into another Task's territory; (c) requirements that look built but where the implementation looks wrong. Quote the criterion or the Spec line behind each finding, and name the file and line. The task file and the

spec.md

are the contracts, so judge against what they say rather than against anything you infer from elsewhere in the repo. Where a criterion is too ambiguous to judge, say so as a finding and give the reading you reviewed against. Under 400 words.

Report, per file or hunk: (a) every place the diff breaks a documented repo standard, citing the file and the rule; (b) every place it breaks one of the test rules; (c) any baseline smell you spot, named, quoting the hunk. Documented standards and the test rules can be hard findings; baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything the repo's tooling enforces. Under 400 words.