Secret Management 是一个用于正确管理密钥的 Agent 技能。它的目标是回答三个问题：这个密钥归哪条「通道」所有？哪些文件、名称和校验步骤需要变更？以及该如何记录这个密钥，以便未来的 Agent 用同样的方式处理？具体矩阵、示例、命名规则和文件目标见 references/decision-guide.md。
工作流程
-
识别密钥的主要使用方。可能是运行在 Mac Mini 或其他部署运行时上的应用、某个仓库中的本地开发、一台机器上跨仓库共享的运维工具，或仅用于 GitHub Actions。
-
选择唯一的主要通道。避免为同一个密钥家族维护多个手工维护的存放位置。如果该值必须出现在另一条通道，应从同一个本地规范值生成，而不是新建第二个所有者。
-
应用对应通道的变更，使用 references/decision-guide.md 中的检查清单。
-
当出现新模式时更新持久化文档。优先更新仓库的 docs/reference，而不是仅在对话中做临时说明。
各通道
运行时（Runtime）：用于已部署应用的密钥。值存放在本地规范库 ~/Documents/DobbySecrets/scopes/<scope>/<secret-name>。通过所属运行时的实际物化契约接入；当前 Mac Mini 服务使用仓库映射加生成的 .env 文件以及仓库自有的部署/重启命令。仅对实际支持并消费提供方原生引用或部署时同步的运行时使用这些方式；不要重建已退役的云端主机设置。如果本地仓库开发也需要该值，应在生成的 .env 中使用同一个规范密钥家族，而不是新建所有者。
仓库本地（Repo-Local）：用于某个仓库本地开发工作流所需的密钥。值在本地库中保持规范，通过仓库的本地 bootstrap（secret_env_map.env 或等价物）映射进去，并把 .env.example 仅作为占位符文档保留。
机器本地共享（Machine-Local Shared）：用于一台机器上跨仓库共享、供运维工具使用的凭证。值在本地库中保持规范，同步到 ~/.secrets/<integration>/...，只在 shell bootstrap 中作为生成的机器本地文件被 source。不要把密钥值存放在 ~/GitHub/agents、~/.agents 或被跟踪的 shell 配置中。
外部运行时与 GitHub CI：仅当代码必须在 Mac Mini 之外运行时，才把提供方自有的密钥存储作为生成的投递目标，本地库仍是规范来源。GitHub Actions 密钥应仅限于有意的云 runner 投递或仅用于 CI 的凭证。当工作负载已运行在 Mac Mini 上时，优先使用本地部署自动化。对于 Modal 或其他外部运行时，通过显式清单和本地运维/部署步骤从本地库同步选定值。不要把云 vault 登录作为新本地工作流的 bootstrap 依赖。
命名规则
仓库自有密钥家族：repo--secret-name；共享集成家族：integration--secret-name；机器本地集成：与 ~/.secrets/<integration>/ 下的文件夹名一致；GitHub 密钥名应明确说明用途，而不带仓库历史。
防护准则
不要因为方便就把新密钥加入 GitHub Actions。不要把字面密钥值放进 .zshrc、被跟踪的 YAML 或已提交的配置文件中。当仓库本地 bootstrap 才真正合适时，不要创建机器本地集成。把基于文件的凭证视为单独情况，它们可能需要物化，而不是 KEY=value 同步。使用 ~/GitHub/scripts/bin/local-secrets 进行读取/写入/导入/状态工作流；绝不要在日志或 Agent 回复中打印密钥值。把当前的明文本地库视为有意保持简单的第一阶段后端：其文件保持不被跟踪，目录权限 0700、文件权限 0600，并且不要把 ~/Documents/DobbySecrets 从 Backblaze 中排除。