Current state
Most of Thalix Vault's MVP surface is implemented and tested. This page exists so no reader mistakes "the code exists" for "this is live and usable end-to-end today." Three different kinds of gap show up across this documentation, and they mean different things:
- Code-incomplete — the feature genuinely does not exist yet (for example, the Vault MCP server, tracked as epic #72).
- Operator-blocked — the code and tooling are complete and tested, but a one-time human action (creating a repository, generating a production key, buying a certificate) hasn't happened yet.
- Known, accepted limitation — implemented as designed, with a documented trade-off that is not currently scheduled to change.
Single Supabase data plane
There is exactly one Supabase project per environment: Postgres, Auth, and Storage are all the same managed service. This is a simplicity trade-off, not an oversight — it means:
- No cross-region failover or independent scaling of the catalog vs. object storage.
- A Supabase-side incident affects identity, files, and audit retrieval simultaneously; there is no independent-availability boundary between them today.
- Backup, restore, and disaster-recovery procedures are whatever Supabase's managed-project tooling provides; this repository does not yet layer its own independent backup pipeline on top.
Standalone releases: implemented, unpublished
The entire standalone-installer pipeline — build, sign, manifest, publish, and the client-side verify/activate/rollback engine — is implemented and tested (#12). What has not happened is the operator actions that make a release actually reachable by a real user:
- The
thalixinc/thalix-vault-releasesrepository does not exist yet. - No production Ed25519 signing key has been generated and safeguarded.
- No tag has ever been cut, so no artifact has ever actually been published.
See Install tv (standalone binary) and Releasing tv for the exact runbook once those operator steps happen. Until then, the only working install path is the private Git checkout.
macOS: signed, not notarized
Standalone macOS builds are code-signed with a real Developer ID (macos-sign.mjs verifies the codesign -dv authority line at build time), but not submitted to Apple's notarization service — that requires a one-time notarytool store-credentials operator setup this repository cannot perform for you. Until notarization happens, Gatekeeper still challenges a freshly downloaded binary; see Install for the exact xattr workaround.
Windows: unsigned
Thalix has no Authenticode code-signing certificate. Every Windows standalone build is unsigned, and SmartScreen will show an "unrecognized publisher" warning. This is a known, accepted limitation for MVP, not a bug — checksum verification (documented in Install) is the mitigation until a certificate is obtained.
Invitations: implemented and tested
Administrator invitations are built end to end. tv admin user invite | invites | uninvite drives the admin_invite_user RPC through the service-role-only delivery endpoint in the identity Edge Function, which sends the invitation mail via GoTrue's OTP delivery. The path is covered by contract and security tests (cli-admin-invite, identity-invites-roles, invitation-http). See Invitations.
Reconciliation: detection exposed, cleanup manual
reconcile_stale_file_uploads is implemented, tested, and administrator-gated at the database layer, and tv admin reconcile exposes it as a read-only report that cross-checks each stale pending upload against live storage. Actually cleaning up (deleting orphaned objects and pending rows) remains a manual, out-of-band step. See Reconciliation.
What is genuinely complete
Everything else referenced elsewhere in this documentation set — identity/session, Root Folders and metadata, files and versions and lifecycle, access delegation, the unified audit surface, the Agent Skill (install/doctor/update/uninstall/export), ICM templates and workspaces, the Tier 1 local stdio MCP server, and the standalone-install tooling itself — is implemented, tested, and merged. Architecture overview's module table is the authoritative per-module status list.