Apple Notes Snapshot

Apple Notes Snapshot

Apple Notes Snapshot 是 macOS 上 Apple Notes 的备份控制室。保留上游 notes-exporter 引擎，同时增加支持路径的导出、launchd 调度、直观的健康检查，以及本地备份循环偏离预期时更从容的恢复方式。

🤝 姐妹仓库：想要事后恢复已删除的笔记，而不是提前备份？请参阅 notes-recover——用于读取 Apple Notes 的 NoteStore.sqlite 的取证级工具（恢复已删除的笔记、浏览原始存储，并生成可供审计的资料包）。notebackup 负责事前；notes-recover 负责事后。二者共同覆盖 macOS 上 Apple Notes 的完整生命周期。

控制室本身已能满足需求后，仓库还提供额外的构建和诊断界面，方便用户和编码 Agent 检查相同的备份状态，同时不必将工作流变成托管服务。

开始 3 步快速入门 | 首次运行故障排查 | 打开验证页面 | 与上游版本比较 | 浏览发布历史 | 获取支持或路由帮助

• 让路径一目了然 在首次写入快照前，检查或更改导出目标位置。
• 将单次导出变成持续运行的本地循环 使用 launchd 调度可重复执行的快照，不必守着手动导出。
• 先查看健康状况，再做判断 当备份循环偏离预期时，检查新鲜度、失败原因、日志和恢复线索。
• 先了解下一步安全操作 Web 控制台现在会在原始记录上方显示操作重点面板，方便你先了解下一步操作、原因和阅读顺序，再查看操作输出。

类别：Apple Notes 备份控制室。 AI/Agent 接入点：AI 辅助诊断，以及在操作工作流已清晰后可选的编码 Agent 访问。 结果：在自己的 Mac 上获得更从容、更易审查的备份工作流。

最适合：已经依赖 Apple Notes，并希望在自己的 Mac 上建立更从容、易审查的备份流程的人。

目标不包括：云同步、团队协作，或向 Apple Notes 双向写回。

概览

如果你只想在深入阅读前快速了解真实情况，请先查看此表：

你需要了解的内容	当前答案
产品定位	macOS 上 Apple Notes 的备份控制室
首次成功	./notesctl run --no-status -> ./notesctl install --minutes 30 --load -> ./notesctl verify
首个验证界面	本地循环健康运行一次后查看验证页面
仅属第二层的功能	操作路径清晰后，再使用 AI Diagnose、本地 Web API 和 MCP
绝不能简化成的产品	托管式 Notes 服务、云同步产品或通用 AI 控制面板

一次本地运行即可验证的内容

• 目标位置一目了然：在写入任何内容之前，你可以检查或覆盖快照路径。
• 循环确实可行：手动运行一次，再配合 launchd，就能将一次性导出变成可重复的本地流程。
• 控制室可供检查：status、verify、doctor、日志和证明页面都基于同一组本地事实。
• 集成入口可选：AI Diagnose、本地 Web API 和 MCP 都作为操作流程的补充，而不是取而代之。

如果完成首次运行后，你想查看最精简的公开证据链，请打开 证明页面。 它汇集了仓库管理的检查项、由 GitHub 控制的发布与 Pages 证据，以及当前的访问边界。

从 Run -> Install -> Verify 开始

把首次正常运行的流程当成一份分为三个步骤的检查清单，而不是需要一次看懂的仪表板。

1. 运行 使用 ./notesctl run --no-status 运行一次，让 macOS 显示权限提示，并让本地记录簿记录首次成功的基线。
2. 安装 首次运行后使用 ./notesctl install --minutes 30 --load，让工作流变成可重复的 launchd 循环，而不是手动任务。
3. 验证 先使用 ./notesctl verify，只有在仍有警告或状态为空时才使用 ./notesctl doctor。

有了经过验证的循环后，Web 控制台、证明页面、AI Diagnose、本地 Web API 和 MCP 入口就更容易理解，因为它们描述的都是你已经验证过的基线。

操作流程之后的集成与维护者路径

面向公众的产品入口仍是本地备份控制室。以下路径面向已完成首次正常运行的构建者；它们不会取代 Run -> Install -> Verify。

• 面向公众的产品入口：备份控制室
  • 核心流程仍是在你自己的 Mac 上检查本地路径、首次运行快照、建立 launchd 循环，以及查看健康检查界面
• 第二环构建者协议路径：纯 MCP
  • 仓库面向机器的主要入口，是通过 ./notesctl mcp 和根目录 server.json 实现的本地 stdio MCP 流程
• 第二环构建者数据包路径：纯技能
  • 公开技能数据包 examples/public-skills/notes-snapshot-control-room/ 用于指导宿主如何连接到同一控制室
• 后续配套路径：插件外壳和 .mcpb 打包
  • plugins/apple-notes-snapshot-control-room/ 和 packaging/mcpb/ 是围绕同一套本地工作流、针对不同宿主打造的打包入口
  • 它们很重要，但不是新审核者首先应该了解的内容
• 当前不作出的承诺
  • 不提供托管的 Notes 服务
  • 不提供云同步产品
  • 未经近期的宿主端回读确认，不声称已在官方技能或插件市场上架
  • 不保证支持跨机器连接

只有在操作流程已经清晰之后，才使用下面的集成链接。

首次正常运行后的次要集成参考： AI Diagnose | 本地 Web API | MCP Provider | 分发与上架边界 | Codex / Claude Code 集成指南

快速开始

如果你想用最简洁、务实的方式，从手动导出开始搭建可重复的本地快照循环，请从这里开始。首次成功运行的承诺是分 3 步，耗时约 3 分钟，而不是零点击安装。

1. 查看 config/notes_snapshot.env，保留或修改默认导出路径。
2. 运行一次快照，让 macOS 显示 Apple Notes / AppleScript 权限提示。
3. 安装调度器，然后检查运行状况。

# review config/notes_snapshot.env first
./notesctl run --no-status
./notesctl install --minutes 30 --load
./notesctl verify
./notesctl doctor

快速排查：

• 如果 ./notesctl verify 显示 FAIL: no last_success record; run ./notesctl run，说明你还没有完成首次手动导出。
• 如果 macOS 权限阻止首次运行，请使用 ./notesctl permissions，并参阅公开的故障排除指南。
• 完整且权威的指南请参阅docs/quickstart。
• 公开的验证页面集中展示了仓库端检查、在线界面检查和信任边界。
• 面向维护者的验证内容见后文的验证与检查；首次成功生成快照无需执行这些操作。

选择合适的使用路径

请将操作员路径与维护者路径分开。

• 操作员路径
  • ./notesctl run --no-status
  • ./notesctl install --minutes 30 --load
  • ./notesctl verify
  • ./notesctl doctor
  • ./notesctl status --full
  • 本地状态已生成后可选：./notesctl ai-diagnose、./notesctl web 和 ./notesctl mcp
• 维护者路径
  • ./notesctl clean-cache --dry-run
  • ./notesctl clean-cache
  • ./notesctl rebuild-dev-env
  • ./notesctl update-vendor
  • ./notesctl setup / ./notesctl self-heal

如果你的目标是建立可靠的备份循环，请先使用操作员路径。维护者路径用于仓库维护和贡献者验证，前提是本地工作流已清晰可行。

为什么要构建此项目

上游 notes-exporter 项目非常适合需要立即导出 Apple Notes 的场景。本仓库则适用于“运行一次”变成“每天都让它稳定运行”的时候。

Apple Notes Snapshot 在上游导出工具的基础上增加了：

• 唯一受支持的人工入口：notesctl
• 通过 launchd 定时执行
• 锁保护，避免运行重叠
• 用于健康检查的结构化状态文件和指标文件
• 日志轮转和日志健康摘要
• 可选的本地 Web 控制台，用于查看状态并执行安全操作

相比上游 notes-exporter，你可以获得什么

可以将上游项目视为引擎，而将本仓库视为围绕引擎搭建的控制室。这个封装工具会告知快照的存放位置，并让你更轻松地检查调度状态和运行状况，以便在发生故障时进行排查。

需求	上游 notes-exporter	Apple Notes Snapshot
导出一次笔记	支持	支持
定期安排导出	手动设置	内置 launchd 流程
检查数据新鲜度和上次成功记录	功能有限	status、verify 和 Web 健康界面
查看结构化运行元数据	功能有限	状态文件、指标和摘要
轮转日志并检查故障	手动操作	由封装工具管理日志
使用本地 Web 控制台	不支持	可选的、本地且支持令牌的控制平面

如果你只需要一次性导出，请直接使用上游项目。如果你想建立可重复的本地备份循环，同时能查看调度器状态、明确快照路径，并在发生故障时更轻松地恢复，请使用本仓库。

Web 控制台的展示内容

本地 Web 控制台是可选的，最好在你已经完成第一轮 run -> install -> verify 后再使用。它用于观察你刚验证过的流程，而不是替代首次验证。

它会展示：

• 快照健康状态、上次成功时间、launchd 状态和失败原因
• 操作员关注事项面板，说明下一步该做什么，以及应先打开哪个面板
• doctor 警告和依赖项就绪情况
• 近期指标和触发来源
• 日志健康摘要
• 访问策略和快捷操作

可选的 AI 和面向 Agent 的界面

这些界面为同一间本地控制室增添了功能，不会替代 notesctl 或确定性运行时检查。

• AI Diagnose 如果你想获取对当前本地状态的建议性说明，请使用 ./notesctl ai-diagnose。它会读取 status、doctor、log-health 和近期运行摘要；启用 AI 时，会通过本地 Switchyard 运行时路由模型调用；未配置 AI 提供商时，也可作为确定性回退方案正常运行。请阅读公开的 AI Diagnose 指南。
• MCP Provider 如果你想为 Agent 提供一个以 stdio 为先、只读为先的 MCP 界面，请使用 ./notesctl mcp。它会提供本地备份诊断和资源，不会把 Web 控制台伪装成 MCP API。请阅读公开的 MCP 指南。
• Local Web API 如果你想使用带令牌门控的本地浏览器控制室，以及由同一组仓库自有命令提供支持的小型 JSON API，请使用 ./notesctl web。这是面向本地操作员的 API，不是公共 OpenAPI 或托管集成界面。请阅读公开的 Local Web API 指南。

AI 和 Agent 的适用场景

如果你关注 Codex、Claude Code、MCP 或其他本地主机集成生态，可以参考这个思路。

适用场景：

• 当宿主能够启动 stdio MCP 服务时，适用于 Codex 和 Claude Code 风格的本地工作流

• 需要与人工操作人员使用相同本地备份信息的 MCP 感知型编码 Agent

• AI Diagnose = 操作人员的下一步助手

  • 它会解读本地状态、诊断、日志健康状况和近期运行证据。
  • 它不是通用聊天浮层，也不会成为系统事实来源。

• MCP Provider = 只读 Agent 基础层

  • 它向 MCP 感知型宿主提供相同的本地备份状态。
  • 它不会将项目变成托管式 Agent 平台或具备写入能力的远程控制平面。

• Local Web API = 令牌门控的浏览器/API 接口

  • 它提供本地 Web 控制台以及 status、doctor、recent-runs 和 access 等 JSON 端点。
  • 它面向你自己设备上的浏览器或本地 HTTP 工作流，并不承诺提供公共 OpenAPI。

• notesctl + state.json + 汇总信息 + 令牌门控的 Web API = 当前基础层

  • 此仓库目前不提供公共 OpenAPI、生成的客户端或 SDK。
  • 真正可用的集成入口是 CLI 契约、Web/API 接口和只读 MCP 接口。

集成相关文档现在各有专属页面，因此本 README 无需涵盖每种宿主的详细设置步骤：

• 查看公开的 For Agents 指南， 了解准确的构建者概览和证据图例。
• 如果需要适配宿主的安装指南，请查看 Codex 入门包、 Claude Code 入门包或 OpenClaw 入门包。
• 查看 构建者集成包， 获取功能矩阵和可复制示例；或查看 公开技能包， 了解经过筛选、适合公开使用的指令子集。
• 如果你的工作流面向浏览器或本地 HTTP，而不是 stdio MCP，请查看 Local Web API 指南。

典型工作流

1. 检查导出路径，然后验证首次运行

./notesctl run --no-status
./notesctl install --minutes 30 --load

这是主要的入门路径。文档站点中的其他内容都是围绕此流程提供的辅助内容。

2. 检查备份是否仍然健康

./notesctl status --full
./notesctl verify
./notesctl doctor

3. 需要控制中心时，打开本地控制台

export NOTES_SNAPSHOT_WEB_TOKEN="<long-random-token>"
./notesctl web

4. 维护封装程序时，刷新 vendored 上游代码

./notesctl update-vendor --ref <tag|branch|sha>

适用人群

• 已经使用 Apple Notes，并希望获得本地、可重复快照的用户
• 更偏好使用 launchd 而非云端计划任务的 macOS 用户
• 希望围绕 Apple Notes 导出获取备份健康状况、日志和运维可见性的用户
• 希望使用易于审查的封装程序，而非临时 shell 片段的维护者

不适用人群

• 寻找共享云端笔记产品的团队
• 期望双向同步回 Apple Notes 的用户
• 跨平台笔记自动化工作流的用户
• 寻找托管式 SaaS 或桌面应用的用户

证明与验证

此仓库附带由仓库维护的验证命令，而不是要求你只凭截图来信任结果。这些是维护者 / 贡献者的门槛，并非首次成功生成快照的必需条件。

如果你想先查看面向公众的简短证据页面，请打开 证明页面。 它将仓库侧门槛、由 GitHub 控制的交付事实以及 当前访问边界集中在一处。下方的验证阶梯仍是面向维护者的验证契约。

默认的本地维护者流程：

./notesctl rebuild-dev-env
./.runtime-cache/dev/venv/bin/python -m pre_commit run --all-files
PYTHON_BIN=./.runtime-cache/dev/venv/bin/python scripts/checks/ci_gate.sh

维护者验证需要本地 Python 3.11+ 工具链。./notesctl rebuild-dev-env 会从头重建 .runtime-cache/dev/venv，使文档中记录的验证 命令始终与当前检出路径和解释器保持一致。 此仓库的 GitHub Actions 在 GitHub 托管的运行器上运行；下方的本地验证阶梯 属于维护者验证，并非要求使用自托管运行器。

五层 CI 契约：

层	规范位置	内容
pre-commit	本地钩子	gitleaks、文档链接根目录规范检查、旧路径扫描和公共表面敏感项扫描
pre-push	本地钩子	scripts/checks/ci_gate.sh，用于仓库本地的确定性检查：文档 / 根目录规范、供应商目录树规范、单元测试和包装器冒烟测试
hosted	GitHub Actions	Canonical Quick Gate、Secret Scan、GitHub Alert Gate、Dependency Review、Actionlint、Zizmor、Trivy、CodeQL 和 Pages
nightly	GitHub Actions 计划任务	Nightly Deterministic Audit 会在 GitHub 托管的运行器上重新执行仓库维护的验证阶梯，同时不增加 pre-push 的负担
manual	实机 / 所有者会话	`notesctl run

仅限 GitHub 的治理门槛：

• Dependency Review 会在拉取请求中运行，因为它需要 GitHub 的 base/head 依赖差异。
• CodeQL、Secret Scan、GitHub Alert Gate、Actionlint、Zizmor 和 Trivy 均优先在托管环境中运行；本地重新运行是可选的维护者复现步骤， 不属于默认钩子流程。
• 最新的发布标签应指向当前规范的收尾提交；不要将较旧的标签视为当前仓库侧收尾完成的证明。

运行时与缓存契约

可以将运行时布局视作两个各司其职的房间：

• 仓库本地的可重建内容位于 .runtime-cache/ 下
• 仓库维护的机器级残留内容位于由 notesctl 管理的当前机器缓存根目录下

当前仓库本地契约：

• .runtime-cache/dev/venv -> 仓库维护者虚拟环境
• .runtime-cache/cache/apple-notes-snapshot -> 仓库本地运行时缓存 / 状态支持
• .runtime-cache/temp -> 临时文件
• .runtime-cache/logs -> 仓库本地日志
• .runtime-cache/pytest -> pytest 缓存
• .runtime-cache/coverage -> 覆盖率数据
• .runtime-cache/pycache -> Python 字节码缓存
• .runtime-cache/browser-proof -> 根据当前文档表面可重建的生成式证明截图
• .runtime-cache/phase1 -> 历史硬切换回滚构件，并非当前运行时事实
• .runtime-cache/phase1-history-rebuild -> 历史重建回滚构件，并非当前运行时事实
• .runtime-cache/mcp-registry-lane/out -> 可按需重建、可用于发布的 MCP 注册表构件

当前外部仓库维护契约：

• 当前和过时标签的 launchd 记录
• 已启动的仓库自有服务的运行时残留
• launchd 包装器使用的仓库范围运行时副本
• 此仓库专用的持久隔离浏览器根目录
• 可丢弃的浏览器临时残留
• vendor-runtime 当前指针 / 缓存

较旧的机器级 Application Support 和缓存根目录仅用作迁移输入。 新的仓库自有运行时 / 缓存写入应保留在当前由仓库管理的机器缓存根目录内。

本地清理与运行时审计

这是仅供维护者使用的清理流程。它适用于重建验证工具或回收仓库管理的运行时残留，不适用于完成首次成功快照。

• ./notesctl clean-cache --dry-run
  • 预览 .runtime-cache/ 下仓库本地可重建／可丢弃内容的清理操作
• ./notesctl clean-cache
  • 删除仓库本地可重建内容、生成的证明捕获文件、历史回滚包以及生成的可丢弃残留
• ./notesctl runtime-audit
  • 报告仓库本地支持目录，以及仓库管理的外部缓存／运行时根目录
• ./notesctl clean-runtime --dry-run
  • 预览对仓库管理的机器缓存根目录中非当前残留的清理操作
• ./notesctl clean-runtime
  • 删除仓库管理的外部过期残留，同时保护当前 launchd 标签
• ./notesctl browser-bootstrap
  • 将当前 apple-notes-snapshot 源配置文件从默认 Chrome 根目录复制到仓库管理的隔离根目录
• ./notesctl browser-open
  • 启动或连接到此仓库专用的单个仓库管理 Chrome 实例
• ./notesctl rebuild-dev-env
  • 在清理后恢复规范的路径感知维护者环境

如果旧版 .pytest_cache、.coverage 或分散的 __pycache__ 目录已经存在，仓库仍可能清理它们，但这些只是迁移 兜底措施。当前约定会将仓库管理的可丢弃工件存放到 .runtime-cache/*，包括不再需要时可安全重新生成的历史回滚文件夹和证明捕获文件。

自动清理钩子会在创建或复用机器级残留的仓库管理入口上运行，包括 run、web、install、ensure、 rebuild-dev-env 和 runtime-audit。默认策略有意设得较为严格：

• 外部仓库管理内容的限额：2 GB
• 通用外部 TTL：72 hours
• 浏览器克隆 TTL：24 hours
• 仅凭 TTL 永远不会删除当前／受保护的 launchd 标签
• browser/chrome-user-data/ 是永久状态，不受 TTL／容量上限清理影响

此仓库目前没有仓库管理的 Docker 清理流程。 自动清理程序不会触及 Docker、系统临时目录根路径，也不会触及来自 Cursor、Codex、Claude、Serena、Homebrew、pip、nodeenv、uv 或其他机器级工具的共享工具缓存。

浏览器自动化约定

本仓库的浏览器自动化现在采用隔离的 Chrome 根目录 + 单个仓库自有实例 + CDP 附加约定。

• NOTES_SNAPSHOT_BROWSER_PROVIDER=chrome
• NOTES_SNAPSHOT_BROWSER_ROOT=<repo-owned-browser-root>
• NOTES_SNAPSHOT_CHROME_USER_DATA_DIR=<repo-owned-browser-root>/chrome-user-data
• NOTES_SNAPSHOT_CHROME_PROFILE_NAME=apple-notes-snapshot
• NOTES_SNAPSHOT_CHROME_PROFILE_DIR=Profile 1
• NOTES_SNAPSHOT_CHROME_CDP_HOST=127.0.0.1
• NOTES_SNAPSHOT_CHROME_CDP_PORT=9337

旧的默认 Chrome 用户数据根目录现在仅作为 ./notesctl browser-bootstrap 的一次性读取来源。它不再是本仓库长期使用的运行时根目录。

请将 browser-bootstrap 视为一次性迁移，而不是常规同步步骤。之后如果你在隔离根目录中添加或刷新登录信息，除非你有意再次用默认 Chrome 根目录替换隔离根目录，否则不要重新运行 browser-bootstrap。

请按以下顺序使用这些命令：

• ./notesctl browser-bootstrap
  • 将默认 Chrome 根目录一次性复制到仓库自有的隔离根目录
• ./notesctl browser-open
  • 如果仓库自有的 Chrome 实例尚未运行，则启动它
  • 否则返回附加信息，而不是再次启动实例
• ./notesctl browser-contract --json
  • 输出规范的优先附加约定，包括供 Playwright/CDP 客户端使用的 CDP 端点

如果 127.0.0.1:9337 已被你机器上的其他程序占用，仓库应快速失败，而不是悄悄附加到错误的程序。在这种情况下，请在启动或附加到仓库自有实例前，使用 NOTES_SNAPSHOT_CHROME_CDP_PORT=9347 之类的明确环境变量覆盖值。

本仓库不会悄悄回退到捆绑的 Chromium，也不会在同一用户数据目录上不断启动新的浏览器实例。人工手动操作和自动化都应附加到同一个仓库自有的 Chrome 实例。

CI 约定

本仓库保留五层验证机制，彼此不可互换：

层级	默认触发条件	规范位置	约定
pre-commit	每次本地提交尝试	本地钩子	仅进行快速规范检查
pre-push	每次本地推送尝试	本地钩子	仅运行确定性的仓库本地快速门禁
hosted	拉取请求 / 推送 / 工作流调度	GitHub 托管的运行器	感知 GitHub 状态的安全与策略门禁
nightly	GitHub 定时运行	Nightly Deterministic Audit 在 GitHub 托管的运行器上重新运行仓库自有的验证梯
manual	人工有意触发的操作	真实机器 / 维护者会话	对实时浏览器、桌面端、提供方和外部控制平面进行验证

这个开源仓库不依赖本地自托管运行器通道。本地验证用于帮助维护者在拉取请求前后复现仓库自有的门禁，而不是因为 CI 预期会在开发者的 Mac 上运行。

高价值本地检查：

./notesctl status --full
./notesctl verify
./notesctl doctor

仓库自有的快速门禁现在涵盖文档 / 根目录规范检查、供应商目录规范检查、单元测试，以及封装器级别的 JSON / 帮助信息冒烟检查。GitHub 告警状态已全部移至托管通道，因此默认的本地 pre-push 路径更轻量，也更具确定性。scripts/ops 下仓库自有的 Python 部分仍须达到 90% 以上的覆盖率门槛；Shell 封装器部分则通过冒烟检查进行把关，不会假装它也适用同一覆盖率指标。

验证阶梯与测试金字塔

可以把验证约定看作一个小型测试金字塔，而不是一大块“直接运行所有测试”。

• 单元测试
  • 最快检查仓库自有的 Python 逻辑和确定性报告整形
  • 示例：tests/unit/test_ai_diagnose_unit.py、 tests/unit/test_mcp_server_unit.py、 tests/unit/test_web_server_unit.py
• 包装脚本冒烟测试
  • 仓库自有的 Shell 契约检查，涵盖 notesctl 帮助信息、JSON 接口和 包装脚本入口
  • 示例：bash scripts/checks/run_wrapper_smoke.sh
• 端到端测试
  • 较慢的集成检查，涵盖 launchd、迁移、Web 服务行为和 实际命令编排
  • 示例：./.runtime-cache/dev/venv/bin/pytest tests/e2e --no-cov
• 本地手动验证
  • 在真实 Mac 上执行实际操作流程： run -> verify -> status -> doctor -> web

金字塔的含义如下：

1. 单元测试最快捕获逻辑回归
2. 包装脚本冒烟测试保障 Shell 契约
3. 端到端测试验证仓库自有组件仍能协同工作
4. 本地手动验证确认实际机器运行正常

安全与隐私

本项目专为由你在自己的机器上控制而设计：

• 你的 Apple Notes 内容保留在你自己的 Apple Notes 帐户和导出 目标位置中
• 可选的 Web 控制台默认仅在本地运行，启用后会识别令牌
• 仓库在 SECURITY.md 中说明了私密漏洞报告方式
• 密钥、运行时缓存、生成的 launchd 文件和日志不属于 纳入版本跟踪的源文件范围

报告敏感问题前，请阅读 SECURITY.md。

常见问题

这是上游导出器的替代品吗？

不是。它是一个包装工具，让上游导出器更安全，也更便于作为持续的本地工作流来操作。

它会将更改同步回 Apple Notes 吗？

不会。本仓库用于快照和导出，而非双向同步。

我需要使用 Web 控制台吗？

不需要。notesctl 是受支持的人工操作入口。Web 控制台是可选的。

如何打开交互式菜单？

不带参数运行 ./notesctl。交互式菜单现在位于规范的 命令接口中。

使用这个工具需要 GitHub Pages 吗？

不需要。Pages 仅用于公开文档和提高搜索可见度。实际 工作流仍在你的 Mac 本地运行。

如果我把检出目录移到另一个路径，该怎么办？

重新安装调度程序，让基于路径的 launchd 接口指向当前检出目录。如果你还使用仓库自有的验证环境或 可选的 Web 控制台，也需要重新构建该环境：

./notesctl install --minutes 30 --load
./notesctl rebuild-dev-env

社区

请根据你的目的使用对应的 GitHub Discussions 版块：

• 问题与设置障碍： 问答讨论
• 功能构想与路线图建议： 构想讨论
• 真实使用示例： 展示与交流讨论
• 版本公告： 公告讨论

如果你想先了解支持请求的分流概要，请阅读 SUPPORT.md 或 公开的支持页面。

贡献

更改包装逻辑、文档或面向公众的文案前，请阅读 CONTRIBUTING.md。本项目倾向于小规模、易于审查的更改，并附上明确的 验证说明。

许可证

本仓库基于 MIT 许可证发布。