Remove honeypot fields from US-1 and US-3

Honeypot spam protection is overengineered for this project's scope.
Removed the acceptance criteria from both stories and added addenda
documenting the decision. Updated implementation order and review
findings accordingly.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

review-findings.md

@@ -44,7 +44,7 @@ US-1 hat 8 ACs, aber implizit beinhaltet sie den gesamten Erstaufbau des Stacks:
 | Schicht | Was US-1 implizit verlangt |
 |---------|---------------------------|
 | DB | Event-Tabelle, Migration, Flyway-Setup |
-| Backend | Entity, Repository, Service, REST Controller, UUID-Generation, Honeypot-Validation, JSON-Serialisierung |
+| Backend | Entity, Repository, Service, REST Controller, UUID-Generation, JSON-Serialisierung |
 | Frontend | Formular, Validierung, API-Call, localStorage-Management, Routing zur Erstellungsseite, Redirect zur Event-Page |
 | Integration | Frontend↔Backend Verbindung, CORS-Konfiguration |
 

spec/implementation-phases.md

@@ -37,9 +37,9 @@ The vertical slice. After these three stories, the app is usable: an organizer c
 
 | # | Story | Depends on | Delivers |
 |---|-------|------------|----------|
-| 1 | US-1: Create event | T-4 | Event creation with tokens, localStorage, honeypot |
+| 1 | US-1: Create event | T-4 | Event creation with tokens, localStorage |
 | 2 | US-2: View event page | US-1 | Public event page with attendee list, expired state |
-| 3 | US-3: RSVP | US-2 | Attend/decline flow, localStorage dedup, honeypot |
+| 3 | US-3: RSVP | US-2 | Attend/decline flow, localStorage dedup |
 
 ### Increment 2: Organizer Toolset — US-5, US-4
 

spec/userstories.md

@@ -32,13 +32,14 @@ The following terms are used consistently across all stories:
 - [ ] The event token, title, and date are also stored in localStorage alongside the organizer token, so the local event overview (US-7) can display the event without additional server contact
 - [ ] No account, login, or personal data is required to create an event
 - [ ] The expiry date field is mandatory and cannot be left blank
-- [ ] A honeypot field is present in the event creation form: hidden from real users; any submission with the field populated is silently discarded server-side
 - [ ] The event is not discoverable except via its direct link
 
 **Dependencies:** T-4
 
 **Notes:** Non-guessable tokens (UUIDs) are specified in Ideen.md under security. Expiry date is mandatory per Ideen.md. No registration required per core principles. Per Q-4 resolution: organizer authentication uses the organizer token stored in localStorage on the device where the event was created. The organizer token is separate from the event token — since the event link is designed to be shared in group chats, using the same token for both public access and organizer auth would allow any guest to manage the event.
 
+**Addendum (2026-03-04):** Honeypot field removed — overengineered for this project's scope. Expiry date must be in the future at creation time — an event should never exist in an invalid state (resolved during US-1 research).
+
 ---
 
 ### US-2: View event landing page
@@ -78,14 +79,15 @@ The following terms are used consistently across all stories:
 - [ ] The event token, title, and date are also stored in localStorage alongside the RSVP data, so the local event overview (US-7) can display the event and link to it without server contact
 - [ ] If a prior RSVP exists in localStorage for this event, the form pre-fills with the previous choice and name
 - [ ] Re-submitting from the same device updates the existing RSVP entry rather than creating a duplicate
-- [ ] A honeypot field is present in the RSVP form: hidden from real users; any submission with the field populated is silently discarded server-side
 - [ ] RSVP submission is not possible after the event's expiry date
 - [ ] RSVP submission is not possible if the event has been cancelled (US-18) [deferred until US-18 is implemented]
 - [ ] No account, login, or data beyond the optionally entered name is required
 
 **Dependencies:** US-2, T-4
 
-**Notes:** RSVP flow specified in Ideen.md: "Ich komme" (with name) / "Ich komme nicht" (optional with name). LocalStorage device binding is the explicit duplicate-prevention mechanism — not a hard guarantee, but sufficient against accidental duplicates. Ideen.md acknowledges that malicious spam without accounts is an acceptable risk. Honeypot fields are listed under Ideen.md security measures.
+**Notes:** RSVP flow specified in Ideen.md: "Ich komme" (with name) / "Ich komme nicht" (optional with name). LocalStorage device binding is the explicit duplicate-prevention mechanism — not a hard guarantee, but sufficient against accidental duplicates. Ideen.md acknowledges that malicious spam without accounts is an acceptable risk.
+
+**Addendum (2026-03-04):** Honeypot field removed — overengineered for this project's scope.
 
 ---
 
@@ -464,3 +466,4 @@ The following terms are used consistently across all stories:
 **Dependencies:** US-1, T-4
 
 **Notes:** The overseer identified that using the expiry date as a deletion mechanism (setting it to today or a past date in US-5) was unintuitive and conflated two different actions. US-5 now enforces that the expiry date can only be set to a future date. If the organizer wants the event gone immediately, they use this explicit deletion feature. Unlike cancellation (US-18), which keeps the event visible with a cancellation notice until the expiry date, deletion removes the event entirely and immediately. This is the organizer's "nuclear option" — useful when the event was created by mistake, contains wrong information, or is no longer needed at all. The deletion behavior is identical to what US-12 does automatically after expiry, but triggered manually and immediately by the organizer.
+