Suggestion
app/CLAUDE.md's Code style section already mandates extracting well-named private/protected helpers to keep methods doing one thing — but it never says where those helpers should live. In practice that means agents (and humans) insert them wherever the extraction happened, often between public actions, so files drift into an inconsistent order.
Proposed addition to Code style (cross-cutting) in app/CLAUDE.md, right after the extract-a-helper rule:
- MUST order methods by visibility:
public first, then protected, then private.
Extracted helpers live at the bottom of the class, below every public method — the
public contract reads first, implementation detail follows (step-down rule).
Rationale
The public actions are the reason the class exists — routes point at them, and they're what you almost always came to read. Ordering them first means the file answers "what does this class do" in the first screenful (newspaper/step-down rule: callers above callees).
Helpers are discovered at the call site, not by scanning the file — ->map($this->gameSummary(...)) tells you the helper exists at exactly the moment you have context for it, one go-to-definition away.
It makes the stability gradient structural: stable public contract up top, frequently-irrelevant implementation detail below.
It complements the existing extraction rule. Since the ruleset actively pushes code into helpers, it should also say where they go — otherwise the more the rule is followed, the messier the ordering gets.
Pint can't enforce member ordering, so a written rule is the only lever the ruleset has here.
Happy to PR this if you'd rather review a diff.
Suggestion
app/CLAUDE.md's Code style section already mandates extracting well-named private/protected helpers to keep methods doing one thing — but it never says where those helpers should live. In practice that means agents (and humans) insert them wherever the extraction happened, often between public actions, so files drift into an inconsistent order.
Proposed addition to Code style (cross-cutting) in app/CLAUDE.md, right after the extract-a-helper rule:
publicfirst, thenprotected, thenprivate.Extracted helpers live at the bottom of the class, below every public method — the
public contract reads first, implementation detail follows (step-down rule).
Rationale
The public actions are the reason the class exists — routes point at them, and they're what you almost always came to read. Ordering them first means the file answers "what does this class do" in the first screenful (newspaper/step-down rule: callers above callees).
Helpers are discovered at the call site, not by scanning the file — ->map($this->gameSummary(...)) tells you the helper exists at exactly the moment you have context for it, one go-to-definition away.
It makes the stability gradient structural: stable public contract up top, frequently-irrelevant implementation detail below.
It complements the existing extraction rule. Since the ruleset actively pushes code into helpers, it should also say where they go — otherwise the more the rule is followed, the messier the ordering gets.
Pint can't enforce member ordering, so a written rule is the only lever the ruleset has here.
Happy to PR this if you'd rather review a diff.