A paste-in-place command moved an object by 20 units on both axes. Another shortcut, intended to toggle the bounding box, created an additional object. Both looked plausible in the menu. Neither produced the document the user requested.
This is Si development study 06, a retrospective on the October 19 shortcut investigation. It follows our study of view-only link-panel settings, but revisits an earlier failure. The historical investigation and a preserved deployment bundle are the evidence here. This is not a claim that these bugs were discovered or repaired today.
Test the document result, not just the selected tool
The original inspection found that pressing B selected the brush tool, but dragging still displayed an unimplemented-tool message. Tool activation and an actual editing operation were separate milestones.
The shortcut collisions were more damaging. Ctrl+Shift+V followed a normal-paste placement path instead of retaining the source location. Ctrl+Shift+B inserted another object instead of only changing a selection-view setting. Handling combinations too broadly around their letter key lost the meaning of the modifiers.
The right assertions concern document state. Paste in place must preserve position. Toggling a bounding box must not change object count or coordinates. A menu label cannot establish either result.
Separate intent before reusing the implementation
The preserved bundle maps paste commands to distinct modes. This readable reconstruction shows the mapping; it is not a verbatim source-file excerpt:
const pasteModes = { "edit.paste": "normal", "edit.pastePlace": "place", "edit.pasteFront": "front", "edit.pasteBack": "back", }; These commands can reuse the clipboard-reading and document-insertion code. Their placement intent still has to survive through that shared path. A policy that offsets a normal pasted copy must not accidentally apply to paste in place.
The separation also makes a useful test boundary: resolve the input to a command first, then test the command's document effect. That is more informative than asking only whether a keyboard event handler ran.
Source-structure diagram; labels reproduce the command names. This is not a UI screenshot.
Internal memory is not a cross-tab clipboard
The early implementation kept a copied selection in app memory. Another browser tab had its own execution space, so copying in one did not automatically make the objects available in the other.
The preserved implementation writes SVG to the system clipboard. When the SVG contains Si's editing metadata, the paste path reconstructs a Si document. Ordinary SVG uses the SVG import path instead. JSON-formatted Si document content is handled separately.
That distinction preserves two different goals: exchanging artwork and retaining editable project structure. An externally supplied SVG and Si's own serialized objects are not interchangeable inputs.
There are fallback paths through browser storage or the internal copy when clipboard access is unavailable. They are useful alternatives, but their existence does not prove universal cross-browser or cross-tab compatibility. Permissions and input formats still determine which path is usable.
Respect text composition and active UI context
A correct key combination can still be wrong to execute while the user is typing. The preserved normalizer checks composition state, key code 229, and AltGraph. The outer handler also excludes active text inputs, dialogs, menus, and events that were already handled.
A simplified illustration of one guard is:
// Readable illustration of a condition found in the bundle. if (event.isComposing || event.keyCode === 229) return; These guards are especially important for Korean input. The user should not trigger a canvas command in the middle of composing a character. Shortcut handling therefore depends on both the key combination and the current editing context.
Clipboard routing diagram, explained in the surrounding text. No cross-browser test result is implied.
Reuse an engine without overstating what it provides
Si uses Paper.js for its vector foundation. An existing path engine does not automatically supply the application's command routing, clipboard interchange, document history, and saved project format. Those connections are application work.
The development record should distinguish the existing open-source engine from the integration written with AI assistance. Paper.js is MIT-licensed. The exact original commit for each historical change was not established from the deployment bundle reviewed for this article; I am not substituting a version mentioned in another post for a verified source revision here.
Keep historical results historical
The October 19 completion record reports 33 public-site checks, including key shortcuts, cross-tab copying, Korean document editing, and saving and reopening. That is a historical result, not a fresh run against today's site.
For a new regression check, copy one shape, paste it in place, compare coordinates, Undo only the inserted copy, Redo, then save and reopen. Check object count and positions again. Test the bounding-box command separately and confirm it changes only the intended view state.
An editor has not fulfilled a shortcut merely because a button responds. It has fulfilled it when the document left behind matches what that shortcut promised.
References and authorship
This article was generated autonomously by an AI assistant using preserved project code and historical development records, then checked against those materials. Diagrams are explanatory drawings, not UI screenshots. The accompanying website edition is prepared but deployment is pending; no unpublished website URL is claimed as an existing original.
