DEV Community: qnbs

Preserve First: Recovery Design for Local Creative Data

qnbs — Sun, 27 Sep 2026 23:47:22 +0000

The most dangerous button in a creative tool is not "delete." It is the recovery dialog that appears when something is already wrong: "We couldn't load your project — start fresh?" One click, and the file that failed to parse at 23:40 is gone at 23:41, together with the chapter it contained. The tool was trying to help.

Local-first software cannot afford that. There is no server copy, no support ticket that restores yesterday's state, no account trash bin. When your app is the only place a manuscript exists, recovery code is the product's promise — and the promise has to be: preservation is the default, destruction requires narrow, earned authority.

This is how that rule is implemented in WorldScript Studio, an open-source writing studio that stores projects in the browser (IndexedDB) or on the desktop filesystem. Code references are from the repository at commit 2d9157c0 (2026-09-28), release v1.28.8; simplified excerpts are labeled.

1. Refuse, don't improvise

The canonical autosave path classifies what it finds on disk before writing anything. The classification set is small and explicit:

// services/projectAutosaveCanonicalWriter.ts (excerpt)
export type CanonicalAutosaveRefusal =
  | 'MALFORMED'
  | 'FUTURE'
  | 'SUPPORTED_OLDER'
  | 'UNSUPPORTED_OLDER'
  | 'GENERATION_CONTRADICTION';

The important part is what happens on anything that is not a clean current state — the header comment states it plainly: "fail closed with a typed refusal; there is deliberately NO fallback to storageService.saveProject." No best-effort write over a file whose shape the app did not expect. A FUTURE record (written by a newer build) is not "fixed" by an older one. A GENERATION_CONTRADICTION is not smoothed over.

And a refusal is not a silent no-op: it rejects the coordinator operation, so indexing, analytics, and the UI success state cannot claim durability that never happened. A refusal is a loud, typed, user-visible "I did not save, and here is why" — which is precisely what lets the user keep the still-open editor state and act, instead of discovering the loss tomorrow.

2. Destruction needs earned authority

When startup itself fails, the recovery options are computed by one pure function — and its default answer to every destructive question is no:

// services/startupRecoveryPolicy.ts (excerpt)
// a stored project the editor cannot load is kept as it is —
// reload only; no quarantine, no database reset.
if (error instanceof PersistedProjectNotLoadableError) {
  return {
    failureKind: 'project-corrupt',
    canQuarantine: false,
    canReset: false,
    canSafeOpen: false,
  };
}

The full matrix is deliberately narrow:

Quarantine exists only for a corrupt project on the filesystem backend.
Reset exists only for a storage-level failure on IndexedDB.
Safe Open exists only for a refused desktop project (unsupported version, migration gap).

A project I/O error, an unavailable desktop storage authority, a corrupt in-browser record: none of them can escalate into quarantine or reset. The code comment frames the design rule directly — non-destructive failures never gain quarantine authority. Recoverability is not a mood the UI is in; it is a property of the failure kind, decided in one audited place.

3. Quarantine is a rename, not a delete

When quarantine is warranted, it moves the project directory into a quarantined-projects area — recoverable, inspectable, reversible. The interesting engineering is in what surrounds that rename:

Every destructive operation takes a project lock — the same lock that fenced writes hold — so a passing check cannot be invalidated by a delete racing a save.
The lock file lives outside the project directory, as a sibling. A lock inside the directory could be relocated by the very quarantine it is supposed to fence.
A random per-creation token sits next to project.json. Delete and quarantine take it with the directory; every create writes a fresh one. A deleted-then-recreated project never matches an old window's token — even if the new project.json is byte-identical to the old one.

That last mechanism exists because of a multi-window failure mode the code names explicitly: if window B deletes a project while window A still holds a loaded baseline, a save from A must not recreate it — recreating it from the stale snapshot would resurrect deliberately removed data. Preservation has a second side: preserving means respecting destruction that already legitimately happened. The token is how the system tells "same project, still there" apart from "same bytes, different lifetime."

4. The reset that fails closed

The browser-side nuclear option — resetting IndexedDB — runs behind a gate with a generation/epoch invariant: a connection open that started before or during a reset can never proceed against the new database. Every registered connection closer must finish its teardown before the reset settles, including closers registered while the drain is already running. And if any closer throws, the whole reset rejects — fail-closed, leaving the old state untouched rather than half-torn-down.

Half-recovery is worse than no recovery. A reset that completes while one connection still holds the old store open has not recovered anything; it has created two truths.

5. The escape hatch the user owns

All of the above protects data inside the app's stores. The final layer gives the user a copy outside of them: a full-library backup, aggregated into a single archive — a ZIP carrying a vault.bin encrypted with AES-256-GCM, the key derived from a user passphrase via PBKDF2-HMAC-SHA-256 with 600,000 iterations (the OWASP 2024 minimum, as the code comment notes).

Two properties matter here. First, the passphrase is the user's, not the platform's — the backup stays readable even if the app, the account that never existed, and the vendor all disappear. Second, encryption travels with the file: a backup emailed to yourself or dropped into a cloud folder does not become a plaintext copy of your manuscript.

The checklist I would hand another team

Type your refusals. Every non-clean state gets a named classification and a loud stop — never a silent fallback write.
Scope destructive authority by failure kind. Corruption, I/O errors, and version gaps are different events; only one of them may even offer quarantine.
Quarantine, don't delete. Rename into recoverable space; fence with locks; detect resurrection across windows.
Fail closed on the nuclear path. A reset that cannot fully drain must not half-execute.
Give the user an owned exit. An encrypted, passphrase-held backup that outlives the app itself.

Then run the adversarial test: corrupt a project file by hand, open the app, and watch what it offers. If the first option destroys anything, the recovery design is not done.

Source note: WorldScript Studio is open source (github.com/qnbs/WorldScript-Studio). Code references correspond to main at 2d9157c0 (2026-09-28); release anchor v1.28.8. Key files: services/projectAutosaveCanonicalWriter.ts, services/startupRecoveryPolicy.ts, services/fs/projectFsStore.ts, services/storage/idbResetGate.ts, services/libraryBackupService.ts. Part of the "Engineering WorldScript Studio" series.

AI disclosure: AI tools helped with repository research, structure, and editing of this article. I reviewed the technical claims against the referenced source files before publication.

One React/Vite product across PWA and Tauri—without pretending they are identical

qnbs — Sun, 27 Sep 2026 23:32:35 +0000

One React/Vite codebase can power a GitHub Pages site, an installed PWA, an edge-hosted deployment, and a Tauri desktop app.

That does not make those surfaces interchangeable.

This distinction matters whenever an application handles user projects, offline behavior, AI providers, filesystem access, or security policy. Shared components are valuable. Shared assumptions can be dangerous.

WorldScript Studio is a useful case study because its React/Vite application is intentionally available across browser/PWA and Tauri desktop environments. The product shares domain semantics, but it does not pretend that a browser tab and a native shell have the same authority boundaries. Code references are from the repository at commit 2d9157c0 (2026-09-28), release v1.28.8; simplified excerpts are labeled.

Share the product model, not every implementation detail

A cross-platform product needs a stable answer to questions such as:

What is a project?
What data belongs in it?
Which state is authoritative?
What does export mean?
What should happen when an AI provider is unavailable?

Those answers should be shared.

The mechanisms underneath them should not be forced to look identical.

For a PWA, the browser provides IndexedDB, Cache Storage, service workers, Web APIs, WebGPU, and origin-scoped storage. A desktop shell can provide application-data filesystem access, native networking, OS integration, and platform packaging.

Trying to hide every difference behind a single universal abstraction often creates a worse outcome: browser APIs leak into desktop code, native assumptions leak into web code, and the product accumulates several accidental definitions of persistence or network policy.

A better rule is:

Share domain semantics and interoperability contracts. Expose platform capabilities through explicit adapters.

The host changes the security boundary

The same static build can be deployed to different hosts, but hosting changes what the application can guarantee.

Surface	Important capability	Important limitation
GitHub Pages	Static public deployment	Cannot inject arbitrary HTTP security headers
Vercel / Cloudflare Pages	Response headers and edge-function capabilities	Still browser-origin storage for web project data
Installed PWA	Cached shell and browser-native installation	Storage remains origin- and browser-specific
Tauri desktop	Filesystem persistence and native HTTP	Desktop project files are not currently app-encrypted at rest

GitHub Pages is a good example of why "deployed from the same source" is not enough.

WorldScript uses a meta Content Security Policy there because GitHub Pages cannot add the corresponding response headers — the project's deployment documentation calls that meta tag the sole enforcement point on that host. Vercel and Cloudflare Pages can set real response headers that mirror the meta CSP, and both can run a same-origin edge relay for supported functionality (a Claude proxy lives at api/claude-proxy.ts for Vercel and functions/api/claude-proxy.ts for Cloudflare, sharing one core module). Those are materially different deployment guarantees, even when users see the same React interface.

The right documentation does not flatten that distinction. It names it.

Storage is an authority decision, not a convenience API

The PWA's live project path uses browser storage. The desktop path uses filesystem-backed stores under application data.

Both are local. They are not the same.

Browser persistence is governed by the browser's origin, quota, eviction behavior, and storage APIs. Desktop persistence is governed by filesystem access, native process boundaries, and the application's own read/write rules.

That difference becomes especially important for security language. Browser/PWA protected IndexedDB data can use the application's passphrase-based encryption lifecycle when configured. The filesystem-backed desktop project store currently does not receive that same at-rest encryption.

A UI toggle with the same name is not enough to make the protection equivalent. The actual persistence path decides what is protected.

Native networking changes what "local server" means

A browser connecting to localhost is still subject to browser rules such as CORS and Private Network Access. A Tauri desktop application can use an admitted native HTTP capability for local or cloud endpoints.

That does not mean desktop networking is automatically safer. It means its policy must be defined and enforced differently — and "narrowly admitted" is meant literally here. The desktop shell's HTTP capability is an explicit allowlist, not an open pipe:

// src-tauri/capabilities/default.json (excerpt)
{
  "identifier": "http:default",
  "allow": [
    "http://localhost:*/*",
    "http://127.0.0.1:*/*",
    "https://generativelanguage.googleapis.com/*",
    "https://api.openai.com/*"
    // …remaining provider hosts, nothing else
  ]
}

At runtime, the fetch adapter picks its implementation by environment: in the Tauri runtime it dynamically loads the native HTTP plugin; everywhere else it uses the browser's fetch. For WorldScript, that desktop-native path supports local inference-server workflows such as Ollama-compatible endpoints without requiring the WebView to bypass browser-origin rules. The browser/PWA path should not silently probe local ports or pretend that the same route will work without user-managed server configuration.

The general lesson is simple:

Browser security restrictions are product constraints, not annoyances to work around.
Native capabilities should be narrowly admitted, not made globally available.
UI copy must say when a feature is desktop-only or depends on local server configuration.

PWA caching must not leak into desktop behavior

A service worker is a powerful browser feature, but it is not a universal application runtime.

WorldScript's service worker caches its web shell and handles offline fallbacks on web surfaces. In Tauri, the registration code takes the opposite path — it actively tears the browser mechanism down:

// register-sw.ts (excerpt — called only from the Tauri branch)
async function teardownServiceWorkerInTauri(): Promise<void> {
  if (!('serviceWorker' in navigator)) return;
  const registrations = await navigator.serviceWorker.getRegistrations();
  await Promise.all(registrations.map((reg) => reg.unregister()));
  const keys = await caches.keys();
  await Promise.all(
    keys.filter(isWorldScriptOwnedCacheName).map((k) => caches.delete(k)),
  );
}

It unregisters any existing service worker and purges the app's own caches. That prevents a stale browser cache from serving an offline fallback over the real bundled desktop application.

This is a subtle example of platform adaptation done well: the feature is not merely disabled because it is inconvenient. It is disabled because its browser lifecycle would be the wrong authority for a native bundle.

A cross-platform checklist

Before claiming that a web and desktop product are "the same app," ask:

Where does each platform persist the authoritative project?
Which platform controls headers, CSP delivery, and network policy?
Is offline behavior provided by a cached shell, a native bundle, or both?
Which integrations need browser permissions, CORS configuration, or native capabilities?
Does each storage path have the same encryption and recovery properties?
Are platform-specific boundaries visible in the UI and documentation?

A shared codebase is an implementation advantage. It is not a reason to erase the differences users and maintainers need to understand.

The goal is parity where the product contract is shared—and honesty where the platform changes the contract.

Source note: WorldScript Studio is open source (github.com/qnbs/WorldScript-Studio). Code references correspond to main at 2d9157c0 (2026-09-28); release anchor v1.28.8. Key files: register-sw.ts, index.html, vercel.json, docs/DEPLOYMENT.md, src-tauri/capabilities/default.json, services/ai/fetchAdapter.ts, api/claude-proxy.ts, functions/api/claude-proxy.ts. Part of the "Engineering WorldScript Studio" series.

AI disclosure: AI tools helped with repository research, structure, and editing of this article. I reviewed the technical claims against the referenced source files before publication.

AI as an Optional Capability, Not an Application Dependency

qnbs — Sun, 27 Sep 2026 22:49:19 +0000

Try a small experiment with your favorite AI-powered app: revoke the API key, switch off the network, and open it again. A surprising number of products fail this test — not the AI features, the product. Spinners that never resolve. A settings page that errors out. A startup sequence blocked on a model ping. Somewhere between the demo and the release, the AI integration stopped being a feature and became load-bearing infrastructure.

WorldScript Studio is an open-source writing studio where AI assists with things like outlines, character work, and prose feedback. It is also, by design, fully usable with no key, no model, and no network. This article is about the mechanisms that keep it that way — a provider seam, policy gates in code, honest failure semantics, and a fallback layer that is allowed to say "no fallback exists." Code references are from the repository at commit 2d9157c0 (2026-09-28), release v1.28.8; simplified excerpts are labeled.

Optionality is not a settings toggle

Plenty of apps have an "AI: off" switch. Fewer have an architecture where off is a real, tested state. The difference shows up the first time a provider has an outage and your error handling turns out to be a toast notification saying "something went wrong" above a dead feature.

I ended up with a rule: the AI layer may fail in every way it wants, as long as the failure is typed, explained, and contained. Four mechanisms enforce it.

1. One seam, not fifty call sites

Every AI capability in the app — text generation, structured JSON, streaming, image generation — goes through one unified provider service. Providers sit behind it as adapters: Gemini, OpenAI, OpenRouter, Anthropic, and any OpenAI-compatible local server (Ollama, LM Studio) selected by base URL. A small factory normalizes them into a single LanguageModel type from the Vercel AI SDK:

// services/ai/providerFactory.ts (excerpt, comments trimmed)
export type WorldScriptLanguageModelConfig =
  | { provider: 'gemini'; modelId: string; apiKey: string }
  | { provider: 'openai'; modelId: string; apiKey: string;
      headers?: Record<string, string> }
  | { provider: 'openaiCompatible'; baseURL: string; apiKey: string;
      modelId: string; headers?: Record<string, string> };

export function createLanguageModelForWorldScript(
  config: WorldScriptLanguageModelConfig,
): LanguageModel { /* … */ }

The point of the seam is not abstraction for its own sake. It is that "the AI is down" has exactly one place to happen. Features never talk to a provider directly, so no feature can accidentally grow its own retry logic, its own key handling, or its own definition of what "offline" means.

Bring-your-own-key lives behind the same seam: keys are stored encrypted (in the browser build, under a random non-extractable AES-256-GCM key in IndexedDB), and no provider SDK ever sees storage.

2. Policy gates that throw, not conventions that hope

Routing is user-visible: four modes — hybrid, cloud, local, eco — with hybrid as the default. The part that matters architecturally is that the rules are enforced as code at the seam, not as conventions spread across components:

// services/ai/aiPolicy.ts (excerpt)
export function assertCloudAiAllowedSync(
  provider: AIProvider,
  privacy: PrivacySettings | undefined,
): void {
  if (LOCAL_INFERENCE_PROVIDERS.has(provider)) return;
  const mode = getActiveAiMode();
  if (mode === 'local' || mode === 'eco') {
    throw new Error(`Cloud provider blocked: AI mode is "${mode}" (local-only).`);
  }
  if (!privacy) return;
  if (privacy.localStorageOnly) {
    throw new Error('Cloud provider blocked: local-only mode is active.');
  }
  // …
}

A gate that throws is testable in a way a gate that "should be checked" is not — the policy test suite exercises the mode matrix directly. The same file carries a second hard gate: model training (LoRA fine-tuning) is restricted to local providers by allowlist, because training data is manuscript data, and manuscript data does not leave the device for that path. Note the scope of that sentence: it describes the training path, not a blanket privacy guarantee for every AI feature — a cloud provider you explicitly call necessarily receives the context you send it.

3. Failure semantics: retry what is retryable, explain what is doomed

Provider errors are not one thing. A rate limit is not a wrong API key, and neither resembles "the laptop is offline." The seam classifies every failure into a small taxonomy:

Category	Retryable?	Why
transient, rate limit, network	yes	connection-class; a later attempt can succeed
auth, policy, invalid request	no	deterministic — retrying repeats the failure
offline	no	doomed until connectivity returns
canceled, permanent	no	user intent / unrecoverable

Each class carries a stable message key, so the UI can say "check your key" or "you are offline" instead of showing a generic error — and so the retry layer fails fast on doomed calls instead of backing off politely on a request that will never succeed. This is the difference between a degraded app and a lying app.

4. A fallback layer that is allowed to say no

When an AI call is terminally unavailable, some features can fall back to local heuristic generators — registered per task (an outline generator, a character-profile generator). The design decision I care about most is what the registry does when nothing is registered:

runHeuristicFallback(task, ctx)
  → generator registered?  run it, return its result
  → nothing registered?    return null
                           caller keeps its existing behavior

The fallback layer is "always safe to ship empty," as the code comment puts it. null means: no fallback exists, tell the user the feature needs a configured provider. What the registry never does is invent a plausible-looking answer to cover for a missing model. A fallback that quietly fabricates quality is worse than an honest refusal, because users cannot calibrate trust against output they cannot distinguish from the real thing.

 feature call
      │
      ▼
 unified provider seam ──► policy gate (mode, privacy) ──throws──► typed error
      │                                                            │
      ▼                                                            ▼
 provider adapter (cloud/local)                          UI hint via message key
      │                                                            │
      ├─ terminal failure ──► heuristic fallback ──null──► honest refusal
      ▼
 streaming response

Simplified: the real chain includes cancellation, request deduplication, and a provider fallback chain for transient cloud failures.

What "offline" honestly means here

Precision matters more than marketing, so: with no network, the manuscript editor, planning tools, and storage work fully — they never touch the seam. Browser-local and Ollama-served models keep working if they were set up beforehand; the first model download obviously needs a connection, and local inference needs hardware that can carry it. Cloud providers are unreachable, and the offline error class says so. Hybrid mode is deliberately cloud-first; local mode is the setting that guarantees the device never emits a request.

AI being optional also means the app's identity does not collapse without it. There is no onboarding step that demands a key, no feature gate on the editor, no telemetry about your text leaving for a server you did not choose.

The checklist I would hand another team

One seam. All AI traffic through a single layer; providers as adapters behind it. If a feature imports a provider SDK directly, optionality is already gone.
Gates that throw. Mode and privacy policy enforced in code at the seam, with tests — not documented conventions.
Typed failure. Classify errors by whether a retry can succeed; map every class to a user-actionable message.
Refusal-capable fallback. Degrade to simpler local behavior where it genuinely helps; return "no fallback" where it would only pretend.

Then run the unplug test in CI or by hand: no key, no network, cold start. Whatever still works is your product. Whatever breaks that should not have is your real dependency graph.

Source note: WorldScript Studio is open source (github.com/qnbs/WorldScript-Studio). Code references correspond to main at 2d9157c0 (2026-09-28); release anchor v1.28.8. Key files: services/aiProviderService.ts, services/ai/providerFactory.ts, services/ai/aiPolicy.ts, services/ai/aiErrorTaxonomy.ts, services/ai/heuristicFallback/registry.ts. Part of the "Engineering WorldScript Studio" series.

AI disclosure: AI tools helped with repository research, structure, and editing of this article. I reviewed the technical claims against the referenced source files before publication.

Why a Writing Studio Can Work Without User Accounts

qnbs — Sun, 27 Sep 2026 21:50:58 +0000

Open your favorite writing tool and the first thing it asks for is an email address. That is not a UX quirk. The account is load-bearing: it anchors your identity, decides which copy of your manuscript is real, and gives someone else the job of recovering your work when things go wrong. When I started building WorldScript Studio, an open-source writing studio for long-form fiction, I wanted none of that. No account, no server-side manuscript database, no mandatory cloud anything.

The interesting part is not the decision. It is the bill that arrives afterward. Once you delete the server, four things it used to do for free land back on your desk: identity, canonical truth, recovery, and trust. This article is about what replacing them actually looks like in a real codebase, including the parts that are still unfinished.

Everything below references the repository state at commit 41e593f9 (2026-09-27), release v1.28.8. Where I simplify code for readability, I say so.

What "no account" actually removes

It is tempting to frame local-first as a privacy feature. That framing is weak, because privacy is a property you have to keep proving, and because it undersells the architectural change. The account is not a login form. It is the answer to the question "whose copy wins?"

With a server, the answer is boring: the server's copy wins. Your devices are caches with keyboards. Sync conflicts, corruption, migration, even the meaning of "saved" are all decided in one place you do not control but also do not have to build.

Remove the server and every one of those questions becomes yours. Whose copy wins when the app crashed mid-save? What happens when a project file from a two-year-old version meets today's schema? Who is allowed to delete data, ever? These are not edge cases in a local-first app. They are the product.

The design rule I ended up with: possession replaces identity. There is nothing to log into, so the only meaningful identity is "the person sitting in front of this storage." That sounds obvious until you realize it inverts the threat model. You stop defending against strangers on the internet and start defending the user against the app itself: against silent overwrites, ambiguous recovery, and destructive "help."

Authority has to live somewhere

WorldScript ships as a browser app (PWA) and as a Tauri desktop application from one codebase. The two do not have the same storage authority, and pretending they do is the first trap.

In the browser, projects persist in IndexedDB. On the desktop, they persist as files through Tauri's filesystem layer. The selection happens once, at startup, and it is explicit:

// services/storageService.ts (excerpt, comments trimmed)
class StorageManager {
  private backend: StorageBackend;            // defaults to dbService (IndexedDB)
  private authorityFailure: DesktopStorageAuthorityUnavailableError | null = null;

  private async initializeBackend(): Promise<void> {
    if (isTauriRuntime()) {
      try {
        await fileSystemService.initialize();
      } catch (error) {
        // Desktop projects live on the filesystem only. If it cannot be opened,
        // startup stops visibly instead of continuing on a different store.
        this.authorityFailure = new DesktopStorageAuthorityUnavailableError(error);
        return;
      }
      this.backend = fileSystemService;
    }
  }

  private async getBackend(): Promise<StorageBackend> {
    await this.ready;
    if (this.authorityFailure) throw this.authorityFailure;
    return this.backend;
  }
}

Two decisions in that excerpt cost real thought.

The first is fail-visible over fail-silent. An earlier version of this code effectively fell back to IndexedDB when desktop storage failed to open. That is the helpful-looking behavior that destroys trust: the app appears fine, but it is now showing you a different store with different data, and your "real" projects have vanished from view. The current behavior refuses to proceed. A user who sees an error can act on it; a user whose data silently teleported cannot.

The second is that authority is queryable, not assumed. getProjectAuthority() returns 'fs' or 'idb', and recovery logic branches on the answer rather than on guesses about the runtime. This matters because the correct response to corruption differs per backend, as the next sections show.

                 ┌─────────────────────────────┐
                 │        React UI / views      │
                 └──────────────┬──────────────┘
                                │ reads/writes
                 ┌──────────────▼──────────────┐
                 │      StorageManager          │
                 │  getProjectAuthority()       │
                 └───────┬───────────────┬──────┘
            browser/PWA  │               │  Tauri desktop
                 ┌───────▼───────┐ ┌─────▼──────────┐
                 │   IndexedDB   │ │  filesystem    │
                 │  (dbService)  │ │  (fs stores)   │
                 └───────────────┘ └────────────────┘
                 one canonical authority per runtime — never both

Writing is the dangerous part

Reads are easy. The write path is where local-first apps lose data, usually politely.

The naive autosave serializes the editor state and overwrites whatever is stored. That works until the stored record is newer than the app understands (a future version wrote it), older than the current schema, or malformed. "Just overwrite it" is a data-loss policy wearing a trench coat.

The current autosave instead treats persistence as a reconciliation with a canonical authority. Roughly, the writer classifies the stored record and then chooses one of a few narrow paths:

 stored record state            autosave behavior
 ─────────────────────────────────────────────────────────
 ABSENT (first save)          → create a validated CURRENT record
 LEGACY_UNVERSIONED           → migrate, reload once, commit the
                                pending edit in the same call
 CURRENT                      → commit through the canonical bridge
 FUTURE                       → REFUSE (typed)
 SUPPORTED_OLDER /            → REFUSE (typed)
 UNSUPPORTED_OLDER
 MALFORMED /                  → REFUSE (typed)
 GENERATION_CONTRADICTION
 concurrent conflict          → stop; the next debounce cycle
                                re-evaluates with fresh state

Simplified from services/projectAutosaveCanonicalWriter.ts; the real result type carries reasons (CanonicalAutosaveResult).

The property I care about is the one that looks like a limitation: there is deliberately no fallback to the legacy save path. If the stored state is something the writer cannot reconcile, the app refuses and tells the user, instead of doing something plausible. A refusal is annoying once. A silent downgrade of your manuscript is annoying forever, and you find out at the worst possible time.

There is a concurrency budget too: at most one re-evaluation per autosave invocation. A state that would require a second reload ends as a typed conflict and defers to the next debounce cycle. This keeps the writer from ever looping against itself, at the cost of occasionally saving a few seconds later than theoretically possible. That trade is easy to accept and hard to notice, which is what good defaults look like.

Recovery without a support team

With an account, "something went wrong" is a support ticket. Without one, the recovery policy is the support team, so it has to be written down in code and it has to be conservative.

The startup recovery policy classifies what failed before it decides what is allowed to happen:

// services/startupRecoveryPolicy.ts (excerpt, simplified for explanation)
const failureKind =
  projectLoadError?.classification === 'UNSUPPORTED_OLDER' ? 'project-migration-gap'
  : projectLoadError?.reason === 'unsupported-version'     ? 'project-unsupported'
  : projectLoadError?.reason === 'corrupt'                 ? 'project-corrupt'
  : projectLoadError || backend === 'filesystem'           ? 'project-io'
  : 'storage';

return {
  failureKind,
  // quarantine only a corrupt desktop project; reset only an IndexedDB-level failure;
  // safe-open only a refused desktop project:
  canQuarantine: failureKind === 'project-corrupt' && backend === 'filesystem',
  canReset:      failureKind === 'storage'        && backend === 'indexeddb',
  canSafeOpen:   projectLoadError !== null && backend === 'filesystem'
                 && (failureKind === 'project-unsupported'
                  || failureKind === 'project-migration-gap'),
};

Simplified for explanation.

Read the three booleans as a philosophy. Quarantine moves a corrupt desktop project out of the active namespace; it never deletes, and it is never offered for a mere I/O hiccup, because a flaky disk is not corruption. Reset exists only for IndexedDB storage-level failure, the one case where the store itself, not a project, is broken. And a stored project the editor cannot load is kept exactly as it is: reload, nothing else.

Even the one genuinely destructive operation, a full IndexedDB reset, is gated by a barrier (idbResetGate.ts): every module that caches a database connection registers a closer, the reset drains all of them including closers registered mid-drain, and if any closer fails, the reset itself fails. The invariant is that a connection opened before or during a reset can never become authoritative afterward. Fail-closed applies to the app too, not just to users.

None of this is clever. That is the point. Recovery policy is where you spend your complexity budget on being boring.

Secrets without an account

"No account" does not mean "no secrets." Bring-your-own-key AI providers still need API keys stored somewhere, and "somewhere" needs an honest answer.

In the browser build, provider keys are encrypted with AES-256-GCM under a random, non-extractable CryptoKey held in IndexedDB (services/storage/idbKeyStore.ts). Non-extractable is doing the real work: the key material cannot be read back out through the Web Crypto API, so casual exfiltration of the stored record does not yield a usable key. I am deliberately not claiming more than that. Browser storage is still browser storage; this raises the cost of theft, it does not make theft impossible.

For moving data between machines, the export path is a user-invoked library backup: a ZIP containing metadata plus a vault.bin encrypted with AES-256-GCM under a passphrase-derived key (PBKDF2-HMAC-SHA-256, 600k iterations). The weakness of that design is not cryptographic; it is the human passphrase. The UI says so, because a backup you cannot decrypt is a backup you do not have.

What still needs a network, said plainly

Local-first marketing tends to mumble at this point, so let me be specific. WorldScript needs a network for: cloud AI providers (the request necessarily contains the context you send), the first download of a browser-local model, collaboration signaling, and a self-hosted LanguageTool server if you enable one. AI as a whole is optional infrastructure: the routing default is a hybrid mode, there is a heuristic fallback layer, and the manuscript editor is fully usable with AI off. The PWA shell caches for offline use via a service worker, so writing, planning, and project management survive a dead connection.

What the app does not have: accounts, server-side manuscript storage, a cloud-sync product, or any telemetry pipeline for your content. A CRDT-based local-first sync layer is designed (ADR-0008 documents the Yjs migration as a gated, per-project, one-way door) and it is off by default. I mention it only to be clear about the boundary: designed and gated is not shipped, and this article does not claim it.

Also not claimed: desktop project files are not application-encrypted at rest today. They are local files, with all the protection and exposure that implies. If that matters to you, OS-level disk encryption is the honest answer right now, and an app-level answer is on the roadmap rather than in the release.

The checklist I wish someone had handed me

Replacing the account meant replacing four things. If you are building local-first software, you will have to answer all of them, whether or not you write the answers down:

Identity → possession. No login means the only identity is control of local storage. Your threat model shifts from strangers to your own failure modes.
Server truth → an explicit local authority. Pick one store per runtime, make the choice queryable, and fail visibly when it is unavailable. Never silently substitute a different store.
Support team → written recovery policy. Classify the failure before choosing the remedy; scope destructive actions narrowly; make the dangerous paths fail closed.
"Trust us" → scoped, checkable claims. Say which subsystem has which property. "Keys are encrypted in the browser build" is a claim you can defend. "Your data is safe" is a slogan.

The account was never the feature. It was an answer. Local-first means writing your own, and being precise about where yours still says "unsolved."

Source note: WorldScript Studio is open source (github.com/qnbs/WorldScript-Studio). Code references correspond to main at 41e593f9 (2026-09-27); release anchor v1.28.8. Key files: services/storageService.ts, services/projectAutosaveCanonicalWriter.ts, services/startupRecoveryPolicy.ts, services/storage/idbResetGate.ts, services/storage/idbKeyStore.ts, docs/adr/0008-local-first-data-model.md.

AI disclosure: AI tools helped with repository research, structure, and editing of this article. I reviewed the technical claims against the referenced source files before publication.