# Application foundation and temporary guest mode

The user explicitly requested complete functionality before authentication is available. The application therefore resolves a single persistent guest account through CurrentUser. Every visitor uses the same guest account for now. This is the production identity boundary for the interim guest mode; OIDC can later provide another CurrentUser implementation without removing owner IDs from domain records.

The stable guest UUID is 00000000-0000-0000-0000-000000000001. Startup creates it only when absent and preserves existing settings. WERKJOURNAL_GUEST_MODE defaults to true for this requested interim version. Setting it to false fails startup until authenticated identity resolution exists; it does not silently fall back to guest access.

## Persistence

- Production H2 file: ./data/werkjournal.mv.db relative to the service working directory, configurable with WERKJOURNAL_DATABASE_URL. No PostgreSQL compatibility mode.
- Boot-managed Hikari pool, at most four connections; Spring-managed transactions.
- Liquibase 4.33.0 formatted SQL: src/main/resources/db/changelog.sql. Delivered changesets must not subsequently be edited.
- Production jOOQ Kotlin fields are generated from that SQL in a disposable H2 database under build/. No generator connects to application data.
- Tables: app_user, customer, work_project, work_entry, habit_day, weekly_allowance and day_off. Identity/session/invitation/push schema extensions follow their respective implementation nodes.
- Composite foreign keys prevent a work entry from referring to another owner's project or the wrong customer. Database constraints cover row-level hours, nonnegative counts/allowances, Monday effective dates, uniqueness and version columns.
- OwnerTransactions resolves the current owner server-side, locks that user's row and encloses mutations in a transaction. The daily sum across entries still requires the upcoming work service; the row constraint alone does not enforce the twelve-hour daily total.
- UI error handling distinguishes missing records and version conflicts, uses German/English messages and avoids displaying SQL exception details. Unexpected errors receive a correlation reference; logs contain the exception type without potentially private SQL values.

## Verification

FoundationTest migrates and reopens the production schema, checks stable guest identity and retained preferences, rejects foreign owner/customer/project combinations and invalid row hours, rejects a non-Monday allowance date and verifies rollback through OwnerTransactions using the same DataSource as jOOQ. The HTTP test uses an isolated in-memory database. The production JAR smoke runs in a temporary working directory with its own file database.

This node supplies the foundation, not the requested tracking UI or complete domain behavior. Guest tracking screens, catalogs, work/day-total rules, habit counts, settings, export and reminders remain their implementation nodes. No new guest database has yet been deployed to Hostsharing; the public URL still runs the initial stateless prototype until the next validated release.

Local validation: tools/ci-jvm passes with 14 regular JVM tests and 12 isolated auth-probe tests, plus production JAR/PWA smoke PASS.

Werkator verification: commit c6728202c8039f36944a934fcd56cb7eb4f305c2 succeeded in 105 seconds, including the production JAR/PWA smoke. Foundation node completed.