patrickandClaude Sonnet 5
beead59907
BUG-1/BUG-2 (High) — DELETE now polls getRoomDeleteStatus() (up to 10x
1s) before treating the purge as done. "complete" -> drop local mapping
+ audit; "failed" -> 502, mapping left untouched; still "purging" after
the poll window -> 202 {pending:true}, mapping also left untouched.
Frontend handles 202 explicitly instead of assuming success.
Found and fixed a second bug while verifying the first fix live:
getRoomDeleteStatus() assumed a {results:[...]} array response, but
GET .../delete_status/<delete_id> (by delete_id, as used here) returns
a flat object. This silently misread every "complete" as "pending" —
caught only by testing against a real Synapse instance, not by
reading the code.
BUG-3 (Medium) — confirmed live: re-deleting an already-gone room still
returns 200 instead of 404, because Synapse's v2 delete never validates
room existence. Left as-is: the outcome is correct and the operation is
idempotent, so the originally-documented 404 branch is dead code but
not a functional gap.
BUG-4 (Medium) — audit_logs.organization_id is nullable now (migration
0004). Deleting an unassigned room gets a real audit row
(organization_id: null) instead of only a server log warning.
BUG-5 (Medium) — the mapping delete and its audit write now run inside
one db.transaction() (logAudit() takes an optional tx handle); the
delete route has its own 10/min rate limit instead of only the global
100/min.
BUG-6 (Medium) — frontend pagination uses pagination.nextFrom/prevFrom
(Synapse's own cursors) instead of client-side arithmetic against
`total`, which could offer a "Weiter" onto an empty page during a
search.
All verified end-to-end against the live talkhub/matrix Synapse:
fresh orphan room deletes in ~1.1s as "complete" (was a 10s timeout
misreported as pending before the results/flat-object fix); re-deleting
an already-gone room still 200s; a null-org audit row appears after
deleting an unassigned room. Test rooms/accounts/audit rows cleaned up.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0143yYvjesjHndBACoweyK67
Feature Specifications
Dieser Ordner enthält detaillierte Feature Specs vom Requirements Engineer.
Naming Convention
PROJ-X-feature-name.md
Beispiele:
PROJ-1-user-authentication.mdPROJ-2-kanban-board.mdPROJ-3-file-attachments.md
Was gehört in eine Feature Spec?
1. User Stories
Beschreibe, was der User tun möchte:
Als [User-Typ] möchte ich [Aktion] um [Ziel zu erreichen]
2. Acceptance Criteria
Konkrete, testbare Kriterien:
- [ ] User kann Email + Passwort eingeben
- [ ] Passwort muss mindestens 8 Zeichen lang sein
- [ ] Nach Registration wird User automatisch eingeloggt
3. Edge Cases
Was passiert bei unerwarteten Situationen:
- Was passiert bei doppelter Email?
- Was passiert bei Netzwerkfehler?
- Was passiert bei gleichzeitigen Edits?
4. Tech Design (vom Solution Architect)
## Database Schema
CREATE TABLE tasks (...);
## Component Architecture
ProjectDashboard
├── ProjectList
│ └── ProjectCard
5. QA Test Results (vom QA Engineer)
Am Ende des Feature-Dokuments fügt QA die Test-Ergebnisse hinzu:
---
## QA Test Results
**Tested:** 2026-01-12
**App URL:** http://localhost:3000
### Acceptance Criteria Status
- [x] AC-1: User kann Email + Passwort eingeben
- [x] AC-2: Passwort mindestens 8 Zeichen
- [ ] ❌ BUG: Doppelte Email wird nicht abgelehnt
### Bugs Found
**BUG-1: Doppelte Email-Registrierung**
- **Severity:** High
- **Steps to Reproduce:** 1. Register with email, 2. Try again with same email
- **Expected:** Error message
- **Actual:** Silent failure
6. Deployment Status (vom DevOps Engineer)
---
## Deployment
**Status:** ✅ Deployed
**Deployed:** 2026-01-13
**Production URL:** https://your-domain.example
**Git Tag:** v1.0.0-PROJ-1
Workflow
- Requirements Engineer erstellt Feature Spec
- User reviewed Spec und gibt Feedback
- Solution Architect fügt Tech-Design hinzu
- User approved finales Design
- Frontend/Backend Devs implementieren (dokumentiert via Git Commits)
- QA Engineer testet und fügt Test-Ergebnisse zum Feature-Dokument hinzu
- DevOps deployed und fügt Deployment-Status zum Feature-Dokument hinzu
Status-Tracking
Feature-Status wird direkt im Feature-Dokument getrackt:
# PROJ-1: Feature Name
**Status:** 🔵 Planned | 🟡 In Progress | ✅ Deployed
**Created:** 2026-01-12
**Last Updated:** 2026-01-12
Status-Bedeutung:
- 🔵 Planned – Requirements sind geschrieben, ready for development
- 🟡 In Progress – Wird gerade gebaut
- ✅ Deployed – Live in Production
Git als Single Source of Truth:
- Alle Implementierungs-Details sind in Git Commits
git log --grep="PROJ-1"zeigt alle Änderungen für dieses Feature- Keine separate FEATURE_CHANGELOG.md nötig!