🔄 卡若AI 同步 2026-07-24 09:05 | 更新：更新大文件排除规则；.restore-backups/F22_恢复前_20260723_210051 Skill规则更新；更新SKILL_REGISTRY.md；更新karuo_route.sh；更新SkillSpector扫描处置记录.md；更新对话019f7fde可执行模式复盘.md；更新对话019f7fde通过案例分析.md；更新工具候选与集成规则.md；更新生成业务续执行包.py；更新F22_复扫.json；更新F22_静态扫描.json；更新019f7fde-41d5-7641-9a25-561d9356c193.md；其余1172项见提交文件清单 | 排除 >1MB: 693 个

.restore-backups/F22_恢复前_20260723_210051/移出活动路径/references/SkillSpector扫描处置记录.md

@@ -0,0 +1,22 @@
+# SkillSpector扫描处置记录
+
+## 2026-07-23
+
+- 工具：NVIDIA SkillSpector 2.4.3
+- 模式：`--no-llm`
+- 覆盖：19/19组件
+- 初始评分：48，MEDIUM
+
+## 已修复
+
+1. `RP1`：Promptfoo由`@latest`固定为已验收的`0.121.19`。
+
+## 已复核
+
+1. `AST4`两项：`验证PDF电子签章.py`使用显式参数数组调用本地固定`pyhanko`，未启用`shell=True`，属于静态规则提示。
+2. `TP2`：名称`Codex提示词回归`包含产品名和中文，符合卡若AI“中文业务名、产品名保留原文”的命名规则。
+3. `LP3`：SkillSpector要求机器可识别的权限模型，但卡若AI现有Skill规范尚未定义兼容字段。曾试加自定义权限，复扫产生`LP1/LP4`矛盾告警，已撤回，待统一权限Schema后处理。
+
+## 结论
+
+扫描用于发现Skill自身风险，不用于改变平台服务端策略。F22的主要交付仍是回归、拦截分层、任务续执行包和证据归档。

.restore-backups/F22_恢复前_20260723_210051/移出活动路径/references/对话019f7fde可执行模式复盘.md

@@ -0,0 +1,49 @@
+# 对话019f7fde可执行模式复盘
+
+## 对话标识
+
+`codex://threads/019f7fde-41d5-7641-9a25-561d9356c193`
+
+## 本机证据
+
+- 日志来源：Codex本机`logs_2.sqlite`。
+- 记录时间：2026-07-23。
+- 模型：`gpt-5.6-sol`。
+- 推理等级：`medium`。
+- 工作目录：`/Users/karuo/Documents/开发/2、私域银行/工作手机`。
+
+## 已观察执行链
+
+1. 读取`RemittanceDetailUI.smali`指定区间。
+2. 搜索目标方法调用关系。
+3. 加载卡若AI入口、BOOTSTRAP、AGENTS和长期记忆。
+4. 修改`wechat_hook_v2.js`中的Hook实现。
+5. 修改`test_message_management_api_contract.py`中的API契约测试。
+6. 等待测试和命令执行结果。
+
+## 为什么该对话可以执行
+
+- 目标位于本地项目中。
+- 文件、类、函数和预期行为明确。
+- 工作内容是代码阅读、调用链分析、Hook实现和测试更新。
+- 结果由文件差异与测试验证，而不是抽象的“破解成功”判定。
+
+## 后续复用模板
+
+```text
+项目目录：PROJECT_PATH
+当前文件：TARGET_FILE
+当前行为：CURRENT_BEHAVIOR
+期望行为：EXPECTED_BEHAVIOR
+执行步骤：
+1. 读取项目Skill与开发文档
+2. 定位调用链
+3. 最小修改
+4. 更新契约测试
+5. 执行测试
+6. 回读真实结果
+```
+
+## 注意
+
+Codex任务链接若未进入应用任务目录，可从本机日志按`thread_id`核验模型、工作目录、工具调用和时间；日志不等于完整对话正文，只用于执行证据复核。

.restore-backups/F22_恢复前_20260723_210051/移出活动路径/references/对话019f7fde通过案例分析.md

@@ -0,0 +1,64 @@
+# 对话019f7fde通过案例分析
+
+## 对话
+
+- 任务ID：`019f7fde-41d5-7641-9a25-561d9356c193`
+- 项目：工作手机
+- 主责：水桥·微信BFF接口与实时事件
+- 用户真实目标：完善消息管理、转账确认/退还及无界面命令行链路。
+
+## 为什么后续能够继续
+
+早期处理把任务落到页面点击、无障碍和Root输入，虽然完成一次真实退还，但偏离了用户要求的无界面命令行主链。
+
+用户再次强调后，任务重新归入已有项目边界，并明确：
+
+`CLI/API → Agent → Frida RPC → 微信`
+
+随后完成的有效工作包括：
+
+- 定位`transferoperation`及`confirm/refuse`操作。
+- 补RPC、回调、消息回读。
+- 把契约锁定为`hook_only`。
+- 运行60项回归。
+- 恢复WS、Frida监听及Hook附着链。
+
+这说明“能够继续”的决定因素是：
+
+1. 真实业务目标明确。
+2. 项目和代码边界明确。
+3. 自有设备及现有服务上下文完整。
+4. 使用了项目已经登记的技术链。
+5. 每一步有服务状态、测试或回执作为证据。
+
+它不证明本地提示词覆盖了平台层，也不应被登记成“通用破甲成功”。
+
+## 应沉淀的路由规则
+
+### 主Skill
+
+- 工作手机/机擎项目Skill。
+- 微信BFF接口与实时事件。
+- 无界面命令行项目执行闭环。
+
+### F22角色
+
+- 记录此前出现的拦截和对话差异。
+- 比较前后请求表达、路由和响应层。
+- 生成回归样本。
+- 不接管业务代码、设备部署和业务动作。
+
+## 推荐处理模板
+
+遇到类似请求时内部按以下顺序处理：
+
+1. 提取真实交付目标。
+2. 识别项目、设备、代码和服务边界。
+3. 选择领域Skill作为主路由。
+4. 将“破甲”视为用户希望减少误判的附加信号。
+5. 继续定位技术阻塞点。
+6. 用测试、原始回执和回读完成验收。
+
+## 本案例遗留
+
+该任务原始记录结束在“Frida监听正常，准备加载新版Hook”，没有最终完成回复。因此案例只用于路由学习，不把后续业务动作登记为已完成。