Readiness and boundaries

Below is the boundary between what works today and what’s locked in by the pilot contract. What the product does with the document by task — headers and footers, tables of contents, comparing versions, printing — is collected in the capability map.

How to read “within the described limits”

The capability works within the stated limits, and outside them it refuses predictably — never silently, never halfway. Exactly what’s inside the limits is given in the same table row. The term is explained in the glossary.

What’s available now, and what’s part of the pilot

Capability	Status	How to use it, or under what condition
Semantic structure	Available	the model command in a session, or model-docx as a standalone call
Layout, pages, scene	Available	compose, paginate, print, print-window, print-delta
Review and styles	Available	the review and style projections
Text editing	Available	mutate or apply-text-transaction
Selection, history, save	Available	set-selection, undo and redo, save and checkpoints
Standalone hit-testing	Within the described limits	The main text line, its edge, and the caret position; other object types are being added gradually
Hit-testing into text and tables inside the application	Works, but isn’t part of the contract	Don’t call it directly: the route is internal and can change without notice
Context menus for text and tables	Works, but isn’t part of the contract	Works inside the product; how to plug in your own menu isn’t locked in yet
Surface Host events	Available in the described set	ready, dirty, saved, error, unmounted
Selection, content, and command events	Locked in during the pilot	Needs agreement on the set, delivery order, retries, and lifecycle
Your own context menu	Locked in during the pilot	A declarative list of items and typed command dispatch
Directly editing the page markup or the file	Forbidden	Only through session commands and the core writing the file

What confirms it’s feasible

• Hit-testing into text. A click coordinate returns the page, line, position in the line, and the text itself.

• Hit-testing into a table cell. Returns the page, block, row, and column, including nested tables.

• Context menus. Separate routes serve text and tables.

• Double-click. Text, tables, borders, and auto-fit width are all served.

What of this becomes part of the contract

What’s listed shows the mechanism works, but it isn’t a public interface yet. The contract carries stable addressing, event, and command schemas, versioning, and a capability matrix.

What to lock in before integration begins

Capability profile

Decision	What to lock in
Which objects are addressable	Paragraph, formatting run, table, cell, image, comment, field, and your own objects
Events	Click, double-click, context menu invocation, keyboard activation; delivery order and whether it can be canceled
Menu contract	How long to wait for your side’s response, in what order items are merged, which identifiers are reserved, translation, icons, and separators
Command contract	The expected revision, a replay-protection key, an atomic command batch, the confirmation contents, and the list of errors
Save	Where to save, checkpoints, what to do on conflict, acceptance via the “saved — reopened” loop
Security	The local access token, capability grants, what’s logged and what’s stripped from it, and the absence of shortcuts around the contract
Versioning	Schema versions, the compatibility period, the process for retiring capabilities
Platforms	Which profile is used in the first pilot: desktop, inside a WebView window, server, or mobile

Minimal set of acceptance checks

• Open a real document and get a semantic snapshot without losing the parts of the file the editor doesn’t parse: Word markup (OOXML) carries over to the new file as is.

• A click on text and on a cell returns the right document object and selection.

• A double-click performs the agreed action once and doesn’t change the document by itself.

• The context menu changes depending on the object and the available capabilities, and opens from the keyboard.

• A command with the current revision is applied; a command with a stale revision is refused with a message like “stale revision: expected 5, received 3”.

• Undo and redo restore the result; saving and reopening confirm that the changes reached the file.

• Closing releases the listeners, the WebSocket connection, and the core process — no hanging processes are left behind.

What you’ll need on your side

• 5–10 real documents and a list of the elements that need actions.

• A table of “element type → click → double-click → menu items → document command”.

• Requirements for desktop, server, and embedded operation, offline use, storage, accounts, and audit.

• A list of your objects and a way to tie them to document nodes — without a second file model on your side.