Clipboard history grows faster than most people expect. A day of research can add dozens of links. A design session can add screenshots and SVG fragments. A support shift can add names, error messages, and commands.
The history remains useful only when you can separate material from noise. Syzygy uses tags for meaning. It uses Trash for reversible removal. It uses retention rules for permanent cleanup.
Those jobs stay separate.
A tag is a shared record
A tag has a name. It can have a color. It has a count of linked items. Clipboard headers link to the tag.
The color belongs to the tag record. It does not belong to a single chip component. It
does not come from a random color function after every refresh. Choose blue for
reference.
Every reference chip should show blue. Rename reference to research. The linked
clipboard items should keep the relationship. Change the color to green.
The next read should return green. That behavior turns color into user configuration.
Four operations cover tag management
Create makes a tag record. Query reads tags and counts. Update changes a name, a color, or both. Delete removes selected tags and their item links.
Attaching tags to an item is an item-header update. The public product model can stay this small. The request can still contain precise fields. A rename request needs the current name and the new name.
A color update needs the tag and the new color. A combined update can send both values. The API does not need a different public permission for every field. The server still validates each field.
The server still reports the affected items. The UI still refreshes the changed rows.
What happens during a rename
The update starts with the source tag. The new name is normalized. Empty names are rejected. Names that only differ by surrounding whitespace collapse to one value.
The color is normalized. Invalid color strings are rejected. The update finds every linked clipboard header. It moves each relationship to the target name.
If the target already links to that item, the duplicate relationship is removed. The target tag keeps its configured color. If the target has no color, the source color can move with the rename. An explicit new color wins over both existing colors.
The source tag is removed after its relationships move. The operation returns the updated tag. It also returns the affected item keys. The UI uses those keys to refresh the visible list.
The user sees one completed rename. They do not see a half-renamed history.
Why the update runs as one transaction
A rename touches more than one table. The tag record changes. The item relationships change. The count changes.
The read model needs a refresh. Splitting those writes creates intermediate states. One item could show the old name. Another item could show the new name.
The source color could disappear. A transaction keeps the writes together. The event publishes after the transaction commits. The UI then reads the final record.
That sequence is the reason a chosen color survives an application restart.
Tagging a pending synced item
P2P sync can deliver a header before a content blob. The header already has an item identity. It can already carry tags. It can already carry a content family.
The item can therefore receive a tag while its content remains pending. Tagging does not start a blob download. Changing color does not start a blob download. Renaming the tag does not start a blob download.
The metadata update stays small. The content transfer follows the sync policy. This separation matters for mobile data. It also matters for large file collections.
The tag editor workflow
Open an item. Choose Edit tags. Search existing tags. Select one or more tags.
Create a tag when the list does not contain the right term. Choose a color when color adds meaning. Save the selection. The item header updates.
The visible chips update. The tag count updates. Close the editor. The item remains selected.
The content preview does not reload unless the item content changed.
Suggestions and AI auto-tagging
The tag editor can show suggestions. Suggestions can come from recent use. They can come from item text. They can come from an AI profile.
A suggestion is not a stored tag. The user chooses the final value. The normal validation path handles the save. The same color rule applies.
The same rename rule applies. The same count rule applies. AI does not receive a private write path around tag persistence.
Showing tags on a compact item
A clipboard card has limited width. Showing every tag can push the content out of view.
Syzygy displays a bounded number of chips. Extra tags collapse into a +N entry.
The entry opens the full set. The chosen tag colors remain visible. Text still needs enough contrast. Color never replaces the tag name.
Keyboard users can reach the expanded list. Screen-reader users receive the tag text. The compact view stays useful at narrow widths.
Trash is a state, not a hidden list
Move to Trash marks the item as trashed. The item leaves the active Clipboard scope. It enters the Trash scope. The content is still recoverable.
The tags are still attached. The item identity is still known. Restore clears the Trash state. The item returns to active history.
The search and list views refresh. The user can continue using the item. Trash therefore supports a reversible cleanup step.
Delete forever is a different operation
Permanent delete removes the item. It removes the local content that belongs to the item. It removes the search document. It records deletion for synchronization.
The record prevents an older peer from reviving the item as new content. The action needs a stronger confirmation than Move to Trash. The confirmation names the item count. It explains that restore will no longer work.
It keeps the default focus on the safer choice. The operation reports failures. The Trash list refreshes after completion.
Retention performs planned cleanup
Some users keep a short history. Some users keep weeks of references. Some devices have little storage. Retention rules can use age.
They can use item count. They can combine those limits. The cleanup process selects eligible trashed items. It claims a bounded batch.
It removes the content. It updates the search index. It preserves synchronization deletion evidence. The process does not delete an active item because its blob is large.
Active history and Trash remain separate scopes.
Keep offline, Pin, Favorite, and Trash
Keep offline controls blob retention. Pin controls list position or prominence. Favorite marks user preference. Trash marks removal from active history.
These states answer different questions. Can the device evict the local blob? Should the item stay near the top? Did the user mark it as valuable?
Should the item appear in active history? One state should not impersonate another. A pinned item can still move to Trash. A trashed item can still keep its tags until deletion.
A favorite can remain on demand. A keep-offline item can have no tags.
A practical tagging system
Start with fewer than ten tags. Use project names for active work. Use reference for
material you expect to reuse. Use follow-up for content tied to an action.
Use share for content that can leave the device. Use private only when the term has
an agreed meaning. Choose colors for categories that deserve quick scanning. Do not
assign a unique color to every tag.
Names carry the meaning. Color shortens recognition time. Review unused tags once a month. Rename overlapping terms.
Delete tags that no longer describe any item.
A real workflow: research notes
Copy a quote from a paper. Tag it research. Tag it with the project name. Choose a
consistent project color.
Copy a second quote. Reuse the same tags. Search the project tag later. Open the quote preview.
Copy the exact source text. Move an irrelevant quote to Trash. Restore it if the project changes direction. Permanently delete it when the retention window expires.
A real workflow: support snippets
Copy a diagnostic command. Tag it support. Tag it with the platform name. Give
platform tags distinct colors.
Copy a customer-specific value. Avoid a shared tag that implies the value is safe to share. Use a clear private-data policy. Move the temporary value to Trash after the session.
Delete forever after the required retention period. Keep reusable commands in active history.
Troubleshooting tag colors
The color changes after restart
Read the saved tag record. Confirm the color reached the update request. Confirm the update completed. Confirm the UI uses the returned record.
Remove random display color as the primary source. Use a fallback color only when no user color exists.
The Tags page shows one color and the preview shows another
Both surfaces should read the same tag record. Check stale local state. Check event delivery after the save. Check whether the preview cached the old record.
Refresh the affected item keys.
Rename loses the color
Check whether the destination tag already had a color. An explicit update color should win. An existing destination color should remain. A source color should move only when the destination has no color.
The result should return the final color.
A tag remains after its last item changes
Check the relationship count. Check whether another item still uses the tag. Check the cleanup after replacing an item's tag set. An unreferenced tag can be removed.
Troubleshooting Trash
Restored items do not appear
Check the active scope filter. Check the restore result. Check the history change event. Check the active-list refresh.
Check the current search query. The item may be restored but filtered out.
Delete forever leaves a search result
Check the index delete job. Check whether the search view has stale results. Check the item identity in the delete event. Open results through history so a missing item reports a clear state.
An old peer restores a deleted item
Check synchronization deletion evidence. Check peer catch-up order. Check whether permanent delete completed before the peer reconnected. The system should prefer the deletion record over an older header.
Questions people ask
Can I change a tag color without renaming it?
Yes. Send an update with the tag and color. The saved tag record returns the final value.
Can I rename and recolor in one action?
Yes. The update can carry both fields. The transaction applies them together.
Can two tags have the same color?
Yes. Color is a visual aid. The name remains the identity.
Can I tag a file that has not downloaded?
Yes. Tags belong to header metadata.
Does deleting a tag delete its clipboard items?
No. Deleting a tag removes the relationships and the tag record. The history items remain.
Does Move to Trash delete the content?
No. It changes the item scope and keeps restore available.
Does Delete forever keep a backup?
The application does not promise an undelete path after permanent removal. Use an external backup when policy requires one.
Can retention delete active items?
Trash retention targets eligible trashed items. Active-history policies should remain explicit and separate.
Why show a +N chip?
The compact card needs room for content. The full tag set remains one action away.
Can AI assign tags without review?
AI can suggest tags. The normal save path still validates and stores the final selection.
What users should be able to verify
A chosen color survives restart. The Tags page and item chips show the same color. A rename updates every linked item. A rename into an existing tag does not create duplicate links.
A pending item accepts tags without a content download. Move to Trash removes the item from active history. Restore returns it. Delete forever removes it from Trash and search.
Retention follows the configured rule. Keep offline stays independent from Trash.
Continue reading
Read clipboard content types to understand which metadata arrives before a blob. Read indexer and search to combine tags with full-text retrieval. Read P2P pairing and sync to understand how tag updates reach trusted devices. Good organization keeps the label, the content, and the deletion state separate.