Docsmemory-sync
Quick GuideCLISDKMCPGUITechnical DetailsDesign Rationale
GitHub

文档组件

doc/ 现在可以直接在 MDX 里使用一组共享文档组件，而不用手写大段 Markdown 表格。它们通过 doc/mdx-components.tsx 全局注册，所以任何 .mdx 页面都能直接使用这些 JSX 标签。

1. 多工具能力矩阵

memory-sync 能力矩阵

当你想用一张表展示 CLI、MCP、GUI 和文档站分别负责什么时，这个组件会很有用。

ToolCore CapabilityEntry / SurfaceNotes
CLI
Stable
负责 install 与 clean 执行的用户入口。
  • 运行默认 install 流水线
  • 支持 install / dry-run / clean / plugins
  • 暴露 npm native 包与 crate 入口
  • tnmsc
  • ./target/release/tnmsc --help
对用户来说，真正的执行入口仍然是 CLI，而不是文档站或 GUI。
MCP Server
稳定 API
向外暴露 prompt 管理能力。
  • 列出 prompts
  • 读取 source / dist
  • 更新 zh/en source
  • 写回翻译产物
  • memory-sync-mcp stdio server
  • MCP 客户端集成
它复用 CLI 侧 prompt service，不应该再发明另一套 schema。
GUI
Beta
桌面调用与呈现层。
  • 调用 tnmsd crate
  • 承载桌面工作流
  • 展示项目状态与操作页
  • Tauri 桌面壳
  • React 前端
GUI 负责调用与呈现，但不应反向从前端驱动领域设计。

2. 多系统支持矩阵

系统支持表

当你需要描述平台支持级别以及它们之间的差异时，这个组件很好用。

SystemSupportCoverageNotes
WindowsFull
  • CLI 工作流
  • 文档站开发
  • Tauri 桌面开发
这是当前用户群最重要的平台，所以命令示例应该优先照顾它。
macOSPartial
  • CLI 工作流
  • 文档站开发
原则上支持，但桌面打包与签名仍需要单独验证。
LinuxPartial
  • CLI 工作流
  • 文档站开发
  • 部分桌面场景
很适合 CI 和开发机，但桌面分发仍受发行版差异影响。
WSL推荐
  • Node / pnpm / Rust 开发
  • Windows 上的跨文件系统协作
这个仓库已经非常适合基于 WSL 的维护方式。

3. 平台卡片

平台概览

当你想在首页或安装页快速表达平台定位，而不是摆一张冷冰冰的支持表时，这个组件很有用。

Desktop

Windows

Full

用户的主要桌面环境，也是同时说明 WSL、PowerShell 和 Tauri GUI 的好地方。

  • 优先提供安装与升级指引
  • 适合同时展示 GUI 和 CLI 两个入口
  • 截图与命令示例在这里价值最高
Desktop

macOS

Partial

常见的开发环境，也适合记录 Homebrew、codesign 和桌面集成细节。

  • 强调开发者体验
  • 把签名和分发问题单独处理
  • 命令示例里避免写死 Windows 特有路径假设
Desktop / CI

Linux

Partial

更适合自动化、CI 和本地开发说明。

  • 适合放 CI 与构建命令
  • 明确指出发行版差异
  • 按打包格式解释桌面分发

4. 技术栈命令参考

技术栈命令表

你可以在不改组件结构的前提下继续追加行。它很适合列 pnpm、cargo、Tauri 和文档站命令。

StackTaskCommandRuntimeNotes
pnpm workspace安装依赖
pnpm install
Node.js 22+所有 workspace 都从仓库根目录启动。
docs / Next.js本地运行文档站
pnpm -C doc dev
Node.js 22+适合一起预览 MDX 内容和组件。
docs / Next.js类型检查
pnpm -C doc run validate:contentpnpm -C doc run check:type
Node.js 22+修改 MDX、frontmatter 或文档组件后，优先跑这个。
Rust workspace运行测试
cargo test --workspace
Rust 1.88+适合检查变更是否影响了 Rust-first 这一侧。

5. 包管理器安装标签

PackageManagerTabs 仍然适合“同一个包名，不同包管理器命令”的场景。现在 CLI 主包会自动解析并安装对应的平台 native 子包，所以安装页更适合直接展示统一主包命令，再额外说明 Linux musl/Alpine 这类暂不支持的环境。

MDX
npm install -g @truenine/memory-sync-cli
 
> Linux musl / Alpine is not covered by the published npm native binaries yet.

用法

把下面这类代码直接写进任意 MDX 页面即可：

TSX
<FeatureMatrix items={[{tool: 'CLI', capabilities: ['sync'], surfaces: ['tnmsc']}]}/>
<SupportMatrix items={[{system: 'Windows', support: 'full'}]}/>
<PlatformGrid items={[{name: 'Windows', description: 'Primary desktop target'}]}/>
<CommandReference items={[{stack: 'pnpm', task: 'dev', command: 'pnpm -C doc dev'}]}/>
<PackageManagerTabs commands={{npm: 'npm install -g pkg', pnpm: 'pnpm add -g pkg', yarn: 'yarn global add pkg'}}/>

如果你以后继续扩展这套系统，建议继续沿着这个方向走，而不是退回到零散的原始 Markdown 表格：

  • 对表格型信息复用 FeatureMatrix、SupportMatrix 和 CommandReference
  • 对展示型内容复用 PlatformGrid
  • 对安装命令切换复用 PackageManagerTabs
  • 只有在你真的需要更自由布局时，再新增卡片类或对比类组件