# BONE FLOW #024 Calendar — v1.0.320 Actual DB Selection (Candidate)

Status: DEVELOPMENT / NOT COMPLETED. Do not use for employee/payroll shared production without server-side access controls and real Windows/phone E2E validation.

## User-facing operation

Open `/boneflow/sample/024/calendar/minimal.html`.

- **Personal / Local**: The existing `boneflow-calendar-standard` SQLite in browser IndexedDB is used. Existing personal data remains untouched by the server switch.
- **Organization / Server**: Select a company from the existing Company Master or enter a company ID (the `?id=C0001` link selects it automatically), then click **団体DBへ切替**. The current origin is used; no server name is hardcoded or manually required. Authenticated Apache WebDAV must exist at `/boneflow-private/bf024/`. A registered company ID resolves to `registry/C0001.json` and its company `.sqlite` filename under `companies/`. A mismatch between the ID and the company master inside SQLite refuses the switch.
- An administrator can **explicitly** create a new company DB only from a company already listed in the personal Company Master, after confirmation. No personal work history is copied. Existing company IDs and DB file names refuse overwrites.
- In organization mode the Calendar mounts an **isolated** device-side cache named `bf024-org-cache-*` loaded from the server's SQLite. Calendar edits auto-save to this separate cache, then upload to WebDAV using `If-Match` with an ETag. Before server overwrite, the previous server SQLite is copied to a unique immutable snapshot and read back. The edited server file is then read back and checked. The UI says **server saved** only on success.
- If WebDAV is absent, inaccessible, not authenticated, the company ID isn't registered, or a conflict is detected, there is **no false server switch or false success status**. On server upload failure edits remain in the isolated device cache, visibly marked unsent. The user may retry server save or export an SQLite backup. A mode switch is refused while unsent changes remain.
- Click **ローカルDBへ切替** to return to the unchanged personal DB (when there are no pending server changes). The `?id=` parameter is removed to avoid reselecting the organization accidentally.
- When opening an `?id=` link for another company, the selected company ID takes precedence if the current server mode is clean. Pending changes in the former company block cross-company switching.

## Existing features and limits

The existing Company, User, Invoice, Payslip, Payroll, and Calendar runtime remain unchanged. No Frozen Component, DB adapter or SQLite engine code has been modified. The finance voucher subpage uses its own persistence path and is not part of this minimal.html backend-switch acceptance proof.

**Security limitation**: WebDAV Basic authentication alone DOES NOT enforce company/user-level field/row restrictions. A user who can GET a company's full SQLite file can read salary, payslip and invoice data regardless of UI role flags. Do not grant employees/customers read access to the raw company SQLite files. Separate server-side per-user authorization must be completed before general organization production use.

**Consistency limit**: Server updates are conditional, not auto-merged on conflicts. Conflict means STOP, preserve device draft and perform an explicit reviewed merge. Existing manual compare/merge page remains available. A separate external API is not used. Apache must have authenticated WebDAV configured already; WebRoot copy alone does not create writable server storage.

**Testing**: v320 unit tests cover separate store identity, company registration, duplicate name refusal, backup, conflict and failed PUT handling. A real Apache 2.4 (Linux) WebDAV integration checks authentication, conditional update, conflict and immutable backup. The UI tests are isolated browser tests with stubbed storage. Windows PowerShell 5.1, production HTTPS, actual smartphone access and full two-user/finance workflows are **NOT verified**.