138 lines
5.0 KiB
Markdown
138 lines
5.0 KiB
Markdown
|
---
|
|||
|
|
title: Vault 修复计划
|
|||
|
|
date: 2026-02-25
|
|||
|
|
tags:
|
|||
|
|
- meta
|
|||
|
|
- improvement-plan
|
|||
|
|
- vault-health
|
|||
|
|
type: improvement-plan
|
|||
|
|
status: active
|
|||
|
|
source_report: 06_Metadata/REVIEW_REPORT_2026-02-25.md
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# Vault 修复计划（基于 2026-02-25 审查报告）
|
|||
|
|
|
|||
|
|
## 范围与目标
|
|||
|
|
|
|||
|
|
本计划针对 `06_Metadata/REVIEW_REPORT_2026-02-25.md` 中的 P0/P1/P2 问题，目标是：
|
|||
|
|
|
|||
|
|
1. 先消除高风险（凭据泄露、Dataview 全失效）。
|
|||
|
|
2. 再恢复日常可用性（Inbox、Hub、目录一致性）。
|
|||
|
|
3. 最后建立可持续维护机制（链接密度、插件治理、周流程）。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 修复计划
|
|||
|
|
|
|||
|
|
### Phase 0（D0：2026-02-25，当天完成）
|
|||
|
|
|
|||
|
|
1. 建立修复分支与快照备份
|
|||
|
|
- 分支：`fix/vault-review-2026-02-25`
|
|||
|
|
- 对当前工作区打标签或保存快照，确保可回滚。
|
|||
|
|
2. 处理明文凭据（P0）
|
|||
|
|
- 扫描范围：`01_Projects/`、`03_Resources/`
|
|||
|
|
- 推荐命令：
|
|||
|
|
- `rg -n -i "(password|secret|token|api[_-]?key|access[_-]?token|shared[_-]?secret)" 01_Projects 03_Resources`
|
|||
|
|
- 修复动作：
|
|||
|
|
- 将真实凭据替换为占位符（如 `{{SECRET_FROM_1PASSWORD}}`）。
|
|||
|
|
- 对已暴露凭据执行轮换（Rotate），并记录轮换日期与系统。
|
|||
|
|
- 处理 Git 历史：使用 `git-filter-repo` 或 BFG 清理历史泄露。
|
|||
|
|
3. 修复 Dataview 路径（P0）
|
|||
|
|
- 将 `02_Areas` 下 7 个 Hub 文件内 `from "200-area/..."`
|
|||
|
|
批量修正为 `from "02_Areas/..."`。
|
|||
|
|
- 验证查询返回不为空，且可覆盖子目录。
|
|||
|
|
|
|||
|
|
### Phase 1（D1：2026-02-26 前）
|
|||
|
|
|
|||
|
|
1. 根目录收敛（P2）
|
|||
|
|
- 将元文档统一迁入 `06_Metadata/`（保留 README/必要入口除外）。
|
|||
|
|
- 将 `2026-01-05.md` 归入合适目录（日期笔记目录或 `04_Archive/`）。
|
|||
|
|
2. 插件配置对齐（P2）
|
|||
|
|
- 修复或移除已启用但目录缺失插件：
|
|||
|
|
- `obsidian-opencode`
|
|||
|
|
- `opencode-obsidian`
|
|||
|
|
- 在 `templater-obsidian` 与 `quickadd` 中指定单一主流程，避免重复。
|
|||
|
|
3. Dataview 回归验证
|
|||
|
|
- 打开 7 个 Hub 文件确认查询结果与排序正常。
|
|||
|
|
|
|||
|
|
### Phase 2（W1：2026-03-03 前）
|
|||
|
|
|
|||
|
|
1. Inbox 清债（P1）
|
|||
|
|
- 对 `00_Inbox/Clippings/2023`、`2024` 应用 90 天规则：
|
|||
|
|
- 需要保留：移动至 `04_Archive/` 或对应主题目录。
|
|||
|
|
- 无价值：删除。
|
|||
|
|
2. 去重与目录整理（P2）
|
|||
|
|
- 合并 `03_Resources/PKM` 与 `03_Resources/Personal Knowledge Management`。
|
|||
|
|
- 合并 `Pickled-Cucumber*` 系列冗余笔记，保留单一权威版本。
|
|||
|
|
- 将 `02_Areas/Lifestyle/Cooking`、`Gaming` 迁入 `03_Resources/`。
|
|||
|
|
3. 补齐 Hub 缺口（P2）
|
|||
|
|
- 新增：
|
|||
|
|
- `02_Areas/GFW/GFW.md`
|
|||
|
|
- `02_Areas/Job/Job.md`
|
|||
|
|
- `02_Areas/Lifestyle/Lifestyle.md`
|
|||
|
|
- 使用统一 frontmatter 与 Dataview 查询模板。
|
|||
|
|
|
|||
|
|
### Phase 3（W2：2026-03-10 前）
|
|||
|
|
|
|||
|
|
1. frontmatter 规范化
|
|||
|
|
- 使用 `pnpm lint` 与格式化流程统一字段样式。
|
|||
|
|
- 可选安装并配置 Obsidian Linter。
|
|||
|
|
2. 提升双链密度（P1/P2）
|
|||
|
|
- 优先 Projects/Areas：每篇至少补 2 个 `[[wikilink]]`。
|
|||
|
|
3. 建立周维护机制
|
|||
|
|
- 固定每周 30 分钟 Inbox 清零与异常检查。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 计划审核（可执行性审查）
|
|||
|
|
|
|||
|
|
### 结论
|
|||
|
|
|
|||
|
|
当前计划可执行，优先级排序正确；但为降低实施风险，需要补充以下控制项。
|
|||
|
|
|
|||
|
|
### 发现的问题与修正建议
|
|||
|
|
|
|||
|
|
1. 缺少明确的“凭据轮换清单”落地位置
|
|||
|
|
- 风险：做了文档替换但未真正轮换线上密钥。
|
|||
|
|
- 修正：新增 `06_Metadata/SECURITY_ROTATION_LOG_2026-02.md`，记录系统、凭据类型、轮换日期、责任人。
|
|||
|
|
2. 缺少 Dataview 修复后的验收口径
|
|||
|
|
- 风险：路径修了但查询逻辑仍可能为空（例如过滤条件问题）。
|
|||
|
|
- 修正：每个 Hub 记录“修复前/后结果数量”，确保不是偶然命中。
|
|||
|
|
3. Inbox 清理无批处理标准
|
|||
|
|
- 风险：执行成本高、容易中断，导致再次积压。
|
|||
|
|
- 修正：按年份和主题分批，每批 30-50 篇，设置单批 20 分钟时间盒。
|
|||
|
|
4. 去重合并缺少“主文件判定规则”
|
|||
|
|
- 风险：合并后信息丢失，或出现新重复。
|
|||
|
|
- 修正：定义保留优先级：
|
|||
|
|
- 有完整 frontmatter 的版本优先；
|
|||
|
|
- 更新时间更近优先；
|
|||
|
|
- 被引用次数更多优先。
|
|||
|
|
5. 缺少回滚策略说明
|
|||
|
|
- 风险：批量移动/删除后难以恢复。
|
|||
|
|
- 修正：每个 Phase 完成后提交一次原子 commit，并保留变更清单。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 验收标准（Definition of Done）
|
|||
|
|
|
|||
|
|
1. 安全
|
|||
|
|
- 指定扫描范围内无明文凭据；已暴露凭据完成轮换并记录。
|
|||
|
|
2. Dataview
|
|||
|
|
- 7 个 Hub 查询恢复正常，结果不为空且可复现。
|
|||
|
|
3. Inbox
|
|||
|
|
- `00_Inbox/Clippings/2023`、`2024` 清空或降至可控阈值（<= 20）。
|
|||
|
|
4. 结构
|
|||
|
|
- 重复目录与重复笔记完成合并；旧路径有迁移说明或重定向。
|
|||
|
|
5. 维护
|
|||
|
|
- 每周 Inbox 处理流程写入 `06_Metadata/WORKFLOWS.md` 并开始执行。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 执行顺序（建议）
|
|||
|
|
|
|||
|
|
1. Phase 0（安全 + Dataview）
|
|||
|
|
2. Phase 1（根目录 + 插件）
|
|||
|
|
3. Phase 2（Inbox + 去重 + Hub）
|
|||
|
|
4. Phase 3（规范化 + 链接密度 + 周期化）
|
|||
|
|
|