From 99bbe6b6bd682bb10a8783865ee955e0a738c7f9 Mon Sep 17 00:00:00 2001 From: amar-python Date: Mon, 2 Nov 2026 15:51:14 +1100 Subject: [PATCH 1/2] docs: record D4 decision (BYTEA for file storage) Closes decision raised in #68. No local/prod split existed; keeping BYTEA across all environments. Full reasoning in DECISIONS/2026-11-02-file-storage-backend.md. --- DECISIONS/2026-11-02-file-storage-backend.md | 41 ++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 DECISIONS/2026-11-02-file-storage-backend.md diff --git a/DECISIONS/2026-11-02-file-storage-backend.md b/DECISIONS/2026-11-02-file-storage-backend.md new file mode 100644 index 0000000..5d39cba --- /dev/null +++ b/DECISIONS/2026-11-02-file-storage-backend.md @@ -0,0 +1,41 @@ +# Decision: File storage backend + +Status: Decided +Date: 2026-11-02 +Review: On trigger (see below), not scheduled + +## Choice + +**BYTEA in PostgreSQL** for file bodies. One backend across all environments. + +## Context + +#68 asked whether to introduce Azurite as a local Blob emulator to match a BYTEA-local / Blob-prod split. Investigation showed no such split exists: the system runs BYTEA in every environment today. The real decision is upstream — Postgres BYTEA or Azure Blob Storage for file bodies. + +## Reasoning + +- **Transactional integrity.** `api/services/originals.py` commits upload record, blob, source rows and audit together. Moving blob to Azure Storage breaks that guarantee or needs an outbox pattern. +- **Air-gap simplicity.** No Azure Storage SDK, no network reach required for file I/O, no credential rotation. Reinforces #60 (offline install). +- **Operational surface.** One backup system (Flexible Server PITR covers file bodies for free), one restore story, one monitoring target. +- **Scale fits current need.** `MAX_UPLOAD_BYTES = 50 MB`; expected tenant volume is tens of GB per year. Postgres handles this cleanly. + +## Trade-offs accepted + +- DB size scales with upload volume. Backup and restore times grow with it. +- No streaming insert — full file bytes loaded in memory per upload. +- Can't serve files directly with signed URLs. +- Potentially leaves provisioned Terraform storage accounts unused (separate follow-up issue). + +## Reopen trigger + +Reconsider if any of: + +- A tenant's upload volume grows to where PITR restore times exceed 1 hour +- Direct-serve of uploaded files (signed URLs, CDN) becomes a feature requirement +- A deployment target needs multi-region file replication that Postgres HA can't deliver + +## Related + +- #68 (closed with this decision) +- #60 (offline install — reinforced by this decision) +- D3 (ReportLab for PDF — same air-gap discipline) \ No newline at end of file From 2b3152125b8f79d18f40b69c74a2104c0312440f Mon Sep 17 00:00:00 2001 From: amar-python Date: Mon, 2 Nov 2026 16:04:59 +1100 Subject: [PATCH 2/2] docs: record decision to end Lovable platform dependency Resolves #69. The Lovable-generated code in csv-table-hub-main/ already runs standalone against the FastAPI backend; this decision ends the connection to the Lovable platform itself. Frontend architecture (keep/replace that code) tracked in #152. --- .../2026-11-02-end-lovable-dependency.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 DECISIONS/2026-11-02-end-lovable-dependency.md diff --git a/DECISIONS/2026-11-02-end-lovable-dependency.md b/DECISIONS/2026-11-02-end-lovable-dependency.md new file mode 100644 index 0000000..ae4db89 --- /dev/null +++ b/DECISIONS/2026-11-02-end-lovable-dependency.md @@ -0,0 +1,40 @@ +# Decision: End Lovable platform dependency + +Status: Decided +Date: 2026-11-02 +Review: On trigger (see below), not scheduled + +## Choice + +**No further dependency on the Lovable platform.** Any Supabase instance behind the Lovable project is retired without migration. Future frontend work does not sync to or from Lovable. + +## Context + +#69 raised the question of what to do with any data stored in Lovable's Supabase backend. On investigation (`csv-table-hub-main/src` on `main` 59aab1a) the code calls the FastAPI backend and has no Supabase references. The product owner decided to end the Lovable relationship entirely rather than investigate what, if anything, is behind the Lovable project. + +## Reasoning + +- **Simpler ownership.** The code in-repo is self-contained; keeping a connection back to Lovable adds a sync and licensing dimension for no gain the project needs. +- **Fewer external dependencies.** Reinforces #60 (offline install, due 15 Nov) and the broader sovereignty positioning. +- **No evidence of value to preserve.** The frontend does not call Supabase today, so no live feature breaks when the Lovable connection ends. + +## What this does and does not cover + +- **Does:** retires Lovable Supabase without migration. Marks the 4 Oct Lovable-adoption decision as superseded regarding platform dependency. +- **Does not:** decide what to do with the Lovable-generated code already in `csv-table-hub-main/`. That is a separate architecture decision tracked in #152. + +## Trade-offs accepted + +- Any data in Lovable Supabase that has not been checked is lost (no evidence this matters). +- The 4 Oct decision to use the Lovable workflow for visual iteration no longer applies. + +## Reopen trigger + +Reconsider if the Lovable platform offers something no reasonable alternative provides and that becomes a project need. + +## Related + +- #69 (closed with this decision) +- #152 (frontend architecture decision, filed as the follow-up) +- 4 Oct 2026 decision: adopt Lovable frontend (now superseded on platform dependency) +- #60 (offline install, reinforced by this decision) \ No newline at end of file