hypertwist/docs/MIRROR_KEEP_VS_MOVE_OUT_EVALUATION.md

Mirror Keep Versus Move Out Evaluation

Status

This is an evaluation document, not a removal order.

Unless already explicitly removed in a prior cleanup pass, the mirrors discussed below are to be retained for now pending review with other models.

Scope

This evaluation applies to the current C:\ScriptoriumAI\mirrors inventory and the product-adjacent mirrors under C:\ScriptoriumAI\scriptoriumai-ui\mirrors.

Already removed in the prior cleanup pass:

• mirrors/claude-prism
• mirrors/zotero
• scriptoriumai-ui/mirrors/GitNexus
• Overleaf/overleaf
• Overleaf/overleaf-main

Evaluation Method

The classification below is based on:

• direct path-based references in the active app, server, scripts, and service code
• whether the mirror is a true pinned runtime or build dependency
• whether the mirror is only used as inspiration, examples, or internal tooling
• whether the mirror looks like a large intake candidate better suited to an external workspace

Keep In Repo

These are the mirrors that still make sense as in-repo pinned dependencies.

High-confidence keep

• mirrors/GitNexus
• mirrors/claude-skills
• mirrors/awesome-claude-skills
• mirrors/latexocr
• mirrors/pdfdelta
• mirrors/pdfmd
• mirrors/code2video
• mirrors/paper2video
• mirrors/liquid-glass-react

Why they stay

• GitNexus remains the retained internal code-intelligence tool and the root copy is the correct one to keep.
• claude-skills and awesome-claude-skills remain tied to the skills-management workflow.
• latexocr remains path-wired into the OCR service and Docker build.
• pdfdelta and pdfmd remain tied to the PDF intake and diffing flows.
• code2video and paper2video remain wired into server services.
• liquid-glass-react remains a pinned donor for the glass UI implementation.

Move Out Candidates

These are the mirrors that look better as external workspace mirrors than as in-repo submodules.

Highest-confidence move-out candidates

• mirrors/fabro
• mirrors/litellm
• mirrors/open-webui
• mirrors/OpenSpace
• mirrors/ReMe
• mirrors/Roo-Code
• mirrors/skillhub
• mirrors/smriti
• mirrors/supermemory

Why they are candidates

• In the active code scan they only showed up in mirror-sync automation or similarly shallow references.
• They do not currently present as pinned path dependencies of the shipping product.
• They fit better as external research, evaluation, or optional integration repos.

Likely Move Out Candidates

These do not currently justify living inside the main repo, but the evidence is weaker than the group above because some of them inform UI concepts or feature directions.

• mirrors/cheatsheet
• mirrors/veritas-kanban
• mirrors/paper2all
• mirrors/featurebase
• mirrors/itshover
• mirrors/mind-map
• mirrors/next-ai-draw-io
• mirrors/paperbanana
• mirrors/remotion
• mirrors/storm
• mirrors/supertokens-auth-react
• mirrors/excalidraw

Why they are not automatic keeps

• Several are only referenced by inspiration comments, examples, or visual donor notes.
• Several appear conceptually relevant but not directly path-wired into current runtime logic.
• These are good external workspace candidates unless a later pass proves they need pinned in-repo revisions.

Large Cluster Best Moved Outside

The following family should almost certainly be managed as external mirrors rather than in-repo mirrors unless there is a very specific active editing reason:

• mirrors/chanim
• mirrors/manim
• every mirrors/manim-* entry
• every mirrors/Manim* entry

Why

• The cluster is broad and repo-heavy.
• The active product does not currently justify keeping the entire family pinned inside the main repo.
• This is exactly the kind of fleet that benefits from the external workspace model.

Current Decision

The current operating decision is:

• keep the existing retained mirrors in place for now
• do not promote more in-repo mirrors casually
• direct future intake toward the external workspace roots
• revisit each move-out candidate only when there is a concrete integration or editing need

Practical Rule Going Forward

Use this rule for new mirror decisions:

Keep a mirror in-repo only if all three are true:

• the product depends on it by path
• the revision must be pinned inside the product repo
• CI or deployment depends on that exact in-repo location

Otherwise:

• move or add it to C:\Workspaces\ScriptoriumAI\mirrors
• track it in C:\Workspaces\ScriptoriumAI\repos.manifest.json
• leave it in root include mode until active editing justifies promotion

Handoff Note

This file is intentionally conservative.

It records what looks safe to keep, what looks safe to move out, and what should remain undecided until another review round. The aim is to preserve optionality while preventing the main repo from turning into a permanent warehouse for every interesting upstream project.