# Separate private Daybook Money

Receivables (`receivables`) and passport allocations (`trading.passportFunds`)
are included in finance snapshots and Excel backups. They do not increase bank
balances, trading holdings, deposits or profit. Older backups remain importable;
no additional SQL migration is required.

**The deployed app is not connected to your finances automatically.** A Mac
workbook, Mac browser records and phone browser records are separate stores.
This frontend uses **separate private finance tables and a separate browser
Auth session**, not Life OS / Telegram storage. You can use a dedicated
Supabase project or an existing project with the finance-specific setup below.
The public deployment configuration names the selected project, but no schema,
Auth user or financial data is provisioned by the app. Never upload your private
Excel workbook into the public website.

## Public deployment default

`finance-public-config.js` contains the user-approved project API URL and
**publishable browser key**, not an admin/service secret. A new browser starts
in private Money mode and asks for sign-in. A default project/key is **not**
proof that schema setup, authentication or finance syncing has succeeded.
The frontend only uses the private table/RPC described below, never the legacy
anonymous finance endpoint.

A saved Money connection overrides this default on that device.
**Disconnect / use local records** saves an explicit local-mode preference,
which survives reloads and avoids reconnecting to the default unexpectedly.
In local mode the default URL/public key prefill the connection form so you can
explicitly reconnect. Existing `finDash_v3` records remain untouched throughout.

## One-time setup (project owner)

1. In local Money on your Mac, choose **Backup**. If the default connection
   first asks for sign-in, choose **Disconnect / use local records** to access
   your existing browser records, then Backup. Keep this Excel file privately.
   If the latest records are in `finance-data.xlsx`, use that existing file.
   Keep other devices/older dashboards closed during the initial import.
2. Select your Supabase project. A **dedicated project** gives stronger
   infrastructure isolation; an **existing project** also works without
   changing its planning/Telegram tables. In its SQL Editor run
   **`finance-private.sql`** from this directory. This creates `finance_private_workspaces` and
   `save_private_finance_workspace`; it inserts no financial records.
   **Do not run `schema.sql`**: that is the older anonymous/public design,
   retained only as a legacy reference, not private setup.
3. In Authentication → Users, manually add your Money user with email/password
   and confirm the email (or complete verification), or use an existing user you
   control. Keep the password in your password manager. There is no frontend
   signup or password-reset flow; manage the user/password in Supabase.
   In a **dedicated Money project**, disable **Allow new users to sign up** and
   anonymous sign-ins. In a **shared existing project**, do not change global
   Auth settings without checking other applications: those settings affect
   the whole project. Other users still cannot access your owner-protected row.
4. Copy the **Project URL** (`https://project-ref.supabase.co`) and
   **publishable key** (`sb_publishable_…`) from the project connection/API
   settings. A legacy JWT key with role `anon` also works. These public keys
   identify the project; they do **not** authorize access to finance rows.
   Never use `sb_secret_…`, a service-role key, database password or admin token.
5. Open Daybook → Money → **Money connection · separate private Supabase** on
   your Mac. Enter the URL/public key, choose **Save Money connection**, confirm,
   then sign in with your Money user. The page reloads after
   configuration. Do not edit source constants; they must stay placeholders.
6. After a successful empty-cloud read, choose **Restore**, select your Excel
   backup and explicitly confirm its upload. Nothing is uploaded by merely
   configuring, signing in or refreshing. Editing a never-created cloud
   workspace is disabled until this explicit initial restore succeeds.
7. On your phone, configure the **same Money project** and sign in as the
   **same Money user**. The saved snapshot now loads. Other users intentionally
   have different, empty workspaces. The app checks for changes every 15 seconds
   while visible and on focus, except during editing/saving or while an error
   or failed restore needs attention. Use **Refresh** to retry after an error.

The URL/public key and Supabase session are browser-local under
`daybook-money-connection-v1` and `daybook-money-auth-v1`, separate from planning.
Daybook does not store the entered password; Supabase persists refresh/access
tokens for this browser. Treat a signed-in browser as access to your finances.
Sign out on shared devices. Disconnect clears this browser's Money connection
credentials/session and saves a local-mode preference, returning to its untouched
local records; it does not delete cloud records or copy them locally. Backup
first if you need a local cloud copy.

### Reusing an existing Supabase project

Only `public.finance_private_workspaces`, its read policy/grants, and
`public.save_private_finance_workspace(jsonb,bigint,uuid)` are managed by this
setup. It does not alter/drop planning, diet, Telegram, legacy finance or other
tables, nor change global Auth settings. Check that these two finance-specific
names are not already used by an unrelated application before running SQL.
An existing project's URL/public key can be entered through **Money connection**
on each device; do not copy its keys into app source constants. A project dashboard URL
(`https://supabase.com/dashboard/project/<ref>`) is not the API URL; use
`https://<ref>.supabase.co` and that project's publishable/anon public key.

Separate browser session storage prevents Money from reusing another app's
stored sign-in automatically. Supabase **Auth users, project administrators and
infrastructure remain shared** within one project; this is table/row isolation,
not a separate Auth tenant. Using the same user in two apps gives that user
whatever permissions both apps grant. Use a dedicated project if you need fully
separate administration. Review existing broad grants/functions independently;
this script cannot correct unsafe access paths created by other applications.

## Privacy and database safety

- RLS permits authenticated users to read **only `owner_id = auth.uid()`**.
  Anonymous/public clients cannot read or write. Knowing the public key alone
  is not access. Frontend sign-in is not a substitute for installing this SQL.
- Clients cannot directly insert, update or delete snapshots. The RPC derives
  ownership from `auth.uid()` and requires the draft's `expected_owner` to match
  that identity, rejecting missing identity or a session switch. It cannot write
  to an arbitrary owner. Its fixed search path excludes caller-created objects.
- Each user owns one versioned snapshot. Updates compare the loaded version
  atomically. Concurrent first imports use insert-if-absent, not overwrite/upsert.
- Rerunning the private setup preserves snapshots. It never reads, migrates,
  reassigns ownership of or alters legacy singleton/normalized finance tables.
  It cannot make an old project's existing public tables private. Review legacy
  access independently if reusing an existing project.
- Before storing real records, verify in your project using two test Auth
  users: user A can restore/read their snapshot; user B cannot read A's row;
  a public key without a signed-in session cannot select rows or call the RPC;
  direct table writes fail; stale versions and concurrent initial imports
  report conflicts. Check policies/grants in Supabase. Browser regression tests
  mock the server and **do not certify a deployed database**.

## Local records, Excel and conflicts

Without a connection, Money says **Local only** and reads `finDash_v3`,
preserving legacy payment migration. Only a validated, successful local save
replaces this record. Browser data is not shared between Mac and phone.
On a loopback local server only, an absent browser record can preview the
same-origin `finance-data.xlsx` read-only. Public hosts do not fetch that file.
If absent/invalid, Restore asks you to choose a file; no example balances appear.
Blank legacy account/checkpoint labels use neutral “Unnamed account” /
“Undated checkpoint” labels without dropping amounts or rows.

**Backup** exports the displayed snapshot. **Restore** validates the complete
workbook and asks before replacing anything; arbitrary/incomplete sheets are
rejected. Existing workbooks are never modified. Save/restore use the same
compare-and-swap protection. There is no force-overwrite.

Failed saves keep the editor and draft open. Download the draft, close the
editor, Refresh, then merge your changes. A failed Restore retains a downloadable
draft; the original selected file is also unchanged. Successful Refresh discards
that retained restore draft, so back it up first. Automatic checks pause on
errors and never replace open drafts. If sign-in changes during editing/saving,
the draft is preserved and a refreshed identity/snapshot is required before
merging. A dropped response after a server commit is an uncertain save, not a
claimed success; preserve the draft and Refresh.

Cloud snapshots are not written into `finDash_v3` or its local previous-record
key. Local-mode saves detect another tab's changed record (with Web Locks where
available). Storage failures never claim success. Browser storage can be cleared;
keep independent Excel backups. Offline cloud refresh fails visibly and disables
editing until a successful Refresh; the last displayed snapshot may be stale.

## Embedding, dependencies and accounting

Embed `dashboard.html?embedded=1&theme=light` or `theme=dark`. Same-origin parent
messages `{type:'daybook-theme',theme:'dark'}` (also `daybook:theme`) change theme.
No finance records go to the parent, Life OS, Telegram or analytics.
React 18.3.1, Babel 7.26.9, Chart.js, XLSX and Supabase JS v2 are CDN dependencies;
first load needs network access. The configured Supabase project handles Money
authentication and cloud data. Settings only accept hosted HTTPS Supabase URLs.

Accounts/investments may overlap; the UI does not claim combined net worth.
Trading + resale profit includes unrealised trading P/L, not cash savings.
Major creditors remain separate from running debts. Savings payments do not
silently rewrite Etsy accounts.

## Local regression tests

From the project root, serve the source with
`python3 -m http.server 8768 --bind 127.0.0.1`, then run
`python3 supabase/test_finance.py http://127.0.0.1:8768`.
Tests use Python Playwright and installed Chromium/WebKit. All cloud operations
are mocked, never real financial writes. Apply/test SQL in a disposable
Supabase project before using it with private records. Live cross-device
verification requires the project API URL/public key, installed SQL and a valid
Money Auth user; a project dashboard link alone is not a working connection.