update .gitignore and SKILL.md with important testing guidelines

Author: hendrikebbers

.claude/conventions/software-quality.md

@@ -35,6 +35,8 @@
 - **IMPORTANT**: Every new feature must ship with automated tests. Backend code must reach **at least 80% test coverage**, frontend code **at least 70%**. Coverage is measured on the code added or changed by the feature, not only on the project total.
 - Measure coverage as part of the build (e.g., JaCoCo for Java, the test runner's `--coverage` for TypeScript) and fail the build when a feature drops below the threshold.
 - Coverage is a floor, not a goal — high coverage of meaningless assertions is worthless. Test real behavior, edge cases, and error paths, then ensure the floor is met.
+- **IMPORTANT**: Tests must be deterministic — the same code must always produce the same result, regardless of timing, execution order, machine speed, or external state. A test that passes or fails intermittently (a flaky test) is a defect and must be fixed, not retried.
+- **IMPORTANT**: Never "wait X seconds and hope" the work is done — fixed sleeps are a flaky-test anti-pattern. Wait for the actual condition instead: poll the observable state with a timeout (e.g., Awaitility in Java, `waitFor`/`vi.waitFor` in TypeScript), await the returned promise/future, use synchronization primitives (latches, callbacks), or inject a controllable clock so time is advanced explicitly.
 
 ## Continuous Integration
 

.claude/skills/java-best-pratices/SKILL.md

@@ -86,6 +86,8 @@ Formatting rules (indentation, charset, line endings) are defined in `.editorcon
 - Test one behavior per test method. Provide meaningful assertion messages.
 - Test edge cases: null values, empty collections, boundary values, and expected exceptions.
 - Keep tests independent and fast — each test should run in milliseconds without depending on other tests.
+- **IMPORTANT**: Tests must be deterministic — they must produce the same result on every run, independent of timing, execution order, or machine speed. A flaky test (one that passes or fails intermittently) is a defect to be fixed, not ignored or retried.
+- **IMPORTANT**: Never use `Thread.sleep(...)` to "wait and hope" that asynchronous work has finished — it is the classic flaky-test anti-pattern. Wait for the actual condition: use Awaitility (`await().atMost(...).until(...)`), `Future.get()`/`CompletableFuture.join()`, `CountDownLatch`/`CompletableFuture` callbacks, or inject a fixed/controllable `Clock` so time-dependent logic is exercised deterministically.
 - **IMPORTANT**: Avoid excessive mocking. Excessive mocking is often a sign that APIs have too many dependencies or are poorly designed. Prefer simple dummy/stub implementations of interfaces for test dependencies instead if possible. Use mocking when the dependency is a concrete or final class that cannot be substituted otherwise or the complexity becomes too big.
 - **IMPORTANT**: New features must reach at least **80% test coverage** on the added or changed code (see [software-quality.md](../../conventions/software-quality.md)). Use the JaCoCo Maven plugin (`org.jacoco:jacoco-maven-plugin`) to measure coverage during the build and fail the build below the threshold.
 

.claude/skills/release-doc/SKILL.md

@@ -43,6 +43,7 @@ Pin down exactly which two points you are documenting:
 
 Then gather the real changes between them — do not rely on memory:
 
+- **Ignore changes to the `.claude/` directory** (and `CLAUDE.md`). These are AI/tooling configuration — skills, conventions, hooks, settings — not product changes, and they have no place in release notes or upgrade guides. Exclude them from every command and from the summary, e.g. `git log <previous>..<target> --oneline -- . ':(exclude).claude' ':(exclude)CLAUDE.md'`.
 - `git log <previous>..<target> --oneline` for the change set.
 - Inspect merged PRs / commit messages for intent and grouping.
 - For anything that looks structural, read the actual diff. In particular, for libraries, diff the **public API surface** and contracts:

.claude/skills/typescript-best-practices/SKILL.md

@@ -198,6 +198,8 @@ Contains the single Node version used for development and CI (e.g. `24`). `nvm u
 - **IMPORTANT**: Document what each test verifies. The `describe` block names the unit under test and the `it` description states the scenario and expected outcome, so a reader understands what is tested without reading the test body.
 - Group related tests with `describe` blocks.
 - Prefer `toEqual` for deep equality and `toBe` for reference/primitive equality.
+- **IMPORTANT**: Tests must be deterministic — they must produce the same result on every run, independent of timing, execution order, or machine speed. A flaky test (one that passes or fails intermittently) is a defect to be fixed, not ignored or retried.
+- **IMPORTANT**: Never use a fixed `setTimeout`/`await new Promise(r => setTimeout(r, …))` to "wait and hope" that async work has finished — it is the classic flaky-test anti-pattern. Wait for the actual condition: `await` the promise directly, use `waitFor`/`findBy*` (Testing Library) or `vi.waitFor`/`expect.poll` to retry until the assertion holds, or use fake timers (`vi.useFakeTimers()`/`jest.useFakeTimers()`) to advance time deterministically.
 - **IMPORTANT**: Avoid excessive mocking. Prefer simple stub/dummy implementations for test dependencies if possible and not too complexe. Excessive mocking often indicates poorly designed APIs with too many dependencies. Only mock when the dependency cannot be substituted otherwise (e.g., browser APIs, third-party services) or complexity will become too big.
 - **IMPORTANT**: New features must reach at least **70% test coverage** on the added or changed code (see [software-quality.md](../../conventions/software-quality.md)). Measure coverage with the test runner's coverage mode (e.g., `vitest run --coverage` or `jest --coverage`) and fail the build below the threshold.
 

.gitignore

@@ -1,3 +1,3 @@
 .idea
-target.claude/settings.local.json
-target
+target
+.claude/settings.local.json