The first increment implements a Solid 2.0/Vite browser application, Rust/Axum API, and native Turso storage for church membership and versioned song metadata. It is a mergeable foundation for the accepted design, not the complete first release.
Available workflow🔗
An installation administrator bootstraps a locally verified email/password account and its first church. Team members sign in, switch between their existing church memberships, search song metadata, and view songs. Administrators and Editors can add songs and edit titles, alternate titles, authors, copyright, themes, and multiple songbook references. Viewers can read them.
Songs hold lyric versions, one per language and edition (for example German original and English translation). Each version has named sections such as Verse 1 and Chorus, their lines, and a default singing sequence that can repeat sections. Editors add and edit versions in the song's detail pane; everyone can read them, including through the public catalogue. Section and line identifiers stay stable across ordinary edits so services and bilingual layouts can refer to them later. Each version has its own revision history and stale-save handling, independent of the song metadata.
Each metadata save appends an immutable revision. A competing save is rejected with the current song; the editor preserves its draft and offers comparison, reload, or deliberate reapplication against that revision. A retried create or save reuses its operation identity, preventing duplicate songs or revisions after a lost response.
A church's public catalogue at /catalogue/{churchId} exposes current unarchived metadata and lyrics without sign-in. It does not expose account information, audit history, or operation results. PDFs are not available yet.
Local setup and checks🔗
The repository's root README.md contains the complete setup, bootstrap, environment, and container commands. Use Rust 1.97.1, Node.js 24, and npm; local development uses a durable native Turso file and deployed instances can share Turso Cloud. Solid is pinned to release candidate 2.0.0-rc.13. Start the development API and browser server separately, then visit http://localhost:5173; the canonical browser origin must match APP_ORIGIN.
Run npm run format:check and npm run check. Tests create an isolated temporary database and exercise church authorization, foreign keys, immutable history triggers, and transactional concurrency; they do not clear your development collection. The check includes strict frontend TypeScript, HTTP integration tests against the compiled Rust service, Solid component tests, and a production build. Also run Cargo formatting, Clippy, and unit tests, plus npm run api:check to verify the generated contract and frontend types. The application container serves both the built interface and API. OpenAPI 3.1 is served at /api/openapi.json and exported to api/openapi.json; future clients can generate their own SDKs from the same contract. The foundation API describes the current contract.
Scope and follow-up🔗
Requirement status distinguishes partially started work from verified complete behavior. SC-14 is implemented for themes and book/number references. SC-12 is In progress: lyrics have named sections and a default sequence, while service sequences do not exist yet. Account access, collection content, revisions, search, public access, and deployment remain In progress because their full requirements extend beyond metadata and lyrics.
Search is currently normalized literal substring matching across metadata fields and lyric text in pages of 50 songs; results name the lyric versions that matched. PDF text, full-text and typo ranking, performance targets, and offline search remain planned. Audit events and outbox records commit with song changes, but no worker delivers events yet and other clients must refresh to see saves.
Invitations, SMTP verification, account recovery, member/settings administration, arrangement documents, bilingual alignment, assets, service plans, readiness, requests, presentation rendering, external adapters, backups, and offline storage are subsequent increments. The release validation gates in Decision 001 still apply.
Behind a reverse proxy, configure TRUSTED_PROXY_IPS with its exact socket addresses and ensure it supplies the real client address in X-Forwarded-For. Untrusted forwarding headers are ignored; missing or malformed headers from trusted peers are rejected. This isolates request and login quotas by client rather than the proxy. Non-loopback APP_ORIGIN values must use HTTPS. See the root README for proxy-chain configuration and health probes.