You copy a paragraph. You copy a code block. You copy an SVG from a design tool. You copy a screenshot.
You copy a PDF file. The keyboard shortcut is the same. The data is not. That difference decides what you should be able to do next.
Syzygy treats clipboard history as a set of typed content items. Each item keeps a content plan. The plan names the document family. It records the text representation when one exists.
It describes the best preview. It lists the capabilities that the item can support. The desktop uses that plan when it builds the action menu. The result is a history you can reuse instead of a pile of undifferentiated strings.
Start with a concrete copy
Imagine a designer copies an SVG icon. The clipboard may contain HTML wrappers. It may contain a rendered bitmap preview. It may contain the SVG source.
A filename-only clipboard manager sees an image. It offers an image preview. It drops the source. Syzygy asks a different question.
Can the payload be proven to be an SVG source? If the answer is yes, the item keeps both useful views. The graphic opens in a visual preview. The source remains available for copy, search, translation, or editing.
The preview does not erase the data that produced it.
What the content plan contains
Each item carries a content plan with a document description, a presentation description, and a capability plan.
It can carry preview assets. It can carry a collection plan for multiple files. The plan travels with the history header. The content blob can arrive later.
This separation lets a device show a title before it downloads a large file. It also lets the UI explain why an action is waiting.
Document family
PlainText represents ordinary text. Markdown represents Markdown text. SourceCode
represents code and configuration. Svg represents a standalone SVG document.
Excalidraw represents Excalidraw JSON and its canvas view. Figma represents a Figma
clipboard payload or a binary Figma file. Bitmap represents a raster image. Pdf
represents a PDF document.
Office represents a document, spreadsheet, or presentation file. Archive represents
a ZIP, TAR, GZip, BZip2, XZ, 7z, or RAR container. RichHtml represents a complete HTML
page without a stronger semantic family. Mixed represents HTML with both visible text
and visual media.
Collection represents a multi-file clipboard item. Binary represents content that
the recognizer cannot classify further. The family is a domain fact. The renderer is a
presentation choice.
The two values work together. They do not replace each other.
Text representation
Plain means the item has ordinary text. Markdown means the item has Markdown text.
SourceCode means the item has source text with code semantics. The text representation
is optional.
A binary .fig file has no text representation. A Figma clipboard source can have
SourceCode. That distinction prevents a binary file from receiving an editor that
cannot operate on it. It also allows a source-bearing graphic to expose a text workflow
without losing its canvas preview.
How recognition chooses a family
Syzygy combines several signals. It checks magic bytes. It checks a declared MIME type. It checks a filename and extension.
It inspects readable text. It inspects HTML structure. It keeps evidence for the decision. Authoritative container bytes receive priority.
An actual PDF header outranks a misleading filename. An image magic number outranks a text label. Readable text then receives structural inspection. The recognizer checks Excalidraw JSON.
It checks complete HTML. It checks standalone SVG. It checks Figma clipboard markers. It checks source-code patterns.
It checks Markdown signals. It falls back to plain text. The filename and MIME still matter. They help when the body is incomplete.
They do not get to overwrite stronger body evidence.
Why HTML needs special handling
Browser copy operations add markup around content. Code editors add spans for syntax colors. Design tools add metadata attributes. Rich text adds hidden nodes and styles.
The wrapper is transport. The user content is the payload inside it. Syzygy removes head, script, style, template, and comments from visible-text extraction. It keeps block boundaries and meaningful line breaks.
It keeps source whitespace inside pre, textarea, and source-preserving styles. It
uses image alt text as a fallback signal. It does not promote an image-only SVG into
plain text because the SVG contains <text> nodes. It keeps SVG as a graphic source.
It recognizes a Figma marker before it treats the wrapper as ordinary HTML. The order protects semantic content from a generic HTML fallback.
Capabilities answer “what can I do?”
The domain capability list is explicit. Preview allows a semantic renderer or a safe
placeholder. Ocr allows image or rendered-image recognition. Search allows indexer
participation.
Export allows extraction or file export. Ai allows an AI workflow when the profile
and quota allow it. Thumbnail allows thumbnail generation or reuse. Copy allows
system clipboard output.
SyntaxHighlight allows a code renderer. OpenExternal allows a local file to go to
another application. Translate allows the translation workflow. Edit allows an
editor or TextWorkbench.
The capability plan comes from one shared product rule. The desktop does not create a second list. The button set is a runtime projection. The projection checks local content.
It checks the configured provider. It checks feature gates. It checks the platform action. This is why a capability can exist while an action remains pending.
An item can support OCR while its image blob is still downloading. An item can support Edit while its source is incomplete. An item can support OpenExternal while no local file exists. The UI should say what is missing.
It should not remove the domain fact. It should not show a success state for a local prerequisite that failed.
The capability matrix in practice
Plain text supports preview, search, copy, AI, translation, editing, and external opening. Markdown adds export. Source code adds syntax highlighting. Source-bearing SVG, Excalidraw, and Figma add graphic preview, OCR, thumbnails, export, search, translation, and editing.
Bitmap supports preview, OCR, thumbnails, copy, export, and AI. PDF supports preview, OCR, search, copy, export, and external opening. Office and archive files support preview, search, export, and external opening. Rich HTML supports safe preview, search, copy, export, AI, translation, and editing through visible text.
Mixed content combines text and media actions. Binary content has preview, copy, and external opening. Collections aggregate member capabilities in a stable order. The collection order starts with preview and search.
It then includes copy, export, external opening, OCR, thumbnails, AI, highlighting, translation, and edit when a member supports them. The order keeps the action menu stable as more files become available.
A pending item is still a useful item
P2P sync can deliver a header before the content blob. The header can include a title. It can include a content family. It can include tags.
It can include a preview summary. The UI can show those facts immediately. The content action waits for materialization. This design matters for large projects.
It matters on mobile data. It matters when a peer is online for a short time. Tags belong to header metadata. Tagging a pending item does not download its blob.
Search metadata can arrive before OCR text. The indexer can fill the text field later. The history row remains stable during that process.
Source and render are two views of one item
Users often need to inspect a visual copy before they edit it. The preview surface can show the rendered graphic. The source surface can show the semantic text. The user can copy the source without copying a screenshot.
The user can copy a rendered image when the renderer exposes an image source. These actions have different prerequisites. The model does not pretend that they are interchangeable. SVG source is not the same as a PNG.
An HTML wrapper is not the same as a Figma marker. A binary Figma file is not editable source. The distinction prevents data loss during a common copy-and-reuse loop.
Markdown images and remote resources
The web content platform renders standard Markdown image links.
An image link displays a resource. It does not place the resource into the system clipboard. It does not turn a remote image into local content. Clipboard HTML image materialization follows a separate backend path.
That path normalizes the URL. It validates the protocol. It applies request and response limits. It handles redirects within the security boundary.
It reports errors without injecting a partial clipboard item. This separation lets a Blog show a stable image without weakening Clipboard security.
Try a format-safe workflow
Copy a Markdown snippet. Open the command palette. Search for the item. Open the preview.
Copy the source into a document. Then copy an SVG. Switch between graphic and source views. Run a text operation on the source.
Keep the graphic unchanged. Finally copy a screenshot. Send it to OCR. Search for a word from the image.
The same history list handles all three workflows. The actions change because the data changes.
Troubleshooting
The item shows the wrong family
Check the payload that reached the recognizer. Check the magic bytes. Check the declared MIME. Check whether an HTML wrapper hid the source marker.
Check whether the header contains an old plan. The current plan can be normalized by the content-plan migration. The UI should not patch the family from the filename.
The source view shows HTML spans
The renderer should extract semantic source. Syntax-highlighted spans belong to transport. Extract visible text without transport markup. Extract the complete SVG element for SVG source.
Normalize Figma markers into one stable source form. Raw HTML is a last fallback.
OCR is available but the button is disabled
Confirm that the image blob is local. Confirm that a rendered PNG exists for a source graphic. Confirm that the OCR provider is configured. Confirm the image size is inside the provider budget.
The capability remains a domain fact. The disabled state reports the missing runtime prerequisite.
Edit is unavailable for a .fig file
That file may be binary. Binary Figma content has no source text. Open the visual preview or use an external editor. Use a Figma clipboard source when you need TextWorkbench operations.
A collection has too few actions
Inspect the member plans. The parent collection aggregates member capabilities. An empty collection receives the collection baseline. The parent does not invent actions that no member supports.
Select a file entry to see its own renderer and actions.
Questions people ask
Does Syzygy convert every copy into Markdown?
No. The recognizer keeps the source family it can prove. Plain text remains plain text. Code remains source code.
An image remains an image.
Does an image preview mean the original image is local?
No. A preview asset can be a small header field. The full blob may still be pending.
Can I search a screenshot?
Yes, after OCR completes. The OCR result enters the local search index. The original screenshot stays unchanged.
Can I edit a PDF directly?
Text extraction and editing are separate operations. PDF gains searchable text or OCR text. TextWorkbench edits a text source and creates a new snapshot. It does not rewrite the PDF binary.
Why does Figma need two cases?
A clipboard source carries semantic markers. A binary .fig file carries a file format.
Only the first has source text for the text workflow.
Does the capability list come from the frontend?
No. The capability plan comes from the shared product rule used by every surface.
Can I tag a pending item?
Yes. Tags are header metadata. Tagging does not force a blob download.
Can a remote image link write to the clipboard?
Only through an explicit materialization and clipboard action. The Markdown renderer only displays the image.
What happens when the plan is old?
The database migration and normalizer restore derived fields. The UI consumes the normalized plan.
Where should a plugin read content type?
Read the content plan attached to the history item. Do not recreate the MIME and filename table in the plugin.
What we verify before shipping a new type
We define the document family, its legal signature, its text representation, and its presentation renderer.
We define capabilities in the shared rule, add recognition tests, and verify that older items still receive a valid normalized plan.
We add preview tests. We test a pending header. We test a complete payload. We test a collection member.
We test a malformed input. We test capability and runtime prerequisite errors. This list keeps a new format from becoming a button-only feature.
Continue the workflow
Read preview, popup, and Command + K for the next interaction step. Read OCR and index search for visual content retrieval. Read P2P clipboard sync for header and blob delivery. The format-safe clipboard loop starts with one rule.
Keep the data type visible.