The first increment implements a Solid 2.0/Vite browser application, Rust/Axum API, and PostgreSQL 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.
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 without sign-in. It does not expose account information, audit history, or operation results. Lyrics and 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, npm, Docker Compose, and PostgreSQL 17. 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 use a runtime login with row security enforced; 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. Account access, collection content, revisions, public access, and deployment remain In progress because their full requirements extend beyond metadata.
Search is currently normalized literal substring matching across metadata fields in pages of 50 songs. Lyrics, PDF text, full-text/trigram 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, lyric and arrangement documents, 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.