Docs/Tasks.md

@@ -1,43 +1,3 @@
-## [Backend] Login rate limiter — penalty sleep does not block the request
-
-**Where found**
-
-- `backend/app/routers/auth.py:82-107` — rate limiter check happens before password verification, penalty sleep happens after
-
-**Why this is needed**
-
-The current design means attackers who stay under 5 requests/minute get no penalty at all. The `asyncio.sleep` only fires after the rate limit is already exceeded, significantly weakening the limiter's effectiveness.
-
-**Goal**
-
-Ensure the rate limiter blocks requests **before** the password check is attempted. Each wrong password should incur a progressive delay.
-
-**What to do**
-
-1. Remove the `acquire`/`release` pattern
-2. Change flow so `record_failure` is called on every wrong password and `is_allowed` returns False when limit exceeded
-3. Implement exponential backoff: `penalty = min(base_delay * (2 ** failure_count), max_delay)`
-4. Consider using a token bucket rather than sliding window
-5. Ensure `is_allowed` uses the failure count atomically
-
-**Possible traps and issues**
-
-- If `asyncio.sleep` is called before password check, legitimate users experience latency on response
-- Keep maximum penalty reasonable (2-5 seconds)
-- `record_failure` counter must be stored durably (in-memory is fine for single-worker)
-
-**Docs changes needed**
-
-- Update `Docs/Architekture.md` § 2.2 (auth router) — reflect rate limiting behavior
-- Add note in `Docs/Backend-Development.md` about rate limiter design
-
-**Doc references**
-
-- `Docs/Architekture.md` § 2.2 (auth router)
-- `backend/app/routers/auth.py` (login endpoint)
-
----
-
 ## [Backend] Module-level imports inside dependency provider functions
 
 **Where found**