A delegated session never sends "the vault's signature." The browser holds a local P-256 keypair, and the delegation itself is a Capability blob (proto: documents/v3alpha/access_control.proto, fields issuer, delegate, role) that the vault signs once during the sign-in callback (auth-session.ts:207-238). That capability is published as a blob and lives in the document graph just like any other blob. From then on, the browser signs Change blobs directly with its local key.

This is the part we add. The check has to mirror the daemon's rule, but client-side. The Documents.ListCapabilities RPC and the existing resolveCapability helper (frontend/packages/client/src/capability.ts:59-72) already give us what we need:

useWebCanEdit(docId) →
  if no userKeyPair.delegatedAccountUid → {canEdit: false}
  else:
    if docId.uid === delegatedAccountUid → owner, canEdit: true
    else: resolveCapability(client, docId.uid, delegatedAccountUid)
          if WRITER or AGENT and scope covers docId.path → canEdit: true
          else canEdit: false
  then site-scope filter:
    gateway origin → keep canEdit
    custom-domain → require docId.uid === originHomeId.uid

The capability lookup matches delegate against the delegated account UID (not the local pubkey), because on the public capability graph the delegate field of the outer writer-capability is the account UID; the vault's session-signing capability that bridges "browser pubkey → delegated account" is a separate blob handled by the daemon. From the frontend's perspective, "can the delegated account write to this doc?" is the right question, and ListCapabilities answers it directly.

There is no existing dynamic canEdit(docId, accountUid) hook — selectCanEdit (use-document-machine.ts:347) just reads a boolean set at machine init. We are introducing the dynamic resolution.

• Gateway origin (no custom domain): user can edit any doc they have capability for.

• Custom-domain site: user can only edit docs under that site's home (docId.uid === originHomeId.uid), even if they hold capability elsewhere. This keeps per-domain identity expectations intact and avoids "I edited X on site Y" confusion.

The publishDocument actor:

1. Reads the editor baseline (selectEditorBaseline) and live blocks (via EditorHandlersContext.getCurrentBlocks()).

2. Diffs them with the existing compareBlocksWithMap + extractDeletes from frontend/packages/shared/src/utils/document-changes.ts to produce block-level DocumentChange entries.

3. Adds metadata (setMetadata for name/icon/cover) and navigation (setAttribute operations) using the helpers that desktop already uses.

4. Calls seedClient.publishDocument({ account, changes, baseVersion: deps, genesis, generation }, signer) — the same call already exercised in production today by auth.tsx:261 for profile updates. The signer comes from getCurrentSigner() (WebCrypto over the locally-held P-256 key, gated to vault-delegated accounts in V1).

5. On success, deletes the IDB draft and returns the new HMDocument so the machine can transition to loaded with refreshed baseline.

New files (all under frontend/apps/web/app/document-edit/):

• web-document-actors.ts — createWebDocumentMachine({ getSigner, ipfsPublish }) returning documentMachine.provide({ actors }). Implements writeDraft, publishDocument, pushDocument.

• web-draft-db.ts — Thin IDB wrapper: getWebDocDraft, putWebDocDraft, deleteWebDocDraft, listWebDocDraftsForDoc. Mirrors the existing local-db.ts pattern.

• use-web-can-edit.ts — useWebCanEdit(docId) returning {canEdit, signingAccountId} per the rules above.

• web-editing-toolbar.tsx — In-page toolbar: Edit / Publish / Discard, change-count badge using useUnpublishedChangeCount (lifted from frontend/apps/desktop/src/components/editing-toolbar.tsx:73-90 to shared if not already).

• web-image-upload.ts  —  ipfsPublish(file)  using  filesToIpfsBlobs  + seedClient.publish.

Modified files:

• frontend/apps/web/app/web-resource-page.tsx — compute  useWebCanEdit(docId) (client-only), build the web machine via useMemo, pass machine and input into <ResourcePage>, render <WebEditingToolbar />, wire the five sync hooks. SSR-safe defaults:  canEdit = false until hydration.

• frontend/apps/web/app/loaders.ts and app/routes/$.tsx — extend the document fetch to include genesis and generationInfo (needed by the publish call; shape is already exercised in auth.tsx:266). No new identity/capability work in the loader — capability is resolved client-side only.

• frontend/packages/ui/src/resource-page-common.tsx — verify it already accepts machine and input props for DocumentMachineProvider and that DocumentContentComponent reacts to selectIsEditing. No structural change expected; verification only.

• frontend/packages/shared/src/models/use-editor-gate.ts — verification only; the canEdit: false short-circuit must be honored during SSR / pre-provider renders.

Reused (no change):

• seedClient.publishDocument — auth.tsx:207, 261

• getCurrentSigner / signWithKeyPair — auth.tsx:53, auth-utils.ts.

• compareBlocksWithMap, extractDeletes, createBlocksMap, docAttributeChange* — frontend/packages/shared/src/utils/document-changes.ts.

• documentMachine, useDocumentMachine, useEditorGate, useDocumentSync, useDraftResolutionSync, useCapabilitySync, useAccountSync, useVersionLatestSync — frontend/packages/shared/src/models/*.

• EditorHandlersContext (setEditable, applyInitialContent, placeCursor, getCurrentBlocks) — already provisioned by the editor.

• filesToIpfsBlobs + seedClient.publish — commenting.tsx:449-451.

• draft-media-db.ts IndexedDB media pattern.

1. Plumb useWebCanEdit, web-draft-db, and a skeleton  createWebDocumentMachine (no-op actors) and confirm canEdit correctly toggles editor isEditable.

2. Implement IDB writeDraft + useDraftResolutionSync reading IDB.

3. Implement publishDocument for block changes only; verify a paragraph edit publishes and survives reload.

4. Add metadata edits (name/icon/cover).

5. Add image upload via ipfsPublish.

6. Add embeds (expected to work with no extra wiring).

7. Add navigation editing (already flows through change.navigation).

8. Finalize the writer-capability integration and gateway-vs-custom-domain gating.

Manual smoke against a local daemon, vault-delegated account:

• Gateway origin: own home doc → Edit → paragraph edit → IDB draft visible → Publish → reload → content present, draft removed. Repeat for heading, metadata name, image upload (CID resolves), embed insertion, nav add/reorder. Open a doc the user lacks capability for → Edit hidden.

• Custom-domain site: same scenarios, plus verify Edit shows only on docs under that site's home and stays hidden for off-site docs even when the user holds capability.

Automated:

• Unit tests (Vitest, colocated): web-document-actors.test.ts (publish builds expected DocumentChange[] from baseline + new blocks), use-web-can-edit.test.ts (matrix of {gateway, custom-domain} × {owner, writer-cap, none} × {vault-delegated, local-only}), web-draft-db.test.ts (round-trip + delete).

• Integration: extend tests/ with one Playwright/Vitest scenario for "vault-delegated user edits and publishes a paragraph on the gateway."

• Per frontend/AGENTS.md: pnpm typecheck, pnpm --filter @shm/web test, pnpm --filter @shm/shared test (if useUnpublishedChangeCount is lifted), pnpm format:write.