@yoooclaw/phone-notifications 1.12.0 → 1.12.2

package/skills/notification-to-memory/references/step-1-scan-pending.md

@@ -1,137 +0,0 @@
-# Step 1：扫描未处理通知
-
-## 通知数据存储说明
-
-### 路径说明
-
-不要假设通知目录固定。先执行：
-
-Exec 调用规则：等待 `ntf` 命令输出时使用 `yieldMs: 60000`；不要用 `timeout` 作为等待时间。`timeout` 是按秒计算的杀进程上限，默认 1800 秒，除非明确需要终止长时间运行的命令，否则不要写。
-
-```text
-Use exec with:
-command: ntf storage-path
-yieldMs: 60000
-```
-
-返回示例：
-
-```json
-{
-  "ok": true,
-  "path": "/absolute/path/to/notifications"
-}
-```
-
-后续所有通知文件、`.ids/`、`.checkpoint.json` 的位置都以这个 `path` 为准。
-
-### 目录结构
-
-按日期文件存储，每个 JSON 文件包含当天所有通知：
-
-```
-<storage-path>/
-├── 2026-03-02.json        # 2026-03-02 当天的所有通知
-├── 2026-03-03.json        # 2026-03-03 当天的所有通知
-├── 2026-03-04.json        # 2026-03-04 当天的所有通知
-├── .ids/                  # 去重索引目录（插件内部使用）
-│   └── ...
-└── .checkpoint.json       # 消费进度（本 Skill 使用）
-```
-
-### 文件格式
-
-每个文件为 JSON 数组，按时间顺序追加（append-only，写入后不可修改）：
-
-```json
-[
-  {
-    "appName": "wechat",
-    "title": "张三",
-    "content": "周末去爬山吗？",
-    "timestamp": "2026-03-02T08:30:00+08:00"
-  },
-  {
-    "appName": "dingtalk",
-    "title": "工作群",
-    "content": "下午3点有评审会",
-    "timestamp": "2026-03-02T09:15:00+08:00"
-  }
-]
-```
-
-先执行 `ntf storage-path` 确认目录可用，再根据 Step 0 记录的范围选择唯一对应的 CLI 命令扫描未处理条目。
-
-范围为“今天”或用户没有说明范围时，必须先通过本机命令获取当前本地日期，再把日期显式传给 `scan`：
-
-```text
-Use exec with:
-command: date +%F
-yieldMs: 60000
-
-Then use exec with:
-command: ntf sync scan --date <date returned by date +%F>
-yieldMs: 60000
-```
-
-范围为用户明确指定的某一天时：
-
-```text
-Use exec with:
-command: ntf sync scan --date 2026-03-09
-yieldMs: 60000
-```
-
-范围为用户明确指定的日期范围，或“最近 N 天/近 N 天”时，先按 Step 0 计算起止日期，再执行：
-
-```text
-Use exec with:
-command: ntf sync scan --from-date 2026-03-02 --to-date 2026-03-09
-yieldMs: 60000
-```
-
-只有范围明确为“上次同步后/全部未处理/补全历史/所有日期”时，才允许执行：
-
-```text
-Use exec with:
-command: ntf sync scan --all
-yieldMs: 60000
-```
-
-禁止在“今天”、未说明范围、指定日期、指定日期范围或“最近 N 天/近 N 天”的场景使用 `--all`。裸命令 `ntf sync scan` 的 CLI 兜底行为也是只扫描本地当天，但执行本 Skill 时仍应显式传入 Step 0 计算出的范围。
-
-返回示例：
-
-```json
-{
-  "ok": true,
-  "scope": {
-    "mode": "date",
-    "fromDate": "2026-03-09",
-    "toDate": "2026-03-09"
-  },
-  "pending": [
-    { "date": "2026-03-09", "count": 12, "startIndex": 5 }
-  ],
-  "totalPending": 12,
-  "outsideScopePending": 3,
-  "allDatesTotalPending": 15
-}
-```
-
-## 核对本次请求范围
-
-`ntf sync scan` 的 `pending` 和 `totalPending` 已经按 CLI 参数限制在本次请求范围内。扫描完成后必须核对返回的 `scope` 与 Step 0 记录的范围一致，然后令：
-
-- `selectedPending = pending`
-- `selectedTotalPending = totalPending`
-
-`outsideScopePending` 表示仍有多少条其他日期的未处理通知，仅用于最终汇报。不得因为该值大于 0 而执行第二次 `scan --all`、扩大 `selectedPending`，或进入其他日期。
-
-如果返回的 `scope` 与 Step 0 范围不一致，使用正确的参数重新执行一次 `ntf sync scan`，不要进入 Step 2。例如用户要求“今天”时，即使其他日期仍有历史未处理通知，也只处理本地当天。
-
-按返回结果判断：
-- 若 `selectedTotalPending` 为 0：直接结束并汇报“本次请求范围内暂无待处理通知”，不要进入其他日期。若 `allDatesTotalPending` 也为 0，可补充说明“记忆已是最新状态”。
-- 若 `selectedTotalPending` 大于 0 且 `outsideScopePending` 大于 0：只处理 `selectedPending`，并在最终汇报中说明仍有其他日期未处理。
-- 若 `selectedTotalPending` 较大（如超过 300）：不要向用户发起二次确认；记录“大批量处理”状态，按 Step 2 的“单回合最多 3 个批次（每批 ≤100 条）”分回合处理。本回合处理到上限后提交 checkpoint 并汇报进度即停止，剩余部分留待定时任务或下次触发续传，不要在单个回合内硬跑完全部数据导致超时卡死。
-- 若有选中的未处理通知：按 `selectedPending` 日期列表进入 Step 2。

package/skills/notification-to-memory/references/step-2-process-dates.md

@@ -1,98 +0,0 @@
-# Step 2：逐日期逐批次处理
-
-## Checkpoint 格式
-
-消费进度由 `.checkpoint.json` 独立记录，与通知数据文件解耦：
-
-```json
-{
-  "2026-03-02": { "lastIndex": 15 },
-  "2026-03-01": { "lastIndex": 42 }
-}
-```
-
-- `lastIndex`：该日期文件中已处理到的条目索引（0-based）
-- 下次处理从 `lastIndex + 1` 开始
-
-根据 Step 1 筛选出的 `selectedPending` 日期列表，从最新到最旧依次处理每个日期；每个日期内再按批次顺序处理。对每个日期，先根据 Step 1 返回的 `startIndex` 和 `count` 计算本次同步快照边界：`targetEndIndex = startIndex + count - 1`。本次只处理到该 `targetEndIndex`，运行过程中新增的通知不要追入本次循环，留到下一次同步处理。
-
-Exec 调用规则：等待 `ntf` 命令输出时使用 `yieldMs: 60000`；不要用 `timeout` 作为等待时间。`timeout` 是按秒计算的杀进程上限，默认 1800 秒，除非明确需要终止长时间运行的命令，否则不要写。
-
-**单回合批次上限（强制，防止超时卡死）**：
-- 维护一个本回合批次计数器，从 0 开始；每完整执行一次 `2.1 -> 2.2 -> 2.3`（即处理并提交一个批次）计数 +1。
-- 单次 Agent 执行（前台或后台子任务）最多处理 **3 个批次**。一旦计数达到 3，立即停止本回合：当前批次的 checkpoint 已在 2.3 提交，直接进入最终汇报，说明“本回合已处理 N 条，还剩 M 条，将由定时任务或下次触发继续”。
-- 不要为了“一次跑完”而忽略该上限；checkpoint 已记录进度，续传不会重复处理，也不会丢数据。
-- 单批 ≤100 条 × 最多 3 批 = 单回合最多约 300 条，可确保任何一次回复都远在超时窗口内完成。
-
-默认行为：
-- 一旦开始 Step 2，就连续处理 Step 1 已选中的日期，直到“本次范围内全部完成”或“达到单回合批次上限（3 批）”为止，二者满足其一即收尾
-- 不得处理 `selectedPending` 之外的日期；用户要求“今天”时，只处理今天，即使 scan 中还有历史未处理日期
-- 处理完最近的已选中日期后，不要停下来询问用户是否继续
-- 不要逐个日期让用户做选择，除非用户在最初请求中明确要求只处理某一天或指定日期范围
-- 不允许批量处理多个日期或多个批次；只能按顺序逐个日期、逐个批次串行处理
-- 必须先完成当前批次的记忆写入与 checkpoint 更新，才能开始下一批；不要同时读取多个批次的数据，否则会造成严重的遗忘
-- 模型必须逐个批次阅读、理解并总结通知内容后再写入记忆；不要编写脚本替代逐批阅读与总结，脚本不能代替模型完成这一步
-- 不要因为单日数据量大或总数据量大，就省略 `2.1 -> 2.2 -> 2.3` 中的任何步骤
-
-## 2.1 获取未处理通知详情
-
-```text
-Use exec with:
-command: ntf sync fetch --date 2026-03-02 --max-end-index <targetEndIndex calculated from selectedPending>
-yieldMs: 60000
-```
-
-返回规则：
-- 单次最多返回 100 条未处理通知
-- 若当前日期未处理通知超过 100 条，返回结果中会通过 `hasMore = true` 明确标记还需再次执行 `fetch`
-- `--max-end-index` 必须使用当前日期在 Step 1 中计算出的 `targetEndIndex`，确保本轮只处理扫描时已存在的快照数据
-
-处理规则：
-- 若返回 `notifications` 为空：说明当前日期已无待处理通知，可进入下一个日期
-- 若返回 `hasMore = true`：说明当前日期还有后续批次；必须先按顺序执行完当前批次的 `2.2 选择记忆写入提示词 -> 2.3 更新 checkpoint 并重新读取主 SKILL`，然后再回到 `2.1`，对同一天再次执行 `fetch`
-- 若返回 `hasMore = false`：说明当前批次已是该日期最后一批；处理并提交后再进入下一个日期
-- 若当前日期不在 `selectedPending` 中：不得执行 `fetch`，直接跳过该日期
-
-## 2.2 选择记忆写入提示词并更新记忆系统
-
-在拿到当前日期的未处理通知详情后，立即执行脚本选择本批次唯一可用的记忆写入提示词：
-
-```text
-Use exec with:
-command: bash skills/notification-to-memory/scripts/select-memory-prompt.sh
-yieldMs: 60000
-```
-
-脚本会返回一个相对于当前 Skill 根目录的提示词文件路径。随后立即读取该文件，并严格按该文件中的说明处理当前日期的记忆相关文件的写入。
-
-每个批次执行该步骤，都要重新执行一次脚本并重新读取一次对应提示词文件。
-
-强制规则：
-- 不要自行判断或脑补其他记忆写入路径
-- 若脚本执行失败或返回的文件不存在，立即停止当前任务并汇报失败原因
-
-## 2.3 更新 checkpoint 并重新读取主 SKILL
-
-每个批次完成后，必须按以下顺序执行
-
-```text
-Use exec with:
-command: ntf sync commit --date 2026-03-02 --end-index <endIndex returned by the immediately preceding fetch>
-yieldMs: 60000
-
-Then read:
-skills/notification-to-memory/SKILL.md
-```
-
-不可跳过读取 skills/notification-to-memory/SKILL.md。若跳过会造成严重遗忘，并直接影响后续批次或后续日期的处理质量。
-
-提交规则：
-- `commit` 必须使用当前批次 `fetch` 返回的 `endIndex` 精确推进 checkpoint，避免把 fetch 之后新追加的通知误标记为已处理
-- 若当前批次的 `fetch.hasMore = true`，继续处理同一天的下一批，不要提前切换到下一个日期
-- 若 `commit.hasMore = true` 但当前 `committedIndex >= targetEndIndex`，说明 fetch 之后有新通知追加；不要追入本次循环，进入下一个选中日期，并在最终汇报中说明新追加通知会留待下次同步
-- 只有当当前批次的 `fetch.hasMore = false`，并且当前批次已提交到 `targetEndIndex` 后，才进入下一个日期
-
-循环处理：
-- 对每个日期，必须完整执行 `2.1 -> 2.2 -> 2.3`
-- 同一天内若存在多个批次，每个批次都必须执行一次完整的 `2.1 -> 2.3`
-- 只有当前日期所有批次都完整执行完 `2.1 -> 2.3` 后，才能进入下一个日期

package/skills/notification-to-memory/references/step-3-check-cron-status.md

@@ -1,38 +0,0 @@
-# Cron 检查说明
-
-在最终汇报前，必须检查 cron 配置；未检查不得结束。
-
-这里检查的范围只包括“根据通知更新记忆”相关的定时任务，不要把其他无关 cron 任务算作已配置。
-
-可判定为相关任务的示例：
-- 每天凌晨3点根据通知更新记忆
-
-不可判定为相关任务的示例：
-- 仅做天气播报、日历提醒、灯控巡检、录音整理、新闻订阅等与通知记忆无关的 cron 任务
-- 虽然名字里带有 `sync` 或 `memory`，但消息内容并不是“根据通知更新记忆”的 cron 任务
-
-## 使用 CLI 检查：
-
-Exec 调用规则：等待 CLI 命令输出时使用 `yieldMs: 60000`；不要用 `timeout` 作为等待时间。`timeout` 是按秒计算的杀进程上限，默认 1800 秒，除非明确需要终止长时间运行的命令，否则不要写。
-
-```text
-Use exec with:
-command: bash -c 'openclaw cron list'
-yieldMs: 60000
-```
-
-
-场景 A：已有通知同步相关定时任务
-- 确认配置存在，并记录：`CRON: 已检查（已配置）`
-- 可选提示：已配置根据通知自动同步更新记忆的定时任务
-
-场景 B：没有相关定时任务
-- 中间处理阶段不要向用户输出建议话术
-- 仅记录状态，等待最终汇报统一输出
-- 记录：`CRON: 已检查（未配置）`
-
-场景 C：cron 命令执行失败或无法读取
-- 明确记录检查失败原因
-- 中间处理阶段不要向用户输出建议话术
-- 等待最终汇报统一输出
-- 记录：`CRON: 检查失败（原因）`

package/skills/notification-to-memory/references/step-4-final-reporting.md

@@ -1,57 +0,0 @@
-# 最终汇报说明
-
-本次范围内所有日期处理完成且 cron 检查完成后，进入汇报输出。
-
-## 判断执行环境
-
-- 如果是在主对话中：直接输出汇报内容，不要调用 `message` 工具。
-- 如果是子任务或独立执行环境，且已有明确的 `sessionKey`、`chat_id` 或其他可用会话目标：使用 `message` 工具发送汇报。
-- 如果是子任务或独立执行环境，但没有明确会话目标或 gateway/message 鉴权不可用：直接输出汇报内容，不要为了自动推断会话而调用 `message` 工具。
-
-禁止行为：
-- 不要调用不带 target 的 `message` 工具来自动推断会话。
-- 不要因为汇报发送失败而重试等待；改为直接输出最终汇报。
-
-## 汇报内容格式
-
-### 情况一：本次范围已全部处理完
-
-```text
-📋 通知同步完成
-
-共处理了 X 个日期的 Y 条通知：
-- 2026-03-02: 2 条
-- 2026-01-12: 1 条
-
-CRON: 已检查（已配置 / 未配置 / 检查失败）
-```
-
-### 情况二：本回合达到批次上限、仍有剩余（未跑完）
-
-当本回合因达到“单回合最多 3 个批次”的上限而停止、`selectedPending` 仍有未处理通知时，按下面格式汇报，并明确告知会续传，不要表述为“全部完成”：
-
-```text
-📋 通知同步进行中
-
-本回合已处理 Y 条通知，还剩约 M 条未处理。
-为避免单次处理过久，剩余部分将由定时任务自动继续；你也可以再说一次“继续同步通知”立即接着处理。
-
-CRON: 已检查（已配置 / 未配置 / 检查失败）
-```
-
-仅当 CRON 为“未配置”或“检查失败”时，追加以下建议话术：
-- 💡 建议：设置定时任务
-- 目前每次都需要你手动说"同步通知"。建议添加定时任务，我会定时同步通知数据到长期记忆中。
-- 你可以这样说："每天凌晨3点帮我根据通知更新记忆"
-
-
-## 结束条件
-
-满足以下任一“处理结束”条件即可进入汇报：
-- 本次 `selectedPending` 范围内的日期均已通过 checkpoint 标记完成（→ 用情况一汇报）；若 scan 中还有未选中的历史日期，不得为了满足结束条件继续处理它们，只需在汇报中说明仍有其他日期未处理
-- 本回合已达到“单回合最多 3 个批次”的上限（→ 用情况二汇报）；当前批次已在 Step 2.3 提交 checkpoint，剩余通知留待续传
-
-同时必须满足：
-- 已执行 cron 检查，并在最终汇报中包含 CRON 状态行
-- 已按执行环境完成汇报
-- 若 CRON 为“未配置”或“检查失败”，最终汇报中必须包含建议话术与固定示例句 `"每天凌晨3点帮我根据通知更新记忆"`

package/skills/notification-to-memory/scripts/select-memory-prompt.sh

@@ -1,18 +0,0 @@
-#!/bin/bash
-
-set -euo pipefail
-
-PLUGIN_KEYWORD="memory-lancedb-ultra"
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-SKILL_DIR="$(cd "${SCRIPT_DIR}/.." && pwd)"
-
-PLUGIN_MATCH="$(openclaw plugins list 2>/dev/null | grep -i "${PLUGIN_KEYWORD}" || true)"
-
-if [ -n "${PLUGIN_MATCH}" ] && ! echo "${PLUGIN_MATCH}" | grep -qi "disabled"; then
-  printf '%s\n' "references/write-memory-lancedb-plugin.md"
-  exit 0
-fi
-
-printf '%s\n' "references/write-memory-openclaw-native.md"
-exit 0