Token usage and thinking classification

.claude/rules/github-workflows.md

@@ -0,0 +1,11 @@
+---
+paths:
+  - ".github/**/*"
+---
+
+# GitHub Workflows Standards
+
+- Always use Makefile targets in the workflow to avoid code duplication.
+- Never add the tests that use LLMs to GitHub workflows, because the default GitHub worker does not have the capacity to run them.
+- Only add unit tests to GitHub workflows.
+- Keep GitHub workflows responsible for only a single concern. For example, run linter, and tests in parallel.

.claude/rules/makefile.md

@@ -0,0 +1,13 @@
+---
+paths:
+  - "**/Makefile"
+---
+
+# Makefile Standards
+
+- Keep variables at the top of the file. Always.
+- Prefer real targets over phony targets. If something can be express as a real target, do that.
+- If you see that a phony target can be expressed as a real target, you can suggest a fix.
+- Keep real targets, phony targets grouped together. Keep targets alphabetically sorted within each group.
+- Keep all the real targets above phony targets.
+- Make sure each Makefile target has enough dependencies to be able to run from a clean state.

.claude/rules/python-on-nixos.md

@@ -0,0 +1,19 @@
+---
+paths:
+  - "paddler_client_python/**/*"
+---
+
+# Running Python tooling on NixOS
+
+To run any Python tool that may have ELF / dynamic-linker issues on NixOS — `ruff`, `mypy`, `pyright`, `pytest`, anything installed from a pip wheel with native 
+bits — first enter `paddler_client_python/shell.nix`, then drive everything through `poetry` from inside that shell.
+
+**Why:** 
+pip wheels like `ruff` ship a generic-linux binary, which NixOS does not provide. 
+Running them directly fails with `Could not start dynamically linked executable: ... NixOS cannot run dynamically linked executables intended for generic linux environments`. 
+`shell.nix` provides the Nix-built loader / replacement tools that make those binaries (or their Nix equivalents) actually launch. 
+`poetry` is just the dispatcher you use *inside* that prepared shell — never the entry point on its own.
+
+**How to apply:**
+- Never invoke `ruff`, `poetry run ...`, `python`, `pytest`, etc. from outside `nix-shell`. If a command starts with one of those, it must be inside `nix-shell --run "..."`.
+- If `paddler_client_python/shell.nix` is missing, stop and ask. Adding a `shell.nix` is the fix; running tooling unwrapped is not.

.claude/rules/rust-integration-tests.md

@@ -0,0 +1,13 @@
+---
+paths:
+  - "**/tests/**/*.rs"
+---
+
+# Rust Integration Tests Standards
+
+- Each test needs to be named after what functionality, or issue it actually tests.
+- Each test file needs to be named after what functionality, or issue it actually tests.
+- Each test represents a specific scenario that the core project needs to support, or represent an uncovered issue.
+- If you uncover a new issue while testing, create yet another targeted test that covers that.
+- Every test muse use production code. Never recreate the original code to test something conceptually. Always use production code.
+- They must be single-purpose.

.claude/rules/rust.md

@@ -17,3 +17,20 @@ paths:
 - In Rust, when implementing a `new` method in a struct, prefer to use a struct with a parameter list instead of multiple function arguments. It should be easier to maintain.
 - Always check the project with Clippy.
 - Always format the code with `cargo fmt`.
+- Each file must contain at most a single struct, or single enum. For readability split those into multiple modules. You can still keep multiple private function helpers.
+- Never use Result<> as a function argument.
+- Never forward Result in enums if you can instead create a targeted error enum. It is always better to signal the specific issue, so it can be handled downstream.
+- Always destructure structs in arguments if possible.
+
+# Code Style
+
+Imports/uses must not be mixed with other kinds of rust syntax. 
+
+Each file needs to follow this order: 
+1. `pub mod`/`mod` exports 
+2. vendor crate `use` 
+2. project crate `use` 
+3. local crate `use` 
+4. private function helpers
+5. private struct helpers
+6. single public export

.claude/rules/testing.md

@@ -6,3 +6,9 @@
 - If some piece of code can be handled by proper types, use types instead. Write tests as a last resort.
 - In unit tests, make sure there is always just a single correct way to do a specific thing. Never accept fuzzy inputs from end users.
 - When working on tests, if you notice that the tested code can be better, you can suggest changes.
+- Maintain 100% test coverage across the codebase. No file, branch, or line may be excluded from coverage reports.
+- Reach 100% coverage with the minimum number of tests. Each test must cover a unique code path, behavior, or edge case that no other test already covers.
+- If two tests cover overlapping paths, remove the weaker one. Redundant tests waste maintenance effort without improving correctness signal.
+- Tests must exercise actual functionality and observable behavior. Never write a test purely to hit lines for the sake of coverage.
+- Design tests deliberately before writing them. Identify the feature or branch under test, then write the smallest test that verifies it.
+- Coverage gaps signal missing tests, never permission to exclude files. Write the test instead of suppressing the gap.

.claude/skills/running-all-tests/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: running-all-tests
+description: Runs every test suite in the paddler workspace on the fastest available device. Use when the user asks to run the tests, run all the tests, run the full test suite, or check that everything still passes.
+---
+
+# Running all tests
+
+Run every test suite in the workspace, picking the fastest compiled device backend for the host. 
+
+## Step 1: detect the device
+
+Run this once at the start and echo the chosen device:
+
+```bash
+if [[ "$OSTYPE" == "darwin"* ]]; then
+  DEVICE=metal
+elif command -v nvidia-smi >/dev/null 2>&1 && nvidia-smi >/dev/null 2>&1; then
+  DEVICE=cuda
+else
+  DEVICE=cpu
+fi
+echo "Device: $DEVICE"
+```
+
+`$DEVICE` selects the Rust integration suite variant in Step 2. The other four suites don't take a device feature.
+
+## Step 2: run the five suites
+
+Copy this checklist and tick each item as the suite completes:
+
+```
+- [ ] JS client
+- [ ] Python client
+- [ ] Rust unit
+- [ ] Rust integration
+- [ ] paddler_gui
+```
+
+| # | Suite            | Inner command                                                                                                                     | Working dir              |
+|---|------------------|-----------------------------------------------------------------------------------------------------------------------------------|--------------------------|
+| 1 | JS client        | `make test.client.js`                                                                                                             | repo root                |
+| 2 | Python client    | NixOS: `poetry run pytest`, `ruff`, `poetry run mypy"`. Every other OS: `poetry run pytest`, `poetry run ruff`, `poetry run mypy` | `paddler_client_python/` |
+| 3 | Rust unit        | `make test.unit`                                                                                                                  | repo root                |
+| 4 | Rust integration | `make test.integration` (cpu) / `make test.integration.cuda` / `make test.integration.metal` — pick by `$DEVICE`                  | repo root                |
+| 5 | paddler_gui      | `cargo test -p paddler_gui --features web_admin_panel`                                                                            | `paddler_gui/`           |
+
+Run them in this order. Cheap suites (1, 3, 4) surface bugs quickly; the heavy GPU-bound suites (2, 5) come last.
+
+## Step 3: rules during the run
+
+- **Serialize GPU suites.** When `$DEVICE` is `cuda` or `metal`, run test suites sequentially to avoid device contention.
+- **Per-test 30 s budget.** Flag any individual test that exceeds 30 s wall-clock. That is a real bug — production or test — not flakiness.
+
+## Step 4: report
+
+After all suites finish, sum up the results in an actionable report.

.gitignore

@@ -1,6 +1,5 @@
 .DS_Store
 /*.db
-/.tsimp
 /esbuild-meta.json
 /godepgraph.png
 /models