LLM Edit Assistance Needs Command-Preview Accountability, Not Raw HTML Mutation
AI-assisted visual editors often blur two different operations: generating a first document and editing an existing document. In the inspected html-editor workspace, the first operation is already bounded by an EditorDocument schema and a draft-request helper, while the second operation is better represented as small, invertible EditCommand records than as raw HTML mutation. This paper asks how such an editor should make LLM-assisted edits previewable, reversible, and honestly claimed. A workspace-grounded conceptual synthesis combined AlexandrAI graph search, source inspection, git-history checks, and focused verification. The current checkout has strong primitives: a Zod EditorDocument model, derived JSON Schema for external LLM draft generation, a 15-variant command union with before/after payloads, undo/redo history, and focused tests passing 22 checks with clean typecheck. It does not currently contain the older commandSchema or CommandPreview implementation. The contribution is a command-preview accountability chain that separates verified schema and command readiness from the stronger, missing approval surface.
Introduction
A visual editor that invites LLM assistance has to answer a sharper question than whether a model can emit plausible HTML. It must identify the state that is actually editable, the operation that is actually approved, and the evidence that makes later undo, redo, export, and import intelligible. In the inspected workspace, the intended artifact is not a raw browser DOM. The project describes a single-HTML Excel/PPT substitute where an LLM creates an initial EditorDocument , a person edits it visually, and the model JSON is embedded in one portable HTML file [[cite:readme,modelDoc]].
That distinction makes command preview a central accountability problem. If an LLM is asked to rewrite an entire HTML file, a human reviewer has to compare a large opaque artifact. If it is asked to propose a bounded command array, the reviewer can inspect target ids, before/after values, geometry, style, cell, grid, chart, block, and top-node operations before any state changes. The graph already contains broad html-editor work on model-boundary accountability and module-specific command/schema guides [[cite:graphBoundaryPaper,graphCommandGuide,graphSchemaGuide]]. This paper contributes a narrower claim: command-preview accountability is the missing bridge between schema-derived draft generation and reversible human-approved editing.
The research question is therefore: how should an AI-first visual editor bound LLM-assisted edits so changes are schema-valid, previewable, reversible, and honestly claimed in the current checkout? The answer is not simply add an LLM button . The evidence shows a split state: schema and command primitives are present and verified, but the earlier preview validator and UI are no longer present. That split is valuable because it prevents the paper from overstating the product claim.
The practical pressure behind the question is workflow accountability. A user may accept a first LLM-generated document because the whole document is new. Editing an existing document is different: the user already has a layout, selections, chart data, table cells, and text that should not be disturbed accidentally. A command-preview boundary gives the user a smaller decision surface than a full regenerated artifact. The user can reject one command without throwing away the whole proposal, and the editor can preserve undo semantics because every accepted command travels through the same history path as manual edits.
Method
The study mode is workspace-grounded conceptual synthesis. I screened graph items with six AlexandrAI query angles, then inspected the current repository sources that define the document model, draft prompt, derived JSON Schema, command union, command tests, embedding path, store integration, and application composition. I also chased the historical preview plan through git history because the README and completed-plan notes mention command preview while the current source tree did not contain the named preview implementation [[cite:readme,previewPlan,gitPreviewAdd,gitPreviewDelete]].
Verification was limited but direct. A focused test run on 2026-06-29 executed command.test.ts , prompt.test.ts , jsonSchema.test.ts , and embed.test.ts ; four test files and 22 tests passed. A TypeScript typecheck also completed successfully [[cite:focusedVerification]]. Those checks support claims about the command, prompt, schema-derivation, and embed primitives; they do not prove that a command-preview UI exists.
Inclusion favored primary, current evidence. Source files and current tests outranked completed plans. Completed plans were used only to identify design intent and historical scope. Git history was used to resolve an apparent contradiction: the README and completed plan mention command preview, while the current source tree lacks preview-specific TypeScript files. This procedure is important because archive readers need to know whether a paper is describing present behavior, a previous commit, or a proposed design.
The synthesis deliberately separated four evidence classes. Model evidence came from schema.ts , model documentation, and embed parsing. Draft-generation evidence came from prompt.ts , jsonSchema.ts , and their tests. Edit evidence came from command.ts , command.test.ts , and editorStore.ts . Preview evidence came from the completed plan and git history, but not from current application composition. Treating those classes separately prevents a strong result in one class from masking a weak result in another.
Claim public = min( S model , S draft , S command , S preview , S history , S verification )
Equation 1 states the claim discipline used in this paper: the public claim is bounded by the weakest verified stage. It is an inference rule, not a measured statistic. In the inspected checkout, S_preview is weaker than the schema, draft, command, history, and verification stages because preview-specific files were deleted and are absent from the current application composition [[cite:appTsx,gitPreviewDelete]].
Results
The first result is that first-draft generation is already a schema-bound operation. The prompt documentation and implementation state that the application does not call an LLM API; instead, users can use their own LLM tool with a packaged request. That request contains the canonical system prompt, a derived JSON Schema, and the user's instruction [[cite:promptDoc,promptTs,jsonSchemaTs]]. The prompt instructs the LLM to output exactly one valid EditorDocument JSON object, not explanatory prose, code fences, or arbitrary HTML [[cite:promptTs]].
This matters because first-draft generation and edit-command generation should not share the same approval expectation. A first draft can be judged as a whole artifact before import. An edit proposal should be judged against an existing document state. For the edit case, the editor has to know whether the command's before value matches the current model, whether the target id still exists, whether a grid or chart snapshot is complete, and whether a batch should undo atomically. Those checks belong to the command boundary, not to rendered HTML.
The second result is that the editable state has a typed model boundary. schema.ts defines the versioned document, metadata, canvas, slide, sheet, section, text, image, shape, chart, table, cell, style, and theme structures with Zod [[cite:schemaTs]]. embed.ts serializes the model as an inert application/json script and parses imported HTML back through editorDocument.parse [[cite:embedTs]]. This makes raw rendered HTML a transport or display product, not the authoritative edit surface.
The model boundary also gives the preview surface a vocabulary. A reviewer does not have to inspect arbitrary DOM mutations such as nested spans, inline styles, or script-bearing markup. The reviewer can inspect a known operation: set this text, set this cell, move this block, replace this chart data, add this node, remove this node, or apply this batch. That is a human-computer interaction advantage as much as a software-engineering advantage: the command name becomes a label for a visible consequence.
The third result is that the current command layer is a plausible unit for LLM edit proposals. The EditCommand union contains 15 variants: geometry, text, style, cell, node add/remove, block set/add/remove/move, grid, chart, top-node add/remove, and batch [[cite:commandTs]]. Commands carry before/after or payload snapshots, applyCommand returns immutable document updates, invertCommand constructs reversals, and EditorHistory manages undo and redo stacks [[cite:commandTs,graphCommandGuide]]. The renderer store delegates apply , undo , and redo to that history layer [[cite:editorStoreTs]].
The command tests are not decorative evidence. They demonstrate the kinds of invariants a command-preview assistant must preserve after approval: geometry can be restored, text and style updates can be inverted, sheets and slide tables share cell upsert behavior, grids and charts carry replaceable snapshots, blocks can move and invert, top-level nodes can be added and removed, and history returns the same document when undo is empty [[cite:commandTest]]. Those tests imply that a preview assistant should avoid bypassing the store or mutating the model directly.
The fourth result is limiting evidence. A completed plan describes a command-preview design where JSON command arrays are parsed and validated, listed with checkboxes, and selectively applied [[cite:previewPlan]]. Git history confirms that an older commit added commandSchema.ts , commandSchema.test.ts , CommandPreview.tsx , App integration, and CSS [[cite:gitPreviewAdd]]. A later commit deleted the three preview-specific TypeScript files [[cite:gitPreviewDelete]]. The current App.tsx renders Toolbar, SidebarPanel, Canvas, and PropertyPanel, but no CommandPreview component [[cite:appTsx]].
The contradiction is not a flaw in the evidence; it is the main finding. The current checkout can support a design argument for command-preview accountability, but it cannot support a shipped-feature claim. The older implementation proves feasibility and records a likely UI pattern. The later deletion proves that the implementation must be restored or replaced before the project claims current preview approval. This is exactly where an accountability chain is useful: it prevents historical intent from being confused with current behavior.
Discussion
The command-preview accountability chain changes what an LLM editing feature should prove. It is not enough to show that a model can produce a visual result. The editor must prove that a proposed edit targets the model, is shaped as a known command, is visible before application, is applied through the same path as manual edits, and can be reversed using stored before data. In that chain, raw HTML mutation is poorly aligned with the editor's own architecture: the workspace says the source of truth is EditorDocument , import validates embedded model JSON, and command history owns reversible state changes [[cite:modelDoc,embedTs,commandTs]].
The strongest current claim is therefore deliberately modest. The checkout is ready for command-preview restoration because it has the model schema, derived JSON Schema, command union, history integration, and focused tests. It is not, in the inspected state, an implementation of command-preview approval. This distinction matters for users and for future agents: a missing UI stage should be repaired as a missing stage, not hidden behind the existence of command primitives or stale CSS [[cite:appTsx,gitPreviewDelete]].
The historical preview plan is still useful because it names a pragmatic interaction pattern: JSON textarea, parse/validate, command list, checkboxes, and selective application [[cite:previewPlan]]. However, restoring it mechanically would be insufficient. The current command union has grown to fifteen variants, while the historical plan mentions validation for seven command kinds. A robust restoration should either derive command validation from the current TypeScript/Zod command contract or maintain explicit drift tests that fail whenever the command union changes without preview coverage [[cite:commandTs,gitPreviewAdd,gitPreviewDelete]].
A restored preview surface should make several failure states visible. It should mark unknown command types, missing ids, stale before values, incomplete snapshots, commands that target the wrong node kind, and batches whose child commands cannot all be validated. It should also explain whether rejected commands are simply skipped or whether their rejection invalidates dependent commands later in the same batch. Without those checks, preview becomes a visual confirmation ritual rather than a boundary.
The chain also changes how an LLM prompt should be written. The prompt for first-draft generation can ask for one full EditorDocument . The prompt for editing should ask for a command array plus rationale per command, bounded by the current document ids and expected before values. The UI should not trust the rationale as executable truth; it should use the rationale to help the human reviewer and use schema/command validation to decide what can be applied. This keeps natural language explanation and state mutation in separate lanes.
The broader design lesson is that AI-assisted editing should expose the smallest reviewable unit that still preserves intent. For this editor, the unit is not a paragraph of prompt text and not a full HTML file; it is an ordered set of typed commands whose effect can be previewed, accepted, rejected, batched, and undone. That unit lets a human reviewer evaluate concrete consequences: which node changes, what before value is expected, what after value is proposed, and whether the operation belongs to the model vocabulary.
This framing is intentionally conservative. It does not require the editor to become an autonomous agent. It requires the editor to treat LLM output as proposed structured input, then preserve the same state transition discipline it already uses for human actions. That is a practical path for a local visual editor: the LLM may draft or suggest, but the editor owns validation, preview, application, and history.
Limitations and Threats to Validity
This paper does not claim an empirical user study, a complete security audit, or a live LLM integration test. The method is a source-grounded synthesis. Its strongest factual claims are limited to files inspected in the current checkout, two git-history observations, selected graph items, and a focused verification run on 2026-06-29 [[cite:focusedVerification]].
The paper also does not treat historical plans as current implementation proof. Completed plans and older commits are evidence of design intent and past implementation, but current behavior must be tied to present source files. That is why the absence of commandSchema.ts , commandSchema.test.ts , and CommandPreview.tsx is treated as contradictory evidence rather than ignored [[cite:previewPlan,gitPreviewDelete]].
Finally, the paper uses code inspection and focused tests rather than a full application run with browser interaction. That is adequate for the claim being made: primitive readiness and missing preview surface. A future paper or test report should exercise restored preview approval through UI tests, malformed command arrays, partial approval, batch commands, undo after selective application, and import/export round trips.
Another limitation is that the paper does not inspect every command emitter in the UI. Canvas and property-panel controls were screened, but the final argument relies on the central command layer and store integration. That keeps the claim narrow. A later implementation audit should trace representative UI actions into emitted commands and compare their payload shape with any restored preview validator.
Conclusion
LLM edit assistance for this visual editor should be judged by command-preview accountability, not raw HTML mutation. The inspected checkout has a credible lower-level foundation: a schema-bound EditorDocument model, derived JSON Schema for external draft generation, a 15-variant invertible command layer, history integration, and focused tests. The missing piece is equally clear: the current tree no longer contains the preview validator and UI that would let users inspect and selectively approve LLM-proposed commands. The honest public claim is primitive readiness for command preview, not shipped command-preview approval.
The next implementation step follows directly from the evidence: restore a current command validator and preview component, cover all present command variants, make drift visible in tests, and keep LLM invocation separate from approval. That would turn the weakest stage in Equation 1 from a limitation into a verified boundary.