chore(release): 0.9.0

CHANGELOG.md

@@ -5,6 +5,16 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.9.0] - 2026-05-19
+
+### Added
+
+- Vault deletion — owners can delete a vault from the vault picker; all items inside are permanently purged immediately
+
+### Fixed
+
+- Filter row consolidated into a single layout component; `isMobile` prop removed from `VaultSheet` and `ItemCard`; `ListPanelAnimator` and `SyncStatusBar` polished; flaky e2e specs for folders, sync, and type-filter corrected
+
 ## [0.8.0] - 2026-05-18
 
 ### Added

CONTEXT.md

@@ -46,7 +46,8 @@ The unlocked, in-memory set `{MasterKey, VaultKey(s), private signing key}` held
 ### Vault domain
 
 **Vault**:
-A named container of **VaultItems** owned by one user, optionally shared.
+A named container of **VaultItems** owned by one user, optionally shared. Deleting a vault permanently purges all its items immediately — no trash, no recovery. A user must always retain at least one vault; deletion is blocked (422) when only one remains.
+_Invariant_: every account holds at least one vault at all times.
 
 **VaultItem**:
 One stored credential, fully decrypted. Type-discriminated payload: login, note, card, identity, TOTP, crypto wallet, dev credential. Lives in the browser only — the server never sees this shape. Defined in `packages/vault/src/item/schema.ts`.
@@ -184,7 +185,7 @@ Composes access check + quota + repo for each write ceremony: `createItem`, `bat
 Vault-table queries: `createInitial`, `createVault`, `listOwnedByUser`, `listSharedWithUser`, `findOwnedById`, `updateMetadata`, `listIdsByOwner`.
 
 **VaultsService** (`vaults/service.ts`):
-`createVault` ceremony — checks owner quota, then inserts. Other vault ops (update, list) skip service.
+`createVault` — checks owner quota, then inserts. `deleteVault` — enforces the last-vault guard (rejects if only one vault remains), then deletes the vault and permanently purges all its items. Other vault ops (update, list) skip service.
 
 **SharesRepository** + **SharesService** (`vaults/shares/`):
 Repo: `listForVault`, `create`, `findByIdForUser`, `deleteById`. Service: `createShare` (self-share check + receiver lookup + insert), `deleteShare` (caller must be owner or receiver).

apps/server/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blindpass/server",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "private": true,
   "type": "module",
   "scripts": {

apps/web/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blindpass/web",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "private": true,
   "type": "module",
   "scripts": {

docs/adr/0008-vault-deletion-name-confirmation-not-totp.md

@@ -0,0 +1,10 @@
+# Vault deletion uses name-typed confirmation, not TOTP
+
+Deleting a vault permanently purges all its items with no recovery path. Despite that severity, the confirmation gate is a name-typed dialog ("type the vault name to confirm"), not a TOTP re-entry as account deletion requires.
+
+The asymmetry is deliberate. Account deletion erases the entire account — keys, vaults, items, auth state — and is truly irreversible. Vault deletion is scoped to one container; the last-vault guard (delete blocked when only one vault remains) removes the scenario where vault deletion approximates account destruction. The session is already authenticated and the vault already unlocked, so a TOTP gate would add friction — requiring the authenticator app to be in hand — without a meaningful security benefit over the typed-name ceremony, which already forces deliberate user intent. A TOTP gate would also fail for users temporarily without their authenticator device, blocking a legitimate destructive action they own.
+
+## Considered alternatives
+
+- **TOTP gate (matching account deletion).** Rejected: disproportionate friction for a scoped, owner-initiated action; the last-vault guard eliminates the worst-case scenario; session auth + vault unlock already establish trust.
+- **Soft-delete / grace period.** Rejected: vault deletion should be immediate and deliberate; a grace period would persist UI deliberation as server state (the same reasoning as ADR-0001 for account deletion).

package.json

@@ -1,6 +1,6 @@
 {
   "name": "blindpass",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "private": true,
   "type": "module",
   "packageManager": "pnpm@10.33.0",

packages/api-schema/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blindpass/api-schema",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "private": true,
   "type": "module",
   "exports": {

packages/crypto/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blindpass/crypto",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "private": true,
   "type": "module",
   "exports": {

packages/types/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blindpass/types",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "private": true,
   "type": "module",
   "exports": {

packages/vault/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blindpass/vault",
-  "version": "0.8.0",
+  "version": "0.9.0",
   "private": true,
   "type": "module",
   "exports": {