logic-review

Logic review — review mode

Assess code that already exists against the same trees the design side uses, so a review can never contradict a design recommendation.

To decide where something new should go, use logic-placement.

Procedure

Read in this order, and read the tree before judging its dimension — do not judge from memory.

Rules for the whole pass:

• Judge a split by what varies, not by whether it exists. A missing split is a finding only when one of the variation criteria is met. An existing split whose container only forwards inputs is a finding regardless.
• Do not recommend a store type migration inside the change under review. See the store type migration stop-and-ask in logic-placement.

Check — presenter purity

The test: can the presenter be rendered from a spec by supplying inputs only? If it needs a store or an HTTP mock, logic has leaked.

Follow the injections one level deeper than the imports. A presenter that injects no store and calls no HTTP client can still reach both through a service, which hides the dependency without removing it.

FOR each service a presenter injects:
  does it select from the store, call an API, or trigger a side effect
  beyond the component?
    yes -> FINDING: the dependency belongs in the container
    no  -> allowed, if it is a presentation helper such as formatting or breakpoints

Check — componentType against the actual role

A mismatch between @O3rComponent({ componentType }) and what the class does is a reliable signal that logic sits in the wrong place. Either the type or the logic must move — decide which from the responsibility table in logic-component-shape.