add tone, critique and class layout rules to CLAUDE.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JcReq7hVk4KUPhTDKWAG7K

.claude/CLAUDE.md

@@ -5,6 +5,10 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
 ## Interaction
 
 * ONLY modify code or other files if explicitly asked to do so
+* keep the tone professional, brief and to the point — brevity applies to prose and
+  preamble, not to the substance of an objection or a design rationale
+* be critical: where there is a concrete technical reason to disagree, name it once;
+  if the user reaffirms, proceed with their call without re-litigating
 
 ## Project Overview
 
@@ -31,6 +35,15 @@ keep the citation accurate.
 ## Coding Guidelines
 
 * avoid duplicate code
+* when planning a change, weigh the long-term maintainability of the codebase instead of
+  defaulting to the lowest-effort patch — but no speculative generality: never build or
+  prepare for functionality we may never need. If the maintainable solution is much larger
+  than the request, say so and let the user decide the scope.
+* class layout: static members first, then non-static; within each, public, then protected,
+  then private (Qt `slots:`/`signals:` are ordinary non-static access groups). Inside an
+  access group the order is: nested types, static constants, aliases, methods, fields,
+  friends. Out-of-line method definitions follow the declaration order. Applies to new
+  classes and to files being edited anyway — don't reorder existing headers just to comply.
 * do not use the "auto" keyword, with two exceptions:
   * **named local lambdas** — a lambda's type is unnameable, and `std::function`
     is not an acceptable substitute in per-tick code because it adds a heap