patrickandClaude Sonnet 5
121d80e707
BUG-18 (Critical) — invitations.ts never joined the Matrix room for
members invited with a teamId (only teams.ts's add-member path did).
Standard onboarding flow left every invited team member stuck on
"Raum wird eingerichtet" forever, with no self-healing (reconciliation
only checks user provisioning, never room membership) and no repair
path (blocked by BUG-19). Now mirrors teams.ts: inline addUserToRoom
with an enqueueSyncJob("join_team_room") fallback.
BUG-19 (High) — no global Fastify error handler meant an uncaught
error (e.g. a duplicate-key insert) echoed back the raw Drizzle error,
including the full SQL statement and bound parameters, to the client.
Added app.setErrorHandler(): 5xx is logged server-side and replaced
with a generic message, 4xx keeps its already-safe original message.
BUG-12 (High) — use-team-unread-counts.ts had no SyncState.Error
handling, so an expired token meant matrix-js-sdk retried /sync
against Synapse forever with a dead token while badges silently
froze. Now stops the client and reconnects with a fresh token,
capped exponential backoff.
BUG-11 (High, partially mitigated) — deferred the app-level unread
client's start to requestIdleCallback instead of firing synchronously
on TeamsPage mount, taking it off the critical path. Does NOT fix the
underlying complaint (SDK still loads for anyone who visits the team
list, whether or not they open chat) — documented as an open
architecture question rather than declared fixed.
All four fixes verified end-to-end against the live talkhub/matrix
TLS deployment (invitation accept -> joined_rooms; duplicate insert ->
generic 500). Test data from QA round 3 and this verification pass
cleaned up (orgs, users, Matrix accounts erased, rooms purged).
Not addressed: BUG-20 (predictable Matrix IDs undermine the BUG-2
user_directory mitigation), BUG-5/6/7/9/10/13/14/15/16/17/21/22.
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!