docs: simplify ai generated content

docs/Analytics.md

@@ -16,22 +16,10 @@ The current design goals are:
 
 ## Architecture
 
-TidGi does not initialize a browser-side analytics SDK.
-
-Instead:
-
 1. Renderer code and TiddlyWiki plugins call the TidGi analytics service through the existing IPC proxy layer
 2. The analytics service runs in the main process
 3. The main process sends events to Rybbit over HTTP
 
-Relevant files:
-
-- `src/services/analytics/interface.ts`
-- `src/services/analytics/index.ts`
-- `src/preload/common/services.ts`
-- `src/preload/common/exportServices.ts`
-- `src/services/wiki/plugin/ipcSyncAdaptor/Startup/mount-tidgi-service.ts`
-
 ## Delivery model
 
 - Analytics is enabled only when all of the following are true:
@@ -133,44 +121,3 @@ Plugin event names are intentionally restricted.
 If `pluginId` or `eventName` is invalid, the event is rejected.
 
 If all properties are invalid, the event is still allowed to be sent without properties.
-
-### What plugin authors should track
-
-Good examples:
-
-- whether a plugin feature was used
-- which plugin surface triggered an action (`toolbar`, `context_menu`, `shortcut`)
-- coarse booleans like `has_filter`, `used_template`, `has_due_date`
-- bounded enums represented as short strings
-
-Bad examples:
-
-- card title text
-- search query text
-- raw wiki URL
-- tiddler title
-- workspace name
-- exported content
-
-## When to add a built-in event instead of a plugin event
-
-Use a built-in event when the behavior is part of TidGi core product behavior and should be governed by a fixed property allowlist in source control.
-
-Use `trackPluginEvent()` when the event belongs to a plugin or extension and needs a stable but bounded custom namespace.
-
-## Rybbit usage in TidGi today
-
-Today TidGi only uses Rybbit's event ingestion path for coarse custom events.
-
-The current implementation sends HTTP requests to the configured Rybbit host using the server-side API key stored only in the main process.
-
-## Verification checklist for analytics changes
-
-When editing analytics behavior:
-
-1. Confirm the event does not include content or identifiers from user data
-2. If it is a built-in event, update the property allowlist
-3. If it is a plugin event, prefer `trackPluginEvent()` instead of widening built-in types
-4. Run `pnpm check`
-5. Run eslint on changed files
-6. Update this document and `docs/TidGiServiceAPI.md` if the callable surface changed

docs/features/WorkspaceGrouping.md

@@ -92,32 +92,11 @@ TidGi treats the sidebar as an interleaved sequence of two item types:
 
 Grouped workspaces are rendered under their group header, but the ordering logic still treats the sidebar as one ordered structure. This is why a group can be placed before another group or before an ungrouped workspace.
 
-### Drag intent resolution
+## Developer
 
-The drag system resolves intent from three things:
+### Why the ghost preview was removed
 
-- what is being dragged
-- what is under the pointer
-- where the pointer is inside the target rectangle
-
-For workspace-on-workspace drops, the target rectangle is divided into three zones:
-
-- top third: reorder before
-- middle third: group
-- bottom third: reorder after
-
-For group-header drags, the result is reorder only.
-
-For workspace-on-group-header drops, the result is interpreted as either:
-
-- join that group
-- leave the current group, if the header belongs to the workspace's own group
-
-This model keeps the visible interaction simple while still supporting several operations with one pointer gesture.
-
-## Why the ghost preview was removed
-
-Earlier versions used a ghost or placeholder style preview that visually moved items around while dragging. In theory this made the future drop position easier to imagine. In practice it introduced a more serious problem: the DOM and drop zones moved during the drag itself.
+Earlier versions (before v0.13.1) used a ghost or placeholder style preview that visually moved items around while dragging. In theory this made the future drop position easier to imagine. In practice it introduced a more serious problem: the DOM and drop zones moved during the drag itself.
 
 That movement caused two kinds of trouble.
 
@@ -146,36 +125,7 @@ The highlight still tells the user what will happen:
 
 This trades a more dramatic preview for a more trustworthy interaction. The result is easier to reason about, easier to test, and less likely to produce accidental grouping or accidental reordering.
 
-## Why stable layout matters more than animated preview
-
-The sidebar is not a plain sortable list. It mixes:
-
-- workspaces
-- group headers
-- collapsed groups
-- expanded groups
-- workspace-to-workspace drops
-- workspace-to-group-header drops
-- group-header-to-group-header drops
-
-In that environment, stable hit targets matter more than visual motion.
-
-When users drag in a dense sidebar, they need the drop zones to stay where they are. If the UI animates a placeholder into the structure too early, the pointer can end up triggering a different action from the one the user intended.
-
-Removing the ghost is therefore not a visual simplification for its own sake. It is a correctness decision.
-
-## Implementation notes
-
-At a high level, the workspace grouping UI is implemented in the main sidebar list component. The current implementation:
-
-- keeps a canonical ordered list of workspaces and groups
-- resolves drag intent from pointer position and target type
-- persists reorder or membership changes after drop
-- uses visual intent highlighting instead of in-drag DOM reordering
-
-The Preferences management UI is implemented separately and uses workspace service calls to create groups, rename groups, delete groups, and synchronize membership.
-
-## Related code
+### Related code
 
 - [src/pages/Main/WorkspaceIconAndSelector/SortableWorkspaceSelectorList.tsx](../../src/pages/Main/WorkspaceIconAndSelector/SortableWorkspaceSelectorList.tsx)
 - [src/windows/Preferences/customItems/WorkspaceGroupsItem.tsx](../../src/windows/Preferences/customItems/WorkspaceGroupsItem.tsx)