3.5 KiB
Caterium recovery — 17 September 2026
Target: caterium-fresh, Supabase reference usfjwhztqoopzzfmfbis, region eu-central-1. The retired project was deleted; this recovery creates an empty application. No old users, company data, or passwords are imported. The ai-staff project is outside this recovery.
Database
The supplied production archive and Git history did not contain the v17 normalized-state foundation or the complete promo/developer RPC layer. These were reconstructed from the current frontend contracts and the retained SQL. The v17.8 developer panel and v17.9 developer settings scripts were recovered from the local desktop source.
supabase/migrations/20260917150000_fresh_caterium.sql is the complete transaction applied to the empty target database. The migration rejects an already initialized Caterium schema. Its 25 inputs, in execution order, are listed in tests/recovery/manifest.json; npm run build:recovery reproduces the bundle. Further production changes must use a new migration rather than replaying this baseline.
Deployment verification found 26 public tables, RLS enabled on all 26, two Caterium cron jobs, zero workspaces and zero auth users. The migration is recorded in supabase_migrations.schema_migrations.
The recovered layer includes revision conflict detection, permission-filtered snapshots, normalized orders/catalog/clients, backup and automation RPCs, subscription onboarding, promo codes and developer aliases. Recovery also fixes ambiguous client upserts, enforces confirmed owner email, and avoids an administrator-only audit helper during ordinary owner onboarding. Developer operations enforce AAL2.
npm run test:db uses a disposable local PGlite database with mocked Supabase auth/storage/realtime/cron infrastructure. It exercises owner onboarding, save/read, optimistic conflicts, backups, employee membership, cross-company denial, viewer write denial, MFA restrictions and developer RPCs. It does not replace a real signed-in production acceptance test or verify Supabase email delivery.
Application and hosting
The app and PHP proxy now target the new project. Only the public publishable key is present in the frontend. Existing browser configuration for the retired backend is archived locally and reset; old local workspace data remains isolated through the existing workspace-switch mechanism. A new service-worker cache and asset version deliver the change to installed clients.
GitHub main runs QA and promotes the tested commit to production. Timeweb sync deploys public/ to ~/caterium-app/public_html. The separately hosted PHP proxy is deployed to ~/public_html/api-proxy/index.php; preserve a copy in ~/.caterium-deploy/manual-backups before replacement.
Both Edge Functions are deployed to the new Supabase project: caterium-create-employee and caterium-platform-auth-admin. JWT verification remains enabled; the platform auth function additionally checks the MFA-protected developer dashboard RPC before privileged operations. Supabase Site URL is https://app.caterium.ru, with https://app.caterium.ru/** allowed for redirects. Email confirmation remains enabled.
First use
All old accounts were deleted with the old database. A new owner account must register, confirm its email and set a new password. The first platform administrator and any onboarding promo must be provisioned for the user-confirmed owner identity; there is no universal recovery password or open administrator bootstrap. A real login, email delivery, and company onboarding must be checked once that identity is available.