nitrix/fete
1
0
Fork 0
Code Issues 1 Pull Requests 10 Actions Packages Projects Releases 13 Wiki Activity

initial commit

Browse Source 
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
nitrix
2026-03-03 10:06:47 +01:00
commit 7b460dd322
34 changed files with 3413 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
.ralph/review-findings/questions.md Normal file
View File

@@ -0,0 +1,66 @@
# Open Questions
<!-- Questions that need human decision before certain user stories can be written or finalized. -->
<!-- Format: Each question gets a unique ID, status (open/resolved), and affected stories if known. -->
## Open
(No open questions.)
## Resolved
### Q-5: CI/CD platform choice
**Context:** T-3 originally assumed Gitea as the CI/CD platform (Gitea Actions with `.gitea/workflows/`, publishing to Gitea's container registry). However, this choice is not documented in Ideen.md or CLAUDE.md. The CI/CD platform determines the workflow file format, container registry configuration, and available pipeline features. The platform-independent requirements (run tests, build, publish on success) are clear, but the implementation depends on where the repository is hosted.
**Affects:** T-3
**Options:**
- (a) Gitea Actions (`.gitea/workflows/`, Gitea container registry) — if the project is hosted on a Gitea instance
- (b) GitHub Actions (`.github/workflows/`, GitHub Container Registry or Docker Hub) — if the project is hosted on GitHub
- (c) GitLab CI (`.gitlab-ci.yml`, GitLab Container Registry) — if the project is hosted on GitLab
- (d) Other platform or defer CI/CD to the self-hoster's responsibility
**Answer:** (a) Gitea. The project shall be optimized for Gitea. Only Gitea infrastructure will be used — Gitea Actions for CI/CD pipelines, Gitea container registry for Docker image publishing.
### Q-1: Event page customization scope ("Designbar")
**Context:** Ideen.md mentions under the event landing page description: "Irgendwie auch Designbar, sofern man das will" (somehow also designable, if you want to). This clearly implies some form of visual customization for event pages, but the scope is entirely undefined. The answer fundamentally changes what the user story would look like — from a trivial theme picker to a complex layout system.
**Affects:** US-15 (written based on this answer).
**Options:**
- (a) The organizer can choose from a small set of predefined themes or color schemes when creating/editing an event
- (b) The organizer can set a custom accent color and/or upload a header image for the event page
- (c) More elaborate customization (custom CSS, layout options, etc.)
- (d) "Designbar" was aspirational / nice-to-have and is deferred or out of scope for the initial version
**Answer:** (a) predefined themes, plus as a separate feature the organizer can search/select a header image from Unsplash (server-proxied to maintain privacy). US-15 written accordingly.
### Q-2: PWA start URL target
**Context:** US-14 (PWA installability) requires a `start_url` in the web app manifest — the page shown when a user launches the installed app from their home screen. The natural candidates are the local event overview (US-7) or a generic landing/home page.
**Affects:** US-7 (route changed to `/`), US-14 (start URL updated).
**Options:**
- (a) Start URL points to the local event overview (`/my-events`) — returning users immediately see their tracked events
- (b) Start URL points to a home/landing page that offers both event creation and a link to the local overview
**Answer:** The local event overview lives at the root page `/`. That is also the start URL. The page should show a project header/branding and the list of events the user attends or watches underneath. US-7 and US-14 updated accordingly.
### Q-3: Progressive enhancement requirement (no-JavaScript content rendering)
**Context:** Several user stories originally included acceptance criteria requiring content to be renderable without JavaScript (e.g. US-2: "core content must be in server-rendered HTML", US-10: "reading updates does not require JavaScript"). This presupposes a progressive enhancement / server-side rendering strategy — but the rendering strategy is explicitly listed as undecided in Ideen.md. The app is also specified as a PWA, which typically implies heavy JavaScript usage. These two forces are in tension: progressive enhancement favors server-rendered HTML enhanced by JS, while a PWA/SPA approach favors client-side rendering. The answer determines whether stories need "works without JS" acceptance criteria or not.
**Affects:** US-2, US-10, US-11, and all page-rendering stories. Assumption notes removed from affected stories.
**Options:**
- (a) Progressive enhancement is a hard requirement: all core content (event details, attendee list, update messages) must be in server-rendered HTML; JavaScript enhances the experience but is not required to view content
- (b) JavaScript-dependent rendering is acceptable: the app can be a SPA with client-side rendering, as long as it meets accessibility standards (screen reader compatibility, semantic HTML in the DOM, etc.)
- (c) Hybrid: critical public pages (event landing page) must work without JavaScript for maximum reach; internal pages (local overview, organizer views) may require JavaScript
**Answer:** SPA with PWA, no server-side rendering. Classic frontend + RESTful API. JavaScript-dependent rendering is acceptable. Accessibility must be ensured through proper semantic HTML and ARIA attributes in the client-rendered DOM. Assumption notes cleaned up in US-2, US-10, and US-11.
### Q-4: Organizer authentication mechanism (token format and transmission)
**Context:** Multiple user stories (US-1, US-4, US-5) assume that organizer authentication works via a secret token stored in localStorage on the device where the event was created. This is a reasonable default in the no-account design, but Ideen.md explicitly lists "Wie genau die Organizer-Authentifizierung technisch funktioniert (Token-Format, Übertragungsweg)" as an undecided architectural decision. Alternative approaches — such as a special organizer URL with the secret embedded — would have different UX and security trade-offs. A URL-based approach would enable cross-device organizer access (the organizer can share or bookmark the management link) while a localStorage-based approach is device-bound but keeps the secret out of URLs, browser history, and referrer headers.
**Affects:** US-1, US-4, US-5, and indirectly US-10. Assumption notes removed from affected stories.
**Options:**
- (a) localStorage-based: the server returns a secret organizer token after event creation; the client stores it in localStorage; organizer access is device-bound
- (b) URL-based: the server returns a special organizer URL containing the secret (e.g. `/events/{id}/manage/{secret}`); the organizer bookmarks or shares this URL; no localStorage needed for auth
- (c) Hybrid: the organizer receives a secret URL after creation, and the app also stores the token in localStorage for convenience; either mechanism grants access
**Answer:** Confirmed localStorage-based approach. The user suggested the event's unique ID could double as the organizer access token but left the door open for separation. Recommendation applied: the organizer secret token is kept separate from the public event ID, because the event link is designed to be shared in group chats — using a single token for both guest access and organizer management would allow any link recipient to edit or delete event data. Existing story acceptance criteria (which already assumed separate tokens) are confirmed correct. Assumption notes removed from US-1, US-4, US-5.