When a document starts with a query block as its first block, there is no reliable way to enter edit context for the document.

If the first block in a document is a query block, the user cannot place the cursor into the document body to begin editing. This effectively traps the document outside the edit context unless another editable block precedes it.

The document does not enter edit context. The user cannot place the cursor before or into the first block.

The user should be able to enter edit context even when the first block is a query block, and place the cursor at the start of the document.

This blocks editing of documents whose first block is a query block, creating a confusing dead end in the editor UX.

We’re >95% confident now.

Implementation plan I’d use:

• frontend/packages/shared/src/models/editor-handlers-context.ts

  • extend EditorHandlers with one edge-entry hook

  • purpose: let wrapper-level invisible hit areas trigger “start” / “end” insertion behavior without coupling to desktop-only code

• frontend/packages/editor/src/document-editor.tsx

  • refactor read-only entry handling from mousedown + click to pointer/tap-aware handling

  • keep current guards:

    • drag != activate

    • touch scroll != activate

    • existing selection click/tap clears selection first

    • links / interactive content keep current behavior

  • keep current text-block click-to-edit behavior for normal body clicks

  • add pending edge-action state/ref:

    • start

    • end

    • plus “explicit edge activation” marker

  • consume that pending action during edit entry, after initial content is loaded:

    • if first/last block is text: place cursor at start/end, no insertion

    • if first/last block is non-text: insert plain top-level empty paragraph before/after, then focus it

  • do not change Enter-key fallback in this pass

• frontend/packages/ui/src/resource-page-common.tsx

  • add shared invisible edge-zone wiring around DocumentContentComponent

  • top zone:

    • includes the visible gap below title/summary/header and above first body block

    • does not hijack clicks on title/summary/header controls themselves

  • bottom zone:

    • defined by the last real document block

    • excludes inlineInsert / inlineCards

  • keep zero visible/layout change

• tests

  • likely add a new frontend/packages/editor/src/document-editor.test.tsx

  • cover:

    • first block query/embed/media -> top zone inserts paragraph before

    • last block query/embed/media -> bottom zone inserts paragraph after

    • first/last block text -> cursor moves, no insertion

    • existing read-only selection -> first tap/click only clears selection

    • touch tap activates, touch scroll does not

    • links / interactive block UI still not hijacked

Order:

1. extend shared handler contract

2. implement pending edge-action logic in document-editor.tsx

3. wire top/bottom shared hit areas in resource-page-common.tsx

4. add regression tests

Final plan: implement a shared, zero-visual-change fix for edit-entry dead ends by adding invisible top/bottom edge activation zones. Top includes the header/body gap; bottom is relative to the last real content block only. Explicit tap/click on those zones should place the cursor at the start/end when the edge block is text, or insert a plain top-level paragraph before/after when the edge block is non-text.

• No query-specific special case; rule is generic for all non-text edge blocks.

• No header-field behavior changes; title/summary keep their current semantics.

• No keyboard-scope expansion in this pass; Enter fallback stays as-is.

• Expected files to modify: frontend/packages/shared/src/models/editor-handlers-context.ts, frontend/packages/editor/src/document-editor.tsx, frontend/packages/ui/src/resource-page-common.tsx, plus new/updated editor tests.