Architecture
Review the high-level technical model behind the Ops desktop app, the Supabase backend, and the runtime configuration workflow.
Ops is best understood as a desktop interface over a Supabase-backed application contract. The desktop bundle is important, but the real business guarantees come from the database rules, auth model, and server-side operations.
Polter completes the picture by acting as the workflow orchestrator that prepares repositories and packaged apps for a specific backend.
Desktop app
The desktop layer presents the operational interface, stores local runtime connection details, and bridges into native packaging behavior through Tauri. It should stay thin with respect to backend business rules.
Supabase backend
- Supabase Auth handles sign-in and token issuance.
- Postgres stores operational data and schema.
- RLS policies enforce which records each role can access.
- RPC functions handle critical transactional workflows.
Auth, RLS, and RPC concepts
Authentication proves who the user is. Row-level security decides what that user can see or change. RPC functions are where you put multi-step server-side operations that need consistency, such as inventory reservations or sale finalization.
Runtime configuration model
Check for bootstrap payload
Installed desktop launches can consume a one-time payload that contains the Supabase connection details.
Persist runtime config
After the payload is imported, the app stores the resolved connection locally for later launches.
Fall back to env in development
If runtime config is not present in a source checkout, .env.local can still supply the development connection.
Polter as workflow orchestrator
- Repository bootstrap — setup and link workflows prepare the source checkout for the intended project.
- Migration control — migrate commands provide explicit push, lint, reset, and local-reset operations.
- Runtime preparation — configure and install write the bootstrap material used by the packaged app.