dinary 0.1.0__tar.gz → 0.2.0__tar.gz

dinary-0.2.0/.env.example

@@ -0,0 +1,5 @@
+# Copy to .env and fill in your values (.env is gitignored)
+#   cp .env.example .env
+DINARY_GOOGLE_SHEETS_SPREADSHEET_ID=your-spreadsheet-id-here
+DINARY_DEPLOY_HOST=ubuntu@<PUBLIC_IP>
+# DINARY_TUNNEL=tailscale  # tailscale (default) | cloudflare | none

{dinary-0.1.0 → dinary-0.2.0}/.github/workflows/ci.yml

@@ -29,7 +29,7 @@ jobs:
   matrix-build:
     strategy:
       matrix:
-        python-version: [3.13]
+        python-version: [3.13, 3.14]
         platform: [ubuntu-latest, macos-latest, windows-latest]
     runs-on: ${{ matrix.platform }}
 
@@ -48,6 +48,17 @@ jobs:
     - name: Install dependencies
       run: uv sync --frozen
 
+    - name: Set up Node.js
+      uses: actions/setup-node@v4
+      with:
+        node-version: 22
+
+    - name: Install JS dependencies
+      run: npm ci
+
+    - name: Run JS tests
+      run: npm test
+
     - name: Test with pytest
       run: ${{ env.PYTEST_CMD }}
 
@@ -73,6 +84,17 @@ jobs:
     - name: Install dependencies
       run: uv sync --frozen
 
+    - name: Set up Node.js
+      uses: actions/setup-node@v4
+      with:
+        node-version: 22
+
+    - name: Install JS dependencies
+      run: npm ci
+
+    - name: Run JS tests with Allure
+      run: npm test
+
     - name: Test with pytest and Allure report
       run: "${{ env.PYTEST_CMD }} --alluredir=./allure-results"
 

{dinary-0.1.0 → dinary-0.2.0}/.gitignore

@@ -16,6 +16,11 @@ pytest-coverage.txt
 **/ru/reference.md
 **/.setup-scripts/
 allure-results/
+allure-report/
 dist/
 credentials.json
 .env
+node_modules/
+data/
+_static/
+backups/

{dinary-0.1.0 → dinary-0.2.0}/.plans/architecture.md

@@ -33,6 +33,21 @@ prioritizing clean data model and scriptability over UI polish.
 - Python-native: `import duckdb` — no server, no driver, no ORM needed.
 - At the expected scale (~30K item rows/year), every query completes in milliseconds.
 
+### Server Memory Constraint
+
+The production design must fit on an always-on VPS with **1 OCPU / 1 GB RAM**.
+This is a hard architectural constraint, not just a deployment preference.
+
+Implications:
+
+- Prefer embedded/local components over additional server daemons. DuckDB is acceptable precisely because it runs in-process and avoids a separate database service.
+- The backend must remain a **small FastAPI + DuckDB process**, not a multi-service stack.
+- Do not require Docker in production on the 1 GB instance.
+- Do not run AI/LLM workloads, heavy batch classification, or other memory-hungry jobs on the server. Those stay on the laptop-side `dinary` agent.
+- Keep background work serialized and bounded: no fan-out workers, no parallel sync pipelines, no large in-memory queues.
+- Google Sheets sync should operate on **dirty months / targeted aggregates**, not full-sheet or full-history recomputation on every request.
+- Caches must stay small and optional. Correctness must not depend on large resident in-memory datasets.
+
 ### Partitioning Strategy
 
 One DuckDB file per year:
@@ -324,9 +339,10 @@ The architecture is agnostic — the input layer is a thin client that sends str
 
 **Phase 0 (MVP) requirements:**
 
-- Camera access for QR scanning (extract URL, send to backend for total + date extraction).
-- Fast manual entry: amount + category selector + optional comment, one tap to submit.
-- Offline data persistence with sync-on-reconnect.
+- Camera access for QR scanning. In the implemented MVP the browser decodes the Serbian fiscal QR locally with `zbar-wasm`, and the client can extract amount/date from the QR URL path without waiting for a backend roundtrip.
+- Fast manual entry: amount + group selector + category selector + optional comment, one tap to submit. Entry saves instantly to IndexedDB first; network send happens only after local persistence is secured.
+- Offline data persistence via IndexedDB (reliable for installed PWAs — iOS Safari eviction only affects non-installed sites). `navigator.storage.persist()` for additional protection.
+- QR scan with parallel processing: while user selects group/category, the app finishes local QR parsing and can still fall back to backend parsing when needed.
 
 **Full requirements (Phase 3 target):**
 
@@ -335,13 +351,9 @@ The architecture is agnostic — the input layer is a thin client that sends str
 - Event selector: if the expense date falls within an active event's date range, auto-suggest it. If multiple active events overlap, show a dropdown. Allow manual assignment/removal.
 - Beneficiary selector: defaults to "семья", quick switch to a specific family member.
 
-#### Frontend Tool Evaluation (Phase 3 prerequisite)
-
-Before building the mobile input layer, evaluate the candidate tools listed below **and research whether other tools exist** that may fit better.
-The list is a starting point, not exhaustive — the no-code/low-code landscape changes rapidly and there may be newer or niche tools
-that satisfy the requirements better than any of these.
+#### Frontend Tool Evaluation
 
-Build a minimal MVP with the most promising 1-2 candidates to compare real-world UX before committing.
+**Evaluation result**: .plans/frontend-evaluation.md
 
 **Initial candidate list:**
 
@@ -381,9 +393,7 @@ Nice-to-have:
 
 ### Three-tier Classification
 
-**Tier 1: Rule-based (instant, free).** `category_rules` table contains patterns (substrings or regexes) matched against item names.
-Example: pattern `MLEKO` matches category "Dairy", pattern `SREDSTVO ZA` matches "Household chemicals".
-Rules are applied immediately when items are ingested. This handles the majority of repeat purchases after an initial learning period.
+**Tier 1: Fuzzy ML based classification like in other personal expense tracking apps.
 
 **Tier 2: AI batch classification (deferred, economical).** Unclassified items (`classification_status = 'pending'`) accumulate on dinary-server throughout the day.
 When the user runs dinary (manually or via scheduler), it fetches pending items from the server API and classifies them using `claude -p`:
@@ -546,9 +556,24 @@ The local agent is stateless — it fetches tasks, processes them, and pushes re
 **What it does NOT do:**
 - Any AI/LLM calls. All AI work is delegated to dinary.
 
-**Hosting:** Oracle Cloud Free Tier (free ARM VM, 4 cores, 24 GB RAM — permanent free tier). Alternative: any cheap VPS, or even a Raspberry Pi at home with Cloudflare Tunnel for external access.
+**Hosting (free, always-on options):**
+
+- **Oracle Cloud Free Tier** — AMD Micro VM (1 OCPU, 1 GB RAM, always available) is recommended for reliability. ARM A1 Flex (up to 4 OCPU, 24 GB RAM) is more powerful but often unavailable due to shared capacity pool. Run directly with uvicorn as a systemd service (no Docker — saves RAM on 1 GB instances). Docker available for local development.
+- **Self-hosted (Mac/PC)** — run locally, expose via Tailscale Serve (tailnet-only) or Cloudflare Tunnel (custom domain + Cloudflare Access). Aligns with Phase 4 architecture (dinary desktop app on the same machine).
 
-**Accessibility:** Dashboard and API served via Cloudflare Tunnel (free, no public IP needed) or directly from the VPS.
+**Important:** sleeping/serverless hosting (Render free tier, AWS Lambda, etc.) is **not suitable** — the PWA on iOS cannot run background sync, so the server must respond within 1-2 seconds while the user still has the app open.
+
+**Accessibility:** API served via Cloudflare Tunnel or Tailscale Serve. For the current MVP, Tailscale Serve is the preferred default because it avoids public internet exposure.
+
+#### 1 GB Server Rules
+
+Because the reference production target is the Oracle AMD Micro instance, the server-side implementation must follow these rules:
+
+- Run a single app process by default. Do not scale by adding multiple uvicorn workers on the 1 GB host.
+- Avoid colocating extra infrastructure on the VPS: no separate Postgres, Redis, Celery, message broker, or background analytics service in Phase 1.
+- Treat Google Sheets sync as lightweight projection work, not as a second analytics engine.
+- Prefer on-demand or dirty-month scoped recomputation over broad periodic rebuilds.
+- Any future feature that materially increases steady-state RAM use must be designed to run off-box (for example on the laptop-side agent) or be explicitly deferred until a larger host is available.
 
 ### dinary (User's Laptop)
 
@@ -612,27 +637,28 @@ daemon lifecycle management) depends on the GUI framework choice and will be det
 
 ### Security
 
-- dinary-server API protected by API key or mutual TLS (single user, no need for full auth system).
-- Cloudflare Tunnel provides HTTPS without exposing the VPS directly.
+- dinary-server API protected by Cloudflare Access (if using Cloudflare Tunnel) or by tailnet membership (if using Tailscale Serve). Single user, no need for an in-app auth system.
+- Cloudflare Tunnel or Tailscale Serve provides HTTPS without exposing the application port directly to the internet.
 - DuckDB files are not accessible from the internet — only through the dinary-server API.
 
 ---
 
 ## Build Plan (Incremental Phases)
 
-### Phase 0: MVP — Manual Entry + QR Total → Google Sheets (no DuckDB, no line parsing, no AI)
+### Phase 0: MVP — Manual Entry + QR Total → Google Sheets (completed)
 
 The fastest path to replacing manual spreadsheet editing, with early validation of QR scanning.
 No new database, no line-item parsing — just a mobile frontend that writes directly to the existing Google Sheets structure.
 
 **Scope:**
 
-- A mobile frontend (chosen from the non-disqualified candidates in the evaluation table) with a simple form: amount (RSD) + category (dropdown from the existing ~33 categories) + category group (auto-filled from category) + optional comment.
-- **QR scanning:** the user scans a Serbian fiscal receipt QR code on the phone. The backend fetches the receipt page from SUF PURS, extracts only the **total amount** and **date** — no line-item parsing, no store extraction. The amount and date are pre-filled into the entry form; the user picks a category and submits. This is treated as a single expense entry (one row), same as manual entry.
-- A lightweight backend (Python script or serverless function) that receives the entry and writes it to the existing Google Sheets spreadsheet via the Sheets API.
-- **Auto-month creation:** if the backend detects that rows for the current month don't exist yet in the sheet, it automatically creates the full block of category rows for the new month (copying the category/group structure from the previous month). This eliminates the most tedious manual step.
-- **Currency conversion:** the EUR/RSD exchange rate is stored in the sheet itself, in a cell to the right of the first row of each month block. When the backend creates a new month or writes the first expense of the month, it checks the rate cell: if empty, it fetches the current NBS middle rate from `kurs.resenje.org` (same API as `ibkr-porez-py`) and writes it. Each month thus has its own visible rate. The EUR amount is derived as `amount_rsd / rate`.
-- **Offline queue:** when the device has no internet, completed entries (manual or QR-based) are persisted locally on the device (e.g., IndexedDB for PWA, local storage for the chosen tool). When connectivity is restored, the queue is flushed to the backend automatically. The user must never lose an entry due to network unavailability. The specific storage mechanism depends on the chosen frontend tool — this is a key evaluation criterion.
+- A mobile frontend (implemented as a PWA) with a simple form: amount (RSD) + group dropdown + category dropdown + optional comment. This matches the existing spreadsheet model better than a single huge selector.
+- **QR scanning with parallel processing:** the user scans a Serbian fiscal receipt QR code on the phone. The QR code is decoded on the device (fully offline — client-side image processing) using `zbar-wasm`. The client extracts amount/date from the receipt URL immediately and shows the form without waiting for the backend. Backend QR parsing remains as a fallback/API capability. No line-item parsing, no store extraction in Phase 0.
+- A FastAPI backend that receives the entry and writes it to the existing Google Sheets spreadsheet via the Sheets API. FastAPI (not serverless) because it carries forward into Phase 1 (DuckDB) and Phase 4 (AI agent API) without rewriting.
+- **Auto-month creation:** if the backend detects that rows for the current month don't exist yet in the sheet, it automatically creates the full block of category rows for the new month by copying the previous block, preserving spreadsheet formulas, zeroing RSD values, and inserting the new month at the top of the yearly sheet.
+- **Currency conversion:** the EUR/RSD exchange rate is stored in the sheet itself, on the first row of each month block. When the backend creates a new month or writes the first expense of the month, it checks that month header row and writes the rate only there if missing.
+- **Offline queue:** entries are stored in IndexedDB on the device before any network call. When connectivity is restored, the queue is flushed automatically on app open, on `online`, and after successful user actions when pending items exist. The user must never lose an entry due to network or server failure.
+- **Always-on server required:** PWA on iOS cannot run background sync — sync only happens while the app is open. The server must respond within 1-2 seconds. Sleeping/serverless hosting (Render free tier, Lambda) is not suitable. Use Oracle Cloud Free Tier (AMD Micro, always on) or self-hosted Mac/PC with Tailscale Serve / Cloudflare Tunnel.
 - No line-item parsing, no store extraction, no DuckDB, no AI. The user picks the category manually, just as they do now — but from a phone instead of editing a spreadsheet. QR scanning only extracts the receipt total amount and date, not individual items or store.
 
 **What this validates:**
@@ -647,24 +673,57 @@ No new database, no line-item parsing — just a mobile frontend that writes dir
 - PWA frontend (in `static/`), backend, manuals, deployment scripts — all in the dinary-server repo
 - The `dinary` repo is not used in Phase 0 (reserved for the Rust desktop app, Phase 4+)
 
+**Operational conventions introduced by the completed MVP:**
+
+- Local/CI regression entry point is `inv test`, which runs both pytest and Vitest and writes a shared `allure-results/` directory.
+- New tests must preserve the existing Allure taxonomy unless there is an explicit architecture-level reason to extend it.
+- Phase 0 approved Allure epics are: `Data Safety`, `Google Sheets`, `API`, `Services`, `Build`.
+- Phase 0 approved features are:
+- `Data Safety`: `Formula Preservation`, `Comment Preservation`, `Column Protection`, `Offline Queue`, `No Data Loss`
+- `Google Sheets`: `Read Categories`, `Write Expense`, `Exchange Rate`, `Month Creation`, `Helpers`
+- `API`: `Health`, `Categories`, `Expenses`, `QR Parse`
+- `Services`: `Category Store`, `Exchange Rate`, `QR Parser`
+- `Build`: `Version`
+
 **Exit criteria for Phase 0:**
 - The user has used the system daily for 2+ weeks and no longer opens the spreadsheet to enter data manually.
 - QR scanning has been used successfully on real receipts (camera → URL extraction → total + date pre-fill) and is confirmed to work reliably with the chosen frontend tool.
 
-### Phase 1: Data Foundation & Backend Deployment (dinary-server)
-- Set up DuckDB schema (config.duckdb + budget_2026.duckdb) on VPS (Oracle Cloud Free Tier).
-- Deploy dinary-server (FastAPI) with basic REST API for expense ingestion.
-- Migrate existing Google Sheets data into DuckDB.
-- Write basic SQL queries for monthly aggregates.
-- Backend now writes to both DuckDB (primary) and Google Sheets (view layer).
-- Set up Cloudflare Tunnel or direct HTTPS access to the backend.
+### Phase 1: Data Foundation & Idempotent Ingestion (dinary-server) ✓ IMPLEMENTED
+
+Detailed plan: [phase1.md](phase1.md)
+
+- DuckDB with the **full 5-dimensional classification schema** (category, beneficiary, event, tags, store) from day one.
+- **sheet-to-5D mapping table** (`sheet_category_mapping`) decomposes the current Google Sheet's flat `(Расходы, Конверт)` pairs into proper 5D assignments.
+- **PWA unchanged** -- sends `(category, group)` as in Phase 0; server resolves to 5D via mapping table.
+- DuckDB-backed expense ingestion with idempotent deduplication via `expenses.id PRIMARY KEY`.
+- Google Sheets is a derived read-only view: sync layer projects 5D DuckDB data back into sheet format.
+- Client generates `expense_id = crypto.randomUUID()` at enqueue time; server returns `200 created`, `200 duplicate`, or `409 Conflict`.
+- Allure test suite covers: `Data Safety / Deduplication` (Python + JS), `DuckDB / Bootstrap`, `DuckDB / Mapping`, `DuckDB / Travel Events`, `DuckDB / Reverse Mapping`, `DuckDB / Year Boundary`.
+
+**Historical data migration is NOT part of Phase 1.** After Phase 1 cutover, DuckDB holds only new expenses; historical data remains in Google Sheets until Phase 1.5.
+
+### Phase 1.5: Historical Data Migration
+
+The existing Google Sheets contain ~10 years of data. Nearly every year used a slightly different category system (different category names, different envelope groupings) and even different column layouts. This makes bulk import impractical -- each year requires individual analysis and its own mapping.
+
+- Analyze each yearly Google Sheets tab individually: identify that year's category/envelope structure, column layout, and how it differs from other years.
+- Build per-year mapping from that year's flat `(category, envelope)` pairs to the 5D classification model, handling cases where the same category name meant different things in different years.
+- For "путешествия" envelopes: create a per-year synthetic event "отпуск-YYYY" (`date_from = YYYY-01-01`, `date_to = YYYY-12-31`) and map all travel rows to it (same approach as Phase 1 uses for the current year). Once the PWA switches to native 5D input (Phase 2+), set `date_to` of the last synthetic travel event to the release date of the 5D PWA. From that date forward, the user creates specific named trips instead of a per-year umbrella, and the auto-attach rule for `sheet_group = "путешествия"` is retired.
+- Build per-year import scripts that create synthetic expense rows in `budget_YYYY.duckdb` with `source = 'legacy_import'`.
+- Reconcile imported totals against original sheet totals.
+- After successful import, run DuckDB -> Google Sheets sync to verify the rebuilt sheet matches legacy data.
 
 ### Phase 2: Receipt Parser
 - Integrate or adapt sr-invoice-parser for fetching and parsing Serbian fiscal receipts from SUF PURS URLs.
 - Build the ingestion pipeline: URL → fetch HTML → parse line items → insert into `expenses` table in DuckDB.
-- Implement rule-based auto-classification.
+- Implement fuzzy ML / AI auto-classification that produces 5D classification directly (category, beneficiary, event, tags, store).
+- Change the PWA so it no longer works in Google Sheets terms for new receipt/manual flows. From Phase 2 onward, the PWA should use the native 5D classification model directly instead of asking the user for `(Расходы, Конверт)` from the spreadsheet.
+- Google Sheets sync uses the `sheet_category_mapping` table in reverse: from the 5D classification produced by AI/rules, determine the target `(Расходы, Конверт)` row in the sheet.
 
 ### Phase 3: Mobile Input — Full Version (dinary-app)
+**Done as part of MVP**
+
 - **3a: Frontend tool evaluation.
 
   - ** Research the candidate tools from the evaluation table (see "Frontend Tool Evaluation" section) **and any other tools discovered during research**.
@@ -693,6 +752,7 @@ No new database, no line-item parsing — just a mobile frontend that writes dir
   - Implement the task queue API on dinary-server (`/api/tasks/*`).
   - Build the batch classification flow: fetch pending → `claude -p` → push results.
   - GUI: interactive AI API calls for responsive receipt extraction (paste text/PDF → AI API → extract amount, date, items → store via server API).
+  - After AI classification of receipt line items is available, change the PWA receipt flow so scanning a receipt submits it immediately without waiting for a manual `Save` press. The scan should create the receipt/import job right away; later user interaction is only for review/correction, not for the initial submission.
   - Implement the review/confirm flow (via GUI or CLI).
   - Wire up rule learning (confirmed classifications → new rules in `category_rules`).
 
@@ -709,8 +769,13 @@ No new database, no line-item parsing — just a mobile frontend that writes dir
 Each phase is independently useful.
 
 - Phase 0 alone eliminates manual spreadsheet editing, validates QR scanning, and validates the mobile input tool.
-- Phase 1 establishes the proper data foundation.
+- Phase 1 establishes the proper data foundation with idempotent ingestion and deduplication.
+- Phase 1.5 migrates historical Google Sheets data into DuckDB (complex, per-year analysis required).
 - Phase 2 solves the supermarket opacity problem.
 - Phase 3 adds full line-item QR flow and complete mobile input.
 - Phase 4 builds the desktop app (daemon + GUI) with AI classification and responsive receipt extraction.
 - Phases 5-6 add dashboards, AI analysis, and Google Sheets sync.
+
+## Open questions
+
+- **Cross-year events**: events (e.g. a trip) can span a year boundary (start in December, end in January). Since `expenses` are partitioned into yearly `budget_YYYY.duckdb` files but `events` live in the shared `config.duckdb`, this works at the data level -- expenses in both years reference the same `event_id`. However, reporting and sync need to handle the case where a single event's expenses are split across two yearly DB files. Decide whether to query both years when summarizing an event, or accept per-year totals as sufficient.

dinary-0.2.0/.plans/deploy-oracle-no-db.md

@@ -0,0 +1,168 @@
+# Deploy to Oracle Cloud (replace existing, no DB)
+
+## Context
+
+- Oracle Cloud Free Tier VM is already running a previous version of dinary-server
+- Tailscale tunnel is configured, systemd service `dinary` is active
+- There is no existing DuckDB data to preserve (no `config.duckdb`, no `budget_*.duckdb`)
+- New version on `main` uses `yoyo` migrations instead of inline DDL, dropped `ibis`/`pandas`
+
+## Pre-deploy checks (on laptop)
+
+```bash
+# 1. Ensure .env is configured
+cat .env
+# Should show DINARY_DEPLOY_HOST, DINARY_GOOGLE_SHEETS_SPREADSHEET_ID
+
+# 2. Verify SSH access
+inv ssh
+# Ctrl-D to exit
+
+# 3. Verify local tests pass
+uv run pytest tests/ -q
+
+# 4. Verify main is pushed
+git log --oneline -3 origin/main
+# Should show "yoyo migrations" as latest
+```
+
+## Deploy
+
+```bash
+inv deploy
+```
+
+This runs the following steps automatically via SSH:
+
+1. **Pre-deploy backup** of remote `data/` (will be empty or missing — that is expected)
+2. `git pull` on the server to get latest `main`
+3. `uv sync --no-dev` to install/remove dependencies (installs `yoyo-migrations`, removes `ibis`/`pandas`/`pyarrow` if present)
+4. `mkdir -p data/`
+5. **Apply config migrations** — creates fresh `config.duckdb` with `yoyo` version tracking
+6. Render `__VERSION__` into static assets
+7. `systemctl restart dinary`
+8. Health check: `curl localhost:8000/api/health`
+
+## Post-deploy verification
+
+Run these from the laptop, in order:
+
+### Step 1: Service health
+
+```bash
+inv status
+```
+
+Expected: `dinary.service` active (running), Tailscale serve active.
+
+### Step 2: Health endpoint
+
+```bash
+inv ssh
+curl -s http://localhost:8000/api/health | python3 -m json.tool
+```
+
+Expected: `{"status": "ok", "version": "<short git hash>"}`.
+
+### Step 3: Logs — no errors on startup
+
+```bash
+inv logs --lines=30
+```
+
+Look for:
+- no Python tracebacks
+- no import errors (especially no `ibis` / `pandas` references)
+- migration log line if present
+
+### Step 4: Seed config from Google Sheets
+
+Since there is no existing DB, seed reference data:
+
+```bash
+inv seed-config
+```
+
+Expected: JSON summary with `category_groups > 0`, `categories > 0`, `mappings_created > 0`.
+
+### Step 5: Verify categories API
+
+```bash
+inv ssh
+curl -s http://localhost:8000/api/categories | python3 -m json.tool
+```
+
+Expected: list of category objects from seeded data.
+
+### Step 6: Test expense creation (from phone or curl)
+
+```bash
+inv ssh
+curl -s -X POST http://localhost:8000/api/expenses \
+  -H 'Content-Type: application/json' \
+  -d '{
+    "expense_id": "deploy-test-1",
+    "amount": 100,
+    "currency": "RSD",
+    "category": "<a known category from step 5>",
+    "group": "<its group>",
+    "date": "2026-04-16",
+    "comment": "deploy smoke test"
+  }' | python3 -m json.tool
+```
+
+Expected: `{"status": "created", ...}`.
+
+### Step 7: Verify budget DB was created
+
+```bash
+inv ssh
+ls -la ~/dinary-server/data/
+```
+
+Expected: `config.duckdb` and `budget_2026.duckdb` present.
+
+### Step 8: Verify yoyo tracking tables
+
+```bash
+inv ssh
+cd ~/dinary-server && source ~/.local/bin/env
+uv run python -c "
+import duckdb
+for f in ['data/config.duckdb', 'data/budget_2026.duckdb']:
+    con = duckdb.connect(f, read_only=True)
+    rows = con.execute('SELECT * FROM _yoyo_migration').fetchall()
+    print(f'{f}: {len(rows)} migration(s) applied')
+    con.close()
+"
+```
+
+Expected: 1 migration applied in each file.
+
+### Step 9: PWA smoke test
+
+Open the Tailscale URL on phone. Verify the app loads, categories are visible, and a test expense can be submitted through the UI.
+
+### Step 10: Verify sync (optional)
+
+```bash
+inv sync
+```
+
+Expected: `Synced 1 months` (or however many dirty months exist after the test expense).
+
+## Rollback
+
+If something goes wrong:
+
+```bash
+# Deploy the previous known-good commit
+inv deploy --ref=<previous commit hash>
+```
+
+Since there is no data to lose (no pre-existing DB), rollback is just redeploying the old code. The `data/` directory can be safely deleted and recreated.
+
+## After successful deploy
+
+- Delete the test expense row from Google Sheets if sync wrote it
+- Or leave it as a smoke test record

{dinary-0.1.0 → dinary-0.2.0}/.plans/frontend-evaluation.md

@@ -34,8 +34,8 @@
 
 ### Tech stack
 
-- **html5-qrcode** (MIT) for QR scanning via rear camera
-- **IndexedDB** for offline entry queue
-- **Service Worker** for caching and background sync
+- **zbar-wasm** for live QR scanning in the browser. Earlier MVP experiments with `html5-qrcode` and other JS scanners were not reliable enough on dense Serbian fiscal QR codes, especially on iOS.
+- **IndexedDB** for the offline entry queue
+- **Service Worker** for caching and installability
 - Vanilla HTML/CSS/JS — no build step, no framework
-- Served by FastAPI `StaticFiles` (same origin, same Cloudflare Tunnel)
+- Served by FastAPI `StaticFiles` (same origin; typically exposed through Tailscale Serve, optionally Cloudflare Tunnel)