@senguoyun/dsh-arkme 0.1.58 → 0.1.60

package/docs/dsh-input-system-topic.md

@@ -4,9 +4,13 @@
 
 topic.kind=3 表示 DSH 输入系统主题；kind=2 是原内部 Agent 容器，继续隐藏。record.creation_source=3 是记录的生产来源，不决定主题能力；主题类型不依据标题或 UID 推断，同名普通主题不受限制。
 
-DSH 主题沿既有主题目录、详情和记录读取链路展示，带系统标识，不提供直接输入、改名、隐私、层级、磁铁、置顶或位置等被禁止的主题操作。插件普通主题尚无首页设置 UI，因此系统主题底部也只显示归档说明，不提供专用开关或读取设置。服务端领域 owner 同时校验，不能通过绕过 UI 修改受保护属性。记录本身的正常编辑、删除和移出不等同于修改主题，不扩大禁止范围。
+DSH 输入不属于个人快记：插件的「发给自己」目录、最新预览、时间线、主题日历和 Markdown 导出排除系统主题及 DSH 来源记录。识别只使用权威类型和来源字段，不按名称过滤；同名普通主题不受影响。过滤后的时间线继续翻页补齐，避免空页提前终止导出。
 
-新主题默认 show_in_home=false；重复归档复用稳定容器身份，保留用户开关。存量值不迁移，历史记录不清理，用户可以自行关闭首页展示。首页复用 home/feed；默认分类仍是 uncategorized，两者不是同一个列表。
+第一栏的全局日历继续显示这些归档记录，复用既有 DSH 来源标识和快记详情，不再提供跳回个人系统主题的来源按钮。发给自己的「全部」日历与全局日历是不同范围；前者只包含个人快记，后者还包含聊天和 DSH 输入。
+
+底层系统主题及既有 SDK/Tools 能力保留。服务端领域 owner 继续限制系统主题的直接输入、改名、隐私、层级等操作；记录本身的正常编辑、删除和移出不等同于修改主题，不扩大禁止范围。
+
+新主题默认 show_in_home=false；重复归档复用稳定容器身份，保留用户开关。存量值不迁移，历史记录不清理。即使已有 show_in_home=true，插件的「发给自己」也会在读取时排除 DSH 输入，不重写这项跨端偏好。默认分类仍是 uncategorized，两者不是同一个列表。
 
 ## 归档边界
 
@@ -18,7 +22,7 @@ DSH 主题沿既有主题目录、详情和记录读取链路展示，带系统
 
 | 消费面 | 入口 | 权限与失败边界 |
 | --- | --- | --- |
-| UI | N/A：普通主题没有对应设置入口，系统主题同样不提供 | 纯只读说明，无设置请求；已有策略不重置，仍可在移动端设置 |
+| UI | N/A：插件不在个人主题中展示 DSH 系统主题 | 无设置请求；已有策略不重置，仍可在移动端设置 |
 | SDK | topicHomeVisibility(sourceRef, showInHome?, signal?) | features.topicHomeVisibility 探测；账号作用域的不透明引用 |
 | Tools | arkme_topic_home_visibility | 读取不确认；设置沿现有 explicit-user-write 确认机制 |
 | Host | topic.home-visibility → SourceService | 仅提交 show_in_home，不附带名称、隐私等字段；Record owner 最终校验 |

package/docs/plugin-release.md

@@ -12,7 +12,7 @@ npm 接受发布请求后仍可能异步处理版本。工作流以 15 分钟为
 
 每次普通 PR 发版时，会查询当前 master 版本对应的 `release/v<版本号>` PR 是否已合并。已经合并表示该版本已分配，即使 npm latest 仍落后，新一轮发版也会递增 patch，避免复用可能已经上线的 Runtime 版本。未分配的显式版本递增仍保持原版本；重跑同一次发版时，先复用已有 `release_sha`，并从该提交读取原版本，不重复分配。
 
-npm 失败时，Runtime 可以先完成上线，对应的 Git Tag 和 GitHub Release 可能暂未创建。可重跑 npm 所在工作流的失败 job，继续发布同一提交的 npm 包。两条链路的结果分别查看 npm Action 与生产 Runtime Action；派发成功仅表示事件已发出。
+npm 失败时，Runtime 可以先完成上线，对应的 Git Tag 和 GitHub Release 可能暂未创建。可重跑 npm 所在工作流的失败 job，继续发布同一提交的 npm 包。若版本已经可读且 integrity 一致，则跳过重复发布；若发布返回版本已暂存（staged 409）或已发布的冲突，则继续进入上述回读校验。发布命令最多等待 180 秒，命令超时或网络超时/连接重置同样转入回读，避免服务端已经接受请求、客户端却认为失败。权限、认证及其他错误仍立即失败；冲突或超时本身不算发布成功，必须通过 integrity 与 provenance 校验才能继续后续流程。若 npm 一直没有对外提供该版本，回读仍会超时报错。两条链路的结果分别查看 npm Action 与生产 Runtime Action；派发成功仅表示事件已发出。
 
 `pre-release` 分支的每次 push 会走同一套 Runtime 发布链路，但不会发布 npm。测试版本由稳定基准版本的下一补丁与 GitHub run number 组成，例如 `0.1.34` 在 run `128` 中生成 `0.1.35-pre.128`；版本修改只存在于 Action 临时工作区。