Obsidian的配置与美化 V2（七）——任务、发布与临时分享

任务和发布都涉及“状态变化”。如果界面只画一个好看的圆圈，却没有改到源文件；或者正文刚保存，公开版本号就自动增加，那么整个系统看起来自动化，实际上很难信任。

V2 对这两类状态采用同一个原则：真实状态必须写回明确的源，关键变化必须由用户主动触发。

任务仍然是普通 Markdown

任务的源格式没有被自定义数据库取代：

- [ ] 完成 Homepage 系列初稿 📅 2026-07-18

Tasks 负责理解日期、重复规则和完成状态；Dataview 只负责把符合条件的任务聚合到 Dashboard。点击“今日焦点”里的复选框，修改的是原笔记中的那一行，而不是 Dashboard 自己保存的一份副本。

完成后重新加载 Vault，任务仍然保持完成状态，并从未完成查询中消失。这个简单的验证，比卡片样式是否漂亮更重要。

Homepage 只负责短期判断，Base 负责完整浏览，任务正文保留上下文。没有日期的想法不应该被强行塞进今天的列表。

Blog、Wiki、Project 和 Daily 的发布控件提供四个动作：

每个动作都由 Bedic Publisher 执行。按钮只是入口，不直接拼接 YAML。

动作	前置条件	原子结果
发布	合法的 Blog/Wiki/Project/Daily，当前未发布	`publish=true`，修订号加 1，写入发布时间和更新日期
更新已发布修订	当前已发布	修订号再加 1，刷新发布时间和更新日期
取消发布	当前已发布并确认	`publish=false`，保留源文件和修订号
创建临时分享	合法源文件并确认	在 `60 Temp` 创建独立副本，源文件状态不变
撤销临时分享	Temp 当前公开并确认	只把副本设为私有，文件仍保留

发布前会检查路径、类型和必填属性。任何一步失败都不会留下“修订号已经加了，但 publish 没有成功”这样的半套状态。

假设一篇文章初次发布：

publish: true
publish_revision: 1
published_at: 2026-07-15T14:30:00+08:00

之后在编辑器里修正错别字，修订号仍然是 1。只有准备让网站消费新版本时，才点击“更新已发布修订”，此时变成 2。

这样服务端可以明确判断是否出现了新的公开版本，写作者也不会因为每次自动保存都产生一条发布记录。

取消发布只会把 publish 改回 false。源文件、历史修订号和正文都保留在 Vault 中。它是可恢复的隐私动作，不是破坏性文件操作。

如果以后再次发布，可以从现有修订号继续增加，而不是假装这篇内容从未存在过。

临时分享不会把原文直接公开。系统在 60 Temp 创建一份新笔记，并写入：

type: temp
source_id: <原笔记 ID>
publish: true
publish_revision: 1
published_at: <当前时间>
expires_at:
slug: <高强度随机值>

原笔记继续保持原来的 publish 状态。撤销分享时，只关闭这份副本；是否归档或删除是另一个可恢复决定。

随机地址只代表“不容易猜到”，不代表身份认证。密码、密钥、私人合同等真正敏感的内容不应该依赖这种机制，应该等待后续访问控制方案。

美化可以让发布控件更容易发现，但不能替代这些规则。真正的安全感来自状态清楚、动作可预测、失败可恢复。